三款前沿 LLM 代码审查实测：谁更靠谱

一位开发者将自己的平台代码同时交给三款来自不同公司的前沿大模型进行审查，并对每条结论逐条对照源码核验，再用 A/B 实验验证最准的那条建议。结果显示：五分之五的「最准」评审发现了一处真实的算法缺陷；「最热情」的评审却以近乎满分的姿态给出了最多的杜撰内容；而那条被验证为真的修复建议，在 A/B 中以 75 比 76（83 题中）落败，最终未能上线。

评审一：五发五中，零虚假陈述

最严谨的评审每一条结论都能在源码中找到对应内容，包括唯一一处被所有评审者真正抓到的算法 bug：在混合检索的融合打分中，关键词部分的稀有度是基于「已经从语料里召回的几十个候选」来计算的，而不是基于整个语料。当候选池为 60 时，出现在全部 60 个候选中的词打分趋近于零，而仅在 1 个候选中出现的词反而拿到 3.7 分——这恰好与设计意图相反，对最具区分度的「主题词」惩罚最重。

该评审还展示了一项准确评审应有的克制：所有断言都不超出代码包能支持的范围。

评审二：瞄对了靶子，但理由错了两次

第二份评审准确指向了真正有 bug 的函数，却附上了一个并不存在的「每查询代价过高」理由——相关循环只跑几十个候选，并不涉及全语料。它还通过一条当前部署并不暴露的攻击路径，指出了一个真实弱点。但它对代码包未展示的内容做了明确的不确定表态，而不是强行下结论。

在对其「肯定句」的审计中，四条被肯定的优点里有三条成立，剩下一条「零数据外发」属于误导性表述：嵌入与重排确实是本地执行，但若未走本地通道，检索文本会发送给云端模型。准确的表述应当是限定语境的，而非绝对的。

评审三：评分近乎满分，可信度最低

第三份评审宣称该系统「优于几乎所有生产级实现」，但逐条核验后发现杜撰最多：

• 源码中并不存在的缓存
• 源码中并不存在的重试逻辑
• 源码中并不存在的数据库故障转移路径
• 对向量库的描述自相矛盾
• 仅凭推断就断言的 CI 扫描器与夜间备份

它还报告了一处「缺失的限流」，而生产环境实际会返回 429；将作者公开作品集中的数字回读给作者本人，作为「已在源码中核实」的依据；并把唯一真正包含 bug 的函数评为「最佳实现」。其中一条建议甚至具有反向危害——把原本由宿主机外部注入的密钥搬进仓库目录内的文件中，并冠以「最佳实践」之名。

尾声：一条真实发现为何未能上线

实施与对照

既然池内稀有度 bug 真实存在，作者按评审建议构建了修复版本（融合打分改用全语料统计），并在线上语料上与未改动的基线进行 A/B 对照：基线在 83 道题中命中 76 个正确答案，两个修复版本各命中 75 个。零新增转化、一处边界命中丢失、Top-1 表现持平。

失败原因

架构吞掉了这条 bug：融合打分只决定宽候选池的排序，最终 Top-5 由跨编码器重排模型完成——因此「池内稀有度反转」在这条管道上的影响半径极小。代码被回滚，并在回归测试中钉死了重新打开的条件：一旦重排模型不再掌控最终阶段，这条结论会被重新测量，而不是重新辩论。

一周搭出的四级阶梯

杜撰式表扬 → 理由错误的指认 → 经核验为真的发现 → 经测量的改进——三份评审都没能爬到最上一级。评审结论与测量结果是两件不同的工具，只有经过测量的那一级才能上线。

流程教训

理由错的指认也要审

第二份评审以错误的代价理由指向了正确的函数。代价理由被驳倒后，审计随之收尾——恰恰略过了真正缺陷就坐在刚读过的几行里。理由错不等于靶子错，正确的应对是对靶子再做一次独立审计，而不是去反驳那个理由。

不仅审批评，也要审表扬

假阳性是评审中更危险的一半，因为被评对象总忍不住引用它们。文中对每一条「肯定句」都做了与缺陷相同的逐条核验——这正是「零数据外发」被识别为不成立的系统级断言、并被替换为架构所能支持的限定表述的过程。

一份「热情洋溢」的评审

原文在此处被截断，但从已给出的证据可以推断：评分最高、措辞最暖的评审，未必是工程上最值得采信的评审；当一份结论无法被逐条回溯到源码时，它对生产决策的权重应当趋近于零。