九成代码是 AI 写的，谁来读？
Anthropic 之前公布过一个数字：Claude Code 这个产品，九成的代码是 Claude 自己写的。那问题就来了——代码总得有人读吧？出了事谁兜着？
九成代码是 AI 写的，谁来读？
Anthropic 之前公布过一个数字：Claude Code 这个产品，九成的代码是 Claude 自己写的。那问题就来了——代码总得有人读吧？出了事谁兜着？
Claude Code 团队上周在博客上把答案摊开了。他们的代码审核流程跑出来的结果：六到九月，合并的 PR 数量翻了一倍多，被回滚的比例反而降了四成。读代码的活没有消失，但大部分从人挪给了机器。
这篇博客（Addy Osmani 等人执笔，10 月 15 日发）值得完整走一遍，因为它的起点是一个观念替换。
换掉那个问题
传统代码审核其实干两件事：上线前抓错，顺便让团队互相了解代码。AI 写代码之后，第一件事的规模爆炸了——Anthropic 的 monorepo 里，每天落地的变更从五月的约 2500 个涨到九月的 30000 多个，十二倍。逐行人读，物理上不可能。
团队的解法是换掉衡量标准。「人有没有读过这段代码」是个粗糙的代理指标，真正该问的是：这个改动可能出什么事，哪个检查——机器的还是人的——是抓它的合适工具。问法一换，审查的位置也变了：从流程终点的闸门，变成边写边跑的拼写检查。大部分改动在轮到人看之前，已经被 Claude 自己审过、修过至少一轮。
一段代码的一生
改动在开 PR 之前就要过第一关。团队给 Claude 的不是一句「做完了」，而是它能运行的东西——测试、构建、和设计稿对比的截图——要求它出示输出。然后另一个子代理在全新上下文里审这个 diff（没用过旧对话污染判断）。Claude Code 的创造者 Boris Cherny 说过，给模型一个验证自己工作的方式可能是得到好结果最重要的一件事，他估计这让最终结果好两到三倍。
PR 一开，几层检查排队。CI 照旧，红了挡合并。AI 审核是重头：多个代理并行找 bug，另一组代理对每条发现投票，够票才发出来，风格类的直接丢（这些过滤器是拿自家 PR 做过 A/B 测试才留下的）。留下的按严重度排序，每条必须被回答——修掉，或者带理由关掉线程。安全审核单独一道，未关闭的发现同样挡合并。
然后是人的审批，按风险分级：文档改动零人，普通产品和敏感区域（缓存、自动更新器、系统提示词）一人，最高危路径两人。定级的是分类器，看改动本身，不看作者是谁。有几条线写得特别硬：agent 的批准永远不算人头；审批绑定具体 commit，agent 一推新提交就得重新批；谁指使 agent 写的代码，谁就算一个必需的审核人。
合并走队列——所有检查在打上这个改动的最新主干上重跑一遍，因为两个各自能过的 PR，合在一起不一定能过。上线用功能开关：先给 Anthropic 员工自己用，再放 latest 渠道，stable 渠道殿后。出了事，开关几分钟关掉，坏构建直接回滚，周轮值的 on-call 盯着仪表盘。
审核员自己也要被审核
这套系统里最诚实的部分，是他们对审核 AI 的质量管理办法。
每出一次事故，就变成一个测试用例：工程师确认 bug 是真的、bug 在哪，存进集合。审核 AI 每天对着全部历史事故跑一遍评测，谁改了它的提示词、工具或模型，都要重新打分，分数涨才留。
噪音另有一个量法：看人怎么处理每条评论（修了、说是误报、说是故意的、说无所谓），再拿审核 AI 去跑已知干净的 PR，数它制造了多少有害修改。他们把优先级写下来：先抓真 bug，再减审核轮数。
最有意思的是收敛问题。agent 写代码，agent 审代码，两者可以互相无限刷：审核员每轮总能挑出新毛病，作者 agent 每轮都乖乖修。真事：一个 CLI 的 PR 过夜被审了五十多轮，作者手动叫停。他们用 git blame 一查，审核员反复标的东西里约 59% 是第一轮就在那的老代码——审核员不是在发现新 bug，是每轮多翻出几个旧的。团队于是加了三轮上限（之后逼作者退一步重新想方案）、只审新 diff、按类标记（一次修掉同类所有实例）、不许重复报已发过的发现。改造后，一轮过审的比例从 65% 涨到 78%，五轮以上的从 8.9% 降到 1.5%，平均轮数从 2.08 降到 1.32。
人还剩什么
文章列得很清楚：决定做不做这件事（方向、品味、范围）；审危险代码（计费、自动更新器、CI 工作流，永远要人）；审定模式的架构；读证据——测试输出、命令返回、截图，说不清这套检查会漏什么，就去要一次真正的深审；最后是为结果负责，不管代码是谁敲的。
连代码审核的第二个功能——传知识——也被重做了。没有人脑子里装着整个代码库，想懂哪个模块，让 Claude 现写一份讲解，几分钟，而且反映的是今天的代码。逐行读同事的一行文案改动，学到的东西远不如读一份你正要改的模块的讲解。
文化上也配套：「你落地的，你负责」——中小改动出问题，通常落地的人修。这不会失控的前提写在四句话里：改动都小，好修好回滚；一切可逆，开关和回滚以分钟计；改动炸开来的范围决定审查的密度，贵的代码配更多人更多检查；这不是追责，事故复盘只看系统。
放在这条线上
两天前写过 Self-Healing Harness 那篇：agent 可以提议修改，但持久化的批准权在外部闸门手里。Claude Code 团队的审核流程是同一个原理的产品版——提案权全给了机器（写代码、填模板、过夜修复），批准权按风险分层留在人手里，且机器的批准永远顶不了人头的缺。断言要配执行也是同一个母题：不说「做完了」，出示输出；发现要投票核实；审核员每天对事故集评测。连他们踩过的坑都是这条线的——两个 agent 互相刷五十轮，是审查也可以不收敛的活样本。
结尾停在文章里最克制的一句话上。有同事说放慢速度确实能降错误率，但主要是因为你什么都做得少了；他们宁可更快地发现和修复问题。团队自己也承认，警报拉高就收紧审批的断路器还没造——工程师们想先有它，再让更多改动走零人通道。九成代码是机器写的，但「零人」两个字，现在还写在愿望那一栏。
*信源：How the Claude Code team does code review（claude.dev，2026-10-15，Addy Osmani / Morgan Westlee Lunt / Qing Wang）。文中数字均出自原文：90% 代码占比、6-9 月 PR 翻倍与回滚降四成、monorepo 日变更 2500→30000+、审核评论覆盖率 16%→54%、收敛改造前后 65%→78% / 8.9%→1.5% / 2.08→1.32、Boris Cherny 的 2-3 倍估计。*