Claude Code 团队如何评审 AI 写的代码

Anthropic 2026-10-16 10:09 浙江

人类如何评审 AI 写的代码

Claude 写了 Claude Code 自身约 90% 的代码，那人类开发者是怎么评审得过来的呢？

Anthropic 在最新博客里介绍了团队的做法：

把验证和评审提前，让多个 Agent 找问题、交叉核验，再按改动的风险决定需要多少人工批准。从 6 月到 9 月，Claude Code 合并的 PR 数量翻了一倍多，需要回滚的比例却下降了 40% 以上。

团队也遇到了 Agent 一夜之间互相评审、修改五十多轮的情况，于是开始控制评审轮数，用历史事故持续评测评审器。整套流程要节省的，是人工评审和事后修复加起来的时间。

下面是全文。配图包括原图的重绘及根据正文补充的讲解图，文中的「我们」指 Anthropic 原文作者。

全文

原文标题：Claude Code 团队如何做代码评审

作者：Addy Osmani、Morgan Westlee Lunt、Qing Wang（技术团队成员）

发表于 2026 年 10 月 15 日。

Agent 产出代码的速度这么快，该怎么评审？

在 Claude Code 团队，我们先做到了广泛覆盖和深入评审，随后开始优化人工评审所花的时间：在不增加回滚或事故的前提下，把它降到尽可能少。

我们之前说过，Claude Code 自身大约 90% 的代码是 Claude 写的。那么，面对这样的代码产量，我们怎么做评审？还有人在读代码吗？如果出了问题，又由谁发现？

这篇文章介绍 Claude Code 团队的代码评审流程，以及它是怎样演变的。

从 6 月到 9 月，Claude Code 代码库合并的 PR 数量翻了一倍多，而其中需要回滚的比例下降了 40% 以上。

我们没有取消评审。不过，我们确实把大部分阅读代码的工作交给了机器，把人的时间和注意力作为优化目标，并投入了大量精力，让撤销错误变得更快、更容易。

重新思考代码评审的目的

当 Agent 开始写代码，改动数量会迅速增加。今年，Anthropic 的 monorepo 每天合入的改动，从 5 月的大约 2,500 次，增长到了 9 月的 30,000 多次 [1]。

Claude Code 使用独立的仓库，不在这个 monorepo 里，但它也面临着很大的压力。

当交付速度这么快时，靠人工逐行评审代码，即便不是完全做不到，也已经非常困难。

代码评审承担两项工作：

1. 在发布之前发现并修复问题。

2. 帮助团队共享上下文，建立对代码库的理解。

本文主要讨论发现和修复问题，但在接近结尾时，我们也会回到第二项工作。

我们认为，问「有没有人读过这段代码」，并不能准确回答我们真正关心的问题：这次改动可能出什么问题，应该由哪项自动检查或人工检查来发现？

这个问题也改变了评审发生的时间。以前，评审是流程末尾的一道关卡：写代码，开 PR，等同事来看。

现在，评审持续进行，更像你写字时一直运行的拼写检查。

大多数改动在交给人看之前，已经由 Claude 至少评审、修复过一轮。这样能发现大部分常规错误，让团队把注意力留给更高层面的问题和审查。

稀缺的是人的时间和注意力

我们希望把人的时间和注意力留给只有人能解决的问题，其余的则由自动检查来发现。

以我们现在的改动速度，人仍然有大量工作要做，团队几乎每天都会遇到新的挑战。

人的时间包含评审成本的两部分：评审本身花费的时间，以及修复坏代码所造成问题的时间。减少前者，如果只是把时间转移到了后者，就没有意义。

因此，我们的目标是，让 Claude Code 各仓库里的大多数 PR，在最多一名人类参与的情况下完成合并，这个人可以就是作者本人，同时不增加回滚或事故。这些仓库包括 CLI、桌面端、Web 端和移动端应用。

为了衡量人工投入，我们跟踪每个 PR 的人工批准次数，包括中位数和第 95 百分位数，还会记录人工评论，以及 PR 等待人工处理的时长。

回滚率和事故率是约束条件。如果它们上升了，就说明我们没有节省人的时间，只是把时间转移到了别处。

一次改动的完整流程

一次典型的改动，从工程师的笔记本电脑，或 Slack 里的 Claude 会话出发，会经历多层代码评审。

提交 PR 前先验证工作；每个 PR 都要经过必需的 CI、Claude 代码评审和安全评审，这些都是自动化检查，之后再按风险由人决定审批要求。

