FrontierCode 在 Hacker News 获 101 分

把标准从正确性提升到质量

如今的编程基准测试已经证明，模型能够写出正确的代码。但随着 AI 生成的代码成为进入生产环境的主要途径，正确性现在只是基本门槛。我们应该问的问题是：模型真的能写出优秀的代码吗？

我们很高兴推出 FrontierCode，一个衡量模型能否真正达到高质量生产代码库标准的基准测试。我们的独特之处在于：

• 维护者真的会合并这个 PR 吗？我们是首个衡量代码可合并性的基准测试。我们的评估标准考察端到端的代码质量——正确性、测试质量、范围把控、风格以及对代码库规范的遵循。我们采用了一套全新的组合评分技术，包括单元测试、评分细则（rubrics）以及新型验证器。

• 由开源维护者精心打造。20 多位世界级的开源开发者基于自己维护的代码库构建了真实、多样且具挑战性的编程任务，每个任务耗时超过 40 小时。他们定义了在各自代码库中“可合并”意味着什么。

• 严格的质量控制。评分细则的打分带有主观性，因此我们构建了一套完善的质量控制（QC）流程，包括对抗性测试、校准和多阶段审核，每个任务都由一名 Cognition 研究员人工审核。与 SWE-Bench Pro 相比，我们的误报率降低了 81%。

我们的基准测试提供了衡量模型编写高质量、可维护代码能力的最强信号。我们发现，即使是当今最强大的模型，在这个新标准上也表现挣扎。

20 多位世界级开源维护者

每个任务 40 小时工作量

由 Cognition 研究人员人工审核

每个任务

误报率降低 81%

与 SWE-Bench Pro 相比

首个衡量代码质量的基准测试

以及微妙的人类偏好

结果

我们按照难度递增呈现 FrontierCode 的三个嵌套子集：Extended、Main 和 Diamond。Diamond 包含 50 个最难的任务，Main 包含 100 个最难的任务（含 Diamond），Extended 则是全部 150 个任务的完整集合。

我们报告两项指标，通过率和得分：

• 如果一个解决方案 通过，意味着它清除了所有阻断性标准，即维护者在代码审查中会视为硬性中止的标准；否则该方案 失败。

• 解决方案的 得分 是各评分细则项的加权汇总。未通过阻断性标准的解决方案得分为 0。

每个模型在每个可用的推理强度下运行 5 次。对每个推理强度，我们取 5 次试验的指标平均值，然后报告每个模型在其表现最好的推理强度下的得分。

FrontierCode 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 的 1/4，实现了更优的成本-智能权衡。

在 FrontierCode Main 和 Extended 上，Opus 4.8 仍保持明显领先，分别为 34.3% 和 51.8%。我们还观察到开源模型与前沿模型之间存在巨大差距。表现最好的开源模型 Kimi K2.6 在 Diamond 上仅取得 3.8%，在 Main 上为 16%，在 Extended 上为 37%。

本文其余部分将深入探讨我们为何以及如何构建 FrontierCode。

我们为何构建 FrontierCode

第一代编程基准测试，如 SWE-Bench Verified 和 Pro，是为能力较弱的模型设计的。它们在真实性和鲁棒性的许多方面都存在不足。

从根本上说，它们只测试功能正确性，而非质量。此外，这些基准测试容易出现误分类错误。METR 的实验¹发现，在这些基准测试中得分很高的模型所产生的补丁，往往不会被人类维护者接受。

我们如何定义误分类？它们分为两类：

• 假阳性：验证器不应奖励错误的解法。测试覆盖可能不完整，使模型得以写出错误却仍被通过的解法。

• 假阴性：验证器不应惩罚正确的解法。测试可能过于具体，例如检查确切的错误字符串或函数名；也可能无法解决，即测试了指令或代码库中并不存在的行为。

通过对智能体轨迹的分析，我们证明 FrontierCode 产生的误分类错误比其他领先的基准测试少 81%。这意味着 FrontierCode 的分数是目前最准确的排名。

现有基准测试还在多个方面存在多样性不足的问题。

其他基准测试通过程序化抓取从单个 PR 生成问题，而 FrontierCode 由仓库维护者从多 PR 链和自由格式的请求中人工挑选。我们还将所涵盖语言的数量增加到了 SWE-Bench Pro 的三倍。

众所周知，现有基准测试提供的指引过多，提示词过度细化且冗长。如今的前沿模型需要的引导要少得多。FrontierCode 要求智能体在获得与人类贡献者相同上下文的情况下，自行推断维护者的意图。

我们的提示词包含两部分。第一部分是任务描述。第二部分是代码库指南，涵盖通用测试、lint 和代码风格规范，就像 AGENTS.md 中的内容一样。任务描述如同真人所写，且刻意保持简洁 —— 长度仅为 SWE-Bench Pro 的三分之一。

此外，我们选择通过质量评分标准来提升任务难度，而不是简单地增大补丁规模。尽管补丁比 DeepSWE 等基准测试更小，FrontierCode 对智能体来说却更难解决。

