FrontierCode：把评测问题从「对不对」换成「你会不会真的合并」

概述

做 Devin 的 Cognition 发布了一个新评测 FrontierCode，问的不是「模型写的代码能不能跑通」，而是一个更尖锐的问题：作为这个仓库的维护者，你会不会真的把这段代码合并进生产分支。它自称是第一个直接衡量「可合并性」（mergeability）的评测，评分维度包含正确性、测试质量、改动范围的克制、代码风格，以及是否符合该代码库自身的约定。

这件事的分量不在于又多了一个排行榜。过去两三年里，coding 评测的事实标准是 SWE-bench 这类「跑通隐藏测试就算赢」的功能正确性评测，而 FrontierCode 想说的是：当模型已经普遍能写出能跑的代码，「能跑」本身已经不再是有区分度的信号了。真正稀缺、也真正决定一段 AI 代码能否进生产的，是它会不会被一个有审美、有责任的人类愿意接手维护。把评测目标从「对不对」挪到「你会不会接手」，是这篇博客最值得认真对待的判断，尽管这个目标本身就把一堆主观性请进了门，这点后面要算账。

发生了什么

FrontierCode 的任务不是从单个历史 PR 程序化抓取生成的，而是由 36 个旗舰开源仓库的维护者亲手设计的，包括 Celery、Budibase、uppy、Mattermost 等项目的核心维护者或负责人。按 Cognition 的说法，每个任务平均投入超过 40 小时，由维护者把自己审 PR 时的判断「蒸馏」成一套具体的评分标准：满足这些标准的 PR，他们真的会批准合并。

评分被拆成两类。一类叫 blocker（阻断项），代表维护者在代码评审里会直接叫停的硬门槛，不只是正确性，也包括性能、改动范围这类非正确性的硬要求；另一类是 non-blocker（非阻断项），是代码风格、类型安全、可读性这类不一定挡住合并、但反映质量高低的信号。一个解法只有过了全部 blocker 才算「通过」，分数是它通过的各项标准的加权汇总；只要有任何一个 blocker 没过，分数直接归零。这个「一票否决 + 加权打分」的双层结构，本身就是在模仿真实评审里「致命问题先一票否决，其余再看成色」的逻辑。

评测分三个嵌套子集，难度递增：Diamond 是最难的 50 题，Main 是最难的 100 题（含 Diamond），Extended 是全部 150 题。每个模型在每个可用的推理强度下各跑 5 次，取 5 次平均，再报告其表现最好的那一档推理强度的成绩。结果是：最难的 Diamond 远未被刷满，表现最好的 Claude Opus 4.8 也只拿到 13.4%，GPT-5.5 是 6.3%，Gemini 3.1 Pro 是 4.7%，其余更低；不过博客同时指出 GPT-5.5 用的 token 最多比 Opus 4.8 少到四分之一，成本-智能的性价比更好。到了 Main 和 Extended，Opus 4.8 仍明显领先，分别是 34.3% 和 51.8%。开源模型与前沿之间差距很大：表现最好的开源模型 Kimi K2.6 在 Diamond 上只有 3.8%，Main 16%，Extended 37%。

值得单独拎出来的，是 Cognition 给出的一个可验证对比：通过分析智能体的解题轨迹，FrontierCode 的假阳性率比 SWE-Bench Pro 低 81%。假阳性指测试覆盖不全、把错误解法当对的放过。与之相对的另一类误判是假阴性（测试太死板，盯着确切的报错字符串或函数名，把本来正确的解法判错），FrontierCode 靠维护者亲手设计的评分标准来兜这一类。METR 早先的实验也发现，在老评测上高分的模型，产出的补丁常常是人类维护者根本不会接受的。如果这个 81% 站得住，那它才是 FrontierCode 真正的卖点：不是「换了个更难的题」，而是「打分更接近事实」。

为何重要

最该被记住的判断是：「会不会被合并」是一个复合属性，而通过率是一个标量。一段代码能不能进生产，从来不是单一维度：它要能跑、要不破坏现有功能、要过 lint 和构建、测试要真的覆盖目标行为、改动范围别越界、还要符合这个代码库的设计惯例和可读性。把这些压成一个「通过/不通过」的二元信号，必然丢掉大量信息。FrontierCode 的做法是把这些维度显式拆开、分别打分、再用 blocker 机制还原「有些问题是硬伤」的现实。这比单纯把题目改难、把补丁改大要诚实得多；博客也明确说，他们是用质量评分标准而非单纯加大补丁体量来提升难度，结果 FrontierCode 的补丁比 DeepSWE 更小，却更难解。

第二点是关于「通过率虚高」。当一个评测只查功能正确，模型很容易学会「让测试变绿」而不是「写出好代码」，尤其当测试本身覆盖不全时，写出隐患十足但恰好骗过测试的解法是有利可图的。FrontierCode 引入的几个新机制正是冲着这个去的。反向经典测试（reverse-classical）要求把智能体自己写的测试拿到「原始的、有 bug 的代码库」上跑，它必须失败：这是一个确定性的自动检查，逼智能体证明它真的理解了问题，而不是写了个永远绿灯的空测试。改动范围（scope）检查从文件、行数、语义三个层面约束「只改该改的」，对应真实评审里维护者最反感的「顺手大重构」。自适应经典评分（adaptive grading）则用一个叫 mutagent 的工具，让 LLM 去微调测试环境以适配智能体的实现细节，从而既保留确定性测试的严格，又不至于因为函数名、报错措辞这类表面差异冤枉一个正确解。这三件事合起来，是在认真对付「绿灯不等于好代码」这个老问题。

