从正确性迈向质量的新标杆

如今的代码评测基准已经证明，模型能够写出正确的代码。但随着AI生成的代码成为走向生产环境的主流路径，正确性已只是入场门槛。我们现在应该问的是：模型真的能写出好代码吗？

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

• 维护者会真正合并这个PR吗？我们是首个衡量代码可合并性的基准测试。我们的评估标准覆盖端到端代码质量——正确性、测试质量、范围纪律、风格以及代码库规范的遵循度。这采用了一套新颖的评分技术组合，包括单元测试、评分细则和新型验证器。
• 由开源维护者精心打造。20多位世界级开源开发者从他们自己维护的仓库中设计出真实、多样且富有挑战性的编程任务，每个任务耗时超过40小时。他们定义了各自仓库中“可合并”的标准。
• 严格的质量控制。评分细则本身带有主观性，因此我们构建了广泛的质量控制流程，包括对抗性测试、校准和多阶段审查，每个任务都由Cognition的研究人员手动审核。与SWE-Bench Pro相比，我们的误报率降低了81%。

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

结果

我们推出了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 通过以下维度评估代码的可合并性：

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

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

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

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

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

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

新颖的评分方法

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

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

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

• files：用于快速、确定性地检查哪些文件可以被允许、拒绝或必须删除。
• size：用于强制执行对变更行数、净行数增长或修改文件总数的限制。
• semantic：用于基于大语言模型的检查，验证变更在文件特定部分（例如单个函数内）的局部性或性质。

自适应经典评分（Adaptive Classical Grading）：开放式编码任务可能有多种有效解决方案。静态单元测试过于严格；好的解决方案可能因函数名称或错误措辞等表面差异而失败。我们通过 mutagent（自己构建的工具）解决这一冲突，它使用大语言模型精准修补测试环境（或应用程序代码），使其与智能体的实现细节对齐，从而允许我们对开放式解决方案运行严格、确定性的测试。

示例任务

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. 1.

   设计

   对于可以确定性检查的事项，如正确性，我们倾向于使用经典测试。对于复杂任务，我们更青睐那些能够忽略实现细节中表层差异的行为测试。

   对于软性质量指标，我们倾向于使用大语言模型评分。这种方法更适合评估，例如，代码是否惯用、可读性如何，或者是否遵循了预期的架构模式。

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

2. 2.

   漏洞报告

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

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

   我们通过要求 Devin 想出新的方法来破解评分标准，从而增强了漏洞报告流程。

3. 3.

   评分标准校准

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

4. 4.

   审核

   每位贡献者都属于一个由经验丰富的组负责人领导的评估小组，该负责人作为第一道质量关卡。负责人审核整个评估候选方案，并与贡献者进行多轮迭代。一旦评估候选方案通过所有小组级别的检查，Cognition 的研究员将与组负责人和贡献者一起进行最终审核。对于随机抽取的子集，研究员还会亲自解决任务，以验证指示是否清晰、评分是否公平。

5. 5.

   二次审核

   在任何阶段，审核者都可以将任务发回修改。大多数任务在通过之前会经历多次迭代。

这一广泛流程的结果是一套经久耐用、难度高的任务，反映了世界顶级开源仓库的高标准。

结论

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

致谢

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