LiveCodeBench 被刷到 92 分：三个代码评测榜到底在测什么，测试团队怎么用

这周测试群里传了三张榜单截图：LiveCodeBench 顶分被刷到 92.00，SWE-bench Verified 头部口径 96%—97%，SWE-bench Pro（Public）顶分 80.30。三个数字摆进同一张表，最容易得出的那个结论恰好是错的——它们量的不是同一件事，也不能相互换算。

这篇不预测下一个登顶的是谁，只干一件事：把三个代码评测榜的题目来源、难度形态、防污染机制和顶分口径摊开对照，说清哪些结论能从榜上读出来，哪些绝对不能。

一、三个数字，三把不同刻度的尺子

先把口径钉死，后文所有讨论都基于这三行：

• LiveCodeBench：顶分 92.00，登顶的是 Gemini 3.0 Pro Preview。 题源是竞赛／算法题，带时间窗滚动更新，靠不断换新题来降低被训练语料污染的概率。它测的是「在干净题面上把算法一次写对」的能力。
• SWE-bench Verified：榜面顶分 96.00，登顶的是 Claude Opus 5；部分行业综述记 97.00。 本文统一写「头部口径 96%—97%」这个区间，不咬死单点。题源是真实 GitHub 仓库的 issue 修复，测的是「在陌生仓库里读懂上下文、改对代码、让原有测试转绿」的能力。
• SWE-bench Pro（Public）：顶分 80.30，对应 Claude Fable 5 的深度思考档。 题源同样是真实大仓，但难度显著高于 Verified，天花板本来就低。

这里必须单独强调一句：80.30 是 Pro（Public）的分，不是 Verified 的分。 行业里已经出现过典型的误读案例——把 Pro 的顶分当成 Verified 的顶分来转述，进而得出「榜上根本没有 Opus 5」这种完全相反的结论。一次口径混淆，就能让整份选型判断掉头。两个榜同名不同物，引用时必须带全名。

而截图在群里传递时，最先被裁掉的恰恰就是榜单全名。一张只留下「SWE-bench 80.30」的图，读者会自动用自己熟悉的那个榜去补全，补错的概率极高。所以本文后面所有位置都写全称，也建议你在自己的评审材料里同样处理：宁可标题长一点，也不要让分数失去归属。

二、三榜口径对照表

下面这张表是本文核心，建议直接截图贴进技术评审纪要：

读表三条提示。第一，三列的满分刻度不一样。 LiveCodeBench 的 92.00 和 Pro 的 80.30 之间不存在「差 12 分」这种关系，就像不能拿体温计的读数去减血压计的读数。第二，Verified 已经进入饱和区。 头部口径 96%—97% 意味着榜单前几名的差距小到不足以支撑选型决策，再往上刷分的边际信息量很低。第三，Pro 的低分是设计出来的，不是模型退步。 它把难度抬上去，正是为了在 Verified 饱和之后重新拉开区分度。

三、为什么分数不能直接横比

除了刻度不同，还有三个结构性原因，任何一个都足以让横向比较失效。

一是判分单元不同。 LiveCodeBench 判的是单道题的输出是否正确；SWE-bench 系列判的是一份 patch 能不能让仓库里失败的测试转绿、同时不把原本通过的测试改坏。前者是「做题」，后者是「交付」：一个 patch 里包含定位、复现、修改、回归四个环节，任何一环失手，整题就是零分。

二是运行档位不同。 Pro 顶分 80.30 对应的是深度思考档，消耗的推理预算和常规档不在一个量级。拿一个开了长思考链的分数，去和另一个榜的常规档分数比高低，比的是预算，不是能力。

三是污染窗口不同。 LiveCodeBench 靠时间窗把新题不断换进来，题目在公开语料里存在的时间短；SWE-bench 系列的题面已经公开很久，模型见过相似结构的概率更高。同样一个分数，落在「新题」上和落在「老题」上，含金量并不相等。

四是样本量与执行环境的噪声。 榜单分数是一次特定评测框架、特定超时设置、特定重试策略下的结果，换一套 harness 重跑，同一模型的分数就会漂移。当头部差距已经被压到小数点后一两位时，这点漂移量级足以颠倒名次。所以在饱和区里，「谁高零点几」这种比较基本没有决策价值，真正值得看的是量级差异和长期趋势，而不是当日的位次。

四、该看哪个榜：一张决策表

榜单不是不能用，是要按目的用。把常见诉求收敛成下面这张表：

最后一行才是这张表真正想说的话：公开榜能帮你把候选名单从二十个缩到三个，但不能替你走完最后那一步选择。

五、门禁用自建 evals，公开榜只作线索

真正能当发布门禁的，只有一套贴合自家业务缺陷分布的自建 evals。落地路径并不复杂，四步：

第一步，取样本。 从近两到四个季度的线上缺陷、回归漏测、代码评审打回记录里抽样，按模块和缺陷类型分层，形成一百到三百条的种子集。这一步决定了整套 evals 的天花板——样本不来自真实缺陷，跑出来的分数就只是自我安慰。

第二步，做成可自动判定。 每条样本必须有明确的通过条件，能由脚本直接判 pass／fail，不依赖人工看结果。判不了分的样本，再典型也进不了门禁。

第三步，写进流水线当闸门。 示意片段（数值为方法论示意，非实测）：

eval_gate:
  suite: internal-defect-seed      # 自建缺陷集，非任何公开榜
  threshold: { pass_rate: ">=0.90", new_regression: 0 }
  on_fail: block_merge

第四步，定期换血。 公开榜靠时间窗防污染，自建 evals 同样要防「被背下来」：模型或提示词每次大改，就往集子里补一批新样本，旧样本逐步降权。一个三年不变的自建集，最后也会退化成另一张失去区分度的榜。

这样公开榜和自建集之间的关系就顺了，是三层漏斗而不是二选一：第一层用公开榜做初筛，把明显不合格的候选挡在外面，这一步成本几乎为零；第二层用自建 evals 做复筛，在你自己的缺陷分布上跑分，决定谁能进灰度；第三层用线上观察做终审，看真实缺陷拦截率和评审打回率有没有变化。三层各管一段，谁也替代不了谁。

自建集最常见的失败模式也顺便说一句：把 evals 做成「模型能不能写对这段算法」，那只是复刻了一张小号的 LiveCodeBench。真正有价值的样本，往往长得一点也不像面试题——它是一段带历史包袱的接口、一个偶发的并发时序、一份格式不规范的导入文件。这些题在公开榜上永远不会出现，却占了你线上缺陷的大头。

这套东西跑通之后，公开榜的位置就清楚了：它是行业温度计，不是你家客厅的空调遥控器。

六、写在最后

三个榜单、三个顶分，本质上是三把刻度不同的尺子在量三件不同的事。92.00 量算法基本功，96%—97% 量在真实仓库里改对代码的头部水平，80.30 量的是更难一档的大仓能力——它们各自都有用，前提是别把它们塞进同一个不等式。

榜单告诉你这个模型在别人的题上能做到什么，只有自建 evals 能告诉你它在你的缺陷上会不会翻车。

如果你正在给团队搭第一套自建 evals，留言区说说你们的缺陷主要集中在哪类模块，我帮你看看种子集该怎么分层。