第三点，也是必须泼的冷水：这套东西把大量主观性正式请进了评测。Cognition 自己承认 rubric（评分标准）的设计天然主观、需要领域专业判断，每条标准是 blocker 还是 non-blocker、权重多少、覆盖是否完整，都靠维护者拍板。他们用一整套质量控制流程去对冲：让任务作者扮演「偷懒或恶意的程序员」去尝试用错误解法骗过评分（防假阳性），又写一个与标准答案不同但同样有效的解法去试探评分是否太死（防假阴性），还让 Devin 来想新的「钻空子」方式；之后是 pod 内多轮评审、Cognition 研究员终审、随机抽样让研究员亲自做题验证。流程不可谓不重。但流程再重，也只是把「谁来定义好代码」这个问题从「单个标注员」上移到了「一组维护者 + Cognition 研究员」，并没有消除它，只是让主观判断更一致、更可追溯，而不是变成客观。这是个真实的进步，但不该被包装成「我们终于客观地测出了代码质量」。

对建设者的影响

如果你在为团队选 coding 智能体，FrontierCode 的成绩单比 SWE-bench 通过率更值得看一眼，但要看对地方。它真正的信息量不在「谁排第一」（Opus 4.8 在三档上都领先），而在那个绝对水平：Diamond 上最强的模型也只有 13.4%，意味着在真正高标准的生产代码库里，今天所有前沿模型产出「可以直接合并」的 PR 的能力都还很弱。这跟你在轻量任务上看到的高通过率是两回事。换句话说，它帮你校准期待：让智能体写能跑的代码已是常态，但「写出你愿意接手维护的代码」远未解决，人类评审这道关一时半会儿撤不掉。

性价比这条线索也别忽略。博客特意指出 GPT-5.5 用的 token 最多比 Opus 4.8 少到四分之一，在质量略低的前提下拿到了更好的成本-智能折中。对真要把智能体接进 CI、按量付费跑成千上万次的团队，这种「单位成本下的质量」往往比榜首分数更决定选型。FrontierCode 在图 1 之后的数据浏览器里把各推理强度的 pass@5、token、美元、步数成本都拆出来了，这部分比头条数字更有操作价值。

但选型时也要清楚这张榜的边界。HN 上一个反复被追问的点是 harness 敏感性：博客报告的成绩跑在「自家」harness 上（比如 codex 配 GPT、Claude Code 配 Opus），团队成员也承认有些模型在「非自家」harness 上表现更好。也就是说，同一个模型换一套工具脚手架，分数可能变化不小。这不是 FrontierCode 独有的毛病，但意味着你不能把它的排名直接搬到你自己的那套工具链上。最稳妥的用法，是把 FrontierCode 当成「这件事到底有多难」的标尺，而不是「我该买哪个 API」的最终答案；后者还得在你自己的代码库、你自己的脚手架上实测。

该忽略什么

别把「会不会合并」误读成一个客观分数。HN 上有人直接质疑：连人类自己的代码质量都没法达成共识、没法测量，凭什么相信能测 LLM 的。这个批评有点过头，不需要全人类共识也能测一件事，挑一组质量度量就能构成评测，但它点中的方向是对的：FrontierCode 测的是「这群特定维护者在他们各自的仓库里会不会合并」，不是某种放之四海的「代码质量」。换了一组维护者、换了一个代码库，blocker 和权重都会变。把它的分数当成模型「代码好坏」的通用绝对值，是误用。

也别太纠结排行榜上的名次差异和缺席者。HN 上有人质疑「取每个模型表现最好的那档推理强度」会不会引入类似 best-of-N 的多重比较偏差，也有人问为什么不放误差棒（团队回应说只有 50 道独题、报的是 pass@5，要给出可信区间得跑 50+ 次）。这些都是合理的方法学批评，但对你的实际决策影响有限：它们改变的是小数点后的精确排名，不改变「最强模型也只有个位到一两成」这个大结论。同理，关于「为什么没测某些更便宜的中国模型」「凭什么算前沿模型」的争论，属于覆盖面问题，等后续版本扩充即可，不必现在替它下定论。

对研究者的影响

对做评测的人，FrontierCode 最有借鉴价值的是它对待主观性的态度：不假装回避，而是用对抗性测试、校准、多阶段复核去把主观判断「钉死」成可复现的标准。尤其是反向经典测试这一招，用「测试必须在坏代码上失败」来证明测试有意义，是一个干净、确定性、且可推广到别处的好点子，值得被其他评测借走。同样值得注意的是它对 prompt 的处理：刻意把任务描述写得像人话、且只有 SWE-Bench Pro 三分之一长，逼智能体去推断维护者的意图，而不是被过度规范的题面喂着走。这反映了一个判断：前沿模型已经不需要那么多手把手，评测也该相应「减少喂饭」。

但研究上要警惕的也正是它的设计取舍。Cognition 表示出于防污染考虑暂不公开发布这些任务（HN 上有团队成员说之后会放出，与博客口径略有出入，这一点存疑），只向模型厂商开放评测。这意味着短期内外部研究者很难独立复现或审计它的 rubric，而一个把主观判断当核心的评测，恰恰最需要外部审计。把它当成「目前最接近工程现实的代码评测之一」是合理的；把它当成可被独立验证的客观真理，则为时尚早。

来源

1. FrontierCode: An eval to measure whether you would actually merge the code / blog
2. FrontierCode: An eval to measure whether you would actually merge the code (Hacker News) / hn

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。