Anthropic 日合并 3 万个变更：代码审查告别逐行阅读

AI 把写代码的速度拉高以后，代码进入生产环境之前的整条通道最先开始承压。

Anthropic 最近公开了两篇很值得放在一起看的工程文章。一篇讲 Claude Code 团队怎样重做代码审查，另一篇讲他们为什么在五个月内把巨型单体仓库从 Git 迁移到自研的 Scion。

这两篇文章表面上分别讨论 Review 和 Source Control，底层其实是同一个问题：当代码产量从“人类团队规模”跃升到“Agent 规模”，沿用过去的流程，只会把瓶颈从编码环节推到审查、CI、合并和发布环节。

Anthropic 给出的答案相当激进：机器负责大部分阅读和验证，人的注意力集中到风险、意图、架构与责任；底层基础设施也不再坚持每个客户端都拥有完整仓库，而是围绕始终在线的 Agent 重新设计。

这套做法有不少启发，也很容易被误读。它没有宣布“以后不用 Code Review 了”，更没有证明 AI 可以独立承担软件质量责任。它真正改变的是审查的单位、时机和资源分配方式。

代码产量暴涨以后，Review 先成为瓶颈

Claude Code 团队披露，Claude 已经编写其自身大约 90% 的代码。2026 年 6 月到 9 月，Claude Code 代码库合并的 Pull Request 数量翻了一倍多，同期需要回滚的比例下降了 40% 以上。这是两个同期指标，原文没有证明回滚下降是 AI Review 单独造成的；CI、风险审批、灰度和回滚机制也在同时变化。

放到 Anthropic 的 Monorepo，变化更夸张：2026 年 5 月平均每天合并约 2,500 个代码变更，9 月已经超过 30,000 个。

这组数字说明的工程问题很直接。代码生成的边际成本快速下降后，逐行阅读的成本没有同步下降。若仍要求资深工程师按传统方式审查每个 Diff，最终会出现三个结果：

• PR 排队时间越来越长；
• Reviewer 在大量常规问题中消耗注意力；
• 团队为了追赶吞吐量，审查质量逐渐变成形式主义。

常见的应对方式是增加 Reviewer，或者要求 Agent 少写一点。这只能暂时缓解。只要生产代码的能力仍在增长，人工审查就会再次饱和。

Anthropic 因而换了一个衡量方式。他们不再把“是否有人读过每一行”当作质量代理指标，而是问：这个变更可能在哪里出错，哪一种检查最适合发现它？

这句话很朴素，却会把整个流程重新排列。

Code Review 从最终关卡变成持续反馈

传统流程通常是：写完代码，开 PR，等待同事审查。Review 位于工作末端，是一道明确的 Gate。

Claude Code 团队把审查提前到了编码过程。一个典型变更在 PR 创建前，已经经历了几轮验证：

1. Agent 运行测试、构建或截图比对，并展示证据；
2. 一个拥有新上下文的子 Agent 审查 Diff；
3. 内部 Skill 分别检查 Bug、复杂度和端到端行为；
4. UI 变更额外核对设计规范。

核心要求不是让 Claude 声明“已完成”，而是给它一个能够验证结果的环境。命令行任务可以运行测试，前端任务可以操作浏览器或模拟器，视觉改动可以拿截图与设计稿比较。

Boris Cherny 把 Verification 称为获得高质量结果最重要的手段之一，并估计它能让最终结果改善两到三倍。这个数字来自他的经验判断，不能当作通用基准，但背后的工程逻辑成立：没有可执行反馈，Agent 只能靠语言模型内部的概率判断验收自己的输出。

这让 Review 更像编辑器里的拼写检查。问题在代码形成过程中不断暴露，等到人类介入时，常规错误已经被过滤过。

六层检查，加上一层快速回滚

Anthropic 没有押注某个“全能 Reviewer”。他们把质量控制拆成多层，每一层覆盖不同失败模式。

第一层：作者侧验证

Agent 必须运行真实检查，并提供测试输出、构建结果或截图。另一个新上下文 Agent 再看一遍 Diff，避免原作者沿着同一条错误思路自证正确。

重复出现的审查意见会被写回工程系统：

• 项目约束进入 CLAUDE.md；
• 代码所有者关心的失败模式进入 REVIEW.md；
• 机械规则进入 Lint；
• 稳定流程封装为 Skill。

两个文件名只是表象，更值得学习的是这个闭环：一次 Review 评论若反复出现，就不该永远依赖 Reviewer 记忆。

第二层：每个 PR 都做 AI Review

AI Reviewer 会同时读取 Diff、完整仓库和 PR 意图，检查变更是否真的解决问题、是否符合现有系统、是否破坏其他路径。

