Anthropic 如何做代码审查：中文编译与深度解读

一个 AI 写代码，另一个 AI 找问题，第一个 AI 再修改。这个循环看起来像一条自动生产线，也可能变成一台不断制造新提交、却迟迟交不了货的机器。

Claude Code 团队在 How the Claude Code team does code review 中讨论的，正是这类问题：当代码生成速度超过人的阅读速度，怎样控制缺陷、保留责任，又不让审查吞掉全部时间？

原文由 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 撰写，发布于 2026 年 10 月 15 日。本文提供核心内容的中文编译与独立分析，并非全文逐句翻译。原文实践、官方产品能力和本文建议会分别说明；资料核查截至 2026 年 10 月 27 日。

我的判断是：这篇文章最有价值的地方，是把代码审查当作一套可以测量、可以修正的工程系统。小团队值得学习它分配注意力的方法，能放开多少自动合并，则取决于自己的验证、监控和恢复能力。

原文核心意思：把人的注意力放到风险上

以下是对原文主旨的压缩编译，完整论述请阅读英文原文。

代码审查同时承担发现缺陷和传播团队知识的任务。随着 Agent 生成的变更增多，是否有人逐行读过，已不足以衡量质量；团队需要判断每种风险应由什么检查发现。

Claude Code 团队把验证前移，并组合 CI、AI 缺陷审查、安全审查和按风险分配的人工批准。合并之后，还有内部使用、分阶段发布、监控及回滚。低风险变更可以减少额外审批，但发起变更的人仍对结果负责。

审查器自身也需要评测。真实事故成为后续评测用例，误报和反复审查则成为需要治理的成本。团队希望减少每次变更占用的人工时间，同时用回滚和事故情况约束这种优化。来源：原文

这里有两个值得保留的译法：

• Human time and attention：人的时间与注意力。它包括阅读，也包括判断、纠错和处理事故。
• You land it, you own it：谁把变更合入，谁负责跟进结果。它描述责任归属，不能被理解成把系统性问题归咎于个人。

先核对：内部流程和公开产品是两回事

读这篇文章，最容易出现的逻辑跳跃，是以为给 GitHub 安装一个 AI 审查服务，就得到了 Anthropic 内部整套合并机制。

截至核查日，Code Review 官方文档明确说明：公开服务面向 Team 和 Enterprise 组织，读取 diff 与周边代码，核验候选问题，再发布行内评论及检查结果。它不会批准 PR，也不会阻止合并；审查过程中不会构建或运行代码。

因此，要把几个动作分清：

动作	能证明什么	仍然缺少什么
AI 阅读代码后没有发现问题	本轮审查未报告可确认的问题	对运行行为、未覆盖场景的保证
CI 构建和测试通过	指定提交通过了已配置的检查	测试没有表达的业务约束
人批准某次变更	有人接受了该版本的证据与风险	对后续新提交的自动背书
变更已部署	新版本进入了目标环境	真实用户场景下的正确性
监控显示稳定	观测窗口内未出现已定义的异常	尚未发生或尚不可见的问题

这是本文整理的证据边界。原文里的“未处理问题阻止合并”“按风险决定批准人数”，属于团队自己的规则与集成，不能直接归为公开审查服务的默认功能。

同样，“没有额外的人批准”和“没有人负责”也不能画等号。原文的较轻审批路径只面向可信作者，部分敏感路径始终要求人工，指导 Agent 的人承担变更责任。来源：原文的风险批准说明

那组漂亮的数据，究竟说明了什么

原文报告：从 6 月到 9 月，Claude Code 代码库合并的 PR 数量超过翻倍，需要回滚的 PR 占比相对下降超过 40%。这是团队对自身结果的披露，值得关注；但文章没有同时给出完整样本量、原始回滚率和受控对照，不能据此计算某个 AI 工具单独带来的效果。来源：原文开篇

尤其要注意，回滚率下降并不必然意味着回滚总数下降。

下面完全是假设，用于解释分母变化：

