Claude Code 团队怎么做代码评审：7 层防线，把人工时间压到最低

一句话结论：当 Agent 把代码产量拉高一个数量级后，"有没有人逐行读过代码"就不再是个有效的质量指标。Claude Code 团队给出的替代问题是：这个改动可能出什么错，哪一道检查（自动或人工）才是接住它的正确位置？ 按这个思路，他们把评审从"最后一道人肉闸门"改成"贯穿全程的连续检查"，并用数据兜底——2026 年 6 月到 9 月，Claude Code 代码库合并的 PR 数量翻了一倍多，而被回滚的占比下降了 40% 以上。

披露：本文编译自 Anthropic Claude Code 团队（Addy Osmani、Morgan Westlee Lunt、Qing Wang）2026-10-15 发布的工程文《How the Claude Code team does code review》。文中数据来自 Anthropic 内部实践，样本是自家团队与自家仓库，不代表所有团队的普遍效果。

我们此前说过：Claude 大约写了 Claude Code 自身 90% 的代码。那么按这个产量，我们到底怎么做代码评审？还有人读代码吗？如果出了事，谁来接住？

这篇文章讲 Claude Code 团队的代码评审流程，以及它是怎么演进的。从 6 月到 9 月，Claude Code 代码库上合并的 PR 数量翻了一倍多，而被回滚的比例下降了 40% 以上。

我们并没有取消评审。但我们确实把大部分"阅读"交给了机器，把优化的目标对准人的时间和注意力，并在"快速、方便地撤销错误"上做了大量投入。

一、重新理解代码评审的目的

当 Agent 写代码时，改动数量会迅速上升。在 Anthropic 的 monorepo 里，每天落地的改动从 5 月的约 2,500 次涨到 9 月的 30,000 次以上。

Claude Code 有独立于 monorepo 的自己的仓库，但同样承受着很大压力。当交付速度到这个量级时，人工逐行评审如果不是不可能，也极其困难。

代码评审做两件事：

1. 在上线前发现并修复问题；
2. 在团队里建立共享上下文和对代码库的理解。

本文主要讲第一件事，最后会回到第二件。

我们认为，"有没有人读过这段代码"是对"这个改动可能出什么问题、哪道检查该接住它"的一个不精确的替身指标。

换这个问题之后，评审发生的时间点也变了。以前，评审是道路尽头的关卡：写代码、开 PR、等同事。现在，评审是持续运行的，更像写作时的拼写检查。大多数改动在人被叫来看之前，已经被 Claude 至少评审并修过一遍。这接住了大部分例行错误，把团队的注意力省给更高级别的问题和更严格的审视。

二、最稀缺的资源：人的时间和注意力

我们希望把人力和注意力留给只有人能解决的问题，其余交给自动化检查。以我们当前的改动速率，人仍有大量工作要做，团队几乎每天都在遇到新的、没见过的挑战。

"人的时间"覆盖评审成本的两端：人花在评审上的时间，以及人花在修坏代码造成的后果上的时间。如果只是砍掉前者、后者却涨上来，那就没有省下任何东西。

所以目标定成：Claude Code 各仓库（CLI、桌面与 Web 应用、移动应用）的大多数 PR，最多只要一个人在环里就能合并（这个"人"可以是作者本人），同时回滚率和事故率不上升。为了度量人的时间，我们追踪每个 PR 的人工批准数（中位数与 95 分位）、人工评论数，以及 PR 等待某个人的时长。回滚率与事故率是护栏：一旦它们上升，就说明我们没有省下人的时间，只是把它搬到了别处。

三、一个改动的完整旅程

一个典型的改动，从工程师的笔记本（或 Slack 里的一个 Claude 会话）出发，会经过多层代码评审。

图注：一个 PR 的检查，自上而下。PR 之前，工作先被验证。每个 PR 上：必需的 CI、Claude 代码评审与安全评审（全自动），然后是按风险决定的人工批准。接着是合并队列；合并之后先给内部用的功能开关、灰度发布，最后一步是观察、向前修复或回滚。

大部分路径是自动化的；人的注意力只投到风险所在的地方。

四、逐层拆解

图注：六层自上而下堆叠：验证、必需 CI、AI 评审、安全评审、人工批准，以及合并队列加功能开关。每一层的漏洞位置不同；从一层漏下去的问题会被后面某一层接住；有一个问题穿过了每一层的洞，最后落在底部的快速回滚上。

每一层都会接住一些问题、漏掉另一些。很少有改动能穿过所有层，剩下的交给回滚。

1. 任何人看之前，工作先"自证"

