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%。这个结果是该团队的内部阶段性数据。更可迁移的经验是：节省人工审查时间必须同时观察回滚和事故，单看审批变少并不能证明质量没有下降。
一、代码审查有两项工作
原文把代码审查的职责分成两项：
- 在代码上线前发现并修复问题；
- 在团队成员之间建立对代码库的共同理解。
机器可以承担更多重复的 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 对其他团队的保证。
தொடர்புடைய வழிகாட்டி
Codex auto-review 的边界：别把 GitHub PR review 和审批 reviewer 混成一个开关