审查里变了什么
Claude Code 团队报告，合并进 Claude Code 代码库的拉取请求从 6 月到 9 月增加到两倍以上，不得不回滚的比例下降了 40% 以上。ClaudeDevs 于 2026年10月16日发布了这些数字。拉取请求的比较区间是 6 月到 9 月，这个区间的年份没有写出。
团队还报告，Anthropic 的 monorepo 从今年 5 月每天约 2,500 个落地变更，到 9 月每天超过 30,000 个。这些每日计数属于 monorepo。Claude Code 住在自己的仓库里，与那个 monorepo 分开，团队说这个仓库承受的压力也很大。团队把手工逐行审查称为，在变更以这种速度发出去时极其困难，有时不可能。团队说审查仍然有两件事：在发出去之前抓住问题，以及建立对代码库的共同理解。文章主要跟着“发出去之前抓住问题”，在接近结尾时回到对代码库的共同理解。
团队说自己问的问题是，这项变更可能出什么错，以及哪一种检查，自动的还是人的，应该抓住它。审查以前要等到拉取请求打开。现在在变更还在写的时候就运行，团队说大多数变更在请人看之前，已经至少被 Claude 审查并修过一次。
拉取请求还不存在时，Claude 必须展示一项它自己能跑的检查的输出，例如测试、构建，或与设计对比的截图。随后，一个带着新上下文的子代理，也就是与写出这次变更的会话分开的一轮，审查 diff。团队里许多人还会运行内部检查，用来找缺陷、简化 diff，并把行为从头到尾试一遍。UI 变更会对照设计指南检查。创建 Claude Code 的 Boris Cherny 把给 Claude 一种验证自己工作的办法，称为对好结果而言大概最重要的事。他估计这会让最终结果好两到三倍。他把验证描述为一条 bash 命令、一套测试，或浏览器或手机模拟器里的应用。文章把这个倍数作为他的估计来呈现。
随后，每个人看之前，每个拉取请求都会对照整个仓库和写明的意图接受审查。对缺陷修复，审查者寻找根因。在研究预览阶段，团队说带有实质性审查评论的内部拉取请求比例从 16% 升到 54%。这个数字没有附带预览日期，也没有客户侧比率。超过 1,000 行的拉取请求大多会有发现，小的大多干净返回。
团队叠了六层检查，下面是回滚，然后把快速发现和回滚描述为第七个阶段。
- 拉取请求之前：展示代理能运行的检查输出，然后由一个新上下文的子代理阅读 diff。
- 拉取请求上：Claude 对照仓库和写明的意图审查 diff。
- 安全审查：按团队规则，未关闭的缺陷审查或安全审查发现会挡住合并。
- CI：lint、类型、测试和构建仍然会挡住。
- 人工批准：变更的风险决定等级。更少的人数只给受信任的作者，其余人都需要第二个人。
- 发布：合并队列，先给员工的功能开关，latest 渠道，然后是 stable。
- 发出之后：不部署就关掉功能开关，事故复盘询问哪一层本应抓住这次遗漏。
按风险批准，以及公开产品
在 Anthropic 自己的 Claude Code 仓库里，决定等级的是变更，不是作者。分类器阅读变更，并选择低、中或高。即使等级本身不要求，第二个分类器仍可以再要求一个人。所有者列为敏感的路径，以及任何 CI 工作流文件，仍然需要一个人。
表里更轻的路径，只有仓库受信任名单上的作者能走，大多是拥有该仓库的团队。这份名单是与等级分开的一道门。其余所有人都需要第二个人。代理的批准永远不算作一个人的批准。自动审查可以放行低风险变更，但不能填上要求人的名额。在代理写的拉取请求上，指挥该代理的人算作一名必需审查者，和他们亲手打出这次变更一样。一次批准覆盖一个提交。之后的代理推送，或手工解决的合并，需要再次批准。
是否做这项变更，如何处理计费、自动更新器和 CI，这项变更是否树立别人会照抄的模式，测试输出和发现是否足够，以及谁对结果负责，仍然由人决定。发出去的每一项变更，责任仍在人身上。
Claude Code 的 Code Review 已在 Team 和 Enterprise 计划上正式提供。管理员把每个仓库设为 Quick、Standard 或 Deep。这些是审查者看得多深的深度。团队解释的是 Deep：用在漏掉一个缺陷的代价高于额外审查时间的地方。/code-review 命令在本地运行一个更轻的版本。团队文章没有写价格，也没有说哪些计划可以运行本地命令。
若干代理同时找缺陷。另一组随后投票，只有足够多人同意它是真的，发现才会发布。必须有多少人同意，没有公布。在这个拉取请求审查者上，只涉及风格、诊断或清理的发现会被丢掉。团队说，这些过滤器先在自己的拉取请求上做了 A/B 测试，然后才保留。留下的会标成 Important、Nit 或 Pre-existing。Pre-existing 标出的是这次拉取请求没有引入的缺陷。每条发现要么被修好，要么附上理由关闭讨论串，误报就是这样清掉的。之后修好该问题的提交会自行清掉这条发现。
按 Claude Code 团队的规则，未关闭的缺陷审查或安全审查发现会挡住合并。文章把想要这种拦截的读者指向开源的 security review GitHub Action 和 /security-review。Team 和 Enterprise 计划上的 Code Review 发布发现，并把批准留给人。它不会打开团队的合并拦截。在 Anthropic 自己的仓库里，所有者决定哪些低风险变更只凭自动检查就合并，团队说这条线一直在移动。这个选择与受信任作者名单分开，名单决定谁得到更轻的路径。
关于本地命令，Claude Code 更新日志说，在没有调校审查设置的模型上（包括 Opus 5.5 和 Sonnet 5.5），medium effort 的 /code-review 也会报告清理项和 CLAUDE.md 约定方面的发现。在拉取请求审查者上，只涉及风格、诊断和清理的发现会被丢掉。
| 风险 | 例子 | 人工批准 |
|---|---|---|
| 低 | 文档、文案、仅内部功能、功能开关后面的增量变更 | 自动审查和安全检查通过后，不要求人 |
| 中 | 普通的产品变更，以及对缓存、自动更新器或系统提示等敏感区域的变更 | 一个人 |
| 高 | 风险最高的代码，加上一小部分始终需要两个人的路径 | 两个人 |
如何试同一套流程
拉取请求之前，团队把读者指向简短 CLAUDE.md 里列出的、代理能运行的检查，以及运行格式化工具和 lint 的钩子。它也指向本地的 /code-review 和 /security-review，或一个新上下文的子代理。CLAUDE.md 写着技术栈、约定、目标和非目标。每次审查都会加载它，所以团队把它保持得很短。代码所有者写的 REVIEW.md 说明该区域的失败长什么样，给细碎意见封顶，列出要跳过的路径，要求用文件和行号作为证据，并要求摘要以还剩多少要修的计数开头。同一条意见反复出现时，团队把修复移进一项技能、一条 lint 规则，或这些文件之一。
每个拉取请求上，lint、类型检查、测试和构建仍然会挡住。模板要求填写 Testing、Risk 和 How to revert。Claude 可以起草这些部分。请求这次变更的人来签字确认。三轮之后，审查者请作者重新考虑做法。之后的轮次审查新的 diff。作者被要求修一整类缺陷，已经发布的发现不重复，审查代理也会在夜间跑过现有代码。团队内部拉取请求图表的说明写着，那些收敛方面的改动之后，每个拉取请求的审查轮次更少了。说明没有给次数。
批准方面，按变更写下等级，把更轻的路径留给你信任的作者，并且不让机器人填上必需的人工席位。用 CODEOWNERS 和分支保护，让认证、计费、CI、发布工作流和安装器始终需要一个人。当新提交无法被担保时，撤销已有批准。
他们的发布路径使用合并队列。队列会在应用了该变更的 main 上重跑每一项检查，因此两个分别通过的拉取请求不能合成一个坏掉的 main。新行为通常先在功能开关后面发给员工。公开发布先到 latest 渠道，stable 渠道跟在后面。stable 比 latest 晚多久，没有公布。功能开关不用部署就能关掉。过去的事故拉取请求、向前修复和回滚，由了解这些代码的工程师确认，审查者每天对着这组材料运行。这次每日运行的分数没有公布。
仍然只是目标的部分
目标是，Claude Code 的各个仓库，即 CLI、桌面和网页应用，以及移动应用，大多数拉取请求在至多一个人参与的情况下合并，这个人可以是作者，并且回滚和事故不上升。文章陈述了目标。它没有说目标已经达到。6 月到 9 月的证据是数量和回滚比例。
人的时间用每个拉取请求的批准次数中位数和第 95 百分位、人工评论，以及拉取请求等人多久来跟踪。回滚率和事故率是护栏：如果它们上升，团队说时间是被挪走了，并没有省下来。这些中位数、评论数和等待时间没有公布。
Claude 编写了 Claude Code 约 90% 代码这句话，团队说自己以前说过。本文没有包含这一比例的计数方法。
会在回滚或事故数字变动时收紧批准的熔断器还没有就位。团队的工程师希望，在更多代码转向没有人工批准的合并之前先有它们。没有给出交付日期。发现一次糟糕的合并，仍然取决于作者、每周值班轮换，以及回滚和事故仪表板。事故复盘会问哪一层本应抓住这个问题。
有一个 CLI 拉取请求在作者叫停之前，一夜之间经历了五十轮以上的审查和修复。团队把它讲成代理作者和代理审查者让彼此一直忙的一个例子。人可以在几秒内丢掉一条细碎意见。代理会去修它，这意味着又一次提交和又一轮审查。团队说，对审查者反复标出的内容做 git blame，发现大约 59% 是第一轮就已经存在的代码，审查者很少找到新缺陷，而是每一轮再找到几处旧的。文章没有给出这 59% 的样本量。
团队用人们如何处理评论来衡量这种噪声。每条评论按拉取请求上的回应分类：修好了、说它错了、说这是有意的，或当作无关紧要放到一边。审查者也会在团队知道是干净的拉取请求上运行，团队统计它有多经常报告出一件会让人做出有害变更的事。写下来的优先级是，先抓住真缺陷，其次才是减少审查轮次。
共同理解没有正式流程。需要代码库某一片的人，请 Claude 为那一片写一份说明，有些人还让 Claude 做一个小作品来教这一片。团队说，开放的 Slack 频道会在工作建造的过程中把它展示出来。对小或中等变更，落地它的人通常会去修后来的失败。他们点名的保障是小 diff、功能开关、回滚、分阶段发布，以及快速的内部使用。因为代理让开工变得便宜，文章说队友应当在讨论串早期就追问方向，关闭拉取请求是寻常的事。
来源
相关来源
资料与编写依据
本文依据 2026年10月16日的 ClaudeDevs 帖子，以及同一天核对过的其所链 claude.dev 文章 How the Claude Code team does code review，再加上 Claude Code 更新日志中的一条说明：在没有调校审查设置的模型上（包括 Opus 5.5 和 Sonnet 5.5），medium effort 的 /code-review 也会报告清理项和 CLAUDE.md 约定方面的发现。团队文章没有写价格，也没有说哪些计划可以运行本地命令。安全审查的安装步骤、最佳实践指南、另外的 Code Review 发布公告，以及更晚的更新日志条目，都不在本文范围内。图表说明写的是，收敛方面的改动之后，内部审查轮次下降了，但没有给出次数。每日事故评估有描述，没有公布分数。