要打造像 FrontierCode 这样雄心勃勃的代码质量评测，我们必须把质量嵌入基准构建过程的每一个环节。

我们如何构建 FrontierCode

一支由开源维护者组成的团队

FrontierCode 旨在衡量模型能否产出真正会被合并进生产代码库的代码。为此，我们直接与 36 个旗舰开源仓库的维护者展开合作。这支全明星专家团队曾共同审查并合并了数千次提交到他们的代码库中。他们能为看到的每一个 PR 运用深入的风格与设计知识。

每位维护者为每个任务投入了 超过 40 小时，与其他评测工程师及 Cognition 研究人员进行了多轮迭代。他们将自身的判断提炼为具体的评估标准：任何满足这些标准的 PR 都会被真正批准合入。

以下是他们对 FrontierCode 的评价：

“Working with the team behind FrontierCode was a privilege. Taking on the AI evaluation problem felt like nothing less than an art… Where others grade like a CI, FrontierCode grades like a tech lead.”

Tomer Nosrati，Celery（28.6k stars）CEO 兼技术负责人

“What sets FrontierCode apart is the attention to detail. Each task is calibrated to a depth that simply hasn’t been seen before in LLM benchmarking. We should be moving away from benchmarks that can be gamed and instead using ones like FrontierCode to demonstrate genuine model intelligence and creativity.”

Martin McKeaveney，Budibase（28k stars）联合创始人兼 CTO

“I’m grateful to have worked with leading experts in the Open Source community. We had deep discussions on correctness versus quality and what mergeability means in the context of their repository. FrontierCode is a milestone for AI models respecting subjective quality in the real world.”

Merlijn Vos，uppy（30.8k stars）核心维护者

“FrontierCode’s unique value comes from the human experience encoded in its evals: years of judgment about what makes code high-quality and worthy of merging. The almost obsessive care brought to every criterion is why I believe this benchmark sets a new bar for SWE evaluation.”

Claudio Costa，Mattermost（37k stars）核心维护者

超越单元测试

FrontierCode 通过沿以下维度评估代码来衡量可合并性：

• 行为正确性：补丁是否成功解决了问题？

• 回归安全性：它是否破坏了现有代码库中的任何内容？

• 机械整洁性：它是否通过了项目的构建、lint 和风格检查？

• 测试正确性：智能体的测试是否真正捕捉到了预期的行为？

• 范围：补丁是否只改动了必要的部分？

• 代码质量：代码是否符合代码库的约定、遵循合理的设计模式，并对协作者来说保持可读性？

下表描述了我们如何同时使用经典的单元测试和新颖的方法（例如自适应经典评分、范围检查和反向经典测试，这些方法详见下文）来评估这些标准。

每项标准要么是 阻断项，要么是 非阻断项：

阻断项代表可合并性要求，即维护者在代码审查中会视为硬性中止的标准。这些包括正确性检查，以及性能或范围限制等非正确性问题。

非阻断项代表代码风格、类型安全和可读性等质量信号，这些不一定阻止合并。

如果一个方案满足所有阻断项，则视为通过，其得分是它所通过的所有评分细则项的加权汇总；否则得分为零。

新颖的评分方法

我们引入了三种主要技术，以强化评分标准、防止误分类，同时为多种有效解法留出空间：

反向经典法（Reverse-Classical）： 反向经典标准是一种确保智能体编写的测试有意义的方法：当我们在原始的、有问题的代码库上运行这些测试时，它们 必须失败。这为我们提供了一个自动化、确定性的检查，证明智能体对问题的理解足够深入，能够为它编写出有效的测试。

代码范围（Code Scope）： 一个好的 PR 应当 克制：只修改需要修改的部分，不触碰无关文件，也不引入不必要的重构。scope 标准是一项自动化检查，用于强制执行这些边界。它结合了三类约束：

• files：用于对哪些文件可以被 允许、拒绝或必须被 删除进行快速、确定性的检查。

• size：用于强制限制 变更行数、净增行数或修改的 文件总数。

• semantic：用于基于 LLM 的检查，验证更改在文件特定部分（例如单个函数内部）的 局部性或 性质。

自适应经典评分：开放式编程任务可以有多种有效解法。静态单元测试过于僵化；好的解决方案可能因为函数名或错误措辞等表面差异而失败。我们通过 mutagent 来解决这一冲突，这是我们构建的一个工具，它使用 LLM 精准地修补测试环境（或应用代码），使其与智能体的实现细节保持一致，从而让我们能够对开放式解决方案运行严格、确定性的测试。

示例任务

Andrew He (ecnerwala) 是 Codeforces 上评分第二高的美国选手、两届 IOI 金牌得主、Cognition 的创始工程师，也是我们的资深 C++ 专家。他亲自审查了模型在此任务上的表现。

