Anthropic 如何重做代码审查：让机器读更多 diff，把人的注意力留给风险

本文以 Anthropic 工程团队于 2026 年 10 月 15 日发布的 How the Claude Code team does code review 为主要来源，作者为 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang；并参考宝玉对这套实践的中英文视频介绍。原帖发表于 2026 年 10 月 17 日，包含约 10 分钟英文版和约 9 分 34 秒中文版。团队报告的吞吐、回滚和审查轮次数字是阶段性内部数据，不等于其他组织可以直接复现的结果。

先说结论：代码审查的目标不是让人读完每一行

当 Agent 大量编写代码，变更数量会迅速增加，人工逐行审查很难成为唯一的质量控制手段。Anthropic 团队重新提出的问题是：这次变更可能在哪里出错，自动化还是人工最适合发现它？

因此，他们没有取消审查，而是把审查分散到变更生命周期中：作者先让代码通过可执行验证；AI 对每个 PR 做 diff 审查；安全审查和 CI 可以阻断合并；人按风险决定审批数量；合并后通过 feature flag、渐进发布、监控和回滚控制影响面。

原文报告，Claude Code 代码库在 6 月到 9 月间合并 PR 数量超过翻倍，同时需要回滚的变更占比下降超过 40%。这个结果是该团队的内部阶段性数据。更可迁移的经验是：节省人工审查时间必须同时观察回滚和事故，单看审批变少并不能证明质量没有下降。

一、代码审查有两项工作

原文把代码审查的职责分成两项：

1. 在代码上线前发现并修复问题；
2. 在团队成员之间建立对代码库的共同理解。

机器可以承担更多重复的 diff 阅读和常见缺陷发现，但这会影响团队成员如何学习系统。Anthropic 文中也讨论了第二项职责：成员不必把整个代码库都装进脑中，而是在需要理解某个模块时，让 Claude 针对那一部分生成解释，甚至做一个小型可视化。

这并不意味着人工理解可以省略。它意味着学习应该跟具体任务相连：准备修改某模块的人，先理解相关路径、约束和数据流；而不是把每一个低风险、低信息量的 diff 都当成知识传递的唯一方式。

二、变更生命周期中的七层防线

Anthropic 描述的不是单一 AI reviewer，而是一条有多层检查和回退能力的发布路径。每层会漏掉不同类型的问题，后续层继续接住一部分，最后仍可能漏网，因此需要能快速发现并撤回的机制。

层	发生时间	主要职责	典型机制
1. 提 PR 前验证	本地或 Agent 工作阶段	要求提交者展示实际结果，而不只报告“已完成”	测试、构建、截图对比、端到端验证；用新上下文复核 diff
2. AI 代码审查	每个 PR	对照 diff、仓库和 PR 意图找逻辑问题或跨模块回归	Claude review；发现由其他 Agent 并行复核，再按共识、严重度和证据过滤
3. 安全审查	每个 PR	单独检查安全风险，并可阻止合并	安全 reviewer；未解决的问题需要修复或给出关闭理由
4. 阻断式 CI	合并前	检查代码能否通过确定性验证	lint、类型检查、测试、构建及跨平台任务
5. 按风险进行人工审批	合并前	把人放在方向、架构和高影响变更上	低风险零审批或轻审批，中风险一人，高风险两人或指定路径 owner
6. 合并队列与渐进发布	合并及发布	防止多个各自通过的 PR 组合后破坏主干，控制新功能暴露范围	merge queue、feature flag、内部先用、分阶段发布
7. 快速发现与回滚	发布后	接住前面所有层都可能漏掉的问题	telemetry、on-call、incident review、关闭 flag、回滚或快速修复

层与层之间不能互相替代：AI review 不代替测试，CI 通过不代表产品方向正确，人工审批也不能替代发布后的监控。可靠性来自多层机制互相补位，并且错误发生后有清晰的撤回路径。

三、视频提出的五个问题，分别由哪一层回答

宝玉的视频把这套系统浓缩成五个实际问题。它们并不是五种独立的 AI 功能，而是关于审批边界、自动审查如何收敛、漏检后的补救、工程师如何建立理解，以及最终由谁承担责任。

