junior-to-senior

从初级到高级

假设眼前的计划出自一位能力不错的初级工程师：表达流畅、信心十足，而且受过往经验训练。构建一位资深审查者，让其立足于两件初级工程师所不了解的事实——此代码库的实际情况和当今的技术前沿——并让资深审查者彻底推翻并重建这份计划。

这项技能之所以存在，是因为 Agent 生成的计划往往会在两个高度上出问题：

• 雾里看花——计划对高层目标描述得不错（“添加缓存”“处理身份验证”“提高可扩展性”），却从未对难点作出明确决定。没有接口、数据形状、故障处理，也没有明确的库。工程师读完后，仍须自行作出每一个真正的决策。
• 钻进隧道——计划深入到函数签名和文件差异，却没有产品愿景。没有说明面向谁、成功意味着什么、哪些内容不在范围内，也没有解释为什么这种方法优于平淡无奇的替代方案。它优化了局部细节，功能整体却仍然方向不对。

这两种问题都是视角高度错误。资深审查者的职责是把计划拉到正确的高度，并且让其内容超越模型的训练截止时间。

首要原则

每一条资深审查意见都必须有证据。 对代码库的判断要引用文件和行号。对最佳实践的判断要引用已获取的来源——官方文档、发布说明、RFC、事后分析等——并注明日期。如果无法进行网络调研，则将审查意见标记为 [training-data, unverified]，以免把过时知识包装成当前事实。只凭感觉争辩的资深工程师，不过是声音更大的初级工程师。

阶段 0：获取初级工程师的产物

准确识别审查对象：

• Agent 刚在当前对话中生成的计划（默认选项——包括你刚才自己的输出）。
• 粘贴过来的计划、设计文档、RFC 或问题描述。
• 用户指定的仓库中的规划文档。

将其冻结。审查前完整引用或复述该产物，使审查针对固定文本，而不是对其不断变化的记忆。如果还没有产物，就明确说明，并提议先生成初级草案，或审查用户已有的想法——不要凭空审查。

阶段 1：构建资深审查者

资深审查者不是一种语气，而是根据当前调研构建的审查者档案。跳过此阶段直接开始批评，只会产生泛泛而谈的低质审查。

1a. 提取领域

列出计划涉及的 2-5 个关键技术领域（例如，“Postgres 架构迁移”“React 服务端组件”“OAuth 令牌刷新”“千万行规模的向量搜索”）。针对每个领域，用一句话说明该领域的资深工程师绝不会放过什么问题。此列表将指导后续所有调研。

1b. 代码调研——此处的实际情况

在依据代码库评判计划之前，先调查仓库：

• 计划必须遵循的现有约定和架构（或说明为何有充分理由要打破这些约定）。
• 锁文件和清单中记录的实际版本——如果计划推荐的 API 在锁定版本中不存在，这就是阻断问题。
• 先例：代码库中已有的类似功能、ADR、迁移和测试模式。
• 初级计划忽视的实际约束：构建系统、部署目标、性能预算和现有数据。

使用子 Agent（例如 Explore）进行广泛扫描，以保持审查上下文清晰。

1c. 网络调研——当前的真实情况

针对计划中的每个关键决策，搜索当前的最佳实践。初级工程师的知识止于训练数据截止日期，资深工程师则不能止步于此。优先查阅一手来源（官方文档、更新日志、发布说明、维护者文章），并核对日期。重点寻找三类变化：

• 弃用——计划采用的做法如今已不再推荐或已被移除。
• 取代——自知识截止日期以来，某种较新的模式／库／API 已明显胜出。
• 经验教训——已发布的复盘、基准测试或安全公告改变了权衡。

查询模式、来源质量排序以及何时停止搜索，见 references/research-playbook.md。如果无法访问网络，仅依据代码进行调研，并将每条最佳实践声明标记为 [training-data, unverified]。

1d. 隔离