现在大多数评审发生在 PR 存在之前。 我们给 Claude 一些它能运行的东西——比如测试、构建，或一张可以和设计稿对比的截图——并要求它展示输出，而不是口头说"做完了"。然后再由一个子代理用全新上下文复核 diff。这两个习惯都来自我们的最佳实践指南。

开 PR 之前，我们很多人还会跑几个内部 Skill：一个专门找 bug，一个简化 diff，一个做端到端的行为检查。UI 改动还会对照设计规范检查。

Claude Code 的创造者 Boris Cherny 说过，给 Claude 一种验证自己工作的方式，可能是拿到好结果最重要的一件事，他估计这能让最终结果好上 2 到 3 倍。他写道："验证在每个领域长得都不一样。它可能只是跑一条 bash 命令、跑一套测试，或者在浏览器或手机模拟器里试一下应用。"

当自动评审反复指出同一类问题时，我们从源头修：改 Skill、加 lint 规则，或者更新指导性文件，例如：

• CLAUDE.md 告诉 Claude 这个项目是什么：技术栈、约定、目标与非目标。每次评审都会加载它，所以在大型代码库里我们让它保持简短，再从那里指向别的文档。评审器也会标出违反其中约定的代码，以及让其中某一行过时的改动。
• REVIEW.md 由代码 owner 编写，告诉评审器"在这块代码里什么才重要"。我们单独检查评审器是否真的照做了。好的 REVIEW.md 都很短，它们说明这个仓库里"失败长什么样"（文档是"它在说谎"，配置是"它路由错了"）、给挑刺设上限、列出要跳过的路径，并要求给出文件和行号作为证据，而不是凭名字猜。它们还要求总结以一个数字开头，并在无事可修时直说。

2. 每个 PR 都过一遍 AI 评审

每个人工查看之前，每个 PR 都会先拿到一份 Claude 评审。 它会对照整个仓库和 PR 声明的意图来读 diff，并问：这个改动解决了它要解决的问题吗？它契合系统吗？它会破坏别的什么吗？

对于 bug 修复，它会去找根因。公开版本 Code Review for Claude Code 现在已在 Team 和 Enterprise 方案上正式可用；/code-review 可以在本地跑一个更轻量的版本。

我们发布研究预览版时，拿到实质性评审意见的内部 PR 占比从 16% 升到 54%。超过 1,000 行的大多数 PR 都会得到发现项，而大多数小 PR 干净返回。管理员可以把每个仓库设成 Quick、Standard 或 Deep。在"漏掉一个 bug 的代价高于多花评审时间"的地方，Deep 是值得的。

发现项在给人看之前，会先被其他 Agent 验证。 几个 Agent 同时找 bug，然后由另一组 Agent 对每个发现项投票，只有足够多的一致认为它是真的，才会被贴出来。只涉及风格、诊断信息或清理的发现会被丢掉。我们在自己的 PR 上对这些过滤器做过 A/B 测试，才决定保留。剩下的以行内评论的形式、按严重程度排序展示。每条都打了 Important / Nit / Pre-existing 标签，这样一个并非本 PR 引入的 bug，看起来就不会像是作者的锅。

每一条发现都必须被回应。 你要么修掉，要么带理由地关闭这个讨论串。通常某个 Agent 会连夜把修复做了，于是作者回来时，PR 已经又过了一轮。

3. 能阻断合并的安全评审

安全有它自己的一套自动评审。只要 bug 评审或安全评审还有任何发现项未关闭，这个 PR 就不能合并。你要么修掉，要么用一个简短理由关闭讨论串——这也是你清除误报的方式。

如果后续的提交把问题修好了，发现项会自动清除。你可以用开源的安全评审 GitHub Action 或 /security-review 命令搭出同样的东西。配置见 Claude Code 中的自动化安全评审。

4. 能阻断合并的自动化检查

常规的那套：lint、类型检查、各平台测试、构建。（关于我们如何为这个量级扩容 CI，这里写过。）一个典型的 CLI PR 在有人看之前，可能已经跑了几十项检查。PR 模板会问这个改动是怎么测的、怎么撤销。Claude 可以代填，但提出这个改动的人要为它签字。

5. 按风险分级的人工批准

修一个文档和改一个自动更新器，风险完全不同，所以它们的评审也不同。

分级由改动决定，而不是由作者决定。 一个分类器读取改动并给出它的风险等级；第二个分类器再问：即便按等级不需要人，这个具体改动是否仍然需要另一个人？有些路径永远需要人——owner 标记为敏感的任何东西，以及任何 CI 工作流文件。

只有受信任的作者能走更轻的路径。 只有仓库受信任名单上的作者（基本就是拥有它的团队）能走更轻的路径，其他人都需要第二个人批准。Agent 的批准永远不算人的批准。 自动评审可以放行一个低风险改动，但它不能顶替一个必须由人占的位子。

