AI 写的代码怎么审？Anthropic 的 Claude Code 团队给出的做法是：**别指望人一行行读完，把大部分检查交给机器和 AI，按改动的风险决定要几个人批准，再用合并队列、功能开关和快速回滚兜底。**人的精力只留给几件机器替不了的事：要不要做、高风险代码、架构、看证据、为结果负责。
这篇按一段代码从写完到用户手里的顺序，把这套流程完整走一遍。资料来自 Anthropic 在 2026 年 10 月发布的 How the Claude Code team does code review，其中的理解和评论是我自己的。
为什么 AI 写的代码这么难审
现在用 AI 写代码很普遍了，可怎么审这些代码，一直没个统一说法。
一行一行看？根本看不过来，AI 分分钟写出几千行。Anthropic 自己的大仓库里，每天落地的改动从 5 月的约 2,500 个涨到了 9 月的 30,000 多个，靠人逐行读显然不现实。
干脆不看？又不放心，谁知道它写的跟你脑子里想的是不是一回事。
那只审重要的部分？听着可行，可谁来判断哪部分重要？很多事故恰恰出在看起来不起眼的地方。
Claude Code 团队的处境更极端：他们说 Claude Code 自己大约 90% 的代码是 Claude 写的。那他们是怎么保证质量的？
先说结论里的数字：6 月到 9 月，Claude Code 仓库合并的 PR 翻了一倍多，需要回滚的比例反而降了 40% 以上。代码合得更多，出问题的比例更低。
值得留意的是，原文标题讲“代码审查”，内容却远不止审查。审查跟整个发布流程绑在一起，所以下面也按发布流程来讲。
先补个背景：一段代码平常是怎么上线的
写完代码后，要合并到主分支（main 或 master）。合并前一般先提交一个 PR（Pull Request），可以理解成“这段代码申请合进主分支”。
提交 PR 后通常有两类检查：
- 自动检查：跑测试、跑构建，看代码有没有明显问题。
- 人工审查：让别的开发者看看写得对不对，挡掉一些风险。
检查都过了才能合并。合并了也不等于用户马上能用，还要走一个发布环节。
所以整个过程可以分成四段：PR 前、PR 中、合并时、合并后。Claude Code 团队的大框架也是这四段，变化在于每一段里具体做什么，好适应 AI 大量写代码的情况。
PR 前：先让 AI 自证能跑，再换一个新 Agent 来查
原文说，现在大部分审查在 PR 出现之前就发生了。这一段分两步。
第一步：让 AI 自己验证产品能正常运行
给 AI 配上能运行的东西：测试、构建、浏览器、截图对比设计稿等。要求它把运行结果拿出来，光说一句“做完了”不算数。
Claude Code 的作者 Boris Cherny 认为，给 Claude 一个验证自己工作的办法，大概是拿到好结果最重要的一件事；他估计这能让最终结果好上两到三倍。
第二步：用一个全新的 Agent 检查代码质量
这里有个坑。很多人会想：代码本来就是这个 AI Agent 写的，需求在它那儿，思考过程也在它的上下文里，让它自己检查最合适。
实际跑下来，它会漏掉很多问题。它记得自己当初怎么想的，回头检查时还是顺着原来的思路走，很容易觉得自己写对了。
Anthropic 的办法是开一个上下文全新的子 Agent，只把目标和代码改动发给它，让它判断这些改动能不能达成目标、有没有风险。它不知道写代码时发生了什么，这听着像缺点，恰好让它更客观。
另外，如果自动审查老是报同一类问题，他们会从源头修：改技能、加 lint 规则，或者更新两个说明文件：
CLAUDE.md：告诉 Claude 这个项目是什么，技术栈、约定、目标和不做的事。每次审查都会加载，所以要写短。REVIEW.md：由代码负责人写，告诉审查 AI 这块代码里什么最要紧。好的写法很短：说清这里的“出错”长什么样、限制鸡毛蒜皮意见的数量、列出可跳过的路径，并要求每条意见给出文件和行号作证据。
PR 中：四道检查，只有一道需要人
提交 PR 后，要过四道关：自动检查（CI）、AI 审查、安全审查、按风险审批。前三道全是机器，最后一道才轮到人。
自动检查（CI）：能自动跑的都放这里
CI 是每次提交后自动跑的一整套检查：lint、类型检查、多平台测试、试着构建项目等。原文说，一个普通的 CLI PR 在有人看之前，可能已经跑了几十项检查。
PR 模板里还会问两件事：这个改动怎么测的？出了问题怎么撤回？Claude 可以帮忙填，但提出改动的那个人要签字确认。
AI 审查：发现问题、筛掉噪音、逐条回应
每个 PR 在人看之前，都会先过一遍 Claude 的审查。可以拆成三步理解。
**1. 发现问题。**AI 拿着改动、整个仓库和 PR 写明的目的一起看，问三个问题：这个改动解决了它要解决的问题吗？跟现有系统合得来吗？会不会弄坏别的地方？如果是修 bug，它还会去找根本原因。
**2. 筛选问题。**几个 Agent 同时找 bug，再由另一组 Agent 对每条发现投票，足够多的 Agent 认为是真问题才会发出来。只关于代码风格、诊断信息或清理冗余的意见直接丢掉。这些过滤规则他们先在自己的 PR 上做过 A/B 测试才留下。
**3. 处理问题。**留下来的意见按严重程度排好，标成三类：重要问题、小问题、遗留问题。遗留问题指原来就有、跟这次改动无关的 bug，单独标出来，免得作者背锅。每一条都必须回应：要么改掉，要么写明理由关掉。只要还有一条没处理，PR 就不能合并。很多时候，Agent 会在夜里把修复做完，作者第二天回来，PR 已经又过了一轮。
效果方面，他们刚上线这个功能时，内部 PR 里收到实质性审查意见的比例从 16% 涨到了 54%。超过 1,000 行的 PR 大多会被挑出问题，小 PR 大多干干净净地通过。
安全审查：单独一轮，能卡住合并
安全问题另有一轮自动审查。跟 AI 审查一样，它的发现只要还有一条没处理，PR 就合不进去。如果后面某次提交修好了问题，这条发现会自动关闭。想自己用，可以试试开源的安全审查 GitHub Action 或 /security-review 命令。
按风险审批：改错别字和改计费，待遇不一样
改文档里的错别字，和改计费或自动更新相关的代码，风险显然不同。所以他们按风险把改动分成三档：
| 风险等级 | 典型改动 | 需要几个人批准 |
|---|---|---|
| 低 | 文档、文案、只有内部员工用的功能、藏在功能开关后面的新增改动 | 自动审查和安全检查都通过后，不需要人批准 |
| 中 | 普通产品改动，以及缓存、自动更新器、系统提示词这类敏感区域 | 1 人 |
| 高 | 风险最高的代码，以及一小部分固定要两人审的路径 | 2 人 |
这张表背后还有几条规矩，我觉得比表本身更值得抄：
- **风险等级由改动决定，跟作者是谁无关。**一个分类器读改动、定档位；另一个分类器再判断，这次改动是否虽然档位低、仍需要多一个人看。负责人列为敏感的路径和所有 CI 配置文件，永远需要人。
- 只有受信任的作者能走轻量通道，基本是负责这块代码的团队。其他人都需要第二个人批准。
- **Agent 的批准永远不算人的批准。**自动审查能放行低风险改动，但填不了“需要一个人”的那个位置。
- **谁让 AI 写的，谁就算一个审查人。**指挥 Agent 写代码的人，等同于自己亲手敲了这些代码。
- **批准只对某一次提交有效。**如果之后又有系统无法担保的新提交，比如 Agent 推了新代码、有人手动解决了合并冲突，就得重新批准。
AI 审查本身是怎么越变越好的
流程搭好之后，AI 审查还得持续调。原文围绕三件事：找出真问题、少提没用的意见、审查能正常结束。
用真实事故当考题
他们把过去引发事故的 PR 收集起来，连同后来的修复和回滚，请熟悉那块代码的工程师确认 bug 是什么、在哪里。每个案例就是一道考题，合起来是一个评测集，而且每出一次事故就多一道题。
打分思路很简单：把案例里的 PR 交给 AI 审查，看它有没有找到那个真实的 bug，找到算 1 分，没找到算 0 分。每次改提示词、换工具、换模型，都用同一套题再考一遍，分数涨了才保留改动。这个评测集每天都在跑。
统计“没用的意见”
只看找没找到真 bug 还不够。AI 报得越多越容易得分，可没用的意见也越多，开发者得一条条看。
他们用两种办法衡量噪音：
- **看作者怎么处理每条意见。**分成四类：改了、说它错了、说这是故意这么写的、觉得无所谓。只有第一类算有用。
- **拿确认没问题的 PR 去测。**统计 AI 有多少次报出了“会诱导别人做出有害修改”的意见。
他们写明的优先级是：先抓真 bug，其次减少审查轮数。
作者是 Agent 时，噪音的代价更大。人看到一条鸡毛蒜皮的意见，几秒钟就能略过；Agent 会老老实实去改，于是多一次提交，又多一轮审查。
让审查能收尾
审查怎么会停不下来？AI 审查提意见，写代码的 AI 照着改，交回去；下一轮又有新意见，又改……原文提到，有个 CLI 的 PR 一晚上来回改了 50 多轮，最后是作者手动叫停的。
他们用 git blame 查了审查 AI 反复报的问题，发现约 59% 的代码在它第一轮看的时候就已经在那儿了。也就是说，它很少发现新 bug，每一轮只是多翻出几个老问题。
于是他们改了重审规则：
- **超过三轮就停一停。**三轮还没通过，审查 AI 会提醒作者退一步，想想整体思路是不是有问题，别再一点点修补。
- **前几轮之后，只看新改的部分。**头几轮，审查会把改动连同它影响到的地方整体看一遍。比如改了一个函数，它会去查项目里哪些地方调用了这个函数。这样查得全，但每一轮都整体重看，总能翻出点前几轮就存在的问题，审查就永远停不下来。所以几轮之后，范围收窄到新改的那几行。前几轮已经把改动和影响范围看过好几遍，这样收窄基本不会漏掉大问题。
- **同类问题一次指出。**同一种错误出现了好几处，就一次全标出来，作者一次改完，免得下一轮又被挑出另一处。
- **不重复提意见。**提过的意见，后面几轮不再提。
效果很明显。按原文图表的数据，调整之后：
| 指标 | 调整前 | 调整后 |
|---|---|---|
| 一轮审查加修改就通过的 PR | 65% | 78% |
| 需要 5 轮及以上的 PR | 8.9% | 1.5% |
| 平均需要几轮才通过 | 2.08 | 1.32 |
此外，审查 Agent 每晚还会扫一遍已有代码，把老 bug 提前挖出来。
合并时：用合并队列排队上主分支
PR 过完前面这些关，也不会直接合进主分支，而是先进合并队列排队。
轮到某个 PR 时，系统把它和最新的主分支合在一起，所有检查再跑一遍，通过了才真正合进去。下一个 PR 也一样，只是这次跟它合在一起的主分支已经包含了上一个 PR。
这一步防的是这种情况：两个 PR 各自测试都没问题，合到一起却把主分支弄坏了。合并队列能把这种 PR 拦下来退回给作者，保证主分支一直能正常运行。
合并后：功能开关、分批发布、快速回滚
代码进了主分支，还要安全地送到用户手里。这里有三件事。
**功能开关。**新功能通常先藏在一个开关后面，一开始只对 Anthropic 员工打开。员工每天都在大量使用 Claude Code，很多问题在普通用户碰到之前就被他们发现了。
**分渠道发布。**Claude Code 有两个发布渠道：latest 是最新版，stable 是稳定版。新版本先发到 latest 给愿意尝鲜的用户，stable 会晚一段时间再跟上。
**观察和回滚。**总有漏网之鱼，所以最后一层拼的是发现快、撤回快。功能开关不用重新部署就能关掉，这是最快的止损办法；开关解决不了，就回滚或重新发布一个没问题的版本。Claude Code 还有每周轮换的值班，事故复盘时会问一句：这个问题本该在哪一层被拦住？
原文也坦白了还没做到的部分：发现坏的合并，目前仍要靠作者、值班人员和回滚、事故看板；他们还没有“数字一变就自动收紧审批”的熔断机制，团队希望先有它，再让更多代码走零人工合并。
有位同事的说法我很认同：放慢确实能降低出错率，但主要是因为你什么都做得少了。他们宁愿在发现和修复问题上更快。
一个 bug 想混到用户手里，要闯多少关
把四个阶段串起来看：
- PR 前：AI 先跑测试、验证产品能运行，再由一个全新的 Agent 查代码质量。
- PR 中：CI 跑几十项检查；没拦住还有 AI 审查；再没拦住有安全审查；改的是重要代码，还得有人亲自批准。
- 合并时：在最新主分支上再测一遍，拦住“跟别人的改动合在一起才出现”的 bug。
- 合并后：先给每天重度使用的内部员工用；再发到
latest渠道，确认没问题才推给stable；就算漏到了用户手里，还能马上关开关或回滚。
单看任何一层都可能漏掉问题，叠在一起，一个 bug 想一路混过去就很难了。而且这么多关卡里，除了重要代码要人审批，其余几乎都是机器和 AI 自动完成。
在我看来，这整套设计都围着一个目标转：**保证质量的前提下，尽量少用人。**原文的说法是，他们的目标是让大部分 PR 最多只需要一个人参与（这个人可以就是作者），同时回滚和事故不增加。回滚率和事故率是护栏，这两个数一涨，说明省下的人力只是挪到了救火上。
人的时间该花在哪五件事上
既然人的时间和注意力最宝贵，那该花在哪？原文列了五件事：
- **判断该不该做。**产品方向、品味、功能范围，机器判断不了。原文提到，有个团队宣布自己的审查瓶颈已经解决了，但团队外部提交的改动仍保留人工审查，好让有人问一句：“这事我们真该做吗？”
- **审高风险代码。**计费、自动更新、CI 配置这些地方，一出问题影响就很大，得有人亲自盯。
- **把关架构。**架构一旦定下来，就成了后面代码的样板，人和 AI 写类似功能都会照着来。样板错了，错误会被照抄到一处又一处。
- **看证据。**以前审查看的是每一行代码；现在主要看证据：测试输出、跑了什么命令、返回了什么、产品截图、AI 的发现。原文给了一条很实用的标准：如果你说不出这些检查会漏掉什么，就别随手批准，要求一次真正的审查。
- **为结果负责。**不管代码是谁敲的，上线后都得有一个人对它负责。AI 背不了锅。
想在自己团队试，可以先做这几步
原文最后给了一份落地清单，大部分东西现在就能用上。如果你的团队也在大量用 AI 写代码，可以挑着先做：
- 给 Agent 准备它能自己跑的检查，写进一份简短的
CLAUDE.md，再配上自动跑格式化和 lint 的 hooks。 - 在 PR 模板里加上“怎么测的”“风险”“怎么撤回”三栏。
- 先在一个仓库上接入 AI 审查（比如 Code Review for Claude Code 或 Claude Code GitHub Action），花几周时间打磨
REVIEW.md，再推广到更多仓库。 - 加一道自动安全审查。
- 规定所有审查意见都必须处理完才能合并。
- 限制审查轮数；过了前几轮，只重审新改动。
- 把每次事故和回滚都收进评测集，审查 AI 的提示词、工具或模型一改，就重新打一次分。
- 用上合并队列、功能开关、内部先用、分阶段发布，以及一步回滚。
如果团队规模小、改动量不大，人工审查还看得过来，就没必要一次全上。我会先做 PR 模板和“意见必须处理完才能合并”这两条，成本最低，马上能见效。
写在最后
去年，很多人还在争 AI 写代码靠不靠谱，不少人觉得 AI 写出来的基本是垃圾，真写代码还得靠人。今年这种声音少多了，AI 写代码的能力确实一天比一天强。还坚持纯手工写代码的人，很难跟用 AI 的人拼速度。
写代码变容易了，真正让人头疼的问题换成了：AI 写的代码怎么审，产品质量怎么保证。Anthropic 这篇文章给了一个挺实在的答案，从“PR 翻倍、回滚比例降四成”的结果看，这套流程是靠谱的。
这篇文章讲了很多细节，我觉得最核心的一点是重新划分人和 AI 的分工：AI 负责大量执行，写代码、跑检查、找问题；人负责最关键的决策，这个需求该不该做、用什么架构、出了问题谁负责。
这让我想起 OpenAI 讲 Harness Engineering 时的一句话：Humans steer. Agents execute. 人来掌舵，AI 来执行。Anthropic 和 OpenAI 最后走到了同一个方向。
回到开头的问题：AI 写的代码怎么审？往深一层想，它问的其实是怎么把人有限的注意力用在最关键的地方。
Anthropic 这套流程未必是最终答案，模型越来越强，流程还会变。但大方向应该不会变：能交给 AI 的尽量交给 AI，人把时间花在最重要的决策上。这可能也是整个软件开发接下来要走的路。