此任务基于一个用 C++ 编写的 jsonschema 仓库。它要求实现一个新函数 auto LOG_WARNING() -> std::ostream &，代码库中每一处打印 warning: <message> 的地方都应使用该函数。这个辅助函数应在日志消息前加上 warning: 前缀，输出到 stderr，并忽略 --verbose 标志。

这个任务看似简单：一个通过的解法只需找出给定代码库中所有打印 warning: 的地方，并替换为对新实现的 LOG_WARNING() 函数的调用。然而，模型在这个任务上的失败方式有些出人意料。其中一项阻断性判据要求多行警告消息以惯用方式调用 LOG_WARNING，如下所示：

LOG_WARNING() << "You are opting in to remove schema identifiers... \n"
              << "The only legit use case...\n"
              << "non-compliant...\n" << ... ;

而 Claude Opus 4.8 却始终选择以下实现方式：

LOG_WARNING() << "You are opting in to remove schema identifiers...\n";
    std::cerr << "The only legit use case...\n";
    std::cerr << "non-compliant...\n";

这两种写法在行为上是相同的；两种情况下，多行错误信息都会被打印到 stderr。然而，智能体方案在调用处内置了 LOG_WARNING() 和 std::cerr 是同一个流这一假设，而在未来对 LOG_WARNING() 的修改中这一点可能会发生变化。

质量控制

我们如何迭代改进评分标准（rubric）的质量？

改进单元测试这类二元验证器相对容易处理，因为每个解法都落在两个类别之一——正确或不正确。你可以逐个检查每次 rollout，确认它属于哪个类别，并据此强化测试。

而强化基于提示词的评价标准则是一个难得多的 QC 问题。评分标准引入了一个正确性的 光谱：针对同一任务的两个解法可能在功能上都正确，却在每项标准上得分不同。我们不能再孤立地审视单个解法，而必须在一组解法内部进行比较，并验证它们的相对分数确实能把更好的解法与更差的解法区分开。

评分标准的设计本身也带有主观性，并且需要领域专业知识。对于每项标准，维护者必须决定它是阻断项还是非阻断项，相对于其他标准为其分配权重，并确保覆盖完整，使模型无法钻评分标准的空子。

我们的评分标准创建流程

1. 设计

   对于可以确定性验证的内容，例如正确性，我们更倾向于使用经典测试。对于复杂任务，我们更倾向于采用对实现细节的表面差异具有鲁棒性的行为测试。

   对于较软性的质量，我们更倾向于使用 LLM 评分。这更适合评估诸如代码是否地道、可读性或是否符合首选架构模式等方面。

   基于这些原则，我们首先要求任务创建者人工审核每一条评分标准项，并记录其依据。

2. 钻空子报告（Hack report）

   为了防止误报，任务作者会模仿一个偷懒或带对抗性的程序员，尝试用故意错误或不完整的解法获得通过分数。这可以暴露出需要改进的评分标准。

   为了防止漏报，任务作者会尝试编写一个与标准解法不同的、完全有效的替代解法。如果这个解法未能通过评估，说明评分标准过于死板。

   我们还让 Devin 想出钻评分标准空子的新方法，以此增强钻空子报告（hack report）流程。

3. 评分标准校准

   为了确保评分标准具有足够的分辨率，作者必须编写四个不同的解法，覆盖从 0 到 100% 的分数范围。

4. 评审

   每位贡献者都被分配到一个评测小组，由经验丰富的小组组长负责，作为第一道质量关卡。组长会对完整的候选评测进行审查，并与贡献者通过多轮迭代不断完善。当候选评测通过所有小组级别的检查后，一位 Cognition 研究员会与组长和贡献者一起进行最终审查。对于随机抽取的一部分任务，研究员还会亲自解答这些任务，以验证指令是否清晰、评分是否公平。

5. 复审

   在任何阶段，审查者都可以将任务退回修改。大多数任务都需要经过多轮迭代才能最终通过。

这一繁复流程的成果，是一套经久耐用、难度极高的任务集，反映了全球顶级开源仓库的高标准。

结论

FrontierCode 是面向下一代编程智能体的基准测试。我们相信，开发者、企业和研究人员可以信赖它来评估其最强模型的生产就绪度。虽然为避免数据污染，我们目前不计划公开发布这些任务，但我们将向所有模型创建者开放评测，希望在未来几个月内能够进一步推动前沿发展。

参考文献

1. [1] METR，《许多通过 SWE-bench 的 PR 并不会被合并进主分支》，2026 年 3 月 10 日。metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main

致谢

FrontierCode 是研究、设计以及一个由从业者组成的社区紧密协作的成果，他们贡献自己的专业知识来审核任务并完善评分标准。感谢下列所有人士。

研究

Eric Lu、Ben Pan、Deniz Birlikci、Sam Lee、Ray Wang、Rohan Choudhury、Fermi Ma、TC Qin、Carlo Baronio、Silas Alberti

设计

Katie Cheng、Joseph Alessio

杰出外部贡献者

Claudio Costa、Martin McKeaveny、Lance Fuchia、Merlijn Vos、Tomer Nosrati、Swyx