是谁让 Agent 干的，谁就要负责。 在一个 Agent 写的 PR 上，指挥 Agent 的人算作必需的评审人之一，和亲手敲了这份代码一样。

一次批准只覆盖一个特定提交。 如果之后落了系统无法担保的新提交（比如 Agent 的一次 push，或某人手动解冲突的结果），批准就必须重新给。

6. 合并队列、开关与灰度发布

合并队列会把改动应用后、对着 main 重跑所有检查，这样两个各自通过的 PR 不会合并出一个坏掉的 main。新行为通常先藏在功能开关后发给 Anthropic 内部员工，我们的大规模使用常常能在用户之前暴露回归。公开发布先进 latest 通道，stable 通道跟在后面。

7. 快速发现、快速回滚

总会有错误漏过去，所以最后一层的关键是快速接住它。开关不需要部署就能关掉。Claude Code 有每周的 on-call 轮值，事故复盘会问：哪一层本该接住这个问题？

发现一次坏合并，仍然依赖作者和 on-call，以及回滚与事故看板。我们还没有"当这些数字变动时自动收紧批准"的熔断器；在把更多代码推向"零人工合并"之前，工程师们希望先有它。

一位同事说过：放慢速度确实会降低出错率，但主要是因为你什么都做得更少。我们更愿意在"更快发现和修复问题"上变强。

五、我们怎么把评审器变得更好

我们的代码评审流程是在一个循环里不断改进的。

每次事故现在都是一道评测题。 团队把过去造成事故的 PR 收集起来，连同它们的向前修复与回滚，让熟悉那段代码的工程师确认每个 bug 以及它藏在哪。评审器每天对着这个集合跑。

图注：一次事故或一次回滚，变成一个经专家确认的用例，加入评测集。对评审器的任何改动都进入每日评测运行，对每个用例打分；分数上升就保留，下降就丢弃，然后循环进入下一个改动。

评测集随着每次事故增长，而评审器的每一次改动都要对全部用例打分。

我们通过观察人怎么处理评论来衡量噪声。 只要你不在乎误报，多抓 bug 很容易，所以我们需要一个约束。我们把评审器留下的每条评论，按 PR 上那个人的反应分类：他修了、他说评错了、他说这是有意为之、他判定不重要。我们还会拿评审器去跑已知是干净的 PR，统计它多久报一个"会引导人做出有害改动"的东西。我们写下来的优先级是：先抓真 bug，其次才是减少评审轮数。

当作者是 Agent 时，噪声的代价更高。 人可以在几秒内挥手忽略一个 nit；Agent 会去修它，于是又产生一次提交、又一轮评审。

评审必须收敛。 一个 Agent 作者和一个 Agent 评审可以让彼此无限忙下去。有一个 CLI PR，在作者叫停之前，连夜经历了 50 多轮评审与修复。

我们对着评审器反复指出的内容跑 git blame，发现约 59% 是评审器第一遍时就已经在那里的代码。评审器很少在找新 bug，它只是每一轮都多找出几个旧 bug。

我们自己还把它变得更糟了。 我们习惯了默认跑好几轮，因为每一遍都能抓到点新东西。这对高风险改动或许值得，但不该对每个 PR 都这样。团队现在把"通过所需轮数"和召回率放在一起追踪，并改了重新评审的方式：

• 轮数上限。 超过三轮后，评审器会请作者退一步、重新考虑方案。
• 首轮之后只看 diff 评审。
• 标出 bug 的类别，让作者修掉每一处，而不是只修一行。
• 不重复已经贴出过的发现。

评审 Agent 还会每夜对着既有代码跑，帮我们在老 bug 冒到别处之前就抓住它们。

图注：收敛工作前后的对比：一轮评审加修复就通过的 PR 从 65% 升到 78%；需要五轮或更多的 PR 从 8.9% 降到 1.5%；通过所需平均评审轮数从 2.08 降到 1.32。

收敛改动之后，每个内部 PR 的评审轮数下降。

六、人还在哪些环节

把一位资深工程师从深度工作中拉出来、就为了接住一个例行错误，代价远高于一次自动评审。在 Anthropic，我们的工作已经从"读每一份 diff"转向"做机器不擅长的判断"：

• 这到底该不该做？ 方向、品味和范围。有一个宣称已解决评审瓶颈的团队，仍然对来自团队之外的改动保留人工评审，就是为了有人能问一句"这事我们到底该不该做？"
• 高风险代码，比如计费、自动更新器和 CI 工作流。
• 架构——会定下供他人复制的模式的改动。
• 读证据。 测试输出、跑过的命令和它的返回、一张截图、评审器的发现项。如果你说不出这些检查会漏掉什么，那就去要一次真正的评审，而不是快速点个通过。
• 为结果负责。 每一个上线的改动都有人负责，不管是谁敲的代码。

