AI写代码谁审核？Claude Code公开六层审查流程

当九成代码由AI生成，传统的人工逐行审核显然不再可行。Claude Code团队近期公开了他们的代码审核流程，这套方法在合并改动翻倍的情况下，将需要回滚的比例降低了四成多。AI时代的代码审核到底该怎么做？三个关键点值得关注。

第一点：先自证，再提交

别让AI一句“做完了”就交差。团队要求AI在提交代码前必须提供证据：跑测试、跑构建、截图比对设计稿。据Claude Code的Boris估计，仅这一条就能让代码质量提升到原来的两到三倍。

此外，再派一个“AI分身”专门挑刺——它不看过程，只看最终改动，专门找问题。这种双AI协作的模式，让提交前的自检环节更加可靠。

AI分身挑刺是一种“对抗式审查”模式：审查者与生产者由不同模型实例担任，且审查者被禁止参考生成过程，只看 diff。这能避免“解释性偏差”——生成方往往为自己的改动辩护。这类做法在业界被称为 LLM-as-a-Judge，其可靠性取决于审查提示词是否明确列出检查清单（安全、边界条件、测试覆盖、风格一致性），以及是否要求审查者给出可验证的定位（文件、行号、复现步骤），而非笼统评价。

第二点：不设一道门，设六层筛子

单层审查容易漏，但六层筛子叠加起来，就很难漏到底了。团队设计了多层过滤机制，每层负责不同的检查维度。万一真的漏了，还有一键回滚兜底。

审批权限按风险分级：改文档这类低风险改动，机器可以全部放行，团队自己人就能直接合并；普通改动一个人批准即可；最高危的改动则需要两个人批准。AI能放行低风险改动，但永远顶替不了人的那一票。

多级审批与风险分级的底层是“按变更影响面授权”的思路：把改动按影响范围（文档、配置、业务逻辑、核心链路）分档，不同档位对应不同的批准人数与自动化检查强度。典型分层包括：静态检查与格式化、单元测试、集成/端到端测试、安全与依赖扫描、人工或AI代码评审、发布前冒烟验证。层级越多，单层漏检被后续层拦截的概率越高，但也会增加延迟与维护成本，因此需要为每层设定明确的“拦截责任”，避免重复检查。

第三点：克制审查轮数，AI审AI要设停损点

AI审AI为什么停不下来？因为AI太听话了。人看到小毛病扫一眼就过，AI却每条都改，改完又触发新一轮审查。而且审查的AI一次报不全问题——反复报的问题近六成在第一轮就已经存在了。

团队定下规矩：三轮不过就停下来重新想方案，之后只审查新改动，同类问题必须一次报全。结果，拖到五轮以上的审查从近一成降到了1.5%。

审查停损点借鉴了工程管理中的 WIP 限制与“三次法则”：同一改动经过多轮仍无法收敛，通常说明方案本身有问题，而非细节瑕疵。为审查 AI 设定“同类问题一次报全”的约束，实质是要求其输出结构化、去重的完整问题清单（可按严重级别排序），而不是逐条挤牙膏式反馈。这既减少往返轮次，也避免“修一个冒三个”的震荡。配套做法包括：为每轮审查记录问题指纹（问题类型+位置）以识别重复项，以及在超过阈值后强制触发人工会诊或方案重设计。

人还干什么？

代码可以交给AI，责任交不出去。人的工作聚焦在四件事上：定方向、审高危代码、看证据、负责。完整落地清单在评论区置顶，用AI写代码的开发者不妨先收藏。