本文是同名深入版的精简版。深入版有完整的论证链、全部数据出处和证据分级;这一版只保留主线,用直白的话讲清楚。关键数字都经过独立核查(数据截至 2026 年 7 月)。
AI 写代码越来越快,检查代码的人跟不上了——这是真问题。行业开出的药方是"再买一个 AI 来检查代码"。这副药在窄场景里真的有效,但在最需要它的地方,它更像套娃:用一个会犯错的 AI,去检查另一个会犯错的 AI,而且它们犯的错越来越像。
先看需求是不是真的。AI 让写代码这件事提速了,但每一行代码在合入之前,都要有人确认它是对的——这道工序叫 code review(代码评审)。三家互不相关的数据源指向同一个方向:
写得快、查得慢,堵车堵在检查站——这个诊断成立。问题出在药方上。
市面上的 AI 审代码工具怎么证明自己有效?发成绩单。但这些成绩单有一个规律:谁办的考试,谁考第一。截至 2026 年初,至少 6 家厂商发布过自家的评测基准,发布者本人无一例外排名第一。有一家的工具在自家考卷上"抓住 82% 的 bug";换一家竞争对手用同样五个代码库重新出题,它得 45 分;再换第三家的考卷,它的评论里约 6 条有 5 条指向的根本不是真 bug。同一个工具,三张考卷,三个天差地别的分数。
更有意思的是,后来出现了一个由独立研究机构办的排行榜,总算没有利益冲突了吧?结果一个月之内,三家厂商各自发博客宣布"我们第一"——一家是"综合分第一",一家是"某单项第一",还有一家拿实验室特供版参赛拿了第一(它在售的产品排第四)。
这里面的门道其实六十年前就被科学界解决过:光说"抓住了多少 bug"、不说"报了多少假警报",这个数字毫无意义——把警报阈值调灵敏一点,任何检测器都能"抓住更多 bug",代价是假警报淹死你。而假警报恰恰是审代码场景里最贵的东西,因为它消耗的是工程师本来就不够用的注意力。下次看到任何"我们能抓住 X% 的 bug",先问一句:误报率多少?不敢说的,按没有及格算。
真正值钱的数据来自把 AI 审代码用在自己身上、并且诚实公布漏斗的公司。
谷歌:AI 建议的修改,最终解决了全部人工评审意见的 7.5%。不是 75%,是 7.5%——而且谷歌论文里自己承认,他们能测量的这些指标都只是生产力的"容易测量的代理",至于 AI 到底抓住了多少真 bug,没人测得出来。
Meta:AI 修代码的模型,在自家精选考卷上能拿 68 分;上到真实生产环境,被工程师真正采纳的比例是 19.75%。离线分数和真实价值之间,隔着一个数量级。同一篇论文里还有个更扎心的实验:Meta 把 AI 生成的修复补丁展示给评审者看,结果评审反而变慢了 5.5%(统计显著)——AI 的产出本身成了评审者的新负担。最后怎么解决的?不是改进模型,是把 AI 补丁从评审者眼前藏起来。
独立研究补上另一面:开源的 AI 评审工具发出的评论,只有 0.9% 到 19.2% 真的导致了代码修改,而人类评审意见是 60%;有人在同一批真实 PR 上并行跑了四个主流工具,发现 93.4% 的问题只有一个工具报出来,四个工具全都同意的问题是零条(这个测试的作者在其中一家厂商工作,数字本身开源可查)。四个"检查员"对"什么是问题"几乎没有共识——它们给出的更像各自的意见,而不是检验结论。
最深的问题不是这些工具还不够好,而是这个结构本身有内伤。
第一,AI 检查员自己会捏造 bug。OpenAI 训练了一个专门给代码挑错的模型(CriticGPT),论文的正面结果是真的:它挑错的意见在 63% 的对比中比人类外包审查员的更受欢迎,人机搭配的审查比人单干更全面、比 AI 单干更少胡说。但同一篇论文的摘要里,作者自己写了一句要命的话:AI 评论员幻觉出来的假 bug,"可能误导人类犯下本来不会犯的错误"。检查员不是中性的过滤网,它会往流程里注入新的错误。
第二,AI 们犯的错越来越像。用第二个 AI 检查第一个 AI,前提是它们的盲区不同。但 2025 年一项研究发现:模型能力越强,不同模型犯的错误反而越相似。当写代码的 AI 和查代码的 AI 共享盲区,叠再多层检查,漏掉的还是同一批 bug——这就是"套娃"在数学上的准确含义:一层套一层,每层的花纹都一样。
第三,指望人类当最后一道闸,是 1983 年就被判过死刑的方案。人因工程学四十年的结论:让人盯着一个大部分时候都正确的自动化系统、专门抓它罕见的错误,是"人类不可能完成的任务";自动化带来的自满和盲从,"无法通过培训或指令来预防"。2026 年的眼动实验也证实:告诉评审者"这段代码是 AI 写的",他们盯着看的时间变长了,但检查的彻底程度没有任何变化。更现实的图景来自对 AI 生成 PR 的大规模观察:大多数 AI 写的 PR 根本没有人看,有"人"看的,那个"人"往往也是另一个 AI。
把证据翻个面,AI 审代码在三个条件同时满足时,确实是划算的:
反过来,三个条件都不满足的场景——没有测试兜底的核心业务逻辑、AI 写 AI 审、人只负责点"通过"——就是套娃的标准剧照。
还有一个诚实的注脚:AI 审代码火了两年,整个行业至今没有做过一次随机对照实验来证明它有效,也没有任何一家公司具名发布过"我们为什么关掉了 AI 审查"的复盘。正反两个方向的严格证据都缺席。
如果你在决定要不要给团队上 AI 审查:按"有没有测试和类型系统兜底"来选先上哪些仓库,别按厂商演示;采购时只认"抓住率+误报率"成对出现的数字,只给一半的直接扣分;试点期自己抽样统计"AI 评论里有多少真的被采纳",和文中的公开数字对照。
如果你是被 AI 评论刷屏的工程师:全信和全部无视都是输法。可行的做法是分层:高置信类别(编译错误、明确的 API 误用)默认处理,投机性类别(风格建议、"可能的"并发问题)批量降级、定期抽查。另外两条红线:别拿"测试通过"当"代码正确"的担保,尤其当测试也是 AI 写的;别让自己退化成只看 AI 摘要的评审者——亲手读代码的能力,恰恰是 AI 时代最保值的能力。
如果你在做这类工具:第一个在自家基准页公布误报率、并标注"本基准由参赛者运营"的厂商,能白捡整个行业正在流失的信任。
全文归结为八个可检验的主张,按证据从硬到软排序:
值得盯的判据:第一篇 AI review 工具的对照实验出来时结论朝哪边;"零审查直接合并"的占比是继续涨还是被治理拉回;会不会出现厂商收割不了的独立评测协议。