问题	Anthropic 实践中的回答	落地时要守住的边界
哪些修改仍要人看？	按变更风险分级：文档、小范围且有保护的低风险改动可减少额外审批；普通改动至少一人；账单、自动更新器、CI 等高影响路径需要更多或指定 owner 审批。	不能只按 diff 大小决定风险；目录、权限、数据流、发布范围和可逆性都要纳入判断。分类器可以辅助分流，审批规则和责任人仍由团队定义。
AI 审 AI 会不会没完？	会发生循环。Anthropic 报告过单个 PR 一夜超过 50 轮的情况；随后设置轮数上限、后续只看新增 diff、合并重复问题，并要求超过一定轮数时重新审视整体方案。	不能用“再跑一轮”代替明确的停止条件。用通过轮数、重复 finding、误报导致的修改和等待时间判断新增一轮是否值得。
审查 AI 漏掉问题怎么办？	AI review 只是多层检查之一，后面还有安全审查、阻断式 CI、按风险审批、合并队列、渐进发布、监控和回滚。历史事故与修复案例还会进入 reviewer 评测集。	任何单层都可能漏检。为每层写清它能发现什么、不能发现什么，并保证发布后能观察影响、停止放量和撤回变更。
人不逐行读代码，怎么理解代码？	把理解放到具体任务中：准备修改某模块的人，按需了解相关路径和约束；Claude 可以帮助解释局部代码或生成可视化。机器承担更多重复 diff 阅读，人仍需理解变更意图、验证证据和高风险设计。	减少逐行阅读不等于盲目批准。批准者必须能说明验证覆盖范围、剩余不确定性，以及为何当前风险可以接受。
出问题算谁的？	团队仍由变更负责人承担交付责任；Agent 的批准不能替代要求的人类审批。出错后由熟悉变更的人推动修复，并通过事故复盘找出系统哪一层应当接住它。	模型可以协助写代码、审查和解释，但不是组织中的责任主体。责任需要对应具体 owner、可追踪的 commit 和可执行的回滚路径。

这五个问题合在一起，说明“让 AI 多看 diff”不是完整方案。只有风险决策、检查收敛、独立验证、上下文理解和责任归属都明确，才适合减少人工逐行审查的比例。

四、人工审批按变更风险分配

Anthropic 文中列出的内部分级大致如下：

风险级别	原文举例	人工审批要求
低	文档、文案、仅内部可见功能、由 flag 保护的增量变更	自动代码与安全检查通过后，可不要求额外人工审批
中	普通产品变更，以及缓存、自动更新器、系统提示词等敏感区域	一名人工 reviewer
高	最高风险代码，以及明确要求双人审批的路径	两名人工 reviewer

这里有几个关键约束。风险等级由变更本身决定，而不是由作者或 Agent 的自我判断决定；另一个分类器还可以判断某个具体改动是否需要额外的人。敏感路径、CI workflow 等也可以始终要求人工介入。

低审批路径只对可信作者开放。Agent 的批准不能占用需要人工审批的名额；指挥 Agent 提交代码的人仍要对变更负责。审批针对具体 commit，如果之后出现未经验证的新 commit，审批就需要重新确认。

这套规则的目标不是让机器批准高风险代码，而是把人工时间从低风险重复检查中释放出来，同时保证风险高、影响大或证据不足的变更仍有明确的人类责任人。

五、AI Reviewer 需要做精度和收敛管理

AI 审查如果只是不断增加发现数量，会把噪声和返工转嫁给提交者。Anthropic 团队描述了几种控制办法。

多 Agent 复核发现

多个 Agent 可以并行寻找问题，另一组 Agent 再对每条 finding 投票；达到足够共识后才发布。纯风格建议、泛化诊断或低价值清理会被过滤。每条评论按严重度排序，标注 Important、Nit 或 Pre-existing，避免把已有问题误算成当前 PR 引入的错误。

发现要有证据，至少指向具体文件、行和失败机制。提交者必须处理每条 finding：修复它，或在线程中说明为什么关闭。误报也需要一个简短理由，不能让未解决评论静默通过。

把真实事故加入评测集

团队把造成事故或回滚的历史 PR、对应修复和回滚交给熟悉代码的人核实，把确认过的问题加入评测集。Reviewer 的 prompt、工具或模型更新后，再在同一组案例上测试，判断改动是否真的提升了召回，且没有增加不可接受的误报。

从处理行为中衡量噪声

除了统计发现了多少问题，还要看人们如何处理评论：修复、判断为错误、确认行为是有意的，还是认为问题不重要。对于已知干净的 PR，也可以估算 reviewer 的误报率。

原文特别指出，Agent 作者会让噪声更昂贵：人可以很快忽略一个 nit，而 Agent 可能真的去改它，产生新 commit 和额外 review round。因此评估不能只看 bug recall，还要看评论是否让系统做了有害或无价值的改动。

防止 Agent 互相拉长审查循环

作者提到一条 CLI PR 曾经一夜间经历超过 50 轮审查与修复。回看 reviewer 反复提到的问题，约 59% 已经在它第一次审查时存在，后续多轮经常是在发现旧问题，而非新问题。

团队于是加入轮次上限：超过三轮后，要求作者重新考虑整体方案；早期几轮之后改为只看新增 diff；要求修复一类问题的所有实例；不重复发布已提出的问题。团队同时跟踪从第一次 review 到通过的轮次。

六、公布的指标说明了什么

原文给出一组收敛改进前后的内部 PR 指标：

指标	调整前	调整后
一轮审查和修复后通过	65%	78%
需要五轮或更多	8.9%	1.5%
平均通过审查轮次	2.08	1.32

这些数字来自 Anthropic 团队内部 pull request，不是对外部团队的预测。更值得借鉴的是指标组合：除了 AI reviewer 的召回率，也要跟踪 reviewer 评论噪声、通过所需轮次、人类审批数量、PR 等待人工的时间，以及最终的回滚和事故率。

