Claude Code 团队怎么做 Code Review

原文：Addy Osmani（改写 Anthropic Claude Code 团队）

https://x.com/addyosmani/status/2114604912520921136

我们之前提过，Claude Code 大约 90% 的代码是由 Claude 写的。那在这种体量下，Code Review 怎么做？还有人读代码吗？代码出问题了怎么办？

这篇文章讲的是我们 Claude Code 团队的 Code Review 流程，以及我们怎么把它改得更好。从 6 月到 9 月，合进 Claude Code 代码库的 Pull Request 数量翻了一倍多，不得不回滚的 PR 占比下降了超过 40%。

我们没有停止做 Code Review。我们把大部分「读代码」的工作自动化了，并围绕节省人的时间和精力来调优。我们也在「更快、更容易回滚错误」上投入了大量精力。

重新思考 Code Review 的目标

有 Agent 写代码之后，变更量会迅速上去。在我们的 monorepo 里，每天合入的变更从 5 月大约 2,500 次，涨到了今年 9 月超过 30,000 次。

Claude Code 虽然不在这个 monorepo 里，但压力同样很大。节奏这么快时，逐行人工 Review 会越来越难，甚至根本做不到。

Code Review 有两个目的：

在上线前发现并修好 bug
让团队对代码库形成共同理解

这篇文章主要讲第一个目标；第二个会在文末讨论。

我们不再把「有没有人读过这段代码？」当成精确指标，而改问：「这次变更可能出什么问题？用哪种检查（自动化或人工）最适合拦住它？」

这个问题也改变了 Review 的时机。传统上，Code Review 是事后检查：代码写完、PR 开好，再等人来看。我们则把 Review 嵌进工作流里，更像写字时一直开着的拼写检查。

大多数变更在请人看之前，至少已经被 Claude Review 并改过一轮。这样能拦住大部分常规 bug，把人的注意力留给更高层的判断。

人的时间和注意力

我们希望把人的时间和注意力留给只有人能处理的事，同时用足够的自动化覆盖其余部分。即便按现在的节奏，人要做的事仍然非常多，团队几乎每天都会碰到新问题。

因此，「人的时间」是双向成本。我们不仅要算人花在 Review 上的时间，还要算坏代码引入 bug 之后，人花在修 bug 上的时间。如果只减前者、不减后者，其实并没有省下人的时间。

所以我们的目标是：Claude Code 相关仓库（CLI、桌面与 Web 应用、移动应用）里的大多数 PR，最多只需要一个人介入（可以是作者本人）就能合入，同时不让回滚率和事故率上升。

我们用每条 PR 的人工审批数中位数（以及第 95 百分位）、人工评论数，以及 PR 等人的等待时长，来跟踪「人的时间」。回滚率和事故率是护栏：这些指标一上去，就说明我们只是把人的时间挪了地方，并没有真正减下来。

一次变更会经历什么？

一次典型变更，无论来自工程师的笔记本，还是 Slack 里的 Claude 会话，都会经过多层 Review。

上图是一次典型 Claude Code 变更，从作者环境到生产环境的路径。大部分流程是自动化的，人的注意力集中在风险较高的部分。

我们有六层检查，再加上一套回滚机制，处理漏网的问题。

每一层都会拦住一部分 bug，也会漏掉一部分。很少有 bug 能穿过所有层；就算穿过了，我们也有回滚兜底。

1. PR 之前的验证

我们大部分 Review 发生在开 PR 之前。我们会让 Claude 做「能跑出结果」的事，比如跑测试、跑构建，或把截图和设计稿对比。不是说「做完了」就算数，而是要它把结果拿给我们看。然后，再用一个上下文全新的子 Agent 去 Review 这次 diff。这两种做法都写进了我们的最佳实践指南。

开 PR 之前，很多人还会跑一批内部 skill：找 bug、压缩 diff、端到端验证，以及对照设计规范检查 UI 改动。

Claude Code 的创建者 Boris Cherny 认为，给 Claude 配上验证流程，大概是提高产出质量最关键的一步。

他估计，验证流程能把 Claude 产出质量提升大约两到三倍。

不同领域的验证流程差别很大：

有时只是跑一条 bash 命令；有时是跑一整套测试；有时是在浏览器或手机模拟器里测 App。