接下来进入合并队列，合并后先通过功能开关在内部使用，再逐步发布，最后持续监测，必要时追加修复或回滚。

图中的 CI 还包括打包检查；构建出错时会回滚。「修复前滚」指通过后续修复解决问题。

大部分流程是自动化的，人的注意力跟着风险走。

一层一层地检查

从上到下是验证、必需的 CI、AI 评审、安全评审、人工审批，以及合并队列与功能开关。

每一层都有不同的漏洞，穿过一层的问题可能在下一层被发现；仍然穿过所有检查的问题，则由底部的快速回滚来处理。

每一层都能发现一些问题，也会漏掉另一些。很少有问题能穿过所有层，剩下的由回滚处理。

1. 在交给别人之前，先验证工作

如今，大部分评审发生在 PR 创建之前。我们给 Claude 一些可以实际执行的验证方式，例如测试、构建，或者生成截图与设计稿对比，并要求它展示输出，而不是只说「完成了」。

随后，再让一个使用全新上下文的子 Agent 评审 diff。这两个习惯都来自我们的最佳实践指南 [2]。

在创建 PR 之前，我们很多人还会运行几个内部 skill：一个负责找 bug，一个负责简化 diff，还有一个检查端到端行为。UI 改动也会对照设计规范检查。

Claude Code 的创建者 Boris Cherny 曾说，给 Claude 一种验证自身工作的方法，可能是获得好结果最重要的一件事 [3]。

他估计，这能让最终结果的质量提升到原来的两到三倍，并写道：

不同领域的验证方式各不相同。可能简单到只需要运行一条 bash 命令，也可能要跑一套测试，或者在浏览器、手机模拟器里测试应用。

当自动评审器反复指出同一种问题时，我们会从源头解决。比如修改 skill、增加 lint 规则，或更新下面这些指令文件。

• CLAUDE.md 告诉 Claude 这是一个什么项目：技术栈、约定、目标，以及不打算做的事。

每次评审都会加载它，因此在大型代码库里，我们会让它保持简短，再从中链接到其他文档。评审器也会指出违反其中约定的代码，以及让其中某条说明过时的改动。

• REVIEW.md 由代码负责人编写，告诉评审器，他们负责的代码里什么最重要。我们还会单独检查评审器是否真的遵守了这些要求。

好的 REVIEW.md 通常很短。它会说明这个仓库里的失败是什么样的：对文档来说，是「说了不符合事实的话」；对配置来说，是「路由到了错误的地方」。

它也会限制对小问题的挑剔，列出需要跳过的路径，并要求用具体文件和行号作为证据，而不是根据名字猜测。

它还会要求评审摘要先给出问题数量，如果没什么需要修复，就明确说出来。

2. 每个 PR 都做 AI 评审

每个 PR 在交给人看之前，都会先经过 Claude 评审。

它结合整个仓库和 PR 声明的意图阅读 diff，检查这次改动是否解决了原本的问题、是否适合现有系统，以及是否会破坏其他地方。如果是 bug 修复，它会寻找根因。

对外提供的 Code Review for Claude Code [4] 已向 Team 和 Enterprise 套餐正式开放，而 /code-review 可以在本地运行一个更轻量的版本。

我们推出研究预览版 [5]时，内部 PR 收到实质性评审意见的比例，从 16% 增加到了 54%。

超过 1,000 行的大多数 PR 都会被发现问题，而大多数小 PR 则没有发现问题。

管理员可以为每个仓库选择 Quick、Standard 或 Deep。如果漏掉一个 bug 的代价，比额外的评审时间更高，那么 Deep 就值得用。

在交给人看之前，发现的问题会先由其他 Agent 核验。多个 Agent 同时寻找 bug，随后由另一组 Agent 对每个发现投票，只有足够多的 Agent 同意它是真问题，才会把它发出来。

只涉及风格、诊断信息或代码清理的问题会被过滤掉。在保留这些过滤规则之前，我们先在自己的 PR 上做了 A/B 测试。剩下的问题按严重程度排序，以行内评论的形式出现。

每条评论都会标记为 Important、Nit 或 Pre-existing，分别表示重要问题、小问题或已有问题，避免把这次 PR 没有引入的 bug 算到作者头上。

每个问题都必须得到回应。要么修复，要么说明理由并关闭讨论。经常会有 Agent 在夜里接手修复，因此作者回来时，PR 已经又经历了一轮处理。