指标	时期 A	时期 B
合并 PR 数	100	220
回滚 PR 数	5	6
回滚率	5%	约 2.73%

这个例子中，合并数超过翻倍，回滚率相对下降约 45.5%，回滚次数却增加了 20%。它不是 Anthropic 的实际数据，只说明原文的两个比例不能推出事故处理总量一定减少。

进一步说，同一次观察期里，测试、灰度、审查规则、变更大小和团队熟练度都可能变化。把全部改善归因于 AI 审查，会跳过其他解释。

如果自己做试点，我会同时记录每个 PR 和每次发布的缺陷率、实际事故数量、严重程度、受影响用户、恢复时间，以及每周处理这些问题花掉的人工时间。一个很小的文案回滚，与一次影响支付的事故，不适合只按“一次”来比较。

真正应该优化的是总成本

少一次人工批准，很容易统计；少一次误判引发的返工，则不容易。

本文建议把人工成本拆成四部分：

阅读与判断时间 + 处理审查意见的时间 + 上线后修复时间 + 维护审查系统的时间

如果审查从二十分钟缩短到五分钟，却多出了半小时解释误报，团队并没有节省时间。如果审批等待少了，却要每天维护一套脆弱的自动化，收益也需要重新计算。

这并不意味着所有工作都必须精确计时。起步时可以对有代表性的 PR 做抽样，至少知道时间去了哪里。原文用批准数、人工评论和等待人的时长观察人工投入，这些是有用的代理指标，但不能完全代替真实工时，更不能代替交付价值。

还有一个常被忽略的变量：合并速度变快之后，团队是否开始做更多没有必要的功能？一个需求方向错误、但测试充分的 PR，依然可能增加未来的维护负担。审查系统能帮助判断实现，却不能单独决定需求值得做。

多层检查有用，前提是不要共享同一个盲区

让几个 Agent 分别审查，比同一个会话自我确认更有机会发现遗漏。但多个 Agent 得出一致结论，也不能直接当成独立证据。

假设需求写错了：“管理员可以查看所有租户的客户资料。”作者 Agent 按此实现，审查 Agent 按此核对，测试 Agent 再按此生成测试，三者完全可能一致通过。问题出在业务授权边界，而不是代码是否遵守这份需求。

因此，我更关心不同检查获得了什么证据：

可能的失败	可以补充的证据或检查
同一个需求假设贯穿实现和测试	业务负责人确认权限、金额和状态约束
静态阅读看不出特定运行状态	真实执行结果、边界输入和受控复现
每个模块单独正确，组合后出错	跨模块测试、集成环境及合并后检查
测试环境与生产数据形态不同	脱敏样本、生产观测和逐步扩大流量
审查者被作者解释带偏	先独立读取需求和代码，再核对作者说明

这些是本文提出的检查方向，不是原文展示的效果实验。

“全新上下文”可以减少对作者叙事的依赖，却不会自动提供缺失的业务知识。换一个模型也不必然消除共同错误。要减少共同盲区，需要有意引入不同来源的约束和可执行证据。

这也与本站之前讨论的设计与审查会话隔离相接：隔离的价值在于暴露隐性前提；最终仍要回到规格、源码和实际行为。

审查循环必须有停止条件

AI 作者会认真执行很多人类作者可能直接忽略的细小建议。于是，一条低价值评论可能触发修改、重新构建、重新审查，再产生下一条评论。成本会沿流程放大。

原文提供了一组有关审查收敛的内部前后比较：

指标	调整前	调整后
一轮审查与修复后通过的 PR 占比	65%	78%
需要至少五轮的 PR 占比	8.9%	1.5%
通过所需的平均审查次数	2.08	1.32

这些数字来自原文收敛部分。它们显示该团队的审查往返减少，不能单独证明漏检率也没有变化。原文同时强调，要把缺陷召回与通过所需轮数一起观察。