如果自动化 Reviewer 总在标同一类问题，我们就从源头修：改 skill 本身、加 lint 规则，或更新这类文档：

CLAUDE.md：项目说明文件，用来给 Claude 项目上下文（技术栈、约定、目标、非目标）。Claude Code 每次 Review 都会读这个文件，所以在大型代码库里我们尽量写短，其余文档在这里引用。代码违反了这里的约定，或更新让文件内容过时，Reviewer 就会标出来。

REVIEW.md：由代码负责人告诉 Reviewer，在自己负责的这块代码里什么才重要。我们还会单独核查 Reviewer 是否真的按这些指南在做。写得好的 REVIEW.md 通常很短，重点包括：

定义什么叫项目失败（文档不该撒谎；配置不该指错路由）
限制抠细节
定义可忽略路径
要求给出文件 + 行号引用，不许猜文件名
要求顶层摘要，包含问题数量，并明确写「无问题」

2. 每个 Pull Request 都有 AI Review

每个 PR 在人工 Review 之前，都会先过一轮 Claude Review。

它会对照整个代码库，以及作者在 PR 里写明的意图来分析 diff，检查：改动是否真的解决了问题、是否融入更大系统、是否破坏了代码库其他部分。

Review bug fix 时，bot 会尽量找根因。

我们面向公众的产品 Code Review for Claude Code，现已对所有 Team 和 Enterprise 客户开放。本地也有更轻量的版本：/code-review。

自从发布 research preview 以来，我们内部 PR 收到实质性 Review 评论的比例，从 16% 升到了 54%。Code Review 能在大多数超过 1,000 行的 PR 上检出问题，在大多数较小的 PR 上给出干净结果。管理员可以把仓库配置成 Quick、Standard 或 Deep 模式。Deep 适合「漏掉一个 bug 的代价，高于多花时间 Review」的场景。

发现结果在交给人看之前，还会再过几轮其他 Agent 核查：

多个 Agent 并行找 bug
另有一轮投票决定某条发现是有效还是误报，只有票数够才确认
纯风格 / 诊断 / 清理类发现会被滤掉（我们先在自己的 PR 上 A/B 测过这些过滤器，再全量上线）

剩下的发现会以行内评论呈现，按严重级别排序，并标成：

Important
Nit
Pre-existing（避免因 PR 没引入的旧 bug 不公平地惩罚作者）

所有发现都必须处理：修好，或带理由关掉这条讨论。很多时候，会有 Agent 在夜里就把问题修掉，作者回来时，PR 已经又过了一轮 Review。

3. 可以拦合并的安全 Review

我们还会跑自动化安全 Review。只要还有未关闭的发现（无论来自 Code Review 还是安全 Review），PR 就不能合。作者可以修问题，也可以用简短理由关掉讨论（我们处理误报的方式）。

后续 commit 如果解决了问题，对应发现会自动关闭。你也可以用开源的安全 Review GitHub Action，或 /security-review 命令做同样的事。详见 Claude Code 里的 automated security reviews 指南。

4. 会拦合并的自动化检查

标准检查：lint、类型检查、各平台测试、构建。（我们写过如何扩展 CI 的文章。）一次典型 CLI PR，在任何人看之前，可能已经跑过几十项检查。PR 模板里有「怎么测的」「怎么回滚」这类问题。Claude 可以帮你填，但作者有责任核对。

5. 按风险缩放的人工审批

有些变更风险更高（比如改文档 vs 改自动更新器），需要的 Review 级别也不同。

层级由变更本身决定，不由作者决定。一个分类器根据变更判定风险级别；另一个分类器判断：即便层级没要求，这次变更是否仍需要额外审批。有些路径永远需要再审一遍：负责人标为敏感的路径，以及任何 CI workflow 文件。

只有仓库可信名单上的作者，才适用放宽的 Review 要求，通常就是拥有该仓库的团队。其他人必须有第二个人批准。Agent 的批准不算人工批准。自动化 Review 可以放行低风险变更，但在需要人的时候，不能替代人。

变更作者对变更负责。如果 PR 是 Agent 开的，操作这个 Agent 的人始终算作必需的 Reviewer 之一。一次 PR 批准只对一个 commit 有效。如果又来了一个不可信的新 commit（比如 Agent 推了东西，或有人手动解决了合并冲突），PR 必须重新批准。

