从 6 月到 9 月，合进 Claude Code 代码库的拉取请求翻了一倍以上，必须回退的比例掉了四成以上。
我们没有拿掉评审。我们把大部分阅读交给机器，按人的时间和注意力来优化，并且花了很多力气，让犯错之后撤起来又快又容易。
1重新想代码评审是干什么的
代理写代码的时候，改动量涨得很快。Anthropic 的单体仓库里，每天落地的改动从今年 5 月大约 2,500 条涨到 9 月超过 30,000 条。
Claude Code 住在自己的仓库里，跟单体仓库分开，压力也很大。发得这么快，一行一行人工审，极其难，近乎做不到。
代码评审干两件事：
- 发出去之前找出问题并修好
- 在团队里建立共享的上下文，以及对代码库的理解
这篇文章主要写找出问题并修好。第二件我们快结束时再回来。
我们觉得，「有没有人读过这段代码」测不准「这次改动会出什么错，哪一种检查——自动的还是人的——适合拦住它」。
这个问题也改了评审发生的时间。以前，评审是路尽头的一道闸：写代码，开拉取请求，等同事。现在，评审一直在跑，更像你写字时的拼写检查。请人看之前，大多数改动已经被 Claude 审过并修过至少一次。常规错误大多在这里拦住，团队的注意力留给更高一层的问题和细看。
2稀缺的是人的时间和注意力
我们想把人的时间和注意力留给只有人能解的问题，其余交给自动检查。按我们现在的改动速度，人要做的事仍然多得吓人，团队几乎每天都会碰上新的、没见过的难题。
人的时间覆盖评审成本的两边：人花在审上的时间，以及人花在修坏代码弄出来的麻烦上的时间。砍掉前一块，如果时间只是出现在后一块，并不算帮到忙。
所以目标是：Claude Code 这些仓库（命令行、桌面和网页应用、移动应用）里，大多数拉取请求合并时最多一个人在场，这个人可以是作者，同时回退和事故不增加。为了量人的时间，我们跟踪每条拉取请求的人工批准数（中位数和 95 分位）、人工评论，以及一条拉取请求等人的时长。回退率和事故率是护栏：这两项涨了，我们就没有省下人的时间，只是把它挪了地方。
3一层一层
一条典型的改动，从工程师的电脑（或者 Slack 里的一次 Claude 会话）出发，经过多层代码评审。路径的大部分是自动的；人的注意力去风险所在的地方。
1. 别人看之前，工作已经验证过
现在大多数评审发生在拉取请求出现之前。我们给 Claude 一件它能跑的东西——测试、构建，或者一张对照设计的截图——然后要它出示输出，而不是说做完了。再让一个子代理带着新的上下文审 diff。这两条习惯来自我们的 best-practices。
开拉取请求之前，我们很多人还会跑几项内部技能：一个找 bug，一个简化 diff，一个从头到尾检查行为。界面改动还会对照设计规范检查。
Claude Code 的作者 Boris Cherny 说过，给 Claude 一个验证自己工作的办法，大概是最重要的一件事，才能拿到好结果。他估计最终结果会好两到三倍，并且写：「验证在每个领域长得不一样。它可能只是跑一条 bash，或者跑一套测试，或者在浏览器、手机模拟器里试这个应用。」
自动评审反复标出同一件事，我们就在源头修：技能里、一条 lint 规则里，或者改说明文件，例如：
CLAUDE.md告诉 Claude 这个项目是什么：技术栈、约定、目标和非目标。每次评审都会加载，所以在大代码库里我们写短，从那里指向别的文档。评审也会标出违反其中约定的代码，以及让其中一行过时的改动。REVIEW.md由代码负责人写，告诉评审在他们这块代码里什么要紧。我们另外检查评审是不是真的照着做。好的那些很短。它们说出这个仓库里失败长什么样（文档是「它撒谎」，配置是「它指错路」），限制挑剔的数量，列出可跳过的路径，并且要求文件和行号作证据，不要凭名字猜。它们还要求摘要以计数开头，没事可修就直说。
2. 每条拉取请求都有 AI 评审
每条拉取请求在人看之前都过一遍 Claude 评审。它对照整仓和这条请求声明的意图读 diff，并且问：这次改动解没解决问题、合不合系统、有没有弄坏别处？
修 bug 时，它找根因。公开版本是 Code Review for Claude Code，现在 Team 和 Enterprise 方案已经正式可用。本地的 /code-review 跑一个更轻的版本。
我们 发布研究预览 的时候，内部拉取请求拿到实质评论的比例从 16% 到 54%。超过 1,000 行的大多数会有发现，小的大多数干净回来。管理员按仓库设 Quick、Standard 或 Deep。漏一个 bug 比多花评审时间更贵的地方，Deep 值得。
发现贴给人看之前，要过别的代理验证。几个代理同时找 bug。然后另一组对每条发现投票，够票才贴。只谈风格、诊断或清理的丢掉。这些过滤器我们在自己的拉取请求上做过 A/B 才留下。剩下的按严重程度排成行内评论。每条标 Important、Nit 或 Pre-existing，这条请求没引入的 bug 不会看起来像作者的错。
每条发现都要答复。你要么修，要么关掉线程并写原因。常常有代理夜里接着修，作者回来时这条拉取请求已经又过了一轮。
3. 能挡住合并的安全评审
安全也有自己的自动评审。bug 评审或安全评审还有发现开着，拉取请求不能合并。你要么修，要么用一句短原因关掉线程，假阳性就是这样清掉的。
后面的提交修好了这个问题，发现会自己清掉。你可以用开源的安全评审 GitHub Action，或者 /security-review 命令，搭出同样的东西。搭法写在 Claude Code 的自动安全评审。
4. 能挡住合并的自动检查
老一套：lint、类型检查、每个平台的测试、构建。（我们写过 这个量级下怎样扩 CI。）一条典型的命令行拉取请求，在任何人看它之前，可能跑几十项检查。拉取请求模板问这次改动怎么测过、怎么撤。Claude 可以填，但要这次改动的那个人签字。
5. 人的批准，按风险缩放
改文档和改自动更新器，带着不一样的风险，所以它们得到不一样的评审。
| 风险 | 例子 | 要几个人批准 |
|---|---|---|
| 低 | 文档、文案、仅内部功能、开关后面的增量改动 | 自动评审和安全检查绿了，可以不要人 |
| 中 | 普通产品改动，以及对缓存、自动更新器、系统提示这类敏感区的改动 | 一个人 |
| 高 | 最高风险的代码，外加一小批路径永远要两个人 | 两个人 |
档位由这次改动定，不由作者定。一个分类器读这次改动，挑它的风险档。第二个分类器再问：即便档位说不用，这一次要不要再叫一个人。有些路径永远要人：负责人列为敏感的任何东西，以及任何 CI 工作流文件。
更轻的路径只给受信任的作者。只有仓库信任名单上的作者能走更轻的路径，多半是拥有这块代码的团队。其他人都要第二个人批准。代理的批准也永远不算人的。自动评审可以放行低风险改动，填不了「必须有人」的那个空位。
谁提示了这次改动，谁就对它负责。代理写的拉取请求上，指挥代理的人算一个必需的评审人，和自己敲代码一样。
一次批准覆盖一个具体提交。如果落到系统无法担保的新提交，比如代理再推一次，或者有人手工解决了合并冲突，批准要重给。
6. 合并队列、开关、逐步发布
合并队列把每项检查对着已经打上这次改动的 main 再跑一遍，这样两条各自通过的拉取请求合不到一条坏掉的 main 上。新行为通常先开关给 Anthropic 员工，我们自己用得重，常常在用户之前就把回归顶出来。公开发布先走 latest 通道。stable 跟着它。
7. 发现得快，撤得快
有些错还是会漏过去，所以最后一层是尽快抓住它们。开关可以关，不必重新部署。Claude Code 有每周值班，事故复盘会问哪一层该拦住这个问题。
发现一次坏合并，仍然靠作者和值班，以及回退和事故看板。我们还没有在这些数字动起来时收紧批准的断路器；这里的工程师希望先有它们，再把更多代码放到零人工合并。
有同事说，放慢确实会把错误率压下去，多半是因为你每件事都做得更少。我们宁可在发现和修好问题上变得更快。
4我们怎样让评审变得更好
我们的代码评审一直在一个循环里改进。
事故现在变成评测。团队收集了过去导致事故的拉取请求，连同后续修复和回退，让熟悉那块代码的工程师确认每个 bug 和它所在的位置。评审每天对着这套跑。
噪声我们按人对评论做了什么来量。多抓 bug 很容易，只要你不在乎标出一大堆不是 bug 的东西，所以我们需要一项检查顶住这个。我们把评审留下的每条评论，按拉取请求上的人怎么回应来分类：他们修了、说标错了、说行为是故意的，或者觉得无所谓。我们也把评审跑在已知干净的拉取请求上，数它报出会让人做出有害改动的次数。写下来的优先级是：先抓真 bug，再减评审轮次。
作者是代理的时候，噪声更贵。人几秒就能挥掉一条挑剔。代理会去修，于是又一次提交、又一轮评审。
评审必须收敛。代理作者和代理评审可以互相喂活，停不下来。有一条命令行拉取请求夜里修了五十多轮，作者才叫停。
我们对评审一直在标的东西跑了 git blame，大约 59% 是评审第一轮就已经在的代码。评审很少在找新 bug，每一轮多找出几个旧的。
这有我们自己的份。我们习惯了默认多跑几轮，因为每轮总能再抓到一点。风险高的改动值得，每条拉取请求都这么跑不值得。团队现在同时盯「过关要几轮」和召回，并且改了复审：
- 轮次上限。三轮之后，评审请作者停下来，重新考虑做法。
- 前几轮之后，只审新增的 diff。
- 标出这一类 bug，让作者修每一处，不是修一行。
- 已经贴过的发现不再重复。
评审代理夜里也会在现有代码上跑，帮我们在旧 bug 出现在别处之前抓住它们。
5人还留在哪些地方
把资深工程师从深入的工作里拉出来抓一个常规错误，比自动评审贵得多。在 Anthropic，我们的工作已经从读每一份 diff，挪到机器做不好的决定：
- 该不该做这件事？方向、口味、范围。有个团队宣称评审瓶颈已经解开，对外来改动仍留人审，好有人问「我们到底该不该做」。
- 风险高的代码，比如账单、自动更新器、CI 工作流。
- 会被别人照着抄的架构。
- 读证据。测试输出、跑过的命令和它返回了什么、截图、评审的发现。你说不出这些检查会漏什么，就去要一次真审，不要快速批准。
- 对结果负责。发出去的每一条改动都有人对它负责，不管字是谁敲的。
6在团队里共享上下文
代码评审的第二份工作，一直是把对代码库的理解摊开。读同事的 diff，是你知道改了什么、各块怎么接上的办法。如果大多数阅读由机器做，人怎么学代码？
我们没有正式流程。团队里没有人在脑子里装着完整的 Claude Code，我们也不认为需要。有人想搞懂某一块，就让 Claude 只给那一块写一份说明。几分钟，对着今天的代码。
我们有些人还会再往前一步，让 Claude 做一个小物件，把那一块画出来，按那个人喜欢的方式教。
如果目标是把人的注意力花好，这比一行一行读琐碎的 diff 强。一行文案改动几乎什么也教不到。你正要改的那个模块的说明，能教到很多。我们默认在公开 Slack 频道里干活也帮了忙，别人在建什么，你在他们建的时候就看得见。
7「你合进去，你接着」
你合进去一条小的或中等的改动，后面还是出了问题，团队规范是：通常由你来修。几件事让这条规范不至于走歪：
- 改动小，所以好审、好查、好撤。
- 每件事都能撤。开关、回退、分批发布，多数错误几分钟就能解开。
- 爆炸半径定门槛。贵的代码，要更多人和更多检查。
- 回归冒得快，靠遥测和内部使用。
- 这不是问责。拥有一次修复，是因为你上下文最多；事故复盘看系统。
所有权也是分担的。团队很大一部分在 公开频道 里干活，谁都能看见别人在建什么、接过一个线程、或者把 Claude 指到一个缺口上，反馈也来自并不拥有这块代码的人。质量能在没有「每一行都有闸」的情况下站住，这种敞开是很大一块。
8方向改了怎么办
代理让开工变便宜，所以有些活不该合进去。通常频道里会有人问为什么、指到更早的决定、或者提出更简单的路，作者关掉或改形状。
代码写得快，关掉拉取请求不像亏了一笔。窍门是尽早在线程里提出另一个方向，不要等成品上再当阻塞评论。
9你可以怎样把这套接过来
和你的团队一起做这件事，大多数零件今天已经有了。
拉取请求之前
- 给你的代理能跑的检查，写进一份短的
CLAUDE.md，再加上跑格式化和 lint 的钩子。 - 本地跑
/code-review和/security-review，或者一个新上下文的子代理评审。 - 加一份
REVIEW.md，把反复出现的评审评论搬进去。
每条拉取请求上
- 要求 CI，并在模板里加上「怎么测的」「风险」「怎么撤」。
- 加一个 AI 评审（Code Review for Claude Code，或 Claude Code GitHub Action）到一个仓库，把
REVIEW.md调几周，再铺开。 - 加自动安全评审，并且要求合并前每一条评审线程都关掉。
- 让评审力度跟风险匹配：常规改动快速过，漏一个 bug 很贵的地方用深的（Code Review 里的 Quick、Standard 或 Deep）。
- 给评审轮次设上限；前几轮之后，只复审新增的 diff。
批准
- 写下风险分档，由这次改动定，不由作者定；先严，有证据再松。
- 更轻的批准路径只留给你信任的作者。
- 用 CODEOWNERS 和分支保护，让鉴权、账单、CI 和发布工作流、安装器永远要人。
- 永远不要让机器人的批准顶掉一个必需的人的批准；新提交上来就撤掉旧批准。
合并之后
- 用合并队列、功能开关、先内部用、分批发布、一步回退。
- 把事故和回退收成评测集，评审的提示、工具或模型一改，就重新打分。
- 量人的时间，回退率和事故率当护栏。
10这套东西在往哪走
Code Review 的发布说明说过，批准一条拉取请求仍然是人的决定；产品贴的是发现，不是批准。我们自己的仓库走得更远，允许负责人决定哪些低风险改动只靠自动检查合并，那条线还在往前挪。
评审漏了什么的时候，我们问模型当时眼前少了什么，再把修补写进 CLAUDE.md、一项技能，或一条新检查。目标没变：每条改动少用人的时间，回退不比以前多。
如果你的团队让代理开拉取请求，我们想听听你们把哪些检查自动化了、哪些仍然要人，以及你觉得我们哪里说错了。
感谢 Emma Webb、Michael Segner 和 Amie Rotherham 审过原文。
11出处
这篇是译文。原文 Claude Code 团队，How the Claude Code team does code review，2026-10-15。16% 到 54% 写在 2026-03-09 的 Code Review 发布说明，口径是当时内部拉取请求。日合并 2,500 到 30,000 写在 Redesigning source control，口径是 Anthropic 单体仓库，不是 Claude Code 这个仓。约九成代码由 Claude 写，是原文「我们说过」的说法，这篇没有新的测量。回退掉四成以上没有绝对条数。59% 和五十多轮只在原文里，我没有核过分母。
文中「一层一层」那张图按原文 FIG B 重画，中文标注。学习代码那张图来自原文。