图注：自动化检查全程运行，中间有五个由人决定的点：该不该做、高风险代码、架构、读证据、为结果负责。

人从"读每一份 diff"转向"做机器不擅长的判断"。

七、在团队内共享上下文

代码评审的第二件事，一直是扩散对代码库的理解。读队友的 diff，是了解"改了什么、各块怎么拼起来"的途径。如果大部分阅读都交给了机器，那大家还怎么学代码？

我们没有为此设计正式流程。 团队里没有人脑子里装着 Claude Code 的完整心智模型，我们也认为没人需要。当某人想弄懂代码库的某个部分时，就让 Claude 专门为那个切片写一份讲解。这只要几分钟，而且反映的是代码当下的样子。

我们中有些人更进一步，让 Claude 构建一个小工具，把代码的那部分可视化，并按这个人喜欢的学习方式讲给 ta 听。

如果目标是把人的注意力花好，这比逐行读琐碎的 diff 强得多。一行文案改动教不了你什么；为你要改的模块写一份讲解，能教你很多。 我们"默认在公开 Slack 频道里干活"的文化也有帮助，因为你能在别人构建的过程中就看到他们在做什么。

八、"你合并，你负责"

如果你合入一个中小改动、之后还是出了问题，团队惯例通常是由你来修。有几件事让这不会变糟：

• 改动很小，所以容易评审、调试和回滚。
• 一切可撤销。 开关、回滚和分阶段发布能在几分钟内撤掉大多数错误。
• 影响面决定标准。 昂贵的代码会有更多人、更多检查。
• 回归出现得快，通过遥测和内部使用。
• 这不是追责。 负责修复意味着你最了解上下文；事故复盘看的是系统。

负责也是共享的。 团队很多人工作在公开频道里，任何人都能看到别人在建什么、接起一个话题，或把 Claude 指向一个缺口；反馈也来自并不拥有这段代码的人。这种开放，是"不给每一行都设关卡、质量却依然高"的重要原因。

九、什么时候我们改变方向

Agent 让"开始一件事"变得很便宜，所以有些工作不该落地。通常是频道里有人问为什么、指回早先的一个决定，或建议一条更简单的路，然后作者关掉或重塑这个 PR。

因为代码写起来很快，关掉 PR 不会让人有损失感。 诀窍是尽早在讨论串里提出不同方向，而不是等到 PR 完成后再丢一条阻断性评论。

十、你的团队怎么落地这套流程

做这件事所需的大部分零件，今天都已经存在。

PR 之前

• 给 Agent 一些它能跑的检查，写进一份简短的 CLAUDE.md，再加一些运行 formatter 和 linter 的 hook。
• 本地跑 /code-review 和 /security-review，或用全新上下文的子代理评审。
• 加一份 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 与发布工作流、安装器永远需要人。
• 绝不让 bot 的批准替代必需的人工批准；新提交时作废旧批准。

合并与之后

• 用合并队列、功能开关、先内部使用、分阶段发布和一键回滚。
• 把事故与回滚变成评测集，评审器的提示词、工具或模型一变，就重新打分。
• 度量人的时间，以回滚率与事故率作护栏。

十一、接下来走向哪里

Code Review 的发布说明说，批准一个 PR 仍然是人的决定；产品发布的是发现项，不是批准。我们自己的仓库走得更远：让 owner 决定哪些低风险改动可以仅凭自动化检查合并，而这条线还在移动。

当一次评审漏掉什么时，我们会问模型当时眼前缺了什么，然后把修复放进 CLAUDE.md、一个 Skill 或一道新检查里。目标从没变过：每个改动花更少的人力，而回滚不比以前多。

如果你的团队也让 Agent 开 PR，我们很想听听：你自动化了哪些检查、哪些仍然需要人、以及你觉得我们哪里做错了。

感谢 Emma Webb、Michael Segner 和 Amie Rotherham 的评审。

Sources

• Addy Osmani, Morgan Westlee Lunt, Qing Wang, How the Claude Code team does code review, claude.dev, 2026-10-15：https://claude.dev/blog/solving-code-review-at-anthropic/

相关阅读：AI 编程 / Vibe Coding 完全指南 ｜ Agent 交付验收：claimcheck 与三树差分门 ｜ 如何高效审查 AI 生成的代码 ｜ 多 Agent 编排：Triglav 的三层评审复盘

本文由汇智网编译整理，转载请注明出处。文中的数据来自 Anthropic 内部实践，具体效果取决于你的团队规模、仓库与风险偏好。

这是「AI 编程 / Vibe Coding」专题的一部分。完整地图见：AI 编程 / Vibe Coding 完全指南