6. Merge Queue、功能开关与分阶段放量

Merge Queue 保证：变更合进 main 时，所有检查会在「已带上这次变更的 main」上再跑一遍。这能避免两个各自成功的 PR 合在一起把 main 弄坏。新功能通常挂在功能开关后面，Anthropic 员工先用。因为我们大量使用自己的产品，很多回归我们会比用户更早发现。

对外放量时，先上 latest 通道，stable 通道稍后跟上。

7. 快速反馈与回滚

总会有一些坏合并漏网。这是最后一道防线，重点是尽快发现。挂在功能开关后面的变更，可以不部署就关掉。

Claude Code 有每周 on-call 轮值。任何事故复盘都会回头看：本该是哪一层拦住这个问题。除了盯回滚和事故看板，作者和 on-call 仍有责任发现坏合并。我们还没有根据这些指标自动调节审批要求的「断路器」机制，但这是我们在减少合入人工干预时正在考虑的方向。

有位同事提到，放慢节奏、减少产出，确实可能提高准确率，但那多半是因为总工作量下降了。我们真正优先的是：更快发现并纠正问题。

我们怎么让 Reviewer 变得更好

我们的 Code Review 流程是持续改进的循环：

我们把事故当作评估指标。团队收集导致事故的 PR、对应的 fix-forward 和回滚，再让熟悉代码库的工程师核实每个 bug 的位置和对错。Review 系统每天对照这批样本做评估。

每一起事故都会加入样本集；对 Review 系统的每一次改动，都会对照整套样本重新评估。

为了衡量噪声，我们观察人对 Review 评论的反应。如果愿意报很多非 bug，提升「找 bug 率」很容易，所以必须约束。我们把每条 Review 评论按当事人处理方式分类：修了、拒绝了、说明是有意为之，或判定不重要。另外，我们也会在已知干净的 PR 上跑 Review 系统，观察它多常报出会造成有害变更的东西。

我们明确的优先级是：第一，检出真实 bug；第二，减少 Review 轮次。

作者是 Agent 时，处理一条 Review 评论的成本更高。人关掉一条 nit 只要一秒；Agent 处理它则意味着再提交一次，再走一轮 Review。

Review 过程必须能收敛。Agent 作者和 Agent Reviewer 有可能永远互相改下去。我们在 CLI 项目里观察到过一个 PR，夜里来回超过五十轮，都是 Agent 作者和 Agent Reviewer 在来回改。后来是人手停掉的，否则可能无限继续。

我们对 Review 系统反复标出的内容做 git blame，大约 59% 是第一轮就已存在的代码。也就是说，系统很少在找新 bug，而是每轮再多挖出一点旧问题。

我们还把事情弄得更糟：习惯默认多跑几轮 Review，因为每轮可能发现不同的 bug。对高风险变更，多轮迭代有用；但对每个 PR 都这样做没必要。团队开始同时跟踪「到通过为止的轮次数」和召回率，并改了重新 Review 的规则：

限制轮次。三轮之后，Review 系统会要求作者重新评估做法。
初始几轮之后，重新 Review 只看新 diff。
点明 bug 类别，让作者一次改整类问题，而不是只改一行。
避免重复报已经见过的问题。Review Agent 也会在夜里对当前代码库跑一遍，帮我们在历史 bug 扩散前发现它们。

（文中配图：内部 PR 平均 Review 轮次在 Convergence 之后下降。）

人还在回路里做什么

让一位资深工程师停下手头工作，去 Review 一个常见错误，成本远高于把这件事自动化。但人工 Reviewer 对有些任务仍然必不可少：

该不该做这件事？ 决定要不要做、定产品愿景、品味和目标。

有个声称已经解决 Code Review 瓶颈的团队，对团队外部提交的变更仍然做人工 Review，确认「这是不是该做的事」。

审计危险代码（计费、自动更新器、CI workflow）。

架构 Review，因为这些选择会成为别人遵循的约定。

核实证据（测试输出、跑过的命令、截图、Reviewer 评论）。如果你说不清这些检查会漏什么，就别只求一个 👍，你需要真正的 Review。

承担责任。 每个上线的变更，都有人对它负责，不管字是谁打的。

团队上下文

