这周测试群里传了三张榜单截图：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 | SWE-bench Verified | SWE-bench Pro（Public） |
|---|---|---|---|
| 题目来源 | 竞赛／算法题，独立题面 | 真实 GitHub 仓库的历史 issue | 真实大仓，仓库规模与依赖更重 |
| 难度形态 | 单题算法正确性，边界条件密集 | 跨文件定位＋最小改动＋测试通过 | 同 Verified 但更难，长链路依赖多 |
| 防污染机制 | 时间窗滚动，只收近期新题 | 人工核验题面（Verified 的含义） | 公开子集，题更难、更新更慢 |
| 顶分与对应模型 | 92.00（Gemini 3.0 Pro Preview） | 96.00，行业综述记 97.00（Claude Opus 5） | 80.30（Claude Fable 5 深度思考） |
| 实际测的能力 | 从零写出正确算法 | 在既有代码里安全地改对 | 在复杂大仓里啃硬骨头 |
| 分数该怎么读 | 越高说明算法基本功越强 | 头部已接近饱和，差距在个位数 | 天花板低，80 分档已是头部 |
读表三条提示。第一，三列的满分刻度不一样。 LiveCodeBench 的 92.00 和 Pro 的 80.30 之间不存在「差 12 分」这种关系，就像不能拿体温计的读数去减血压计的读数。第二，Verified 已经进入饱和区。 头部口径 96%—97% 意味着榜单前几名的差距小到不足以支撑选型决策，再往上刷分的边际信息量很低。第三，Pro 的低分是设计出来的，不是模型退步。 它把难度抬上去，正是为了在 Verified 饱和之后重新拉开区分度。
三、为什么分数不能直接横比
除了刻度不同，还有三个结构性原因，任何一个都足以让横向比较失效。
一是判分单元不同。 LiveCodeBench 判的是单道题的输出是否正确；SWE-bench 系列判的是一份 patch 能不能让仓库里失败的测试转绿、同时不把原本通过的测试改坏。前者是「做题」，后者是「交付」：一个 patch 里包含定位、复现、修改、回归四个环节，任何一环失手，整题就是零分。
二是运行档位不同。 Pro 顶分 80.30 对应的是深度思考档，消耗的推理预算和常规档不在一个量级。拿一个开了长思考链的分数，去和另一个榜的常规档分数比高低，比的是预算，不是能力。
三是污染窗口不同。 LiveCodeBench 靠时间窗把新题不断换进来，题目在公开语料里存在的时间短；SWE-bench 系列的题面已经公开很久，模型见过相似结构的概率更高。同样一个分数，落在「新题」上和落在「老题」上，含金量并不相等。
四是样本量与执行环境的噪声。 榜单分数是一次特定评测框架、特定超时设置、特定重试策略下的结果，换一套 harness 重跑，同一模型的分数就会漂移。当头部差距已经被压到小数点后一两位时，这点漂移量级足以颠倒名次。所以在饱和区里，「谁高零点几」这种比较基本没有决策价值，真正值得看的是量级差异和长期趋势，而不是当日的位次。
四、该看哪个榜：一张决策表
榜单不是不能用，是要按目的用。把常见诉求收敛成下面这张表：
| 你的目的 | 参考哪个榜 | 为什么 | 不能得出什么结论 |
|---|---|---|---|
| 判断模型的算法／刷题基本功 | LiveCodeBench | 题面干净、时间窗防污染，干扰项最少 | 不能推出它在你的老仓库里改得动代码 |
| 评估「改既有代码」的能力上限 | SWE-bench Verified | 真实 issue＋真实测试，最接近日常修 bug | 头部已饱和，96%—97% 区间内的名次差不足以选型 |
| 在头部模型之间重新拉开区分度 | SWE-bench Pro（Public） | 难度更高，80.30 的天花板仍有空间 | 不能把这个分数当成 Verified 的分来读 |
| 决定要不要把模型接进自家流水线 | 三个榜都只作线索 | 公开榜题源与你家业务缺陷分布并不重合 | 不能得出「上线后线上缺陷会降多少」 |
最后一行才是这张表真正想说的话：公开榜能帮你把候选名单从二十个缩到三个，但不能替你走完最后那一步选择。
五、门禁用自建 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，留言区说说你们的缺陷主要集中在哪类模块，我帮你看看种子集该怎么分层。
