九成代码AI写，谁来审？Claude Code亮出6道关卡！
Claude Code团队近日公开内部代码审查流程：约90%的自身代码已经交给Claude编写，6月到9月合并进代码库的PR数量翻倍，需要回滚的PR占比反而相对下降超过40%。代码量暴涨之后，逐行人审已经不现实，但他们没有取消审查，而是把大部分“读代码”的活儿交给机器，再用风险分级决定人要签几个字。
九成代码交给Claude，PR一天冲到3万个
Claude Code之父Boris Cherny此前讲过，给Claude一个能自己检验结果的办法，大概是让它把活干好最要紧的一件事，他估计效果能好上两三倍。这个判断如今直接体现在代码审查流程里。
- 5月，Anthropic大仓库一天合进去约2500个改动；到9月，一天超过3万个。
- Claude Code约九成代码由Claude编写，6月到9月合并PR数量翻倍。
- 同期需要回滚的PR占比相对下降超过40%。
在Claude Code团队看来，“有没有人读过这段代码”是个不够精确的问题。真正的问题应该是：这次改动可能出什么错，如果出错应该由哪一道检查阻拦？
PR还没建，Claude先交测试命令和界面截图
第一关发生在创建合并请求（PR）之前。Claude要跑测试、完成构建；涉及界面的改动，还要截图对照设计稿。官方要求很明确：Claude要把执行的命令和输出摆出来，光回复一句“测试全部通过”不算数。
随后，再派一个使用全新上下文的子智能体审查代码差异。它没参与写代码，专门挑刺。普通开发者也能照着做：给AI任务时，把怎么验收一起说清楚，而不是等PR提上来再靠人补漏洞。
十几个智能体分头挑刺，投票不过就别贴评论
PR提上去以后，先过AI这一关。这里不是一个Claude自己说了算：几个智能体并行找bug，另一组再投票核验，票数够了，问题才会贴到PR上。只涉及代码风格、诊断提示或代码清理的意见，不会发到PR上，直接被过滤掉。
这套审查刚上线预览版时，内部有实质性审查意见的PR占比从16%升到54%。每条意见还会打标签，其中一种叫“Pre-existing”，意思是毛病早就存在，不是这次PR搞出来的，作者不用背锅。
AI审查也会较真。曾有一个CLI的PR，写代码的是Agent，审代码的也是Agent。一个提意见，一个改，改完再审，审完又提，一晚上来回拉扯了50多轮，最后还是PR的主人发现，手动给停了。原因不复杂：人看到可改可不改的小毛病，扫一眼就过去了；Agent偏偏真去改，一改多一个Commit，新Commit又把Review叫起来。
但有一条死规矩：Agent点的Approve不算数。哪怕AI审得再好，需要人签字的那一栏，它也填不进去。
安全审查和CI流水线把门，风险分级再决定人签几个字
第三关是安全审查。在团队内部，代码审查或安全审查留下的发现，只要没关闭，PR就合不进去：要么修掉，要么写明理由关掉。
第四关是持续集成（CI）检查，包括代码规范、类型检查、各平台测试和构建打包。一个普通的命令行工具（CLI）改动，在交给人审之前，可能就要跑几十项检查。反复出现的问题，还要变成下一次的检查依据。
往后是风险分级与人工审批。风险档位由改动本身决定，跟谁提交的没关系：第一个分类器读代码、定风险，第二个再判断是否需要额外增加人工审批。
- 文档、文案、仅内部可见的功能，以及藏在开关后的新增改动，属于低风险，自动审查和安全检查通过后，可以免人工审批。
- 普通产品改动，以及缓存、自动更新器、系统提示词这类敏感区域，需要一个人。
- 风险最高的代码，加上少数指定路径，需要两个人。
代码所有者标记的敏感路径，以及所有CI工作流文件，必须有人审查。轻量审批通道也有门槛：只对仓库“可信作者”名单里的人开放，名单外的人必须再找一个人批准。指挥AI写代码的人，本身就算一名审查者，也要像亲手写代码一样，为这次改动负责。
所以，零人审批不等于无人负责。人要决定功能该不该做、架构是否合理，还要判断现有检查能不能覆盖这次的风险。Claude Code团队有条规矩：你合进去的代码，出了问题，通常由你来修。点下批准之前，审查者得说清楚：这些检查验证了什么，还有哪些风险没有覆盖。
瑞士奶酪式兜底：漏网代码还有开关和一键回滚
把六道检查摞起来，有点像航空和医疗安全里常提及的瑞士奶酪模型。每片奶酪都有洞，可洞的位置各不一样，摞够了，很少有问题能从第一片一路漏到最后一片。
这六道关卡大致可以拆成：PR前自检、PR上的AI审查、安全审查、CI检查、风险分类器、人工审批与责任人。最后还有一张安全网：Feature Flag和一键回滚。就算真有改动漏下去，也能快速发现、快速回滚。
纯人工手搓放慢速度确实能少犯错，不过主要还是因为啥都干得少了。Claude Code团队的选择是：不追求“每一行都被人读过”，而是让每段代码都被某道检查拦住，出了问题有人负责。
