本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

How the Claude Code team does code review

How do you review code at the volume agents produce it? On the Claude Code team, once we had high coverage and deep reviews, we started optimizing for the minimum amount of human review time that doesn’t raise reverts or incidents.

当代码由 AI 代理以如此巨大的体量生成时，你该如何进行代码审查？在 Claude Code 团队，当我们实现了高覆盖率和深度审查后，我们开始寻求优化，以在不增加回滚或事故的前提下，将人工审查时间降至最低。

We’ve said before that Claude writes about 90 percent of Claude Code’s own code. So how do we review code at the volume we produce it? Does anyone read code anymore? And if something breaks, who catches it?

我们之前提到过，Claude Code 自身约 90% 的代码是由 Claude 编写的。那么，我们如何审查如此大体量的代码？还有人会去阅读代码吗？如果出现故障，谁来发现它？

This post covers the code review flow on the Claude Code team and how it has evolved. From June to September, merged pull requests to Claude Code’s codebase more than doubled while the share that had to be reverted fell by more than 40 percent.

本文介绍了 Claude Code 团队的代码审查流程及其演变过程。从 6 月到 9 月，Claude Code 代码库中合并的拉取请求（PR）数量翻了一番多，而需要回滚的比例则下降了 40% 以上。

We didn’t remove review. But we did move most of the reading to machines, optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes.

我们并没有取消审查。但我们将大部分阅读工作交给了机器，优化了人类的时间和注意力，并投入大量精力确保能够快速、轻松地撤销错误。

When agents write code, the number of changes goes up, fast. In Anthropic’s monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September this year.

当代理编写代码时，变更数量会迅速增加。在 Anthropic 的单体仓库中，每日提交的变更从 5 月的约 2,500 次增加到今年 9 月的超过 30,000 次。

Claude Code lives in its own repository, separate from the monorepo, but it’s seeing a lot of pressure too. When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible.

Claude Code 拥有独立的仓库，与单体仓库分开，但它也面临着巨大的压力。当交付速度如此之快时，逐行进行人工代码审查即使不是不可能，也是极其困难的。

Code review does two jobs:

代码审查主要承担两项工作：

This article mainly focuses on finding and fixing issues, but we will come back to the second job near the end.

本文主要关注发现和修复问题，但我们会在文末回到第二项工作。

We think “did a human read the code?” is an imprecise proxy for “what could go wrong with this change, and which check—automated or human—is the right one to catch it?”

我们认为，“是否有人阅读过代码？”并不是衡量“此变更可能出现什么问题，以及哪种检查（自动化或人工）最适合发现它”的精确指标。

Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague.

提出这个问题也改变了审查的时机。过去，审查是流程末端的关卡：编写代码、提交 PR、等待同事审核。

Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.

现在，审查是持续进行的，更像是写作时的拼写检查。在请求人工查看之前，大多数变更至少已经由 Claude 审查并修复过一次。这捕获了大部分常规错误，并将团队的注意力节省下来，用于处理更高级别的问题和审查。

We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest. At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily.

我们希望将人类的时间和注意力留给只有人类才能解决的问题，并确保自动化检查能处理其余部分。按照我们目前的变更速度，人类仍有大量工作要做，而且我们的团队几乎每天都会遇到新的挑战。

Human time covers both sides of review’s cost: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first doesn’t help if the time just shows up in the second.

人工时间涵盖了审查成本的两个方面：人们花费在审查上的时间，以及修复糟糕代码所引发问题的时间。如果仅仅减少前者，而时间却消耗在后者上，那是没有意义的。

So the goal is that most pull requests in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time, we track human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, we haven’t saved human time, we’ve only moved it.

因此，我们的目标是 Claude Code 仓库（CLI、桌面和 Web 应用，以及移动应用）中的大多数拉取请求在合并时，最多只需一人参与（可以是作者本人），且不增加回滚或事故。为了衡量人工时间，我们跟踪每个 PR 的人工批准数（中位数和 95 分位数）、人工评论以及 PR 等待人工处理的时长。回滚率和事故率是我们的护栏：如果这些指标上升，说明我们并没有节省人工时间，只是转移了时间成本。

A typical change, from an engineer’s laptop (or a Claude session in Slack), goes through multiple layers of code review.

一个典型的变更，从工程师的笔记本电脑（或 Slack 中的 Claude 会话）开始，会经过多层代码审查。

Most review now happens before a PR exists. We give Claude something it can run—like tests, a build or a screenshot to compare against the design—and ask it to show the output instead of saying it’s done. Then a subagent reviews the diff with fresh context. Both habits come from our best-practices guide.

