如果一天涌进 3 万个代码变更，还指望人类逐行看完，这不叫工程纪律，更像集体自我安慰。
Anthropic 的 monorepo 里，每天落地的代码变更从 5 月约 2500 个，冲到 9 月超过 30000 个。Claude Code 更夸张，团队说 Claude 写了约 90% 的代码。
问题马上来了：代码还有人读吗？出了事谁兜底？
Claude Code 团队给出的答案很直接：把大部分阅读交给机器，把人类时间留给风险、责任和撤销成本。
从 6 月到 9 月，Claude Code 代码库合并 PR 翻倍，但需要回滚的比例下降超过 40%。
他们没有取消代码审查。只是把审查从人的肉眼，挪到了一套机器先跑、人类兜底的系统里。
代码多到人看不完，Review 反而更快了
当 agent 开始大规模写代码，变更数量会迅速膨胀。
Anthropic 内部看到的变化非常直观：5 月每天约 2500 个变更，9 月超过 30000 个。Claude Code 虽然在自己的仓库里，也承受着同样的压力。
这种速度下，传统人工逐行 review 很难成立。
团队重新定义了目标：在最少的必要人工审查时间里，不让回滚和事故上升。
他们衡量人工时间，不只看审查花了多久，也看坏代码后续引发多少修复。回滚率和事故率是护栏。只要这两个数字上升，所谓节省人工时间就只是把成本挪了个地方。
审查不再是最后一道门，更像写作时的拼写检查
过去代码审查像终点站。写完代码，开 PR，等同事。
现在它更像输入法里的拼写检查，边写边跑。
素材里提到，多数变更在人类接手前，已经至少被 Claude 审查并修复过一次。
团队不满足于让模型说自己完成了。他们要求它给出可验证的东西：测试、构建、截图、浏览器或手机模拟器里的实际输出。
Claude Code 创建者 Boris Cherny 的判断很关键：
给 Claude 一个验证方式，可能是获得好结果最重要的事情。验证形式因领域不同，可能是一条 bash 命令、一套测试，也可能是在浏览器或手机模拟器里测试应用。
他还估计，这能让最终结果提升两到三倍。
说实话，这个细节比 AI 写代码本身更值得看。AI 编码的胜负手，正在从生成能力转向验证能力。
让机器审代码，先得把团队规矩写进文档
机器不是天然懂项目。它需要上下文。
Claude Code 团队用两个文件约束审查。
一个是 CLAUDE.md，告诉 Claude 项目是什么：技术栈、约定、目标、非目标。它每次审查都会加载，所以必须短，复杂内容指向其他文档。
另一个是 REVIEW.md，由代码 owner 写，告诉审查器这个模块什么最重要。
好的 REVIEW.md 也很短。它会写清楚失败长什么样，比如文档模块的失败是它说谎，配置模块的失败是它路由错误。它还会限制琐碎意见，列出跳过路径，要求审查器给出文件和行号证据。
这点我挺认同。很多团队以为 AI review 是装个插件，实际上真正难的是把隐性经验变成机器可读的规则。
没有这些文档，模型只会输出更漂亮的泛泛之谈。
每个 PR 先过一遍 AI，但 AI 也不能一票通过
每个 PR 在人类看之前，都会先经过 Claude review。
它会对照整个仓库和 PR 的目标，判断改动有没有解决问题，是否适合系统，会不会顺手砸坏别的地方。
如果是修 bug，它还要找根因。
内部研究预览上线后，拿到实质审查评论的 PR 比例从 16% 升到 54%。超过 1000 行的大 PR 通常会有发现，小 PR 多数干净。
仓库管理员可以设置 Quick、Standard、Deep 三档。深度审查留给那种漏一个 bug 代价极高的地方。
更有意思的是，AI 的发现也不会直接甩给人类。
多个 agent 会同时找 bug。另一组 agent 再投票，只有足够多 agent 认为问题真实，才会发出来。纯风格、诊断、清理类意见会被丢掉。
留下来的意见按严重程度排序，标 Important、Nit 或 Pre-existing，避免把旧账算到本次作者头上。
每条发现都必须回应。要么修，要么说明原因。夜里 agent 甚至可以继续修，作者第二天回来，PR 已经完成下一轮。
安全审查单独跑。只要 bug review 或 security review 还有未解决发现，PR 就不能合并。误报可以关闭线程，但要给理由。
公开版本 Code Review for Claude Code 已在 Team 和 Enterprise 计划中可用，本地也能通过 /code-review 跑轻版。
这套设计的关键，是让 AI 先过滤噪声，再让人类看真正需要判断的部分。
人类没有离场，只是被派去盯高风险
常规检查仍然在。
lint、类型检查、跨平台测试、构建，一个 CLI PR 可能在人类看之前跑几十项检查。PR 模板还会要求写清楚如何测试、如何撤销。
但不同改动风险不同。文档修复和自动更新器改动，不可能用同一套审查强度。
系统会先给变更分级。一个分类器读变更，判断风险层级。另一个分类器再问：这个改动是否需要额外人审。
敏感路径和 CI workflow 文件始终需要人。
可信作者可以走轻路径，多数是仓库拥有者。其他人需要第二个人批准。agent 的批准永远不算人类批准。
低危变更可以靠自动检查放行，但如果流程要求人类名额，AI 不能顶替。
责任也更明确了。谁发起变更，谁负责。如果是 agent 写的 PR，指挥 agent 的人就是必要审查者之一，和自己写代码一样。
批准只覆盖一个特定 commit。如果后面来了系统无法担保的新 commit，比如 agent push 或手工 merge，批准要重新给。
merge queue 会重新跑检查，防止两个单独通过的 PR 合在一起弄坏主线。新功能通常先对 Anthropic 员工开放，重度使用常能提前暴露回归。
老实讲，这一段比 AI 自动审代码更成熟。它承认风险存在，也承认责任不能外包给模型。
反转来了：AI 互审 50 轮，也会把团队拖进泥潭
如果故事到这里结束，它会太像一篇效率爽文。
但素材里有一个很扎眼的案例。
一个 CLI PR 在夜里经历了超过 50 轮审查和修复，最后作者手动停止。
团队跑 git blame 后发现，审查器反复标记的代码里，约 59% 从第一轮起就存在。它很少发现新 bug，只是每轮又挖出几个旧问题。
这就是自动化审查的副作用。agent 作者和 agent 审查者可以互相忙到无限循环。
人会看一眼琐碎意见，然后忽略。agent 会认真修复，产生新 commit，再触发新一轮审查。噪声因此变得更贵。
团队也承认，他们曾默认跑多轮，因为每一轮总能发现点东西。高风险改动值得这样，但每个 PR 都这么干就过头了。
现在他们开始跟踪 rounds-to-pass，不只追求召回率，也要求审查收敛。
个人觉得，这个反转才是全文最有价值的地方。AI review 的难点不在于能不能找出更多问题，而在于什么时候该停。
事故变成评测，学习交给解释器
错误不可能完全消失。最后一层是快速发现。
功能开关可以不发版就关闭。Claude Code 有每周 on-call，事故复盘会追问哪一层应该拦住问题。
团队还会把历史事故做成评测集。他们收集导致事故的 PR、修复和回滚，让熟悉代码的工程师确认 bug 和位置，审查器每天跑这套集合。
噪声也被持续测量。
团队会看人类如何处理审查评论：是修复，认为错误，认为行为有意，还是觉得不重要。他们也会在已知干净的 PR 上跑审查器，统计它是否会诱导有害修改。
优先级写得很清楚：先抓真实 bug，再减少审查轮次。
代码审查还有第二份工作：传播代码理解。过去读同事 diff 是学习系统的方式。现在机器读了大部分，人怎么学？
Claude Code 团队没有正式流程。他们不认为每个人都需要在脑中保留完整代码模型。
有人想理解某块代码，就让 Claude 写一份解释文档，甚至生成可视化 artifact，按自己喜欢的方式学习。
这块我有一点保留。解释器确实快，但它也可能把理解外包给同一个审查系统。素材评论区也有人提出类似担心：让 Claude 写解释，并不能让人真正具备评估复杂 diff 的能力。
外界并不买账：这到底是提效，还是 token 消耗？
素材下方的评论也很值得看。
有人问：
一天 3 万次提交，还有任何可以被称为 review 的东西吗？
也有人质疑安全流程，担心误报被轻易关闭，尤其是关键安全问题不应只靠短理由打发。
还有人吐槽，这像一家 AI 公司在解释如何消耗更多 token。
另一些人则更悲观，认为未来人类验证可能越来越不可能，最终只能接受 AI 验证的假设。
这些声音不算客气，但都戳到了真问题。
当代码生产速度被 agent 拉满，审查成本看起来下降了，责任成本却没有消失。它只是从读每一行，转移到定义风险、设置护栏、承担后果。
真正被改写的，是工程师的注意力
Claude Code 团队没有取消代码审查，他们把审查拆成机器过滤、自动检查、人类盯风险和事故反哺评测的循环。
当 AI 写代码、AI 审代码、AI 解释代码，工程师真正不能交出去的，是判断哪件事值得做、哪个风险必须拦住，以及出了问题谁来负责。
【锐评】：AI 可以读完所有 diff，但读不出责任，真正的代码审查最后仍是人的判断。
参考链接：
https://claude.dev/blog/solving-code-review-at-anthropic/