资料名称： Anthropic 官方博客《How the Claude Code team does code review》，即 Claude Code 团队代码审查实践长文，作者 Addy Osmani、Morgan Westlee Lunt、Qing Wang，2026 年 10 月 15 日发布

帖内资料： 七层检查流程（提交前验证、必过 CI、AI 代码审查、独立安全审查、风险分级人工审批、合并队列与灰度、快速发现与回滚）、风险分级的三档与对应人数、AI 发现的验证与标签机制、把事故转成评测集的闭环、审查轮次收敛的具体改动与前后对比数据，以及 Claude Code 仓库自身的审查强度分档设置

时间覆盖： 长文发布于 2026 年 10 月 15 日；文中统计区间为 6 月至 9 月；讨论串于 2026 年 10 月 16 日提交

许可与引用： 官方博客页面与官方文档页面均未公布转载许可；本贴只整理其中已公开的流程、分档与数字，不复制原文图片、不整段转载

适用任务： 想了解 AI 大量写代码之后审查该怎么重排的，想按风险而不是按人头分配人工审批的，想解决 AI 审查反复刷同一问题、越改越长的

一篇讲自家工程实践的官方长文，配一篇官方产品文档。文章回答的是：当代码产出量涨到原来的两三倍、人手没变，代码审查这一步该怎么改。文章不长，但把流程分层、每层的通过条件、人工介入的触发条件都写清楚了，还给出了改动前后的对比数字。

文章先给背景：Claude 写的代码约占 Claude Code 自身代码量的 90%。在 Anthropic 的 monorepo 里，每天落地的变更从 5 月的约 2500 次涨到 9 月的 3 万次以上。Claude Code 团队自己也有压力，因为 Claude Code 是独立仓库，同样在承受这个增速。

从 6 月到 9 月，合并进 Claude Code 代码库的 PR 数量翻了一倍以上，而需要回退的比例下降了 40% 以上。文章的结论是：审查没有被取消，而是把大部分阅读交给了机器，把人的时间留给真正需要人拿主意的事，并大幅提高了撤销错误的效率。

文章还点明评审的第二个职责——在团队里建立对代码库的共同理解——并说机器接管大部分阅读后这一职责怎么办，后面单独有一节讲。

文章把人的时间拆成两半：一是花在审查上的时间，二是花在修坏代码上的时间。只砍第一项而时间转移到第二项没有意义，所以两个一起算。

衡量人的投入，团队跟踪三项：每个 PR 的人工批准次数（看中位数和 95 分位）、人工评论数，以及 PR 等待人的时长。回退率和事故率是护栏——这两项一涨，就说明并没有省下人的时间，只是把它挪了地方。

目标写成一句话：Claude Code 各仓库（命令行、桌面与网页应用、移动应用）的大多数 PR，最多只让一个人进入流程，那个人可以是作者本人，同时回退率和事故率不上升。

文章的流程图把路径分成提交前、每个 PR 上、合并时、合并后四段。

提交前是验证环节：Claude 跑测试、构建和 lint；再由第二个 agent 在全新上下文里审一遍 diff。团队的做法是给 Claude 一件能跑的东西——测试、构建、或者一张用来和设计稿比对的截图——要它把输出摆出来，而不是只说完成了。

每个 PR 上的必过 CI 包括 lint、类型检查、各平台测试、构建与打包，红了直接挡合并。安全审查是独立一遍，bug 审查或安全审查里任何一条未关闭的发现，都不允许合并。

合并时进合并队列，所有检查在最新 main 上带着改动重跑一次，这样两个各自通过的 PR 不会合出一个坏掉的 main。

合并后是灰度：新行为通常先挂在开关后面只对 Anthropic 员工开放，公共发布先进最新渠道，稳定渠道跟在后面；作者和值班同学盯着，出问题就快速关开关回退。

