> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude Code 团队怎么做代码评审：7 层防线，把人工时间压到最低
- URL: https://www.hubwiz.com/blog/claude-code-team-code-review/
- Published: 2026-10-17T17:08:11.000Z
- Updated: 2026-10-17T17:09:25.000Z
- Description: Claude 写了约 90% 的自家代码。Claude Code 团队把阅读交给机器、把判断留给人：7 层评审、按风险定人、快速回滚。
- Author: admin
- Tags: AI 编程, 代码评审, Claude Code, AI Agent

**一句话结论**：当 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。这两个习惯都来自我们的[最佳实践指南](https://code.claude.com/docs/en/best-practices?ref=hubwiz.com)。

开 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](https://code.claude.com/docs/en/code-review?ref=hubwiz.com) 现在已在 Team 和 Enterprise 方案上正式可用；`/code-review` 可以在本地跑一个更轻量的版本。

我们[发布研究预览版](https://claude.com/resources/articles/code-review?ref=hubwiz.com)时，**拿到实质性评审意见的内部 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 中的自动化安全评审](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code?ref=hubwiz.com)。

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

常规的那套：lint、类型检查、各平台测试、构建。（关于我们如何为这个量级扩容 CI，[这里](https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic?ref=hubwiz.com)写过。）一个典型的 CLI PR 在有人看之前，可能已经跑了**几十项检查**。PR 模板会问这个改动是怎么测的、怎么撤销。Claude 可以代填，但**提出这个改动的人要为它签字**。

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

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

| 风险 | 例子                           | 需要的人工批准            |
| -- | ---------------------------- | ------------------ |
| 低  | 文档、文案、仅内部的功能、开关后的增量改动        | 自动化评审与安全检查变绿后，不需要人 |
| 中  | 普通产品改动，以及缓存、自动更新器、系统提示词等敏感区域 | 1 人                |
| 高  | 风险最高的代码，加上一组永远需要两人过目的路径      | 2 人                |

**分级由改动决定，而不是由作者决定。** 一个分类器读取改动并给出它的风险等级；第二个分类器再问：即便按等级不需要人，这个具体改动是否仍然需要另一个人？**有些路径永远需要人**——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 **专门为那个切片写一份讲解**。这只要几分钟，而且反映的是代码当下的样子。

![图：如果机器完成了大部分阅读，人要怎么学习代码？左侧网格代表代码库，几个方块高亮为 managed settings，也就是你想弄懂的那部分，没有人脑子里装着它的完整心智模型。一条标着"就这个切片问 Claude"的箭头，示例问题是"Claude Code 是怎么检索 managed settings 的？"引向两个结果：一，Claude 写一份讲解，耗时几分钟，反映代码当下的样子；二，对一些人来说，Claude 会构建一个小工具，把代码的那部分可视化，并按这个人喜欢的学习方式来讲。底部：逐行读琐碎的 diff，一行文案改动教不了你什么；为你要改的模块写一份讲解，能教你很多。](https://www.hubwiz.com/blog/content/images/2026/10/img_b5759f750e186e107c34379e748782c3.png)

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

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

## 八、"你合并，你负责"

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

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

**负责也是共享的。** 团队很多人工作在[公开频道](https://claude.com/product/tag?ref=hubwiz.com)里，任何人都能看到别人在建什么、接起一个话题，或把 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 的[发布说明](https://claude.com/resources/articles/code-review?ref=hubwiz.com)说，**批准一个 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/](https://claude.dev/blog/solving-code-review-at-anthropic/?ref=hubwiz.com)

**相关阅读**：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/) ｜ [Agent 交付验收：claimcheck 与三树差分门](https://www.hubwiz.com/blog/agent-delivery-verification-gates/) ｜ [如何高效审查 AI 生成的代码](https://www.hubwiz.com/blog/how-to-review-ai-generated-code-efficiently/) ｜ [多 Agent 编排：Triglav 的三层评审复盘](https://www.hubwiz.com/blog/triglav-multi-agent-orchestration/)

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

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)