对普通团队，我建议把每条审查意见写成一个能够结案的问题：触发条件是什么、会出现什么错误、哪段代码支持判断、怎样证明已经修复。仅仅写“这里可能有问题”，容易把验证责任全部转给作者。

多轮审查还需要区分三类内容：本次变更新增的问题、修改引入的问题，以及顺便发现的历史问题。历史问题并非不值得修复，但应明确它是否必须阻塞当前交付。否则，一次小改动会不断扩大成全库清理。

我的建议是先设一个有限轮数作为人工介入点；达到上限后，检查需求和方案，而不是继续机械重跑。这个上限需要按风险校准，不能用“达到三轮就放行”代替质量判断。对高风险变更，多花时间可能合理；对低风险变更，反复改风格往往得不偿失。

评测要防止“看过答案”

把真实事故变成评测用例，是原文很值得借鉴的做法。但一份事故记录包含出错提交、修复提交和事后解释，如果这些内容全部给审查器，测到的可能只是它能否复述答案。

下面是本文建议的离线评测方式：让审查器看到事故发生前可获得的代码、PR 意图和规则，把后来确认的缺陷位置及修复方案留作评分依据。必要时还要隔离后续代码与讨论，避免答案通过其他路径进入上下文。

同时保留两类样本：确实有缺陷的变更，以及经人工确认没有目标缺陷的变更。前者观察漏检，后者观察是否会提出有害修改。评价单位也要说清：一条评论、一个缺陷和一个 PR，不能混用同一个“准确率”。

“开发者接受了建议”可以作为反馈，却不是正确性的最终证明。作者可能为了尽快通过而接受，也可能由 Agent 自动执行。更可靠的复核还需要代码证据、复现或领域判断。

如果持续根据同一批事故调提示词，最好另外保留不参与调优的样本，或按时间检验后来的新事故。旧题得分提高，才有机会与对未知问题的能力区分开。这里描述的是建议，本文没有对 Claude 审查器做独立效果测试。

风险分级需要硬规则托底

一个改动只有几行，不代表影响很小。修改默认权限、付款金额单位、发布凭据或自动更新地址，都可能比一个大页面重构危险得多。

因此，我会先按最坏后果、影响范围和恢复难度设定人工审查下限，再让分类器辅助识别需要升级的变更。对关键路径，可以由仓库规则要求人工，而不是只依赖模型给出一个“低风险”标签。

审查指令本身也属于控制系统。如果一个 PR 能修改“如何审查这个 PR”的规则，又让新规则立刻用于自身，可信边界就会变得模糊。

这方面，官方定制文档有两个很实际的细节：公开服务从 base 或默认分支读取 REVIEW.md，不会直接采用 PR 自己修改的版本；具体读取范围还取决于分支保护状态。另一个容易踩坑的区别是，本地 /code-review 命令读取 CLAUDE.md，不读取 REVIEW.md。文件写在仓库里，不等于每种工具都会使用它。

下面是本文为业务系统写的示意规则，不是 Anthropic 官方模板：

# 审查重点

- 优先报告可导致错误结果、越权或数据损坏的问题。
- 每个问题说明触发条件、实际后果和源码位置。
- 涉及租户隔离时，沿调用链核对身份来源与数据范围。
- 区分本次引入的问题与历史问题；重复问题合并报告。
- 不确定时写清缺失证据，不把猜测包装成已确认缺陷。

这份文件只能影响审查行为。要求人工批准、限制谁能合并、保护规则文件，还需要仓库权限和相应的合并约束。把一句“必须人工批准”放进提示词，不会自动获得权限控制的效果。

快速回滚的前提，是错误仍然可逆

原文把恢复能力放在很重要的位置。这一思路适合许多可以通过关闭开关或恢复版本纠正的产品变更，但不能不加区分地推广。

以下是本文构造的反例：

• 代码恢复了，已经发出的通知仍然送达；
• 新版本撤回了，错误的外部付款仍需核实与补偿；
• 写入逻辑回滚了，已经污染的历史数据仍需修复；
• 开关关闭了，已泄露的数据无法因此收回。

