Anthropic 在 Claude 写下 Claude Code 约 90% 代码后如何重新设计代码评审

当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审 ？

Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注意力只花在真正需要判断力的地方。核心转变是：从“这段代码有人看过吗”变成“这个变更可能出什么问题，哪种检查（自动或人工）最适合抓住它”。
https://claude.dev/blog/solving-code-review-at-anthropic/

为什么必须改？

背景数字：2026 年 6 月到 9 月，合并的 PR 数量翻倍以上，而 revert 率下降超 40%。传统的“同事互相读 diff”模式在这个吞吐量下会先崩溃；人要么变成瓶颈，要么敷衍放行。

团队对成本的认识很清醒：人力时间 = 评审时间 + 修复坏代码的时间，压缩一头只会把成本转移到另一头。所以他们不追踪“评审覆盖率”这种虚荣指标，而转去追踪 “每个 PR 平均几个人类审批” 和 “等人审批的等待时间”，并以 revert 率 / 事故率作为护栏指标；目标是最多一个人在环（有时只有作者本人），且事故不比以前多。

七层防线：一个变更的一生

1. PR 之前的自我验证 — Claude 必须出示证据（测试输出、构建、截图）而不是声称完成；再用一个全新上下文的第二个 agent 审 diff。Boris Cherny（Claude Code 创造者）认为给 Claude 一个验证方法是“最重要的事”，效果提升 2–3 倍。反复出现的问题会被固化到源头：写进 CLAUDE.md（项目约定）和 REVIEW.md（给代码主人看的指引——失败长什么样、nit 上限、哪些路径跳过，且每条发现必须附文件/行号证据）。

2. 每个 PR 必过 AI 评审 — 内部 PR 上“实质性评审意见”占比从 16% 升到 54%；千行以上的大 PR 几乎总能查出问题。多个 agent 并行找 bug，再有 verifier agent 对每条发现投票才发出。发现分为 Important / Nit / Pre-existing，每条必须解决或说明理由。

3. 阻塞性的安全评审 — 独立的自动化通道，有未处理发现就不能合并。

4. 阻塞性的自动检查 — lint、类型、跨平台测试、构建；PR 模板强制填写“如何测试的”和“如何回滚”，且需一人签字。

5. 基于风险的人工审批 — 分类器定级：低风险（文档、文案）不需人工；中风险（普通产品变更，及缓存、自动更新器、系统提示词等敏感区）一人；高风险两人。关键规则：agent 的批准永远不能算人工批准；批准只覆盖一个 commit，有新提交就要重新审批。

6. 合并队列 + 特性开关 + 灰度 — 针对合并后 main 重跑检查；新行为先给 Anthropic 内部员工，再走 latest channel，最后进 stable。

7. 快速检测与回滚 — 开关无需重新部署即可关闭；事故复盘必问“哪一层本该拦住它”。

两个最有参考价值的工程细节

1. 评审器本身也是被持续评测的系统。 过去引发事故的 PR（经专家确认）构成一个 eval 集，评审器每天跑分，只有分数提升的改动才被保留；噪声则通过“人对评论的反应”和“在已知干净的 PR 上跑评审器”来度量。这本质上是把“评审质量”从主观感受变成了可优化的目标函数。

2. 收敛问题的解法。 曾有一个 agent 写的 CLI PR 一夜跑了 50+ 轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就存在；评审 agent 在翻旧账而不是审新变更。修复手段：三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、标记 bug 类别而非单行、禁止重复发现。效果：一轮通过率 65%→78%，5 轮以上 PR 从 8.9% 降到 1.5%，平均评审轮次 2.08→1.32。这是 AI 评审 AI 代码时特有的“死循环”问题，他们的解法值得所有引入 AI reviewer 的团队抄作业。

人类还留在哪里？

· 该不该做：方向、品味、范围；
· 高危代码：计费、自动更新器、CI 工作流；
· 可被复制模仿的架构决策；
· 读证据：测试输出、截图、发现列表；
· 为结果负责：每个上线变更背后必须有一个承担问责的人。