先看一个特别不起眼的细节。
arXiv 2611.02566，11 月 2 号挂上去，第二天就出了 v2。修订说明写得相当坦诚：调整了提示模板的格式，提升可读性。
一篇评测 AI 代码评审能力的论文，自己改了一版，改的是排版。
【灯光渐暗，审稿人露出了理解的微笑】
评审意见这玩意，格式一乱，读的人先烦，后面说什么都白搭。人和 AI 一个待遇。
论文本身干的事不复杂，但有点坏：把 SWE-Bench 反过来用。原版是给一个 issue 让模型写补丁，它这版是给你一个已经揣着已知缺陷的 PR，看评审智能体挑不挑得出来。584 个实例，其中 174 个来自 SWE-Bench Verified，单拎出来当 Verified 子集。
这里得停一下，说筛选有多费劲——每个缺陷只对应一个来源 PR，还得是“能被评审发现”的那种。
现实里的 PR 长什么样，在座各位都清楚。一个 PR 里躺着一个真缺陷、三个临时补丁、一行忘了删的 console.log，外加一处三个月前就该改但一直没人敢动的命名。你想给它贴“唯一来源缺陷”的标签，得把作者请来问清楚他当时在想什么——而这个问题通常没有答案。
所以 584 这个数背后，是一批被清理得干净得像实验室标本的 PR。拿它测出来的分数，跟你真实仓库里看到的东西之间隔着一截。这一截叫什么，论文没说，我也不打算替它命名。
数字出来了。八种智能体、四种骨干模型，外加一个商用产品，评审结果由三个独立的 LLM 裁判打分。表现最好的系统，已知缺陷检出率约 33%。
Gemini Code Assist，8.1%。
有一种读法我不认。
33% 一出来，评论区排队“AI 果然不行”“就这”。这读法太省事，也太给 AI 面子——它把一个挺扎人的结论，稀释成了一句情绪。
真人 review 也漏。漏多少，我们从来没个数。
没有基线。从来没有。人肉评审不进 benchmark，全靠“这个 PR 我 LGTM 了”外加三个月后的事故回访倒推。现在有人第一次把这东西量化出来，测出三分之一，第一反应不该是“AI 就这”，而是——原来我们那套兜底，跟它大概也就是个位数的差距。
（郑重声明：这句我没数据支撑，纯属偏见。偏见也得写出来，不然这篇就成摘要了。）
但 33% 不是这篇最狠的一刀。
最狠的是第二个指标，Usefulness Rate，有用率。名字平淡，统计的是评审意见里真正可执行的比例。
这指标一出，AI 代码评审那股味儿就藏不住了：每条意见都成立，每条都正确，然后一条都不用改。
它会把你 diff 里所有能想到的边界情况列一遍，格式工整，语气平稳，读完你唯一的收获是——哦，原来这段代码还有这么多我没考虑的情况。然后你一条都没改，因为不知道从哪条下手。
屎上雕花这件事，AI 干得比谁都体面：它没把烂代码改好，它给烂代码出了一份很漂亮的鉴定书。
（这里我犹豫了一下。严格说，被抓出来的那 33% 是真货，是有用的。我说的不是那部分，是剩下 67%——它照样给你输出一整页，一句“我没发现明显问题”是说不出口的。这个区别重要到我差点把整段删掉重写。）
跑个题。
我看 PR 的真实流程：先看标题，再看改了哪几个文件，跳到改动最大的那个扫一遍，看见一个变量名不顺眼，留条 comment，剩下的用一句“看过了”结案。全程四分钟，其中两分钟在权衡要不要留那条变量名的 comment。
——这段是我瞎编的，我审得比这认真。但你是不是觉得特别有代入感？
打住，回正题。
三层套娃是我最想笑的地方。
AI 写的代码，交给 AI 评审，评审结果再由三个 LLM 判谁评得好。整条链路上唯一的人类含量，是那个按下提交按钮、然后起身去倒咖啡的人。
这结构不是笑话，是必然。评审质量本身就是主观的，论文自己都承认：设计、可维护性这类判断，专家评审者之间本来就分歧。既然人会分歧，那就找三个不会累的东西投票，多数决。
“多数决”这三个字，安在三个不会累也不会心虚的东西身上，画面感格外足。
只是这个画面我一时半会儿习惯不了：一个闭环里三个智能体互相打分，产出一份看起来很权威的结论，交给一个刚睡醒的人决定要不要合。
状态机我都画得出来：AI 写 → AI 审 → AI 判 → 人点一下 → 线上出事 → 人渡劫。最后一步的故障等级，我定 P0。
再说生成这一侧。
论文开篇的动因是：自动生成代码的规模在快速扩张，所以自动化评审成了迫切需求。
这句话读着很顺，顺到我差点没注意它在说什么。代码是 AI 生成的，所以我们迫切需要 AI 来评审。根因不是评审难，是我们生产代码的速度，已经超过了我们阅读代码的速度。
然后我们造了个东西，去读那些我们自己读不完的东西。
这循环我暂时看不到出口，但能看出谁在里面渡劫。
8.1% 那个数，我不做文章。
八分之一的检出率，放在一篇自己都承认基准难做的论文里，我不敢断言它代表什么——可能提示词场景不匹配，也可能它压根不是为这种任务设计的。这些解释我一个都不替它找补，也不拿它当靶子。
我只说一个观察：这类数字出来之后，评论区永远两拨人，一拨“果然不行”，一拨“评测不公平”。
两拨都不太关心那三分之一是怎么被抓出来的。
而那才是有意思的地方——能测出 33%，说明这批缺陷是“可被评审发现的”，也就是存在一条只要认真读 diff 就能走通的推理路径。AI 走通了三分之一。
剩下三分之二被什么挡着？论文的解释很克制：diff 之外的上下文、作者的真实意图、关于设计与可维护性的判断。
翻译成人话：需求评审会上没写进文档、靠口头对齐、后来那个人离职了的那部分。
所以真正的困境不在模型侧。你让 AI 看一个 PR，要它推出作者为什么这么改——这问题，作者本人三个月后也答不上来。
写到这儿得修正一下前面的话。
“别读成 AI 不行”这句我保留。但我也不把它读成安慰。它大概就是这个问题的现有信息条件下的上限附近：你给的上下文就那么多，能推出来的就那么多，模型再强也是在猜作者心思。
猜心思的准确率我不评价。它的自信程度，我给满分。
（友情提示：以上百分比均来自论文，情绪均来自本人，两者统计上不相关。相关性分析留到下一篇——如果还有下一篇的话 🫠）