这些情形里，恢复二进制版本只解决了部分问题。还需要数据修复、外部对账、补偿动作或其他处置。

所以风险分级不能只问“这个提交能否 revert”，还应问“发生错误后，哪些状态已经离开了代码仓库”。对于不可逆后果，更多上线前验证和人工判断通常更有价值。

灰度发布也有条件：需要能够识别异常、控制影响范围，并有人及时行动。没有有效观测，只把版本分批发出去，并不会自动得到更早发现问题的能力。

人少的团队，先做一个能算清账的试点

Anthropic 的流程背后有专门的工程投入。小团队若直接复制全部层次，很可能先复制了维护成本。

我会选择一个变更较频繁、已有基本测试、能够恢复的仓库，按以下顺序试：

阶段	做法	决定下一步的证据
建立基线	记录当前审查耗时、返工、缺陷及恢复方式	原来的主要成本在哪里
旁路运行	AI 发表评论，继续保留现有审批	哪类问题有用，哪些评论造成无效修改
固化规则	重复的机械问题交给确定性检查，业务约束写进审查指令	同类问题是否减少，规则是否被实际读取
有限放开	只对已证明稳定、后果可恢复的变更减少额外审批	节省的人工是否超过新增成本，缺陷情况是否可接受

这里的阶段顺序是本文建议，没有预设运行多少天就足以证明可靠。样本太少时，“没有出过事”可能只是还没遇到相关条件。

成本也要依据实际产品计算。官方费用文档说明，Code Review 按 token 使用量计费，独立于套餐内含用量，没有固定的每次审查价格；深度、变更规模、周边复杂度和候选问题核验都会影响费用。

按每次 push 触发审查，还会放大调用次数。粗略预算可以从“PR 数量 × 每个 PR 的平均审查次数 × 单次平均费用”开始，再加入 CI 和人工处理意见的成本。别拿一次小 PR 的报价，直接推算大型仓库整月支出。

预算耗尽或服务不可用时也要有明确状态。没有运行的审查，不能显示成审查通过。是否暂缓合并或改用人工流程，需要提前决定；这比出问题后才发现一批 PR 没有被检查更容易处理。

人仍然需要理解到什么程度

减少逐行阅读，会留下一个长期问题：团队是否仍能在出事时找到负责人，解释关键状态，并做出修复判断？

AI 生成的模块说明可以帮助进入陌生代码，但一份流畅解释本身仍需核对。我更愿意把知识交接的最低要求定为：责任人能定位关键入口、说清业务不变量、指出验证范围，并知道发生异常后如何止损。

不必要求每个人记住整个仓库，也不能让整个团队只剩下“让 AI 再解释一次”的能力。关键模块的设计记录、事故复盘和有针对性的走读，仍然有价值。

对我而言，采用这套思路之前，最应该填写的是一份具体的变更说明：

## 这次解决什么问题
说明用户场景和必要性。

## 哪些证据支持合并
列出实际运行的检查、结果，以及未验证的范围。

## 最坏会发生什么
说明影响对象、不可逆状态和仍需人工判断的部分。

## 出错后谁来处理
写清观察方式、恢复动作、数据处置及负责人。

当这些问题有了可核对的答案，减少人工阅读才有讨论基础。对于缺少测试、监控或恢复手段的项目，先补其中最薄弱的一项，通常比直接追求自动合并更实际。

参考资料

1. How the Claude Code team does code review，2026-10-15。本文编译与分析的原始文章，内部数据均按作者披露表述。
2. Code Review 官方文档。用于核对公开服务的适用套餐、审查方式及能力边界。
3. Customize Code Review。用于核对指令文件、读取分支及本地命令差异。
4. Code Review costs and usage。用于核对计费、触发频率与预算限制。

本文中的假设数字、业务反例、示意规则和试点方案均为分析用途，不是 Anthropic 的实测结果，也不表示已在本文作者的生产环境完成验证。