3. 可以阻止合并的安全评审

安全也有独立的自动评审。只要 bug 评审或安全评审中还有未关闭的问题，PR 就不能合并。你需要修复，或者简单说明理由后关闭讨论；误报也是这样处理的。

如果后续提交修复了问题，对应的问题会自动关闭。

你也可以用开源的安全评审 GitHub Action，或者 /security-review 命令来搭建同样的流程。配置方法见 Claude Code 自动安全评审 [6]。

4. 可以阻止合并的自动检查

这部分是常规检查：lint、类型检查、各个平台上的测试，以及构建。一个典型的 CLI PR，在交给人看之前，可能会运行几十项检查。

我们也写过如何扩展 CI，以应对这样的代码量 [7]。

PR 模板要求说明改动是如何测试的，以及如何撤销。Claude 可以填写这些内容，但提出改动需求的人必须确认。

5. 按风险决定人工审批要求

修改文档和修改自动更新器，风险不同，需要的评审也不同。

风险	示例	人工批准要求
低	文档、文案、仅内部使用的功能、由功能开关控制的新增改动	自动评审和安全检查通过后，不要求人工批准
中	一般产品改动，以及缓存、自动更新器、系统提示词等敏感区域的改动	1 人
高	风险最高的代码，以及少数始终要求两人批准的路径	2 人

风险等级由改动本身决定，而不是由作者决定。一个分类器会阅读改动并确定风险等级。

第二个分类器则会进一步判断，即便等级规则没有要求，这次具体改动是否仍需要另一个人参与。

有些路径始终需要人工介入，包括负责人列为敏感的内容，以及任何 CI 工作流文件。

只有仓库信任名单里的作者才能走较宽松的审批流程，他们主要是负责这个仓库的团队成员。其他所有人都需要第二个人批准。

Agent 的批准永远不能算作人的批准。自动评审可以放行低风险改动，但不能替代明确要求的人工批准。

谁指示 Agent 做出改动，谁就要为它负责。对于 Agent 编写的 PR，指挥 Agent 的人可以算作所需评审者中的一人，就像代码是他亲手写的一样。

一次批准只针对一个具体 commit。如果后来加入了系统无法确认仍受原批准覆盖的提交，例如 Agent 新推送的提交，或人工解决合并冲突后的提交，就必须重新批准。

图中人数指人工批准要求；低风险免人工批准的前提及信任名单、敏感路径等例外，见本节说明。

6. 合并队列、功能开关和渐进发布

合并队列会把改动应用到 main 上，再重新运行所有检查，防止两个分别通过检查的 PR 合在一起后，反而把 main 弄坏。

新行为通常先放在功能开关后面，交给 Anthropic 员工使用。我们内部的高强度使用，往往能在用户遇到问题之前发现回归。

公开发布会先进入 latest 渠道，stable 渠道则晚一些跟进。

7. 快速发现，快速回滚

仍然会有一些错误漏过检查，所以最后一层的重点是尽快发现它们。关闭功能开关不需要重新部署。

Claude Code 每周轮换值班人员，事故复盘则会追问：本来应该由哪一层发现这个问题？

发现有问题的合并，仍然依赖作者、值班人员，以及回滚和事故看板。

我们还没有能在这些指标变化时自动收紧审批要求的熔断机制；这里的工程师希望，在更多代码走向无人参与的合并之前，先把它建起来。

一位同事说，放慢速度确实会降低出错率，但主要是因为你所有事情都做得更少了。我们更希望提高发现和修复问题的速度。

怎样改进评审器

我们的代码评审流程在不断迭代。

现在，每一次事故都会成为评测案例。团队收集了过去引发事故的 PR，以及对应的后续修复和回滚，再请熟悉相关代码的工程师确认每个 bug 及其位置。评审器每天都会在这套案例集上运行。

事故或回滚经过专家核实后，被加入评测集。评审器的每次修改都会在每日评测中接受全部案例的检验；分数提高就保留，没有提高就放弃，然后继续下一次修改。评测集也随着每次事故持续扩充。

我们通过人们如何处理评论来衡量噪声。如果不介意把大量非 bug 也报出来，那么找出更多 bug 并不难，所以我们需要对此加以检查。

我们会根据 PR 参与者的回应，对评审器的每条评论分类：修复了问题、认为判断有误、说明该行为是有意设计的，或者认定它无关紧要。

