原文 How the Claude Code team does code review，Addy Osmani，2026-10-26，同题原始版本发在 claude.dev 官方博客 一句话，90% 的代码由 Claude 写，日均变更涨了十倍以上，一行一行读的人审跟不上了。Claude Code 团队的做法是六层检查加快速回滚，结果是 PR 数翻倍，回滚率反而降了四成多。
code review 值得多大投入，软件行业早有共识。它干两件事，bug 上线前拦住它，顺便让团队里的其他人知道代码库在怎么变，Google 的工程实践书里专门有一章讲怎么做好它。过去二十年它的形态几乎没变，工程师提 PR，同事逐行读 diff，留评论，等修改，点 approve。质量取决于读的人有多认真，以及他当天还有多少时间。
AI 写代码把这个慢环节推成了瓶颈。变更量先涨，Anthropic 的 monorepo 里日均变更数从 5 月的两千五涨到 9 月的三万出头。用 agent 开发的团队都有同感，写码只要几分钟，reviewer 的队列却越排越长，审不过来，也不敢干脆不审，多数时候扫一眼了事。code review 从质量保障变成了吞吐瓶颈，怎么重新设计它，很多团队都在找答案。
10 月 26 日，Addy Osmani 发长文讲了他们团队的做法。他在 Google 待了十四年，长期领导 Chrome 的工程团队，加入 Anthropic 后就在 Claude Code 团队做工程，写的是自家 repo 的一手实践。数据全部来自内部指标，Claude 写了 Claude Code 大约百分之九十的代码，此后 6 月到 9 月合并的 PR 数量翻了一倍以上，必须回滚的 PR 占比降了四成多。连体系跑出来的失败案例（agent 审查循环五十多轮）都原样写了进去。这样的内部数据，外部平时看不到。
下面按原文的顺序拆开，从一次变更的完整周期开始。
一次变更的完整周期
整套体系是从一个问题出发搭出来的，先看这个问题。文章集中讲怎么抓 bug。另一半目的，建立共同认知，作者留到了文末。
团队的基本判断是提问方式本身错了。原文这样写。
“We view ‘did someone read the code?’ as an imprecise measure of ‘what could go wrong with this change, and what check - automated or human - is the right one to catch it?‘”
有没有人读过程序，是个粗糙的代理指标。该问的问题换成这个，变更可能出什么问题，哪一层检查适合接住它，检查可以是自动的，也可以是人。
问题一换，审查的时机也跟着变了。传统流程里 review 是事后关卡，代码写完，PR 提交，作者等人来看。Claude Code 团队把它揉进了写代码的过程，Osmani 的比方是 “It’s more like a spellcheck that you continuously do while writing.” 大部分变更在请人看之前，已经被 Claude 审过并改过至少一轮，常规 bug 在这一步消化掉，人的注意力留给更高层的判断。
人的时间在这里被单独记账。团队同时算两笔账，人花在审查上的时间，加上人花在修复坏代码上的时间。只压第一笔不压第二笔，工时只是换了个地方花。所以他们盯的指标是每个 PR 的中位数人工审批次数（附 95 分位）、人工评论数、PR 等人的时长，同时拿回滚率和事故率当护栏，这两项一涨就说明没省时间。目标是每个 PR 最多一个人在环，这个人可以是作者本人，前提是回滚和事故不升。
接着看全貌。把这套体系画成图，一眼看过去，人在里面出现得非常少。
这张图讲一次变更从作者环境走到生产的完整旅程，值得盯的是图例，对勾是自动环节，菱形是人来定夺，箭头是补救。从开 PR 前的验证，到 PR 上的 CI、AI 审查、安全审查、风险审批，再到合并、灰度、观察，整条链上菱形只出现一次。
第二张图回答紧接着的问题，环节这么多，哪一环负责把好关？没有哪一环，图的标题叫 “Layers, not one gate”。六层检查画成六块带孔的平板，孔洞错位排布，问题穿过这层的孔，会撞在下一层的板上，极少数穿过全部六层的，底下还有 fast rollback 兜底。这张图的意思很直白，每一层都会漏，关键是各层的漏洞对不齐，穿过去的交给回滚。
按变更流的顺序，下面逐层看。
让 Claude 先证明代码能跑
第一道检查不在 PR 上，在代码写完之前。团队要求 Claude 拿出可运行的证据，跑测试、跑构建、把截图和设计稿对比，用 Osmani 的话说，是让它展示结果，而非宣称任务完成。然后一个 subagent 用全新上下文再审一遍 diff。这两条都写进了团队的 best practices 指南。
Boris Cherny，Claude Code 的创造者，认为给 Claude 配验证流程可能是质量提升最大的那个杠杆。他的估计是，验证流程能把 Claude 的产出质量提高两到三倍。验证的形态因领域而异，简单的是一条 bash 命令或一套测试，讲究起来的，是把 app 跑进浏览器或手机模拟器里实际点一遍。
配套的还有一批内部 skill，抓 bug、压缩 diff、端到端验证、UI 对照设计规范。同一问题被反复 flag，就在源头修，写进 skill，变成 lint 规则，或者更新文档。文档里有两个关键文件。CLAUDE.md 写项目的技术栈、约定、目标，每次 review 必读，大库要保持简短，只做其余文档的入口。REVIEW.md 由 code owner 来写，告诉审查者这块代码里什么最重要，好的版本定义清楚什么算失败，禁止猜文件名，只许引用到 file 加 line，顶层汇总要带问题计数和明确的 no issues 声明，团队还会单独验证审查者是否真的在遵守这份文件。
PR 前的这两道检查消化掉大部分常规问题。PR 打开之后，接手的第一波还是机器。
84% 的 PR，一条正经评论都收不到
每个 PR 在任何人看到它之前，都先过了一轮 Claude review。diff 对照整个代码库和作者声明的意图，确认变更真的解决了声称的问题，放进更大的系统没有副作用，也别弄坏了代码库的其他部分。修 bug 的 PR 还会试着找根因。
这套审查已经做成了产品，Code Review for Claude Code 对 Team 和 Enterprise 客户开放，本地有轻量版 /code-review。research preview 上线后，内部 PR 拿到实质性 review 评论的比例从 16% 涨到 54%。这个数字反着读更扎心，在此之前的多数 PR，从头到尾没有收到过一条实质性评论。所谓 AI 时代的审查危机其实一直存在，agent 只是把沉默的存量问题变成了必须回答的问题。规模上，千行以上的 PR 多数能查出问题，更小的 PR 多数干净返回。强度有三档可选，Quick、Standard、Deep，漏一个 bug 的代价高于审查时间时用 Deep。
发现不是直接甩给人的。多个 agent 并行找 bug，另一组投票判定真阳性还是误报，票数够才确认，样式和清理类的发现被过滤掉，这些过滤器先在自家 PR 上做了 A/B 再上线。留下的发现按严重程度排成行内评论，标上 Important、Nit 或者 Pre-existing，最后这个标记用来避免把存量 bug 算到作者头上。所有发现必须处理，修掉，或者说明理由后关闭。很多时候 agent 夜里就把问题修了，作者早上回来，看到的 PR 已经多了一轮修改。
安全审查单独一道。code review 或 security review 只要有未关闭的发现，PR 就不能合并。开源玩家可以配同款 security review GitHub Action，或者在 Claude Code 里跑 /security-review。这些关卡之外，标准 CI 也在每个 PR 上强制跑，lint、类型检查、全平台测试、构建，一个 CLI PR 在任何人看它之前，可能已经跑了几十项检查。PR 模板带着三个问题，怎么测的，风险在哪，怎么回滚。Claude 可以代答，但作者负责核对。
到这里，机器能做的都做完了。剩下的决定要人来做，但人不是每单都看。
改到计费代码，得两个人点头
前面这几道机器检查都过了，PR 到了人面前。Claude Code 团队的做法是给变更定风险等级，等级决定几个人签字。
如图，低风险的文档、文案、flag 后的增量变更，自动检查全绿就放行，一个人都不需要。往上一档是普通产品变更，加上缓存、自动更新器、system prompt 这些敏感区，要一个人。最高危的代码和一小撮固定路径，要两个人。
这套分级有个不常见的地方，等级由分类器按变更本身定，跟提 PR 的人是谁无关，老资历改系统提示词和新人改系统提示词，过的是同一道门。人自己的信用只在 trusted list 里起作用，通常是 owning team 享受宽松审批，其余人一律第二人。agent 的 approval 永远不算人审，低风险变更可以被自动审查放行，需要人的时候它顶不上。变更的作者对变更负责，agent 提的 PR，操作 agent 的人计为 reviewer 之一。审批只对一个 commit 有效，新 commit 落进来，无论来自 agent 还是手工解冲突，都要重新审。
签字之后代码合进主干，防线还没收，合并之后还有一层。
真漏了怎么办
前面几层都在拦坏代码。最后一段工程力气花在另一件事上，承认会有漏网的，把能力建在快速发现和快速撤销上。
merge queue 把全部检查在合了变更的最新 main 上重跑，防止两个各自成功的 PR 合出一个坏掉的 main。新功能默认藏在 feature flag 后，Anthropic 员工先用，团队自己重度使用产品，回归往往先于用户暴露。公开 rollout 时 latest 频道先走，stable 频道殿后，flag 后面的变更不用重新部署就能关掉。Claude Code 每周轮值 on-call，事故复盘固定回看一个问题，哪一层本该接住它。按数据自动调整审批力度的 circuit breaker 还没有，那是正在做的方向。
六层都会漏，合并防线也只保今天。要让审查系统自己越审越准，得有人管它的进化，用的办法是拿它自己的事故当教材。
出了事故，先收进题库
审查系统每天被自己的事故考一遍。
团队把引发事故的 PR、修复补丁（不回滚，直接在主干上修好）和回滚收集起来，让最懂代码的工程师确认每个 bug 的位置和正确性，做成一套案例集。审查系统每天在这套集合上跑分，每起新事故入集，审查系统的每次改动，prompt、工具、模型，都对全集重评，分涨了就保留，没涨就回退。漏掉的 bug 迟早会进题库。
噪音同样被度量。提升找 bug 率很容易，多报一堆非 bug 就行，所以要看人对评论的真实反应，每条评论的处理被记为修了、拒了、声明有意或者不管它。团队还在已知干净的 PR 上跑审查系统，看它多久误报一次。
这个每天跑分的审查系统，还多了一个传统 review 从来不用担心的毛病，它可能停不下来。团队观察到 CLI 项目里一个 PR 在一夜之间循环了五十多轮，agent 作者改一版，agent 审查者提一轮意见，来回拉扯到第二天早上，靠人工才停下来。理论上它可以永远转下去。
复盘那个循环时 git blame 揭了底，反复被 flag 的代码，约 59% 是初版就存在的历史代码。审查系统很少找到新 bug，每一轮只是把旧 bug 再挖出几个，而团队当时的默认配置恰好是连跑多轮，理由是每轮可能找到不同的 bug。
修正从指标开始。除了查全率（recall），团队加了 cycles-to-pass，追踪通过审查需要的轮数。re-review 的规则改成，三轮之后要求作者重新评估方案，复审只看新增的 diff，指明 bug 的类别好让作者一次修完，不重复报告已见过的发现。审查 agent 夜里也在当前代码库上跑，把历史 bug 在扩散前找出来。
改完的效果如图，一轮通过的比例从 65% 升到 78%，需要五轮以上的从 8.9% 降到 1.5%，平均轮数从 2.08 降到 1.32。这里有个成本细节，agent 处理一条 nit 比人贵得多，人一秒钟划掉，agent 要多一个 commit 再多一轮审查。所以顺序是先抓真 bug，再压审查轮数。
到这里，机器的部分讲完了，流水线，外加两个传统 review 没有的观测维度，收敛性和事故率。剩下的问题是，人在这套体系里还剩什么。
机器审完之后，人还干什么
剩下的一成活，是最难自动化的部分。有些事团队坚持必须由人来做。最贵的一件是决定要不要做，愿景、品味、产品目标都长在人身上，原文提到的一个团队，号称解决了审查瓶颈，至今对来自团队外的变更坚持人审，先确认方向本身对不对。计费、自动更新器、CI workflows 这类危险代码的审计也留在人手里。架构评审必须是人，那几个决定会定下后来所有人的写法。最后是验证证据，测试输出、跑过的命令、截图、评审意见。原文在这里有句很硬的话。
“If you can’t describe what the checks would miss, don’t ask for a 👍, you need a real review!”
还有担责，每一条上线的变更背后都有一个具名的人，无论代码是谁敲的。
还记得开头说 code review 的另一半目的，让团队建立对代码库的共同理解。机器读了大头之后，这个目的怎么办？读同事的 diff 曾经是理解代码库的主要方式，团队没有为它的消失设正式机制，也不觉得需要谁把 Claude Code 的完整心智模型装进脑袋。想学哪块，就问 Claude 要一份 explainer，只讲那一小块，几分钟出，永远反映当下的代码。有些人更进一步，让 Claude 做一个小的可视化 artifact，按自己习惯的方式教。
逐行读琐碎 diff 学不到什么，一行文案的改动教不会你任何东西，给自己即将修改的模块生成一份 explainer，能学到很多。团队同时默认 open，工作在开放的 Slack 频道里进行，别人边做边可见。
文化上还有两条。You land it, you own it，合并了中小变更之后出了问题，预期是你自己修。这没有失控。变更小，好审查也好回滚，flag、revert、灰度能在几分钟内撤销多数错误。爆炸半径决定门槛，越贵的代码越多眼睛。telemetry 和内部使用让回归暴露得很快，复盘看系统不追责，谁有上下文谁修。担责的文化能运转，前提就是变更小、撤得快。另一条关于改道。agent 让启动新工作变得便宜，但有时根本不该启动。频道里有人指出方案无效，引用既往决策或者给出更好的路径，作者就关掉 PR 或者改实现，代码本来就没费多少劲，关掉不心疼。关键在线程早期就转向，别等 PR 定稿了再提阻断意见。
走完全部环节，可以退后一步，看这套体系真正在反复做什么了。
这作业不能整页抄
先把流水线放一边。比这六层更值得带走的，是一组反复出现的动作。
整套体系在做一次交换。逐行人审换成了分层过滤加回滚速度，这笔账开头算过，PR 翻倍，回滚降了四成多。只是别误会，审查的总量其实变大了，一个 PR 要过的检查比人工时代多得多，变掉的只是形态和位置。
人的经验在整个流程里被反复写成机器跑得动的东西。CLAUDE.md 和 REVIEW.md 把项目约定与 owner 的关注点变成文档，风险分级把判断固化成规则，incidents eval 把漏掉的 bug 收走，变成明天的考题。回头看 Boris Cherny 那句验证流程值两到三倍，说的是同一件事，把人的标准交给机器去执行。六层流水线是这个循环此刻的样子，昨天漏了什么，今天就多一条新检查。
省下的时间要对账。只统计审查提速、不看修 bug 工时的团队，等于把成本挪进了半夜修 bug 的时间，报表上还看不见。Claude Code 团队拿回滚率和事故率当护栏，防的就是这一手，也是普通团队抄这套体系时最容易缺的一块。
过程要有终点。人审天然会收敛，审的人会累，第三轮之后多半松手。agent 不会，五十多轮的循环证明它可以在来回拉扯里跑一整夜。所以 cycles-to-pass 与查全率并列成了一等指标，审查系统光会找 bug 不够，还得会停。
原则清楚了，落到自己团队该从哪一步开始。原文末尾给了完整清单，直接照单全收会消化不良，这些措施有先后依赖，成本也差得很远。按投入从低到高分三层，各家按家底取用。
第一层今天就能做，零基建。给 agent 一份可运行检查的清单，写进简短的 CLAUDE.md。本地跑 /code-review 和 /security-review，或者开一个新上下文的 subagent 审改动。PR 模板加上怎么测、风险在哪、怎么回滚三问。这一层只花写文档的时间，就能挡掉大部分常规 bug，单兵就能完成。
第二层要团队点头，先在一个 repo 试点。CI 强制过，接一个 AI 审查者，Code Review for Claude Code 或 Claude Code GitHub Action 都行，加一道自动安全审查，要求所有 review thread 关闭才能合并，迭代 REVIEW.md 几周再铺向更多 repo。审查轮数设上限，几轮之后只看新 diff。
第三层是重资产，风险分级、merge queue、评估集都在这一层。风险等级跟着变更走，不跟着作者走，从严起步，见到证据再放松，bot 审批不计入必需审批。建 merge queue，用 feature flag 做试验，内部用户先上，分阶段推出，准备一步到位的回滚机制。拿事故和回滚记录攒一套 eval，改 prompt、工具或模型就重新跑分。
三层共同的底线，是把回滚率和事故率当护栏。前文说过，这两项看不见，省下的时间会在深夜的救火里加倍还回来。
评论区吵起来了
清单抄完了，外界的反应也值得看。文章发出后两天，X 上 1.2 万点赞，Hacker News 488 分、近四百条讨论。评论区的分歧本身就是信息，挑几条有分量的。
质疑最集中的是安全审查。HN 网友 vavkamil 盯住那句「用一句简短理由关闭误报」，安全发现可以由作者单方面关掉，关键级别的误报难道不该让 AppSec 复核一遍？他还补了一句更狠的，回滚率一路降的同时，安全漏洞完全可以一路涨，回滚率这个指标根本照不见安全漏洞。这条对普通团队是实打实的提醒，抄流水线之前，先想清楚自己的安全发现由谁把关。
数字本身也有争论。crooked-v 翻出 Claude Code 的 GitHub 仓库，五千个 open issue 里约三分之一是行为回归，这算不算体系失效。JackSlateur 说 changes per day 和代码行数一样是 vanity metric，一个 for 循环就能刷出任意数字。leoqa 的算术给质疑泼了冷水，三万次日均变更摊到工程师头上，每人每天约十个，他自己 2026 年前一年提 1400 个 commit，agent 提速两倍就是这个量级，数字本身并不玄。
吵得最久的是一个老问题，代码质量还重要吗。dyauspitr 挑头，没人关心好代码，代码只是手段，用户只要跑得快不出错。tripleee 顶回去，说这话的人在暴露自己不懂代码质量，AI 在组织糟糕的代码库上同样挣扎。drewg123 给了个比喻，AI slop 像 GPL 传染，一旦混进项目，人就再也维护不动，只能继续用 AI 维护。bpeng2000 补了一个不起眼的观察，AI 倾向于造新轮子，找和理解既有代码要花更多 token 还容易弄坏旧功能，而人审者偏爱这种干净的新代码，一拍即合，代码库就这样慢慢膨胀。
也有人在争论之外给出了自己的解法。dylanhouli 说自己还是停不下来逐行审，逐行才能看到冗余和重复，不这么干感觉不负责。stillpointlab 的建议是找个不在乎的 side project 放手全交给 AI，把失败模式挨个撞一遍。X 那边 rakesh 的实践正好印证文章，重复出现的 review 评论写进 agent 的规则文件，同一个错不让它犯第二次。
这些争论指向同一件事。这套体系跑在 Anthropic 的基建和内部用量上，分类器、事故评估集、风险分级都是重资产。抄清单容易，掂量自己有几分家底、抄到哪一层为止，才是普通团队要先回答的问题。
这事他们也没做完
争论归争论，Anthropic 自己在这条路上还没停。产品版的 Code Review 定位在人做最终决定，它只贴出自己的发现，但在自家 repo 里他们走得更远，owner 决定哪些低风险变更在自动检查通过后直接合并，这条边界还会继续移动。审查者每次漏掉什么，团队问的问题是模型的上下文里缺了什么，答案变成一份 CLAUDE.md、一个 skill 或者一条新检查。目标没变，压低每个变更的人力投入，回滚率不高于现在。
对用 AI 写代码的开发者，这篇文章最值得带走的是一个提问方式的替换。把「这段代码有没有人读过」退役，换成一串更具体的问题，这个变更可能怎么坏，哪层检查接得住它，坏进去之后几分钟能撤回来。前一个问题在 agent 时代已经没有好答案，后三个问题每一个都能落地成一条检查。