题面故意不说全：编码评测顶分 45.5%，会写代码已经不够

编码评测开始故意把题面写含糊，顶分只有 45.5%。同一批模型名次重排，按任务算钱后价差 12 倍，推理档位的最后 2.1 分最贵。

一个补丁能过测试，不代表该合并。

FrontierCode 2.0 把这句话做成了考题。题面故意写得不完整，让模型自己判断哪些约束没说出来。结果顶分只有 45.5%，八款模型全部低于上一版。分数掉下来，不是模型突然变差，是评测不再奖励「照着题面写完」这件事。

分数集体下滑，先看题目改了什么

2.0 的题目来自更多仓库，比 1.0 多 55%；阻断性评分项多了 43%；参考解平均改动的文件多 67%，代码行多 89%，所在代码库大 25%。还有一类新题：安全补丁和性能优化。

这些变化指向同一件事：任务从「写一个函数」变成「在一个陌生仓库里做一次能交付的修改」。题面只给目标，不给完整设计。模型要自己找相关代码、判断影响范围、补上没被点名的分支。

八款模型在 1.1 版的分数落在 44% 到 55% 之间，到 2.0 变成 18% 到 46%。区间拉开，不是难度线性增加，是原来挤在一起的能力被分开了。

这个分数是评分项的加权汇总。任何一条阻断项没过，该次结果直接记 0。同一轮里，Opus 5.5 的通过率是 49.7%，加权分是 45.5%。

两个数要分开看。通过率回答「有多少任务拿到了可接受的结果」，加权分回答「在通过的任务里做得多完整」。一个补丁可能主体正确，却漏了同类的第二个 bug，评分项被扣，但没到清零。反过来，一个看起来漂亮的改动只要碰了阻断项，直接归零。

所以 45.5 不能读成「一半任务做完了」。它更像一条被刻意压低的及格线：能拿到分，说明改动经得起维护者逐条检查；拿不到，不代表模型不会写代码。

评测里有一组「彻底性」评分项，专门抓那些能从代码库推断、但题面没明说的要求。

题面说某条代码路径有 bug，旁边一条相似路径也有同样的 bug，模型要一起修。题面要求新增一种输入类型，仓库里同类功能已经支持多种类型，模型要顺手补齐。只改题面点到的那一处，功能测试可能全过，评分仍然会掉。

这类要求人类维护者天天在做。读一遍周边代码，知道这个项目怎么处理边界，再决定改动放哪。模型缺的往往不是语法，是这一步。

这也是为什么任务规模变大后分数掉得更厉害。改动一个文件时，猜错成本低；改动十几个文件、还要碰安全逻辑时，遗漏一个分支就是阻断项。

Grok 4.7 掉了 19 个百分点，SWE-2 从 50.0 掉到 23.9。Muse Wonder 1.0 和 Gemini 4 Argon 在另一套编码评测里名次靠前，到这里落到中段。同一批模型，换一套题，排序就变了。

这不是说哪套榜单造假。编码任务的方向差别太大：有的偏仓库内小修，有的偏从零实现，有的偏长程执行。一个榜单的第一名，只能证明它在那类题上最强。采购时拿榜单当筛选可以，拿名次当结论不行。

2.0 同时公布了每次运行的美元成本，按列表价加公开折扣算。

前四名只差 6.5 个百分点，成本从 1.03 美元到 19.94 美元。Sol 拿到 Opus 约 86% 的分数，账单是它的 8%。

这笔账要按「一次能交付的改动」算，不是按 token 单价算。单价低的模型如果多跑几轮、多返工一次，省下的钱会被人工 review 吃回去。反过来，单价高的模型如果一次过，贵得也有理由。

一个可落地的分法：第一版补丁交给便宜档，阻断项由人或者另一道检查兜住；改动涉及安全、数据迁移、权限这类失败代价高的地方，再换贵的模型。别让所有任务都走顶配，也别让顶配只用来改错别字。

Opus 5.5 从低到高的档位，成本曲线很陡：

从 xhigh 到 max，多花 7.64 美元，换 2.1 个百分点，折合每分 3.64 美元。相比之下，从 Sol 的 39.0% 加到 Opus xhigh 的 43.4%，多花 4.15 美元换 4.4 分，每分 0.94 美元。

通过率也跟着变：Opus 从 xhigh 的 47.3% 到 max 的 49.7%，Sol 在 max 档是 42.3%。差距存在，但没有账单差得那么夸张。

默认档位放在 xhigh 更合理。max 只在该阻断项失败会让你多花几个小时返工时才值。把「每分多少钱」和「一次返工多少钱」放在一张纸上比，答案通常很清楚。

第一，数据是评测方自己跑的，题目集不公开。独立复跑能到 46.4% 左右，和官方数字接近，但用的还是同一套题。换个仓库、换种技术栈，绝对值会变。

第二，成本是每次运行的平均花费，不是每次被接受改动的花费。失败的那次也烧钱，还没算人工 review 的时间。真实成本一定比表里的数字高。

第三，价格是列表价加公开折扣。企业合同价、缓存命中率、批量折扣都会改变排序。拿这张表做预算，只能当上限。

第四，单次运行的波动没有展开。分差在 1 个百分点以内的模型，不要当成有先后。要通过率、多次运行、同仓库复测一起看。

第五，题面故意留白，是为了测推断能力，不是让你在真实项目里也这么写需求。生产环境该写的验收条件、阻断条件，还是要写清楚。模型能猜对一次，不代表每次都能猜对。

先在自己的仓库里抽 20 到 30 个真实任务，固定外壳、固定推理档位、固定评分标准，跑两遍。看三个数：一次通过率、被接受改动的平均成本、人工返工时间。

再把任务按失败代价分层。低风险的第一版交给便宜模型，高风险的改动留给贵模型，中间用自动检查接住阻断项。模型路由不是新鲜事，难的是把「失败一次多少钱」算出来。

最后，别把 45.5% 当成模型能力的天花板。它是一套特定题目、特定评分标准下的结果。真正有用的信息是：评测开始从「能不能写出来」转向「该不该合并」，而这个转变会让很多旧名次失效。

会写代码的门槛在降低，判断改动该不该进主干的门槛没降。后者更难测，也更值钱。