Anthropic 披露，Code Review 研究预览上线后，收到实质性审查意见的内部 PR 比例从 16% 上升到 54%。大多数超过 1,000 行的 PR 会发现问题，而大部分小 PR 会保持干净。

为了降低幻觉，多组 Agent 并行寻找 Bug，另一组 Agent 对每条发现进行投票。只有获得足够认同的结论才会发布。纯样式、诊断噪音和无关清理会被过滤，剩余意见按严重程度排序。

这相当于把单模型判断升级为一个带验证和聚合的审查管道。成本会更高，但比让人类逐一排查所有可能问题更容易扩展。

第三层：独立安全审查

安全问题单独进入一条自动审查链路。只要 Bug Review 或 Security Review 仍有开放问题，PR 就不能合并。作者需要修复，或者给出关闭 False Positive 的理由。

这种设计避免把安全检查混在一般 Review 中被稀释，也给后续统计留下了结构化记录。

第四层：传统 CI

Lint、类型检查、多平台测试和构建仍然存在。一个普通 CLI PR 可能运行数十项检查。PR 模板还要求说明测试方式和回滚方法。

这点很重要。Anthropic 没有因为使用 Agent 就弱化确定性验证。恰恰相反，Agent 产量越高，机器可执行的验证越重要。

第五层：按变更风险决定人工审批

他们把变更分成三个风险档位：

风险由变更内容决定，而不是作者身份。另一个分类器还会检查某次具体变更是否需要额外人工介入。CI Workflow、所有者标记的敏感路径等区域始终要求人看。

低风险通道也只开放给受信任作者。Agent 的“批准”不能填补人工审批席位。由谁提示 Agent 生成改动，谁就承担这次变更的一份责任。所谓“零额外人工审批”，仍然包含责任人、自动审查、CI、安全检查和上线后的监控，并不等于无人负责。

第六层：合并队列与渐进发布

在独立于 Anthropic Monorepo 的 Claude Code 仓库中，Merge Queue 会把变更应用到最新 Main 后重新运行检查，避免两个独立通过的 PR 组合后破坏主干。

新功能通常先放到 Feature Flag 后，只对内部员工开放，再进入 Latest 渠道，稳定后进入 Stable。这里的质量保障已经跨出 Code Review，延伸到了发布策略。

第七层：快速发现和回滚

仍会有 Bug 穿过所有检查。最后一道防线包括内部使用、遥测、值班和快速回滚。Flag 可以在不重新部署的情况下关闭功能，事故复盘则追问：前面的哪一层本来应该捕获它？

这个思路比“让 Review 保证零缺陷”现实。软件系统无法消灭全部错误，只能降低错误逃逸概率，并缩短发现与恢复时间。

Recall 很重要，收敛更难

AI Reviewer 很容易陷入一个危险循环：找到问题，Agent 修改，Reviewer 再找问题，Agent 再修改。

Claude Code 团队遇到过一个 PR，在无人干预的夜间经历了五十多轮审查和修复。后续分析发现，Reviewer 反复指出的代码中约有 59% 从第一轮开始就已经存在。它并非持续发现新引入的 Bug，而是在每一轮多捞出一点旧问题。

这类系统若只优化 Bug Recall，几乎一定会变成“永不通过”的审查器。尤其当作者也是 Agent 时，一条低价值 Nit 不会被迅速忽略，它会触发新提交、新 CI 和新一轮 Review。

Anthropic 后来加入了几条收敛规则：

• 最多三轮，之后要求作者重新审视方案；
• 前几轮之后只重新审查新增 Diff；
• 报告 Bug 类别，让作者一次修完同类问题；
• 不重复发布已经出现过的 Finding；
• 同时跟踪 Recall 和 Rounds-to-pass。

调整之后，一轮 Review 加修复后通过的比例从 65% 升到 78%，需要至少五轮的比例从 8.9% 降到 1.5%，平均通过所需 Review 次数从 2.08 降到 1.32。这些同样是 Anthropic 的内部数据，但它们比“发了多少条评论”更能反映审查系统是否可用。

这可能是整篇 Code Review 文章中最容易被忽略、也最值得工程团队借鉴的部分。

Agent 系统的成本并不只来自单次模型调用。任何不能收敛的反馈环，都会把微小噪声放大成提交、构建和审查风暴。给循环设置预算、退出条件和升级到人的路径，比继续增加 Reviewer 数量更重要。

事故不只用来复盘，还要进入 Eval

Claude Code 团队把历史事故、Fix-forward 和 Revert 收集成评测集，由熟悉对应代码的工程师确认 Bug 及位置。Reviewer 每天在这套数据上运行，Prompt、工具或模型调整后，也重新评估。

