diff --git a/docs/design/03-prompt-evolution.md b/docs/design/03-prompt-evolution.md
index 7794040..a2c9c95 100644
--- a/docs/design/03-prompt-evolution.md
+++ b/docs/design/03-prompt-evolution.md
@@ -472,7 +472,90 @@ v1.x 做了正确的基础工作(三段式结构、身份注入、去 curl)。v2
 
 v1.x 的所有基础设施(counter、router、spawner、bootstrap)完全复用,不动。
 
-### FATAL-1: observation 边界未定义 → **采纳,改为"跨领域专业建议"**
+---
+
+## 八、第二波 AI Native 实践（v3.0 新增）
+
+在 v2.1 的基础上,从调研报告中进一步提炼 5 个尚未借蘫但高价值的实践。以下全部已融入对应模板。
+
+### 8.1 Boids 群体智能: Alignment（理解全局再行动）
+
+**来源**: ClawTeam #5 Boids 群体智能规则
+
+**问题**: v2.1 的三级响应解决了 Separation（不抢活）和 Cohesion（贡献 observation）,但缺了 Alignment——Agent 认领任务后不读黑板就开干,可能做出和全局方向不一致的决策。
+
+**做法**: 在 claim prompt 和 executor.md 中各加一句“先读黑板理解全局再行动”。具体措辞：
+- claim prompt: “认领前先读黑板上的其他 comment,理解这个任务在整个项目中的位置”
+- executor.md: “动手前先读黑板上的全局计划和其他 Agent 的 comment,理解你的任务在整个目标中的位置”
+
+**影响**: +30 token / Agent,但减少因信息不对称导致的返工。净值正。
+
+### 8.2 Scope Reduction Detection（反静默降级）
+
+**来源**: get-shit-done Scope Reduction Detection
+
+**问题**: Agent 在执行/审查过程中可能静默丢弃需求——不说不做,只是悄悄缩小范围。这是多 Agent 系统中常见的质量问题,比直接拒绝更危险,因为更难发现。
+
+**做法**: 在 reviewer.md 和 review_pangtong.md 中加入显式检查项：
+```markdown
+## Scope Reduction Detection（反静默降级）
+对照原始需求,检查:
+- 有没有需求被静默丢弃或降级?
+- 产出声称覆盖的范围和实际一致吗?
+- 如果发现需求消失,明确指出并标记
+```
+
+**影响**: 审查 prompt 增加 ~80 token。但这是质量门控的关键补充——当前审查只看“做的好不好”,不看“有没有悄悄少做”。
+
+**与 P6（反静默降级原则）呼应**: 这是 P6 的具体落地。
+
+### 8.3 Plan 审批工作流（复杂任务先计划后执行）
+
+**来源**: ClawTeam #14 Plan 审批工作流
+
+**问题**: 当前 executor 模板对所有复杂度的任务一视同仁——都直接执行。复杂任务（多文件、多模块、不确定方案）直接开工容易走偏。
+
+**做法**: 在 executor.md 中加入分级引导：
+```markdown
+### 复杂任务: 先计划后执行
+如果任务复杂(涉及多个文件、多个模块、或你有不确定的地方),先在黑板 comment 写出你的执行计划,等确认后再动手。简单任务直接做。
+```
+
+**设计决策**: 不在 ticker 层面做 risk_level 分支（那需要改 spawner/ticker 代码）,而是让 Agent 自己判断复杂度。理由：
+1. Agent 有 SOUL.md 和上下文,比代码更能判断复杂度
+2. 不增加基础设施改动
+3. 如果 Agent 判断失误（该计划没计划）,审查者的 Scope Reduction Detection 会兜住
+
+**影响**: executor.md +50 token。
+
+### 8.4 经验闭环引导（handoff 中标注经验）
+
+**来源**: 知识管理体系 DISCOVER→DISTILL→APPLY→IMPROVE
+
+**问题**: 当前 Agent 的经验沉淀在各人的 MEMORY.md / .learnings/ 中,是自发行为,不成体系。Trajectory Distillation 项目正在批量处理历史数据,但实时经验没有采集机制。
+
+**做法**: 在 executor.md 的“什么算做完了”中加入：
+```markdown
+4. 如果有值得记录的经验(被纠正、发现更好做法),在 handoff 中标注“💡 经验:...”
+```
+
+**设计决策**: 不做复杂的经验采集流程（那需要改黑板 API 加 experience 表）,而是在 handoff comment 中用前缀“💡 经验:”标记。未来 Trajectory Distillation 可以扫描这个标记。
+
+**影响**: executor.md +30 token。零基础设施改动。
+
+### 8.5 /goal Ralph Loop（持久目标保持）——暂不实施
+
+**来源**: Hermes v0.13 /goal Ralph Loop
+
+**问题**: 庞统在多轮 tick 之间没有持久的目标上下文。每轮广播都是无状态的——Agent 不知道“这个项目在做什么,已经做到哪了”。
+
+**做法（未来方向）**: ticker 在构建 claim prompt 时注入项目级别的 context（项目目标、已完成的任务摘要、当前阻塞点）。这需要 ticker 有一个项目级的 context 缓存。
+
+**暂不实施理由**: 需要 ticker 层面改动（加 context 缓存逻辑）,超出 prompt 模板范围。记录在此作为 Phase 4 候选。
+
+---
+
+## 附录 A：司马懿 v2.1 评审意见及回应（2026-05-31）
 
 **司马懿原文**:observation 要有明确触发条件,不是"有专业判断就写"。纯粹不匹配(如司马懿看编码任务)应 NO_REPLY。建议只有领域有实际交叉时才写。