当 agent 生成的计划、设计或架构显得含糊或陷入细节时…

把 agent 写出的计划当作初级工程师作品，通过代码库调研与联网调研构建资深评审者，诊断高度失误并重写计划。

适用场景

解决思路

1. 冻结待评审的初级产物：确认评审对象是本次对话中 agent 刚生成的计划（默认，包括自己刚才的输出）、用户粘贴的计划/设计文档/RFC/issue 描述，或用户指定的仓库内规划文档；在评审前完整引用或复述该产物，确保评审针对固定文本而非移动的记忆；若尚无产物，明确说明并提供先生成初级草稿或评审用户现有想法，不要凭空评审。
2. 提取承重技术领域：列出计划涉及的 2-5 个承重技术领域（如 "Postgres schema migration"、"React server components"、"OAuth token refresh"、"vector search at 10M rows"），并为每个领域写一句话说明该领域资深工程师绝不会放过什么，以此驱动后续所有调研。
3. 做代码调研——弄清此处何为真实：调查仓库既有约定与架构（计划必须契合，或明确说明为何要打破并给出理由）、lockfile/manifest 中的实际版本（若计划推荐的 API 在锁定版本中不存在则为 blocker）、既有类似功能/ADR/迁移/测试模式等先例，以及初级计划忽略的真实约束（构建系统、部署目标、性能预算、既有数据）；用子代理（如 Explore）做大范围扫描以保持评审上下文干净。
4. 做联网调研——弄清当下何为真实：针对计划中每个承重决策搜索当前最佳实践，优先一手来源（官方文档、changelog、release notes、维护者帖子）并核对日期，重点找三类差异——弃用（计划做法现已被劝阻或移除）、取代（训练截止后已有更新的模式/库/API 明显胜出）、血泪教训（已发布的 postmortem、benchmark 或安全公告改变了权衡）；查询模式、来源质量排序与停止时机见 references/research-playbook.md；若无法联网，则仅凭代码调研继续，并把每条最佳实践主张标注为 [training-data, unverified]。
5. 隔离评审：当 harness 支持子代理时，在上下文隔离的子代理中运行资深评审，只向其提供冻结的产物与调研发现，不提供产生初级计划的推理过程；同上下文自审会锚定在自己的理由上，隔离才能让评审具有对抗性而非确认性。
6. 诊断高度：在逐行批评前，将产物分类为 fog、tunnel 或 mixed（多数真实计划在难处 fog、在易处 tunnel，需逐节标注）；fog 测试——对计划点名的每个组件，一位有能力的工程师明天能否在不自行做产品或架构决策的情况下开工？tunnel 测试——计划是否说明面向谁、成功是什么样、明确不在范围内的是什么、以及为何该方案胜过显而易见的替代方案？完整诊断清单、含糊词黑名单（"simple"、"scalable"、"handle gracefully"、"robust" 等）与严重度定义见 references/review-rubric.md。
7. 执行对抗式评审：资深评审者从三个视角审查冻结产物——代码库现实（1b）、当前最佳实践（1c）、高度（Phase 2）；交战规则：每个含糊措辞都要用它所回避的具体问题来挑战；每个被点名的技术都要有版本和理由，每个未点名者（"a queue"、"some cache"）要么被点名，要么被标为待定决策；每个跨边界的数据形状都要写下来；每个计划都要被问：回滚是什么、迁移是什么、10 倍规模下什么会崩；先钢人再攻击——先陈述初级选择的最强版本，再说明为何它仍会输（或承认它赢——当证据支持初级时同意它是有效的资深结果，而非技能失败）。
8. 按严重度记录发现：blocker（计划按原样会失败）、major（能工作但明显劣于 SOTA 或与仓库不匹配）、minor（打磨），每条都附证据与具体修复方案；定义与示例见 references/review-rubric.md。
9. 重写并提升计划：批评而不重写只是抱怨；产出资深版计划，结构为——1) 目标与非目标：一段产品意图加明确的 out-of-scope 列表；2) 决策：每个承重选择给出所选方案、版本、理由、最强被拒替代方案与证据（文件引用或来源链接）；3) 正确高度的设计：难处给出接口、数据形状与失败处理，常规处刻意粗线条；4) 排序：里程碑各带一个可观察的验证步骤（"done" 必须可检验，而非凭感觉）；5) 风险与回滚：最难撤销的是什么以及逃生通道；6) 留给人类的问题：资深评审者不被允许自行发明的产品决策——划定范围是资深的职责，产品方向不是。
10. 按指定格式交付两份产物，评审在前：## Senior Review（含 Altitude diagnosis: fog | tunnel | mixed 及一句话理由；### Blockers 每条为 [B1] 发现 — 证据（file:line 或 source+date）— 修复；### Major；### Minor；### What the junior got right 保留在重写中）；## Promoted Plan (v2)（按 Phase 4 结构）；## Delta summary（3-6 条，说明从初级到资深改了什么及为什么）；## Open questions for you（需要人类决定的产品决策）。
11. 遵守边界：资深评审者只划定范围并升级，不发明产品方向，真正的产品选择进入 "Open questions" 而非重写；绝不静默替换初级计划——用户要看到评审、重写与差异并自行决定；若调研与用户陈述的偏好冲突，呈现证据并遵从，用户可能拥有资深评审者所缺的上下文；零 blocker 且零 major 的评审是合法结果，直接说 "this plan holds" 并停止，不要为显得严谨而制造发现。

适用边界 · 注意事项

• 尚无任何待评审产物时（不要凭空评审，应先请用户提供或先生成初级草稿）
• 无法联网且仅凭训练数据时，所有最佳实践主张必须标注 [training-data, unverified]，不能当作当前事实
• 涉及产品方向决策时，资深评审者不得自行发明，应放入 Open questions 交人类决定