我们也会让评审器检查那些已知没有问题的 PR，统计它有多大概率提出会诱使人做出有害修改的意见。我们明确写下的优先级是：先发现真实 bug，再减少评审轮次。

当代码作者是 Agent 时，噪声的代价更高。人可以花几秒钟就把一个无关紧要的小问题略过，Agent 却会去修复，于是又多了一次提交和一轮评审。

评审必须能收敛。写代码的 Agent 和负责评审的 Agent，可能一直让彼此忙下去。有一个 CLI PR 在一夜之间经历了五十多轮评审和修复，最后由作者叫停。

我们对评审器反复指出的那些代码运行 git blame，发现其中大约 59% 在第一轮评审时就已经存在。

评审器很少是在发现新 bug，更多是每一轮又找出几个旧问题。

我们自己也加剧了这种情况。因为每一轮都能发现一些新问题，我们已经习惯默认多跑几轮。对高风险改动来说，这可能值得，但不适合每一个 PR。

现在，团队除了跟踪召回率，也跟踪通过评审所需的轮数，并调整了复审方式：

• 设置轮数上限。三轮之后，评审器会请作者停下来，重新考虑实现方案。

• 最初几轮之后，只复审新增的 diff。

• 指出一整类 bug，让作者修复所有同类问题，而不只是改一行。

• 不重复发布已经提出过的问题。

评审 Agent 还会每晚检查已有代码，帮助我们在旧 bug 出现在其他地方之前发现它们。

完成这些收敛优化后，内部 PR 中，一轮评审和修复就能通过的比例从 65% 提升到 78%；需要五轮及以上的比例从 8.9% 降到 1.5%；通过所需的平均评审次数从 2.08 降到 1.32。图中三组柱形分别比较各自指标。

哪些地方仍然需要人

为了发现一个常规错误，把一位资深工程师从深度工作中打断，成本远高于一次自动评审。在 Anthropic，我们的工作已经从阅读每一份 diff，转向机器不擅长的决策：

• 这件事到底该不该做？涉及方向、品味和范围。有个团队已经宣布解决了评审瓶颈，但仍保留对团队外部改动的人工评审，让人问一句：「我们究竟该不该做这个？」

• 高风险代码，例如计费、自动更新器和 CI 工作流。

• 架构。它会确立其他人随后沿用的模式。

• 阅读证据。测试输出、运行过的命令及其返回结果、截图，以及评审器发现的问题。如果你说不清这些检查可能漏掉什么，就应该请人认真评审，而不只是快速批准。

• 对结果负责。每一次发布的改动，都有一个人承担责任，不管代码是谁敲的。

自动检查贯穿整个流程，而上述五类决策仍由人来做。人从逐份阅读 diff，转向了机器不擅长的判断。

团队如何共享上下文

代码评审的第二项工作，一直是让团队传播和积累对代码库的理解。阅读同事的 diff，能让你知道改了什么，以及各个部分如何配合。

如果大部分阅读都交给了机器，人又该怎么学习代码？

我们没有为此建立正式流程。团队里没人能在脑中保存 Claude Code 的完整心智模型，我们也不认为有人需要做到这一点。

当有人想理解代码库里的某个部分时，他们会请 Claude 专门针对那一部分写一份讲解。几分钟就能完成，而且反映的是代码当前的状态。

图中以托管设置为例，只向 Claude 询问想了解的那一部分。有些人会进一步让 Claude 做一个小型可视化作品，把相关代码画出来，并按照自己喜欢的学习方式进行讲解。

如果目标是用好人的注意力，这比逐行阅读琐碎的 diff 更有效。改一行文案，几乎学不到什么；一份解释你马上要修改的模块的文档，却能让你学到很多。

我们默认在公开 Slack 频道里工作的文化也有帮助，因为你能在别人开发的过程中看到他们正在做什么。

谁合入，谁负责

如果你合入了一项小型或中型改动，后来还是出了问题，通常由你负责修复，这是团队的惯例。下面这些做法让它不至于变成一团糟：

• 改动要小，这样才容易评审、调试和回滚。

• 一切都可以撤销。功能开关、回滚和分阶段发布，让大部分错误能在几分钟内撤销。

• 影响范围决定要求。出错代价高的代码，需要更多人参与、更多检查。

• 通过遥测和内部使用，让回归问题尽快暴露。