他们还根据 PR 作者怎样处理评论来衡量噪声：修复、判定错误、说明是预期行为，或者认为不值得处理。Reviewer 也会在已知干净的 PR 上运行，检查它是否诱导作者做出有害修改。

这套机制把 Review 从一次性的“模型感觉不错”变成持续校准的工程系统。

许多团队部署 AI Reviewer 后，只统计它发了多少评论。这个指标甚至可能奖励噪声。更合理的指标至少应包括：

• 真实 Bug 的命中率；
• False Positive 及被驳回比例；
• 每个 PR 的 Review 轮数；
• 人工评论和审批数量；
• 等待人工处理的时间；
• Revert 和线上事故率。

Anthropic 把后两项作为 Guardrail：如果人工 Review 时间下降了，但 Revert 和事故增加，只是把成本从审查阶段转移到了生产环境。

人从逐行阅读中退出，留下五类决定

自动化增加以后，人类仍然负责几件机器不擅长的事：

• 这个功能是否值得做；
• 方向、范围和产品品味是否合理；
• 计费、自动更新、CI 等高风险代码是否可接受；
• 某个架构模式是否值得被其他代码复制；
• 测试、截图和 Reviewer Finding 提供的证据是否足够。

责任也留在人手里。无论代码由谁输入，都需要有人对上线结果负责。

这与 Anthropic 在 Scion 项目中的经验一致。参与构建 Scion 的工程师认为 Claude 的编码能力已经超过自己，但人的主要价值仍在系统级理解、约束选择和说“不”。Agent 会为了满足局部模式，违反本来不该突破的架构约束；也会在对抗式审查中对假设风险过度防御，制造多余复杂度。Scion 团队仍审查每个 Change Request，只是更关注变更意图，而非逐行阅读全部代码。

因此，Review 重心从“这行代码是否写对”转向“这个变化是否该存在、约束是否正确、证据是否可信、风险是否被控制”。

为什么 Code Review 的变化会逼出新的 Source Control

Code Review 文章解决的是注意力问题，Scion 文章解决的是吞吐量问题。两者共同面对 Agent 带来的规模变化。

Anthropic 的 Main 分支历史接近 100GB，压缩后的 Working Copy 超过 25GB。CI 每天大约执行 2,500 万次代码 Checkout，还没计算开发环境、Agent Sandbox 和研究任务。按朴素方式获取，Git 流量会超过每天 600PB。

他们曾经运行数百个内部 Git Mirror，并使用浅克隆、稀疏 Checkout、Promisor Remote 和对象存储快照。这些方案争取了时间，但随着仓库和合并速率增长，Mirror 的磁盘、内存和维护成本越来越高。

Scion 的出发点是：绝大多数客户端已经变成始终在线的 Agent 和 Job，Git 为离线、去中心化协作保留的能力，在这个特定工作负载下反而成了扩展负担。

于是 Scion 选择了不同原则：

• 客户端默认在线；
• 服务端负责历史、Blame、Commit、Merge 和 Rebase；
• 客户端只维护有界缓存、工作目录和文件变化监控；
• Commit、Diff、Blame 等能力全部暴露为服务端 API；
• Working Copy 可选，并且天然稀疏；
• Commit 只按变更规模付费，不随整个仓库增长；
• 数据结构与服务可以水平扩展。

这套系统让代码查询和修改不再强制依赖本地完整仓库。CI 如果只需要计算 Diff 或查询祖先关系，可以直接调用 API；Agent 只读取某几个目录，就只物化这些文件。

Anthropic 披露，Scion 各层缓存命中率超过 99%，CPU 和内存基础设施规模相较此前的 Git Mirror 缩小了 200 倍。CI 和研究任务的 Checkout 从分钟级缩短到秒级，CI 获得约 25% 的 CPU 容量收益。

这些数字来自 Anthropic 自己的内部工作负载，缺乏独立验证，也不适合直接外推到普通团队。但它们解释了为什么 Code Review 不能孤立优化：当 Agent 让 PR 数量增长十倍，仓库、CI、Merge Queue 和发布系统都要一起重构。

从 Scion 看 Agent 时代的工程接口

Scion 对多数团队没有直接采用价值。Anthropic 自己也明确表示，它不适合作为 Git 的通用替代品。它面向超大 Monorepo、海量在线 Agent 和极高 Checkout 频率，还依赖自研 Code Review、搜索、IAM 与 CI 生态。

更值得迁移的是三个设计判断。

让机器通过 API 获取事实

传统开发工具常常假设“人在本地仓库里操作”。Agent 更需要结构化、低成本、可组合的服务端接口：查询 Merge Base、获取某段历史、计算 Diff、执行 Revert、定位 Blame。

若 Agent 为回答一个元数据问题，必须先下载几十 GB 仓库，系统接口就没有跟上执行主体的变化。

把全局协调压缩到最少