第一层是提交前验证。文章说这是最重要的一层，理由是大部分审查现在发生在 PR 还不存在的时候。Claude Code 的作者 Boris Cherny 认为，给 Claude 一个验证自己工作的方式可能是拿到好结果最重要的一件事，他的估计是这能让最终结果好上两三倍。

反复被自动审查标出的问题，团队在源头堵：放在 skill 里、加一条 lint 规则，或者更新说明文件。CLAUDE.md 告诉 Claude 这个项目是什么——技术栈、约定、目标和不做什么，每次审查都会加载它；在大代码库里这份文件保持简短并指向别的文档。REVIEW.md 由代码负责人写，说明自己那片代码里什么才算失败——文档类的是"它撒谎"，配置类的是"它走错路由"——它会限制细枝末节的数量，列出该跳过的路径，并要求给出文件和行号作为证据而不是凭名字猜，还要求摘要先给数量、没东西要改就直说。

第二层是每个 PR 都有的 AI 审查。它对着整个仓库和 PR 声明的意图读 diff，追问这个改动是否解决了它的问题、是否契合这个系统、有没有弄坏别的东西。修 bug 时它找根因。

第三层是能挡合并的安全审查，同样是自动的。开源安全审查 GitHub Action 和 /security-review 命令可以配成同样的行为。

第四层是必过的自动化检查。一个典型的命令行 PR 可能在有人看之前跑了几十项检查。PR 模板里要写这次改动怎么测的、怎么回退，Claude 可以代填，但提出改动要求的人要签字。

第五层是按风险分配的人工审批，这一层是文章最核心的部分，详见下一节。

第六层是合并队列、开关与灰度发布，上面已经说过。

第七层是快速发现与快速回滚。文章承认仍会有漏网的，所以最后一层是快速抓到。开关不用部署就能关掉；Claude Code 有每周轮值的 on-call，事故复盘会问"这问题本该被哪一层拦住"。文章也写明一个尚未做到的点：还没有在回退和事故指标恶化时自动收紧审批的断路器，工程师希望在更多代码转向零人工合并之前先把这个补上。

文章强调由改动定档，不是由作者定档。分类器读改动内容决定档位，第二个分类器判断这个具体改动是否即使档位说不需要人也仍需多一个人。

低风险档是文档、文案、仅内部使用的功能、以及放在开关后面的增量改动，自动化审查和安全检查全绿后不需要人批。中等风险档是普通产品改动，以及缓存、自动更新器、系统提示词这些敏感区域，需要一个人。最高风险档是最高风险的代码加上一小撮固定路径，需要两个人。有些路径永远需要人：任何被负责人列为敏感的路径、任何 CI 工作流文件。

还有几条硬规则：只有仓库信任名单上的作者能走更轻的路径；智能体的批准永远不算人的批准——自动审查可以放行低风险改动，但不能占用一个要求人审批的名额；一次批准只覆盖一个具体的提交，如果有新提交进来且系统无法担保，批准要重新给。

谁提出的改动谁负责。智能体写的 PR 上，指挥智能体的人算作所需审查者之一，跟自己手写代码一样。发起人所在的频道也会起同样作用。文章里那句"你落地，你负责"是团队规范：出了小中型改动的问题通常自己修，靠的是改动小、容易审容易调容易退、一切可逆、影响面决定门槛、回归通过遥测和内部使用快速暴露；它不是追责，承担修复意味着掌握最多上下文，事故复盘看的是系统。

文章列了人仍然负责的事。

一是决定要不要做——方向、品味和范围。有个团队宣称自己的审查瓶颈解决了，但仍对来自团队外部的改动保留人工审查，好让人问一句"这个到底该不该做"。

二是审查风险代码，比如计费、自动更新器和 CI 工作流。三是审查会形成他人范式的架构。

四是读证据：测试输出、跑过的命令及其返回、截图、审查者的发现。文章说如果你说不出这些检查会漏掉什么，就要求真正的人工审查，而不是给个快速批准。