Code Review 一直还有另一层作用：传达代码库的变化。读同事变更的 diff，通常是人理解「改了什么、代码库怎么工作」的方式。如果大部分阅读交给机器，人又怎么学代码库？

我们没有正式机制。团队里没有人脑子里装着完整的 Claude Code 心智模型，我们也不认为需要有。想了解某块代码时，大家会让 Claude 就那一片生成讲解。只要几分钟，而且讲解永远是最新的。

有些人还会多走一步：让 Claude 生成一个小工件，把这块区域可视化，并用自己喜欢的风格来教。

这比逐行读琐碎 diff（比如改一行文案）更能把人的注意力花在有用的地方。改模块前先生成一份讲解，学到的东西多得多。

另外，我们默认公开：在开放的 Slack 频道里工作，边做边看到别人在建什么。

「你合入，你负责」

如果你合入的是小到中等变更，之后出了问题，一般期望你自己修。这之所以不会失控，有几个原因：

小变更容易 Review、调试和回滚。
几乎都能回滚。功能开关、回滚、分阶段放量，多数错误几分钟内就能撤销。
爆炸半径决定标准。更贵的代码，眼睛和验证也更多。
回归会被遥测和内部使用很快暴露出来。
不是甩锅游戏。修问题的人拥有它，因为他们上下文最多。事故复盘看的是系统。

再加上，很多人通过开放频道分担责任。任何人都能看到别人在做什么、加入讨论，或让 Claude 找缺口。反馈也不只来自代码负责人。这种开放，是质量能在「不必给每一行设闸」的情况下仍然很高的重要原因。

中途转向

有了 Agent，开新活很便宜，但有时不该开。典型情况是：频道里有人指出这条路径不对（引用过往决定，或提出更好路径），作者就关掉 PR，或改实现。

因为一开始写代码很容易，关掉 PR 也不觉得亏。关键是尽早在讨论线程里转向，而不是等到 PR 定稿再发一条拦路评论。

怎么落地

这套做法的大部分组件，你的团队已经可以用上。

PR 之前

给 Agent 一份它能跑的检查清单，写进简短的 CLAUDE.md
用 hooks 让 Agent 调用 formatter 和 linter
本地跑 /code-review 和 /security-review，或让一个新上下文的子 Agent Review 改动
建一个 REVIEW.md，用来跟踪反复出现的 Review 问题

每个 Pull Request

强制跑 CI
在 PR 模板里加上「Testing」「Risk」「How to revert」
先在一个仓库接入 AI Reviewer（Code Review for Claude Code，或 Claude Code GitHub Action），先在 REVIEW.md 上迭代几周，再扩到更多仓库
加上自动化安全 Review
要求合入前所有 Review 讨论都已解决
按风险分配 Review 力度：常规变更快速过，高风险区域（bug 很贵）做彻底 Review。Code Review 有 Quick、Standard、Deep 三档
限制 Review 轮次；几轮之后只 Review 新 diff

审批

定义风险级别，按变更定，不按作者定。先严，再根据证据逐步放宽
宽松审批路径只留给可信作者
Bot 批准不能用来满足必需审批。有新 commit 推上来时，撤销已有批准
指定人来审批控制鉴权、计费、CI、发布流程以及安装器的代码与策略。用 CODEOWNERS 和分支保护落地

合入与合入之后

搭 Merge Queue
试用功能开关
先放给内部用户
分阶段放量
做一键回滚机制
用事故和回滚日志建一套评估集
每次改 Reviewer 的 prompt、工具或模型，都重新打分
跟踪人的投入，用回滚率和事故率做护栏

接下来往哪走

Code Review 发布时的设想是：最终批准仍由人做。产品只负责贴出发现。但在我们自己的仓库里，我们走得更远：负责人在决定，哪些低风险变更在自动化检查通过后可以自动合入。这条边界还会继续演进。

所以，每当 Reviewer 漏掉什么，我们会问：模型上下文里缺了什么？然后把它写进 CLAUDE.md、做成 skill，或加一条新检查。目标没变：降低每次变更需要的人力，同时把回滚率维持在不高于现在的水平。

如果你也允许 Agent 开 Pull Request，欢迎告诉我们：你自动化了哪些检查、哪些还必须有人、我们哪里做得不对。

（本文改写自我们的原文，并用 Pangram 做过检查。）