多镜头回顾

一个 review pass 为什么会漏 bug

普通的代码审查通常是一次走完：读一遍 diff，凭经验扫一眼，然后写几句评论。问题在于，这一次「通用视角」的 pass 里，所有判断都来自同一个认知框架。安全意识强的工程师会盯着输入处理，逻辑敏感的人会盯不变量，但两组人在同一段代码上看到的盲区并不重叠——真正的 bug 往往藏在这些盲区的交集里。

多镜头回顾要解决的就是这件事：与其让一个人反复重读同一行代码，不如把审查拆成几个职责明确的独立 pass，各自带着不同框架去看同一个 diff，最后把结果收敛成一份可复用的产物。

技能如何工作

默认使用三个镜头，除非任务明显需要别的组合：

• Correctness — 逻辑错误、被破坏的不变量、与需求不符的实现
• Security — 不安全的输入处理、密钥泄漏、鉴权/认证漂移
• Test Coverage — 缺失的回归测试、未被覆盖的边界条件

流程上大致分几步：

1. 准备共享上下文：建一个工作目录，写一份 input.md 总结改了什么、PR 声称做了什么、审查范围是什么。所有镜头先读这份上下文，避免各自重新摸一遍仓库。
2. 跑三遍聚焦 pass：运行时支持并行子代理就 fan out，否则串行执行，但每一遍都要保持狭窄——安全 pass 开始谈代码风格，就是跑偏了。
3. 规范化与去重：每个镜头的输出统一转成结构化 schema，包含 category、severity、file_path、line、evidence、confidence 等字段。没有 file + line 证据的结论直接丢弃，低于 0.6 置信度且没有后续 pass 救回的也丢掉。
4. 验证幸存者：对每条幸存 finding 重新读一遍相关代码，仍不确定就先走一次便宜的澄清，只有看起来确实 material 的才升级到昂贵的深度审查。
5. 持久化并输出：把确认过的结论写进 JSON 文件或项目追踪系统，按严重程度排序输出，并明确说明检查了什么、没检查什么。

适用边界与注意点

适合用的时候：diff 不算小、有风险，你需要的是 findings 而不是一份「看起来没问题」的总结，或者单次审查明显容易漏东西。

可以跳过的时候：diff 很小且机械，用户只要轻量总结，或者已经有了一套人工评审过的可靠结论只需要复述。

几个容易踩的坑，原文档里列为 anti-pattern：

• 跑三遍一模一样的通用 review 就叫「多镜头」——每遍必须有自己的明确职责和范围约束。
• 把所有原始 finding 都持久化——只存去重和验证后幸存下来的。
• 每个镜头都去重读整个仓库——先准备好紧凑的 input.md 再分发。
• 一上来就加六七个镜头——先跑默认的三个，真漏了重要问题再补第四个针对性的。
• 对每条候选都用昂贵的深度审查——先用便宜的重新读代码来验证，再决定是否升级。

最终产物的价值在于：比单次 pass 抓住更多真实 bug，噪声更少，而且留下一个可跨会话恢复的 run 目录。