LLM 排行榜的另一条轴

你打开任何一个 LLM 编码排行榜，看到的都是一排数字：82、84、86。看上去越高越好，对吧？

但如果你真把”得分最高”的那个模型搬进公司里写代码，运维很可能在周末打电话骂你。因为榜单只回答了”能不能跑通”，没回答”跑起来之后会不会变成安全漏洞，会不会让 review 的人想辞职”。

Sonar 最近做了一次测评——53 个模型、4444 道 Java 题、跑完之后用 SonarQube 把每份代码扫一遍——把这条隐藏的轴翻出来摆在桌面上。结论挺反直觉：得分越高的模型，代码质量不一定越好，有的反而更糟。

原视频是 Prasenjit Sarkar 在 AI Engineer Summit 2026 的 10 分钟分享：”Can LLMs generate Enterprise Quality Code?”

现在的排行榜在评什么

主流 LLM 编码评测基本只有一类指标：

• 任务完成度：SWE-bench、HumanEval、MBPP——能不能解掉这道题
• 代码正确性：测试通过率、功能是否完整

它们共享一个隐含假设：通过测试 = 代码合格。

工程师都知道这不成立。一段代码能不能跑通用例，和它能不能上线维护、能不能扛住安全审计，是两回事。但目前公开的榜单全都站在 X 轴这一侧——大家比谁的通过率更高，没人比谁的代码更可维护。

Sonar 这次干的事，就是给排行榜补上 Y 轴：工程质量。具体拆成四个分量：代码行数、圈复杂度（人读起来要不要命）、bug 密度、安全问题密度。每个都按”每百万行多少个”算，跨模型可比。

Sonar 翻出来的反直觉事实

一、得分最高的模型，代码也最膨胀

直接看数字。同样是 4444 道 Java 题，不同模型解完写了多少行：

• Gemini 3.1 Pro High：84.17% 通过率（当前 SWE-bench 榜首），30.7 万行，圈复杂度 234，bug 密度 614/MLOC，安全问题 210/MLOC
• Claude Sonnet 4.6：62.7 万行，安全密度 300/MLOC（这批样本里最高）
• GPT-5.2 High：约 100 万行
• GPT-5.4：120 万行
• GPT-4o（老模型对照）：不到 25 万行

从 GPT-4o 到 GPT-5.4，同一批题，代码量翻了 4.8 倍。

这意味着什么？打个具体的算盘——

假设你团队一天处理 50 个工单。换上更新的模型，通过率从 75% 涨到 85%，听起来是好事。但每个工单的产出代码量也翻了 3-5 倍。多出来的代码要 review、要测、要维护、要在出问题时被 oncall 翻出来排查。 review 的人力、CI 的算力、未来的维护成本，都在悄悄按倍率放大。

Gemini 那个圈复杂度 234 也值得单说。圈复杂度衡量一个函数的逻辑分支数，业界共识是单个函数超过 10 就难维护。234 不是”略复杂”，是灾难级。这种代码进了生产环境，半年后没人敢动。

二、bug 没变多，只是变细了

这是整个测评里最重要、也最容易被忽略的一点。

Sonar 发现：随着模型代次推进，bug 总数在下降，但 bug 的”分布”在迁移。

• 老模型的 bug 是显性的：空指针、SQL 拼接、未关闭的资源——资深工程师扫一眼就抓得到。这类问题在新一代模型里基本被修掉了（强化学习见效了）。
• 新模型的 bug 是隐性的：跨方法、跨文件的细微逻辑漏洞，需要把整个上下文串起来才看得出问题。

Sonar 用的词是 “finer bugs”。讲者没有展开，但这两个字背后的含义对工程团队来说是颠覆性的。

放回真实场景里说人话：

通过率在涨，但 review 的难度和成本也在涨——而且涨得更快。

这是一个悖论：模型越强，靠”老办法 review”漏掉真 bug 的概率反而越高。

为什么会出现这种现象

简单分析三层原因，按权重排：

1. 训练数据本身的分布

开源代码池里塞了大量低质量代码、内置安全缺陷、隐藏逻辑 bug。模型不会主动区分”反面教材”和”参考答案”，它学的是分布。代码量越大、风格越花哨的样本被复读得越多，新一代模型继承了这种倾向。

2. 目标函数的偏差

当前训练优化的目标是”生成能通过测试的代码”，不是”生成可维护代码”。这两个目标在简单题上重合，在复杂工程场景里分叉。

3. 评测基准的引导作用

这是最关键、也最被忽视的一层。模型团队不会去优化 benchmark 里不考核的东西。 现有的 SWE-bench、HumanEval、MBPP 全都不看圈复杂度、不看安全密度、不看代码体量。模型自然朝”用更多行、更复杂的逻辑、把测试跑过”的方向漂。

第三层比前两层更值得警惕：只要评测体系不变，下一代模型的工程质量大概率会继续退化，哪怕通过率刷得更高。

对一个真在用 LLM 写代码的团队，这意味着什么

三条直接的动作：

1. 选型记录里加上”工程质量”这一栏

不要只记 pass rate 一条数字。把 Sonar 公开在 sonar.com/leaderboard 上的 bug 密度、安全密度、平均行数都抄一遍。同等通过率下，行数低的模型更适合大代码库；安全密度高的模型不该进生产代码路径，哪怕榜首也只配做内部工具和原型。

2. code review 流程要换思路

“扫一眼觉得写得挺漂亮”在新模型时代是反向信号。靠人眼快速 review 抓得到的 bug 越来越少，靠静态分析、跨文件追踪、多模型互审才能抓到的 bug 越来越多。review 工具链得跟着升级，否则就是把责任转嫁给线上故障。

3. 关注评测体系本身的演进

只要榜单只看通过率，模型就只会朝通过率优化。Sonar 这次的工作，价值不在于又造了个新榜单，而在于示范了如何把传统软件工程的质量度量体系迁移到 LLM 评测上。这条路上接下来还会有更多人跟进。

LLM 排行榜的 80% 通过率，只回答了”能不能跑”。能不能交付，是另外一条轴。

视频 10 分钟，建议跳过最后两分钟的产品广告，前 8 分钟就够。