LLM 排行榜的另一条轴

最近看 LLM 编码能力的排行榜，越来越像高考分数榜。SWE-bench 跑出 84%、HumanEval 80%+、MBPP 85%——一个分数评所有，再把模型按这条轴排队。

工程世界没那么简单。一段代码能不能通过测试是一回事，它能不能被维护、能不能上线、上线后会不会成为下一季度的安全工单，是另一回事。后面这部分排行榜里几乎看不见。

Sonar 在 AI Engineer Summit 2026 做了一个测评，把 53 个模型放进 4444 道 Java 编程题里跑了一遍，然后用 SonarQube Enterprise 把每个模型的产出拿过来扫一遍，记下行数、复杂度、bug 密度、安全问题密度。讲者是 Prasenjit Sarkar，10 分钟的短 session。原视频：Can LLMs generate Enterprise Quality Code?

我看完之后做的第一件事，是回头看了一下自己最近半年用 Claude 写的代码。

通过率是 X 轴，工程质量是 Y 轴

Sonar 这次的关键贡献，不是又造了个新榜单，而是把”通过率”这一条轴拆成了两条。X 轴还是大家熟悉的 pass rate，也就是 SWE-bench、HumanEval、MBPP 这些跑分关心的事，生成的代码能不能跑通用例。Y 轴是工程质量，至少包含四个分量：

• 行数（同一题用多少行解决）
• 圈复杂度和 Sonar 的认知复杂度（人读起来要不要命）
• bug 密度（每百万行多少个 bug）
• 安全问题密度（每百万行多少个安全 issue）

举几个具体数字。Gemini 3.1 Pro High 在 SWE-bench 上 84.17%，是当前 pass rate 榜首；为了解掉 4444 题它写了 30.7 万行 Java，圈复杂度 234，bug 密度 614/MLOC，安全问题 210/MLOC。这是榜首选手的工程质量画像。

Claude Sonnet 4.6 解掉同一批题写了 62.7 万行，安全问题密度 300/MLOC，是 Sonar 这批样本里最高的。讲者顺口提了一句”highest risk”，没展开。

GPT-5.4 写了 120 万行。GPT-5.2 High 大约 100 万行。作为对照，老一点的 GPT-4o 解同一批题只用了不到 25 万行。也就是说，从 4o 到 5.4，同样的题，新模型写了 4.8 倍的代码。

这是一组很有趣的数据。它意味着：通过率在涨，verbosity 也在涨；通过率每提升一点，每个用例的”产出体量”也在膨胀。从 review 视角看，意味着同样数量的工单，code review 的工作量在被悄悄放大。

新模型的 bug 没多，只是变细了

Sonar 这次还有一个不太显眼但很重要的观察：随着模型代次推进，bug 总数和漏洞总数在缓慢下降，但 bug 的”分布”在迁移。

老模型的 bug 容易发现——空指针、明显的 SQL 拼接、未关闭的资源。新模型这类问题修得不错（强化学习见效），但产出的是另一类问题：跨方法、跨文件的细微逻辑漏洞，需要把上下文串起来才看得出问题在哪。讲者用的词是 “finer bugs”，意思是 bug 变得更隐蔽，对人工 review 的注意力分配是更大的挑战。

放在团队语境里说人话就是：

• 老 LLM 的代码，资深工程师扫一眼就抓到几个明显问题
• 新 LLM 的代码，资深工程师扫一眼会觉得”写得挺漂亮”，但留下的 bug 反而更难被这种”扫一眼”抓到

这跟 Matt Pocock 那个判断对得上。AI 时代不能忽略代码质量，得反过来比以前写得更小心，因为坏代码在 AI 放大下变得前所未有地贵。

为什么会这样

Sonar 给了四个原因，我重排一下：

第一是训练数据本身。开源代码池里有大量低质量代码、有内置的安全缺陷、有隐藏的逻辑 bug。模型不会主动区分这是”反面教材”还是”参考答案”，它学到的是分布。

第二是 LLM 的概率本性。同一个 prompt 今天和明天会出两套不一样的代码，行数、结构、写法都可能差。这条对评测影响不大（统计意义上仍稳定），但对单次 review 影响很大——同一个团队同一个人用同一个工具，今天产出的代码质量和明天的会有非平凡的差异。

第三是上下文有限。模型不知道你这家公司的代码风格、不知道你的架构假设、不知道哪些方法是 deprecated。