现在，大多数审查在 PR 创建之前就已经完成。我们给 Claude 提供它可以运行的内容——比如测试、构建或与设计进行对比的截图——并要求它展示输出结果，而不是仅仅说“完成了”。然后，一个子代理会带着全新的上下文审查差异。这两个习惯都源自我们的最佳实践指南。

Before opening a PR, many of us also run a few internal skills: one hunts for bugs, one simplifies the diff, and one checks the behavior end to end. UI changes also get checked against our design guidelines.

在打开 PR 之前，我们许多人还会运行一些内部技能：一个用于查找 Bug，一个用于简化差异，还有一个用于端到端检查行为。UI 变更也会根据我们的设计指南进行检查。

Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results. He estimates it makes the final result two to three times better, and writes, “Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator.”

Claude Code 的创建者 Boris Cherny 认为，为 Claude 提供验证其工作的方法，可能是获得良好结果的最重要因素。他估计这能使最终结果提升两到三倍，并写道：“验证在每个领域看起来都不同。它可能简单到运行一个 bash 命令，或者运行一个测试套件，又或者在浏览器或手机模拟器中测试应用。”

When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files such as:

当自动化审查工具不断标记相同的问题时，我们会在源头修复它：通过技能、Lint 规则，或者更新指令文件，例如：

Every pull request gets a Claude review before a person looks. It reads the diff against the whole repo and the PR’s stated intent, and asks: does the change solve its problem, fit the system, or break something else?

每个拉取请求在人工查看之前都会先经过 Claude 的审查。它会根据整个仓库和 PR 的既定意图读取差异，并询问：该变更是否解决了问题、是否符合系统要求，或者是否破坏了其他功能？

On a bug fix, it looks for the root cause. The public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans, and /code-review runs a lighter version locally.

在修复 Bug 时，它会寻找根本原因。公开版本“Code Review for Claude Code”现已在 Team 和 Enterprise 计划中全面推出，而 /code-review 命令可在本地运行轻量级版本。

When we launched the research preview, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings, and most small ones come back clean. Admins set each repo to Quick, Standard, or Deep. Deep is worth it where one missed bug costs more than the extra review time.

当我们推出研究预览版时，获得实质性审查评论的内部 PR 比例从 16% 上升到了 54%。大多数超过 1,000 行的 PR 都会有发现，而大多数小型 PR 则显示正常。管理员将每个仓库设置为“快速”、“标准”或“深度”模式。在遗漏一个 Bug 的代价高于额外审查时间的情况下，深度模式是值得的。

Findings get verified by other agents before humans review them. Several agents look for bugs at the same time. Then a separate group votes on each finding, and it only gets posted if enough of them agree it’s real. Findings that are only about style, diagnostics, or cleanup get dropped. We A/B tested those filters on our own PRs before keeping them. What’s left shows up as inline comments sorted by severity. Each is tagged Important, Nit, or Pre-existing, so a bug the PR didn’t introduce doesn’t look like the author’s fault.

在人工审查之前，发现的问题会由其他代理进行验证。多个代理同时查找 Bug。然后，一个独立的组对每个发现进行投票，只有在足够多的代理认为它是真实问题时，才会发布。仅涉及风格、诊断或清理的发现会被丢弃。我们在保留这些过滤器之前，已经在自己的 PR 上进行了 A/B 测试。剩下的内容会以按严重程度排序的内联评论形式显示。每个评论都标记为“重要”、“小问题”或“预存问题”，这样 PR 未引入的 Bug 就不会被误认为是作者的过错。

Every finding has to be answered. You either fix it or resolve the thread with a reason. Often an agent picks up the fix overnight, so the author comes back to a PR that’s already been through another round.

每个发现的问题都必须得到回应。你要么修复它，要么给出理由解决该讨论串。通常，代理会在夜间自动修复问题，因此作者回来时，会发现 PR 已经经过了新一轮的审查。

Security gets its own automated review too. A PR can’t merge while any finding from the bug review or the security review is still open. You either fix it or close the thread with a short reason, which is how you clear a false positive.

安全性也有其专属的自动化审查。只要 Bug 审查或安全审查中还有未解决的发现，PR 就无法合并。你要么修复它，要么用简短的理由关闭讨论串，这就是清除误报的方法。

If a later commit fixes the issue, the finding clears on its own. You can set up the same thing

如果后续提交修复了该问题，发现的问题会自动清除。你可以设置同样的功能。