五是对每一个上线的改动负责，不管代码是谁敲的。

文章讲了一个闭环。每一起事故现在都会被做成评测用例：团队收集过去造成事故的 PR，连同它们的向前修复和回退，由懂那段代码的工程师逐个确认 bug 和位置，然后把这批 PR 组成一个集合，审查器每天对着它跑一遍。审查器的提示、工具或模型一改，就用这批集合打分，分数上去了就保留，不行就丢弃。

噪音是另一条单独的衡量方式。文章说抓 bug 很容易，只要不介意标一堆非 bug，所以要加个约束：把审查器留下的每条评论按作者的反应分类——改了、说是错的、说行为是有意的、觉得无所谓；还要在已知干净的 PR 上跑一遍，数它报了多少会让人做出有害改动的发现。写下来的优先级是先抓真 bug，其次才是减少审查轮次。

文章说这在作者是智能体时噪音代价更高：人几秒就能挥手 dismiss 掉一条 nit，智能体会去修，于是多一个提交、多一轮审查。审查必须收敛，智能体作者和智能体审查者可以互相无限折腾——有一个命令行 PR 一晚上来回改了五十多轮才停下。

团队用 git blame 查了审查器反复标记的内容，其中约 59% 是从审查器第一轮就存在的旧代码，也就是说审查器很少在找新 bug，只是在每轮多找出几条旧的。

收敛的改动有五条：轮次上限，三轮之后审查器要求作者退一步重新考虑做法；前几轮之后只重审新增的 diff；标记 bug 的类别，让作者修全部同类实例而不是修一行；不重复已经发过的发现。审查智能体还会每晚在既有代码上跑，帮忙在老 bug  elsewhere 发作前抓到。

改动前后的对比是：一轮审查加修复就通过的比例从 65% 升到 78%，需要五轮以上的从 8.9% 降到 1.5%，平均通过所需轮数从 2.08 降到 1.32。

文章给了一份可以照着做的清单。

提交前：给智能体能跑的检查，写在一份简短的 CLAUDE.md 里，再加跑格式化和 lint 的钩子；本地跑 /code-review 和 /security-review，或用全新上下文的 subagent 审一遍；加一份 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 与发布工作流、安装器永远需要人；绝不让机器的批准顶替人该给的批准，新提交来了就撤销批准。

合并及之后：用合并队列、功能开关、先内部使用、灰度发布和一步回退；把事故和回退变成评测集，审查器的提示、工具或模型一变就重新打分；以人的时间为主指标，回退率和事故率作护栏。

官方文档对 Code Review 这项产品写了几条与上文配套的规则。

审查在 Anthropic 基础设施上分四步：若干 agent 并行读 diff 和周边代码找问题；一个验证步骤对照代码检查候选发现并滤掉误报；剩下的发现去重并按严重度排序；最后把结果发到 PR 上。文档也说明审查只读 diff 和周边代码，不构建也不运行代码。

检查结果以行内评论形式落在相关代码行上，带摘要和一次 check run，评论会标为 Important、Nit 或 Pre-existing，这样 PR 没引入的 bug 不会被看成作者的锅。每一项发现都必须有回应：要么修掉，要么说明理由把讨论结掉；后续提交修掉了，对应发现会自动清掉。

档位是 Quick、Standard、Deep，Deep 适合漏一个 bug 代价高于多花审查时间的地方。管理员按仓库设置。文档还写明这项能力面向 Team 与 Enterprise 套餐，仓库要托管在 GitHub；零数据保留、HIPAA 配置和客户自管加密密钥的组织暂不适用。

长文在 claude.dev 的博客，标题 How the Claude Code team does code review；产品说明在 Claude Code 官方文档的 code-review 页；同主题讨论串在 Hacker News。三个地址和引用提醒放在下面。

长文原文、官方产品文档页和讨论串地址都在下面，回复一下就能看到。