第四是不可解释。代码出问题了，没法 debug 模型为什么这么写。

这四点没什么新意，行业里讲烂了。但 Sonar 这次的贡献是给”verbosity 在膨胀、bug 在变细”这个直觉配了一份带数字的对照表。

ACDC：Sonar 给出的 verify 左移方案

讲到一半，Sonar 抛出他们自己的解决方案，叫 ACDC——Agent-Centric Development Cycle。三段式：Guide / Verify / Solve。命名是为了对应那支老牌摇滚乐队，讲者自己都说 “That’s a funny name”，听众笑了一下。

略掉销售腔，三段的工程含义是：

• Guide：在代码生成前介入。Sonar Context Augmentation 把代码库塞进 LLM 上下文；Sonar Sweep 处理训练/参考数据，先把”原料”洗一遍。这一段对应业界常说的 RAG / context engineering。
• Verify：在 commit 之前介入。SonarQube Agentic Analysis 提供一个 MCP，让 Cursor / Claude Code / Codex / Gemini CLI 在准备 commit 时调一次。CI 跑完一轮要 1-5 分钟，这层分析声称 1-5 秒。
• Solve：在 PR 之后介入。SonarQube Remediation Agent 拿到失败的 quality gate，自动起一批 PR 去修存量 tech debt，每个 issue 一个 PR，自动跑分析+编译，引入回归就回滚，不把脏 PR 塞给开发。

抛开 Sonar 自家产品名，这套架构里真正值钱的是中间那一段：把 verify 从 CI（commit 之后）左移到 commit 之前。1-5 秒 vs 1-5 分钟的差，落到 agent 闭环里就是”修复-反馈”循环能不能成立。CI 跑 5 分钟，agent 的注意力早就漂到下一个 task 了；commit 之前 5 秒拿到反馈，agent 还在原地，可以原地修。

这跟 Karpathy 那条 “verifiability first” 是同一个意思：没有度量、没有对照、没有回滚就没有进步。区别只是 Karpathy 讲的是 agent 训练循环，Sonar 把它落到了代码 commit 这一层。

跟 Review Forge / 多模型互审是什么关系

最近看过 vikingmute 的 Review Forge（一个开源的 Claude skill），它走的是另一个路径：让多个模型独立审同一份 diff，重叠的发现基本就是真 bug，fix 和 verify 必须用不同模型，避免同一个模型给自己擦屁股。

ACDC 和 Review Forge 不冲突，是 verify 链路上的不同层级：

• ACDC 的 Verify 阶段，是生成时实时检查——靠静态分析器 / 规则引擎，速度优先，覆盖确定性问题（明显安全缺陷、复杂度、明显反模式）
• Review Forge 的 Multi-Agent Review，是生成完离线复核——靠多模型独立审，时间长但能抓”另一个模型一眼看出、当前生成模型完全没意识到”的盲区

两者放一起，verify 链路就是：

生成 → Sonar 静态分析（秒级） → 多模型 review（分钟级） → 人决策 → CI（分钟级） → 部署

每一层抓不同类型的问题，每一层都为后一层减少噪音。这其实就是经典的左移测试金字塔，套到 agentic coding 上重写了一遍。

我会怎么用这份数据

回到选型这件事。Sonar 把数据公开在 sonar.com/leaderboard，我看了一圈，自己得出几个判断，不一定对：

• 同等通过率下，行数低的模型更适合大代码库。verbosity 不只是审美问题，是 review 工作量乘子，也是 token 成本乘子。
• 同等通过率下，安全密度高的模型，不该进生产代码路径。哪怕通过率第一，300 安全问题/MLOC 的模型也只适合做内部工具、原型、一次性脚本。
• 不能只看一次性 diff 的质量，要看 commit 前能不能闭环。如果 verify 层接不进 agent 的 inner loop（MCP 或类似机制），再准的报告也只是事后总结。

对我们团队来说，最直接的动作是：把”通过率”和”bug/安全密度”两个指标放进内部 LLM 选型记录里，不要只记一条 pass rate。然后看一下 Sonar 这个 MCP 在私有部署的可行性，因为云服务大概率塞不进我们的合规流程。

最后想留一句话：

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

视频 10 分钟，时间不长，建议跳过最后两分钟的产品广告，看完前 8 分钟就够。