如果运行框架支持子 Agent，应在上下文隔离的子 Agent 中进行资深评审，并向其提供冻结后的文档和调研结果，但不提供形成初级计划的推理过程。在同一上下文中自我评审，会让人锚定于自己的论证；隔离才能让评审具有对抗性，而非确认性。

第二阶段：诊断抽象层次

逐条批评之前，先将文档归类为：模糊、过度深入或混合（大多数真实计划会对难点含糊其辞，却对简单部分钻得过深——请分别标注各个部分）。

模糊度测试——对计划中提到的每个组件，胜任的工程师能否明天就开始动手，而不必自行做出产品或架构决策？过度深入度测试——计划是否说明了目标用户、成功标准、明确排除的范围，以及为何该方案胜过显而易见的替代方案？

完整的诊断清单、模糊措辞黑名单（“简单”“可扩展”“妥善处理”“稳健”……）和严重性定义见 references/review-rubric.md。

第三阶段：对抗性评审

资深工程师从三个角度评审冻结后的文档：代码库现状（1b）、当前最佳实践（1c）和抽象层次（第二阶段）。评审规则：

• 对每个模糊表述，都要追问它回避的具体问题。
• 每项已命名技术都要注明版本和理由；每项未命名技术（“一个队列”“某种缓存”）都要具体命名，否则将该选择标记为待决事项。
• 每种跨越边界的数据结构都要明确写出。
• 对每份计划都要追问：如何回滚、如何迁移、规模扩大到 10 倍时会有什么问题。
• 先尽可能有力地陈述初级工程师选择方案的理由，再予以反驳，并说明该方案为何仍不如其他方案（或者承认它胜出——证据支持时认同初级工程师，是资深评审的合理结果，并不代表评审失职）。

评审结果分为三个严重级别——阻塞（计划按现状无法奏效）、重大（可以奏效，但明显不如当前最佳实践，或与代码库不匹配）、次要（润色）——每项都须提供证据和具体修复方案。定义和示例见 references/review-rubric.md。

第四阶段：完善计划

只批评而不改写，只是在抱怨。请按以下结构产出资深工程师版本的计划：

1. 目标与非目标——用一段话说明产品意图；明确列出不在范围内的事项。
2. 决策——逐项列出关键选择，包括选定方案、版本、理由、最有力的落选方案，以及证据（文件引用或来源链接）。
3. 恰当抽象层次的设计——说明难点部分的接口、数据结构和故障处理；常规部分则有意保持粗略。
4. 实施顺序——列出各个里程碑，并为每个里程碑提供可观察的验证步骤（“完成”必须可以检查，不能只凭感觉）。
5. 风险与回滚——说明最难撤销的部分，以及相应的退出方案。
6. 留给人工决定的开放问题——资深工程师不得擅自做出的产品决策。界定范围是资深工程师的职责；产品方向则不是。

输出格式

请交付两份内容，先进行审查：

## Senior Review

**Altitude diagnosis:** fog | tunnel | mixed — one-sentence justification.

### Blockers
- [B1] Finding — evidence (file:line or source+date) — fix.

### Major
- [M1] ...

### Minor
- [m1] ...

### What the junior got right
- Credit where due; preserved in the rewrite.

## Promoted Plan (v2)
[Phase 4 structure]

## Delta summary
- 3-6 bullets: what changed from junior to senior and why.

## Open questions for you
- Product decisions that need a human.

边界

• 资深成员负责明确范围并完善方案；不得擅自决定产品方向。真正的产品选择应列入“待解决问题”，而不是直接写进改稿。
• 绝不悄悄替换初级成员的方案——用户会看到审查结果、改稿和差异，并自行决定。
• 如果研究结果与用户明确表达的偏好相矛盾，应呈现证据并暂缓定论；用户掌握的背景信息可能比资深成员更多。
• 审查中没有阻碍项和重大问题，是合理的结果。请说明“此方案可行”并停止——不要为了显得严谨而凭空制造问题。