• 这不是追究个人过错。由你负责修复，是因为你掌握的上下文最多；事故复盘关注的是系统。

责任也由团队共同承担。很多成员在公开频道 [8]里工作，任何人都能看到其他人在做什么、接手某个讨论，或者让 Claude 去补一个缺口。反馈也会来自并不负责那块代码的人。

这种开放性，是我们不必在每一行代码前都设置一道人工关卡，仍能保持高质量的重要原因。

什么时候改变方向

Agent 让启动一项工作的成本变得很低，因此有些工作最终不应该合入。

通常，频道里会有人问为什么要做、指出之前已有的决策，或提出更简单的路径，然后作者关闭 PR，或者重新调整它。

因为代码写得很快，关闭 PR 不会让人觉得损失很大。关键是在讨论中尽早提出不同方向，而不是等 PR 已经做完，再留下一条阻止合并的评论。

你的团队如何采用这套流程

要在自己的团队里实现这些做法，今天大部分所需的工具和机制都已经具备。

图中为简要概览，完整步骤包括安全评审和事故率监测等，见下面的清单。

提交 PR 之前

• 给 Agent 可执行的检查，并把它们列在简短的 CLAUDE.md 里，再加上运行格式化工具和 lint 工具的 hooks。

• 在本地运行 /code-review 和 /security-review，或者让使用全新上下文的子 Agent 做一次评审。

• 添加 REVIEW.md，把反复出现的评审意见写进去。

每个 PR 都要做的事

• 将 CI 设为必需，并在 PR 模板里加入「测试」「风险」「如何回滚」。

• 先在一个仓库接入 AI 评审器，例如 Code Review for Claude Code，或 Claude Code GitHub Action。用几周时间调整 REVIEW.md，再扩大范围。

• 加入自动安全评审，并要求所有评审讨论都处理完毕才能合并。

• 按风险投入评审精力：常规改动快速检查，漏掉 bug 代价高的地方深入评审。Code Review 中对应 Quick、Standard 或 Deep。

• 限制评审轮数；最初几轮之后，只复审新增的 diff。

人工审批

• 写清楚风险等级，并根据改动本身定级，而不是根据作者。先严格一些，有了证据再逐步放宽。

• 只对可信任的作者采用较宽松的审批流程。

• 使用 CODEOWNERS 和分支保护，确保身份认证、计费、CI 与发布工作流，以及安装程序始终需要人工参与。

• 不允许机器人的批准替代必需的人工批准；出现新提交时，让此前批准失效。

合并及之后

• 使用合并队列、功能开关、内部先用、分阶段发布和一键回滚。

• 把事故和回滚转化成评测集，每当评审器的提示词、工具或模型发生变化，就重新评分。

• 衡量人的时间投入，同时把回滚率和事故率作为约束。

接下来会怎样

Code Review 的发布公告 [9]说，批准 PR 仍由人来决定；产品会发布发现的问题，不会给出批准。

我们的内部仓库则走得更远，让负责人决定哪些低风险改动可以仅凭自动检查通过就合并，而且这条边界仍在变化。

当评审漏掉问题时，我们会追问模型当时缺少了什么信息，再把对应的改进写进 CLAUDE.md、某个 skill，或一项新的检查。

目标没有变：每次改动占用更少的人工时间，同时不比以前增加回滚。

如果你的团队也让 Agent 创建 PR，我们很想听听，你们已经自动化了哪些检查，哪些仍需要人参与，以及你认为我们哪里做得不对。

感谢 Emma Webb、Michael Segner 和 Amie Rotherham 对本文的审阅。

◇ ◆ ◇

[1] 5 月的大约 2,500 次，增长到了 9 月的 30,000 多次: https://www.anthropic.com/engineering/redesigning-source-control

[2] 最佳实践指南: https://code.claude.com/docs/en/best-practices

[3] 可能是获得好结果最重要的一件事: https://x.com/bcherny/status/2007179861115511237

[4] Code Review for Claude Code: https://code.claude.com/docs/en/code-review

[5] 推出研究预览版: https://claude.com/resources/articles/code-review

[6] Claude Code 自动安全评审: https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code

[7] 写过如何扩展 CI，以应对这样的代码量: https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic

[8] 公开频道: https://claude.com/product/tag

[9] 发布公告: https://claude.com/resources/articles/code-review

[10] 原文：How the Claude Code team does code review: https://claude.dev/blog/solving-code-review-at-anthropic/

跳转微信打开