从正确性提升到质量

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

我们很高兴推出 FrontierCode，这是一个衡量模型在多大程度上真正满足高质量生产代码库标准的基准测试。我们的独特之处在于：

• 维护者会合并这个 PR 吗？我们是第一个衡量代码可合并性的基准测试。我们的标准评估端到端的代码质量——正确性、测试质量、范围纪律、风格以及对代码库标准的遵循。这采用了一套新颖的评分技术组合，包括单元测试、评分细则和新型验证器。
• 由开源维护者精心打造。20 多位世界级的开源开发者从他们维护的代码库中构建了逼真、多样且具有挑战性的编程任务，每个任务耗时超过 40 小时。他们定义了在其代码库中“可合并”的含义。
• 严格的质量控制。评分细则评分具有主观性，因此我们构建了一个广泛的质量控制流程，包括对抗性测试、校准和多阶段审查，其中每个任务都由 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 始终比 Opus 4.8 少用多达 4 倍的 token，实现了更好的成本-智能权衡。

在 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 期望智能体在获得与人类贡献者相同的上下文时，能够推断出维护者的意图。

我们的提示词包含两部分。第一部分是任务描述。第二部分是代码库中关于通用测试、代码检查和风格规范的指南，与 AGENTS.md 中的内容类似。任务描述拟人化且刻意简洁——长度仅为 SWE-Bench Pro 的三分之一。

此外，我们选择使用质量评分标准来划分任务难度，而非简单地增加补丁大小。尽管 FrontierCode 的补丁比 DeepSWE 等基准测试更小，但对智能体而言解决难度却更高。

为了打造像 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 星）的 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 星）的联合创始人兼 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 星）的核心维护者

“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 星）的核心维护者

超越单元测试

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

• 行为正确性：补丁是否成功解决了问题？
• 回归安全性：它是否会破坏现有代码库中的任何内容？
• 机械整洁度：它是否通过了项目的构建、代码检查和风格检查？
• 测试正确性：智能体的测试是否真正捕捉到了期望的行为？
• 范围：补丁是否只触及了它需要修改的部分？
• 代码质量：代码是否符合代码库规范、遵循合理的设计模式，并且对协作者保持可读性？

下表描述了我们如何使用经典单元测试以及新颖方法（例如自适应经典评分、范围和反向经典测试，下文将详细介绍这些方法）来评估这些标准。

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

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

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

如果一个解决方案满足所有阻塞项，则视为通过，其得分为其通过的所有评分项得分的加权总和。否则，其得分为零。

新颖的评分方法

我们引入了三种主要技术来加强标准，防止错误分类，同时为多种有效解决方案留出空间：

反向经典：反向经典标准是一种确保智能体编写的测试有意义的方法：当我们在原始、有缺陷的代码库上运行这些测试时，它们必须失败。这为我们提供了一种自动化的、确定性的检查，确保智能体充分理解了问题，从而能够为其编写有效的测试。

代码范围：一个好的 PR 应该有所节制：它只修改必要的内容，不触及无关文件或引入不必要的重构。范围标准是一种自动化检查，用于强制执行这些边界。它结合了三种类型的约束：

• 文件：用于快速、确定性地检查哪些文件可以被允许、拒绝或必须被删除。
• 大小：用于对更改的行数、净行数增长或修改的文件总数施加限制。
• 语义：用于基于 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()` 未来修改时可能会发生变化。

质量控制

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

改进像单元测试这样的二元验证器相对容易处理，因为每个解决方案只属于两类之一——正确或错误。你可以检查每次运行结果，判断其所属类别，并据此加强测试。

强化基于提示词的评判标准则是一个困难得多的质量控制问题。评分标准引入了正确性的一个谱系：针对同一任务的两个解决方案可能在功能上都正确，但在每项标准上的得分却不同。我们无法再孤立地审视解决方案。我们必须在一组解决方案内部进行比较，并验证它们的相对得分是否确实能将更好的解决方案与较差的区分开来。

评分标准的设计本身也具有主观性，并且需要领域专业知识。对于每项标准，维护者必须决定它是关键性标准还是非关键性标准，为其分配相对于其他标准的权重，并确保覆盖全面，使模型无法利用评分标准中的漏洞。

我们的评分标准创建流程

1. 设计

   对于可以通过确定性方式检查的内容（例如正确性），我们更倾向于使用经典测试。对于复杂任务，我们更倾向于使用对实现细节的浅层差异具有鲁棒性的行为测试。

   对于软性质量指标，我们更倾向于使用大语言模型评分。这更适合评估诸如代码的惯用性、可读性，或是否遵循了首选的架构模式等。

   基于这些原则，我们首先要求任务创建者手动审核每个评分项，并记录其理由。

2. 破解报告

   为防止误报，任务作者模仿一个懒惰或对抗性的程序员，试图用故意错误或不完整的解决方案获得及格分数。这暴露了可以改进的评分标准。

   为防止漏报，任务作者尝试编写一个与标准方案完全不同的、完全有效的替代解决方案。如果该方案未能通过评估，则说明评分标准过于僵化。

   我们通过要求 Devin 提出破解评分标准的新方法来增强破解报告流程。

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 是研究、设计以及一群从业者社区紧密协作的成果，他们贡献了自己的专业知识来审核任务并制定评分标准。感谢以下每一位参与者。