当 AI 写的代码比人还多，最后一道门禁就不能只靠人了

百度网盘主端 FE 团队最近晒了一组数据：每月约 2000 次 CR（Code Review），其中 55.87% 的代码来自 AI。传统人工逐行审查的精度与专注度都在肉眼可见地下降，最后一道门禁效果锐减（来源：网盘 FE 团队 2026-07-06 发布的 AICR 准入实践长文）。

团队里一半以上的代码已经不再是人写的了，但负责把关的还是人。这个错位如果不解决，所谓"AI Coding 提效"就是把审 Bug 的成本转嫁给了 Reviewer，最后还是会以线上事故的形式还回来。

网盘 FE 团队给出的解法，是把 AI 嵌进 CI/CD 流水线做硬阻塞的质量门禁。他们给这套系统起了个名字：AICR。但看完他们 1.2 万字的复盘后我发现，值得借鉴的不是工具本身，而是他们从"单 AI 审查"踩坑走到"多 AI 制衡"的过程——这一路上的几个判断，每个在 AI Coding 渗透过半的团队都迟早会遇到。

<!-- 配图：多 Agent 协作审查流程图 -->

人工门禁正在失效，不是态度问题

把数字摊开看：2000 次 CR/月，AI 生成代码占 55.87%。Reviewer 每次要看的不只是代码风格，还要判断需求逻辑对不对、跨文件调用有没有同步、状态流是否完整、API 契约是否被破坏、运行时会不会崩溃。

CR 量级在放大，单次 CR 的修改规模也在放大。两端一起压，Reviewer 的注意力被稀释成几片——他们不是变懒了，是信息量超过了人脑的接收带宽。继续硬扛，结论只有一个：漏检。

所以问题不是"Reviewer 要更努力"，而是要承认一个事实：当 AI 是主要代码生产者时，最后一道门禁必须也是 AI。问题是，AI 该怎么当这个门禁。

上一个"更聪明的 AI"远远不够

网盘 FE 团队最早用 GLM5.0 做检测，缺陷检出率只有 5% 左右。他们当时的思路是"既然模型不够强，那就用规则补"——把检测规则写得又细又硬，要求 AI 对修改调用链彻查、对代码逐行检验。

这个思路在弱模型阶段有效，规则确实能补足模型的检测深度。但后来他们把模型换成 GPT5.5，缺陷检出率飙升到 25% 左右——按理说该高兴，结果新问题立刻浮出来：审查耗时暴涨，输出内容膨胀到无法阅读，三路检测里有一半上下文是无效的。

他们复盘后得出一个反常识的心法：模型越强，规则反而要越轻。

强规则原本是给弱模型的拐杖，强行套在 GPT5.5 这种自带上下文检索和逻辑推理能力的模型上，反而成了束缚。模型被迫去做大量机械式彻查、生成大量无关联上下文，最后把后续审核 Agent 的注意力也带偏。

规则不是越多越好，而是要看模型能不能自己消化。 模型消化不了，规则就要硬；模型能消化，规则就要软。

<!-- 配图：GLM5 vs GPT5.5 A/B 对照数据 -->

多 Agent 不是花活，是机制需要

把模型和规则都调对了，网盘 FE 团队又撞上一面新墙：单一 Agent 必然偏科。

他们做过一个对照实验：一周内 552 个 CR 用 GLM5 和 GPT5.5 分别审查——GPT5.5 检出 121 条（21.8%），GLM5 检出 38 条（6.9%）。GPT5.5 检出数量是 GLM5 的 3.2 倍，看起来 GPT5.5 是"更强"的审查员。