原文衡量人工审查成本时同时看审批数（中位数和 95 分位）、人工评论数和等待人工的时间，并用 reverts 与 incidents 作为护栏。如果审查时间减少但回滚、事故增加，说明成本只是从 review 转移到修复和 on-call。

七、人仍然要做的判断

Anthropic 团队把人的注意力集中在机器较难承担的工作上：

• 要不要做这项改动：方向、取舍、范围和产品判断；
• 高风险代码：账单、自动更新器、CI 等可能影响面大的路径；
• 架构选择：会成为后续代码范式的设计决定；
• 阅读验证证据：测试输出、运行命令、截图和 reviewer finding；
• 承担交付结果：不论代码由谁输入，负责人都要对上线结果负责。

审查不再要求每个人完整阅读所有 diff，但批准者仍需要知道验证能覆盖什么、漏掉什么。如果无法说明检查的盲点，就不应该把自动结果当成充分依据。

“你合入，你负责”也不是责备机制。原文把它与小变更、可逆发布、风险匹配检查、快速发现回归联系起来。责任的含义是由最了解变更的人推动修复；事故复盘则用来找系统里哪一层应当接住问题。

八、普通团队可以怎样逐步采用

不必一次复制整套流程。可以从以下次序开始：

PR 之前

• 给 Agent 可执行的验证方式，让它展示测试、构建或截图结果；
• 用短的 CLAUDE.md 或等价项目说明写清技术栈、命令、约定和非目标；
• 给敏感目录增加简短的 REVIEW.md 或路径级审查规则；
• 用新上下文复核 diff，反复出现的意见应升级为 lint、测试或仓库规则。

每个 PR

• 必需 CI 包含 lint、类型检查、测试和构建；
• PR 模板要求填写验证方式、风险和撤回方案；
• 在一个仓库先试 AI reviewer，收集误报和漏报案例，校准后再扩展；
• 独立运行安全审查，并要求所有 reviewer thread 都有明确结论；
• 限制自动 reviewer 反复审查的轮数，后续优先审查新增 diff。

审批与发布

• 写出低、中、高风险的路径和例子，先保守设置审批人数量；
• 用 CODEOWNERS 和分支保护锁定账单、认证、CI、发布流程和安装器等目录；
• 不允许 Agent 审批代替要求的人类审批；新 commit 需要重新确认审批有效性；
• 用 merge queue、feature flag、内部试用、分阶段发布和可操作回滚控制影响面。

持续改进

• 把已确认的线上事故、回滚和相关修复加入 reviewer 评测集；
• 同时观察真实缺陷召回和误报造成的返工；
• 记录人类审批数、评论数、等待时间、review rounds、reverts 和 incidents；
• 定期检查成本是否真正下降，而不是转移到返工和 on-call。

常见误区

误区	更准确的理解
AI reviewer 通过就代表代码安全	Reviewer 只是一层；安全检查、CI、风险审批和发布监控仍各有职责
人工审批少了，流程就更高效	还要看回滚、事故、误报和返工，否则只是把成本移到了后面
多跑几轮一定更好	多轮可能发现新问题，也可能重复旧问题；要评估收益并设置收敛规则
所有 PR 都应同样审批	文档小改与发布流程、账单、认证改动的影响不同，审批级别也应不同
Agent 写的代码由 Agent 负责	Agent 可以执行和解释；变更负责人仍要对上线结果负责

小结

Anthropic 这篇文章的核心，不是“把代码审查交给 AI”，而是重新安排每种检查发生的位置：作者先验证，机器广覆盖找问题，安全与 CI 负责阻断，人按风险做判断，发布系统通过渐进放量和回滚接住剩余错误。

要复制这类做法，先建立可重复验证和可逆发布，再引入 AI review；用事故案例检查 reviewer 是否有效，用噪声和审查轮次控制返工，最后才逐步减少低风险路径上的人工等待。评估目标应始终是降低每次变更消耗的总人工时间，同时不增加回滚和事故。

关于“GitHub PR 代码审查”和“本地审批 reviewer”是不同能力的说明，可继续阅读《Codex auto-review 的边界》。

来源

• How the Claude Code team does code review：Addy Osmani、Morgan Westlee Lunt、Qing Wang，2026-10-15。
• 宝玉：Claude Code 团队如何做代码审查（中英文视频）：原帖发表于 2026-10-17；视频分别约 10 分钟和 9 分 34 秒。本文用原帖确认其摘要与提问框架，流程细节和指标以 Anthropic 原文为准。
• Anthropic：Redesigning source control：原文引用的主仓库每日变更吞吐背景。
• Code Review for Claude Code：原文提及的对外产品文档。

本文为来源整理与工作流归纳。团队报告的业务指标及其成因按原文转述，没有独立审计；实施建议是基于原文各层机制整理的通用迁移思路，不代表 Anthropic 对其他团队的保证。