AI 写的代码谁来评审？Anthropic 推倒重来的三个设计

6 月到 9 月，Anthropic 仓库里合并的 PR 数量翻了一倍多，回滚比例反而降了 40% 以上；评审里的实质性意见占比从 16% 涨到 54%。前提是：Claude Code 约 90% 的代码是 Claude 自己写的，monorepo 日均合并量从 5 月的约 2500 次涨到了 9 月的 3 万次以上。

把这轮冲击看成三部曲的话，这是第三章：CI 先被压垮，git 被自研的 Scion 换掉，现在轮到评审和合并。原文是 Anthropic 工程博客的 How the Claude Code team does code review。

评审的问题被重新定义了

旧问题：「有没有人认真读过这段代码？」

新问题：「这次改动可能出什么问题，应该由哪项自动检查或人工检查来发现？」

问题一换，评审就不再是流程末尾的一道关卡，而是一套持续运行的防线。人的时间被定义为「评审时间 + 修复坏代码时间」之和——只减前者、把成本挪给后者，等于没省。目标是大多数 PR 最多一名人类参与就能合并；硬约束是回滚率和事故率不能涨。

设计一：风险分级审批

不是所有改动都需要人。Anthropic 按风险分了三档：

• 低风险（文档、文案、内部功能、藏在功能开关后的改动）：自动检查通过，免人工。
• 中风险（一般产品改动，以及缓存、自动更新器、系统提示词等敏感区）：1 人批准。
• 高风险（最高风险代码、少数固定双人路径）：2 人批准。

三个细节是这套制度的骨头：

1. 风险由改动本身定级，不由作者定级。 分类器读 diff 决定等级，第二个分类器再判断是否还需要额外的人。敏感路径和任何 CI 工作流文件永远要人工。
2. Agent 的批准永远不算人的批准。 你可以指挥 Agent 去批一个 Agent 的 PR（责任算你头上），但机器人点的那下「Approve」不作数。
3. 一次批准只绑定一个 commit。 新提交、解冲突之后，之前的批准作废，重新来。

还有一个顺序问题：先严格（宁可多要人），有证据之后再放宽。反过来做——先松后紧——攒下的隐患很难回收信任。

设计二：让评审器收敛

Agent 评审最大的坑，是它和写码 Agent 会互相喂养。真实事故：一个 CLI 的 PR，一夜之间经历了 50 多轮评审 + 修复。

用 git blame 追查后发现：评审器反复指出的问题里，约 59% 在第一轮就存在——它不是在找新 bug，是在重复念叨旧问题。

收敛四招：

1. 轮数上限：3 轮之后请作者停下来，重新考虑方案，而不是继续磨。
2. 只复审新增 diff：最初几轮之后，别再全量重读。
3. 指出一整类 bug，要求把同类全部修掉，而不是一次报一个。
4. 不重复发布已经提过的问题。

效果：一轮通过率 65% → 78%；需要五轮以上的比例 8.9% → 1.5%；平均评审次数 2.08 → 1.32。

对用 Agent 的人来说，这点特别值得记：人类评审的噪声是「浪费阅读时间」，Agent 评审的噪声是「触发多余的修复循环」——不显式优化收敛，烧的是算力和时间，指数级的。

设计三：把事故变成评测集

评审器本身也被当成一个持续评测的工程对象：

• 每一次事故、回滚，经工程师核实后，变成评测案例。
• 评审器每天在案例全集上跑分，改动只有在分数提高时才保留。
• 噪声要量化：按 PR 参与者的回应把评论分类（真修复 / 误判 / 有意设计 / 无关紧要）；再拿已知没问题的 PR 去测评审器会不会「诱人做有害修改」。
• 优先级明确：先发现真实 bug，再减少评审轮次。别为了数字好看先砍轮数。

底牌：撤销比防错便宜

七个环节连成一条链：提交前验证 → 必需 CI → AI 评审 → 安全评审 → 风险分级人工审批 → 合并队列 + 功能开关 + 渐进发布 → 快速回滚。

每一层都能发现一些问题，也都会漏掉另一些。很少有问题的能穿过所有层——剩下的，交给回滚。功能开关一关不用重新部署；合并队列防止两个「各自通过」的 PR 合到一起弄坏主干。

这套东西能成立的前提是：纠错的重心从「评审不漏」换成了「错了能快速撤掉」。撤销足够便宜，审批才敢降到「最多一名人类」。

个人开发者和小团队能抄什么

不需要任何平台改造的三件事：

1. 提交前，让一个全新上下文的子 Agent 评审 diff（不共享你写代码时的对话历史）。
2. 写一份 REVIEW.md，哪怕只有 10 行：这个仓库的「失败」长什么样、要求带文件和行号的证据、摘要先报问题数量。
3. 设评审轮数上限：3 轮之后停下重新想方案。

再加两条心法：

• 评审反复指出同一类问题？去改指令文件或 lint 规则，别修个案。
• 衡量省没省时间，盯住回滚率和事故率：它们涨了，说明你只是把成本从评审挪到了修复。

需要说明：以上数据是 Anthropic 自述口径，未独立验证；信任名单、分类器的具体实现没有公开；他们的仓库规模和大多数团队也不同——抄制度，别抄配置。

可拿走的

1. 评审的问题从「谁读了」改成「问题该由哪层发现」。
2. 审批按改动风险分级，不按人；机器批准不算人批准；批准绑定 commit。
3. Agent 评审必须设收敛机制，否则会无限循环烧算力。
4. 事故别只写复盘，把它变成评测集。
5. 最划算的投资是让撤销变便宜。