Scion 中的 Changeset 在服务端创建，数据按内容寻址，尽量减少 Ref 和全局锁。不可变对象可以被任意层缓存，服务更容易水平扩展。

Agent 并发会迅速放大全局锁、单 Merge Queue 和中心化状态更新的成本。在超高吞吐的 Scion Monorepo 中，Anthropic 已无法沿用带全局仓库锁的传统 Merge Queue，于是加强 Post-merge 与 Pre-deploy 自动测试；Claude Code 的独立仓库仍保留 Merge Queue。未来的软件交付系统需要重新评估哪些一致性必须同步获得，哪些结果可以异步计算或延后验证。

Working Copy 不再是所有流程的前提

人的开发体验围绕编辑器和本地文件组织。Agent Workflow 未必需要完整 Working Copy。查询、分析、批量重写甚至部分 Review，都可以直接在服务端数据模型上进行。

这并不意味着本地开发会消失。它说明基础设施应允许“只为任务需要的数据付费”。

普通团队最该学什么

绝大多数团队没有每天 30,000 个变更，也没有理由重写 Git。照搬 Anthropic 的低风险零人工审批，会在缺乏测试、遥测和回滚能力时制造事故。

可迁移的路径应该更保守。

先把验证能力补齐

Agent Review 之前，先让代码拥有可以执行的事实来源：测试、类型检查、Lint、构建、浏览器操作、截图比对和安全扫描。

如果系统无法自动判断改动是否工作，增加 Reviewer Agent 只会获得更多自然语言意见。

把 Review 规则写成可维护资产

建立简短的项目说明和 Review 规则，要求每条 Finding 指向文件、行号和具体失败模式。重复意见进入 Lint、测试或 Skill。

Review Prompt 不该成为无人维护的长文档。规则越短、证据要求越明确，越容易评估 Reviewer 是否真正遵守。

从一个仓库、一类变更开始

先选择测试覆盖较好的仓库，让 AI Reviewer 只做 Finding，不自动批准。持续记录哪些意见被修复、驳回或忽略，观察几周后再扩大范围。

风险分级要建立在变更上

文档修改和支付逻辑不能使用同一审查强度。敏感目录、CI、发布脚本、权限、计费和自动更新应保留人工 Gate。新的提交应使旧批准失效。

给审查循环设置停止条件

限制轮数，后续只看新增 Diff，去重历史 Finding。三轮仍不能通过时，升级为人工检查方案，而不是让两个 Agent 无限互改。

优先建设回滚，而不是追求零错误

Feature Flag、灰度发布、内部先用、遥测、值班和一键回滚，决定了团队能否安全提高吞吐量。若一次发布难以撤销，就不适合大幅降低前置人工审查。

用事故率约束效率指标

可以追求更少的人类审批和更短的等待时间，但必须同时观察 Revert、线上事故和恢复时间。少看代码不等于节省成本，生产环境会把被省略的工作重新收费。

一个更重要的变化：Review 正在成为控制系统

Anthropic 的实践可以概括成一个反馈控制系统：

生成变更
  → 执行验证
  → 多 Agent 审查与交叉确认
  → 按风险分配人工注意力
  → CI 与合并验证
  → 渐进发布
  → 遥测、回滚和事故复盘
  → 更新 Eval、规则、Skill 与检查器

在这个系统里，PR 评论只是其中一个信号。目标是用尽可能少的人类注意力，把变更安全地送入生产，并把每次失败反哺到下一轮检查。

这也解释了为何简单安装一个 AI Reviewer 很难复制 Anthropic 的结果。他们的低人工 Review 建立在高测试覆盖、风险分类、Merge Queue、Feature Flag、内部试用、遥测、值班和快速回滚之上。抽走这些基础，只保留“机器看 Diff”，质量收益会大幅缩水。

工程判断：代码便宜以后，约束会变贵

Anthropic 两篇文章共同传递了一个信号：Agent 将继续降低代码生产成本，但系统约束、验证能力和人的判断不会随之自动扩容。

代码写得越快，越需要清晰的架构边界；PR 越多，越需要可执行的风险策略；Agent 越自主，越需要知道何时停止、何时升级给人；发布越频繁，越需要回滚和事故学习。

未来的工程竞争可能不会取决于哪支团队生成了更多代码。更大的差距来自另一件事：谁能把意图、验证、审查、合并、发布和反馈连成一个会收敛的系统。

人的角色也不会简单消失。逐行检查会减少，方向判断、架构约束、风险承担和系统设计会变得更重。

这是一种更难量化的工作，却可能是 Agent 大规模进入软件工程后，最稀缺的部分。

参考资料

1. Claude Code Team：How the Claude Code team does code review
2. Anthropic Engineering：Redesigning source control for the age of AI agents