FrontierCode

# 推出 FrontierCode 来源：https://cognition.ai/blog/frontier-code 作者：Eric Lu、Ben Pan、Deniz Birlikci、Sam Lee、Ray Wang、Rohan Choudhury、Fermi Ma、TC Qin、Carlo Baronio、Silas Alberti 等人 → (https://cognition.ai/blog/frontier-code#acknowledgments) 06.08.26 ## 标准提升：从正确性到代码质量 (https://cognition.ai/blog/frontier-code#raising-the-bar) 目前的编码基准测试已经证明，模型可以编写*正确*的代码。但随着AI生成的代码成为进入生产环境的主要路径，正确性现在只是入场券。我们应该问的问题是：模型真的能写出*优质*的代码吗？ 我们很高兴推出 FrontierCode，这是一个衡量模型在多大程度上真正满足高质量生产代码库标准的基准测试。 我们的独特之处： - **维护者会实际合并这个PR吗？** 我们是第一个衡量代码可合并性的基准测试。我们的评估标准全面评估端到端的代码质量——正确性、测试质量、范围规范、风格以及代码库标准的遵守情况。这采用了新颖的评分技术组合，包括单元测试、评分标准和新型验证器。 - **由开源维护者精心打造。** 20多位世界一流的开源开发者从他们维护的仓库中创建了逼真、多样且具有挑战性的编码任务，每个任务耗时超过40小时。他们定义了在其仓库中“可合并”的含义。 - **严格的质量控制。** 评分标准评分具有主观性，因此我们构建了一个广泛的QC流程，包括对抗性测试、校准和多阶段审查，每个任务都由Cognition研究人员手动审查。与SWE-Bench Pro相比，我们的误报率降低了81%。 **我们的基准测试提供了当前最可靠的信号，用于衡量模型编写高质量、可维护代码的能力。我们发现，即使是当今最强大的模型，在这个新标准上也会感到吃力。** - 20多位世界一流的开源维护者 - 每个任务投入40小时 - 由Cognition研究人员手动审查 - 每个任务 - 误报率降低81% - 相比SWE-Bench Pro - 首个衡量代码质量的基准测试 - 以及细微的人类偏好 ## 结果 (https://cognition.ai/blog/frontier-code#results) 我们按照难度递增的顺序，呈现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 (https://cognition.ai/blog/frontier-code#why-we-built) 第一代编码基准测试，例如SWE-Bench Verified和Pro，是为能力较弱的模型设计的。它们在许多现实性和稳健性指标上存在不足。从根本上说，它们只测试*功能正确性*，而非代码质量。此外，这些基准测试容易出现**分类错误**。 来自METR的实验 (https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/#introduction) 发现，在这些基准测试中得分高的模型常常生成的补丁不会被人类维护者接受。 我们如何定义分类错误？分为两类： - **误报：** 验证器不应奖励错误的解决方案。测试覆盖率可能*不完整*，允许模型编写一个不正确但仍被接受的解决方案。 - **漏报：** 验证器不应惩罚正确的解决方案。测试可能*过于具体*，例如检查确切的错误字符串或函数名称，或者*无法解决*，测试了指令或代码库中不存在的行为。 各基准测试的轨迹误报率和漏报率 通过对代理轨迹的分析，我们表明FrontierCode比其他领先基准测试产生的分类错误减少81%。这意味着**目前可获得的最准确的排名**就是FrontierCode分数。 现有基准测试在多个方面也存在**缺乏多样性**的问题。虽然其他基准测试通过程序化抓取从单个PR生成问题，但FrontierCode是由仓库维护者从多个PR链和自由格式请求中手动选择的。我们还比SWE-Bench Pro增加了三倍的代表语言数量。 按基准测试划分的语言组成，按任务数量标准化 众所周知，现有基准测试以过于具体和详细的提示形式提供**过多的指导**。当今的前沿模型需要的辅助少得多。FrontierCode期望代理推断维护者的意图，赋予与人类贡献者相同的上下文。 我们的提示包含两部分。首先是任务描述。其次，是通用的测试、lint和风格实践的代码库指南，就像在AGENTS.md中找到的那样。任务描述是**类人的**并且**故意简洁**——长度仅为SWE-Bench Pro的三分之一。 FrontierCode提示长度分布 来自每个基准测试的示例提示，以相同比例显示。在每个列内滚动以比较结构、长度和具体性。 此外，我们选择使用*质量评分标准*来扩展任务的难度，而不是简单地增加补丁大小。尽管补丁比DeepSWE等基准测试更小，但FrontierCode对于代理来说**更难解决**。 FrontierCode补丁大小分布 为了生成像FrontierCode这样雄心勃勃的代码质量评估，我们必须将质量嵌入到基准测试创建的每一步中。 ## 我们如何构建FrontierCode (https://cognition.ai/blog/frontier-code#how-we-built) ### 一支由开源维护者组成的团队 FrontierCode旨在衡量模型是否能生成将被合并到生产代码库中的代码。为确保这一点，我们直接与36个旗舰开源仓库的维护者合作。这支全明星专家团队集体审查并合并了数千次提交到他们的代码库中。他们能够将深刻的风格和设计知识应用到他们看到的每个PR中。 每个维护者每个任务投入**超过40小时**，与其他评估工程师和Cognition研究人员进行了多轮迭代。他们将自己的判断提炼为具体的评估标准：任何满足这些标准的PR实际上都会被批准。 以下是一些维护者关于FrontierCode的评论： > “与FrontierCode背后的团队合作是一种荣幸。处理AI评估问题感觉就像一门艺术……别人像CI一样评分，FrontierCode像技术主管一样评分。” > Tomer Nosrati，Celery（28.6k stars）CEO兼技术主管 > “使FrontierCode与众不同的是对细节的关注。每个任务都校准到了LLM基准测试中从未见过的深度。我们应该远离可以被操纵的基准测试，而使用像FrontierCode这样的基准测试来展示真正的模型智能和创造力。” > Martin McKeaveney，Budibase（28k stars）联合创始人兼CTO > “我很感激能与开源社区中的领先专家合作。我们就正确性与质量以及可合并性在其仓库上下文中的含义进行了深入讨论。FrontierCode是AI模型在现实世界中尊重主观质量的一个里程碑。” > Merlijn Vos，uppy（30.8k stars）核心维护者 > “FrontierCode的独特价值来自于其评估中编码的人类经验：关于什么构成高质量代码并值得合并的多年判断。对每个标准近乎痴迷的关怀，就是我坚信这个基准测试为SWE评估设定了新标准的原因。” > Claudio Costa，Mattermost（37k stars）核心维护者 ### 超越单元测试 FrontierCode通过以下维度评估代码以衡量可合并性： - **行为正确性：** 补丁是否成功解决了问题？ - **回归安全性：** 是否破坏了现有代码库中的任何内容？ - **机械清洁度：** 是否通过了项目的构建、lint和风格检查？ - **测试正确性：** 代理的测试是否实际捕获了期望的行为？ - **范围：** 补丁是否只触及了需要修改的部分？ - **代码质量：** 代码是否符合代码库惯例、遵循合理的设计模式，并且对协作者保持可读性？ 下表描述了如何使用经典单元测试和新颖方法（如自适应经典评分、范围和反向经典测试）来评估这些标准。 | 类别 | 方法 | 工作原理 | 通过条件 | |------|------|----------|----------| | 行为正确性 | 经典 | 将测试文件注入仓库，运行，然后清理。 | 所有注入的测试通过 | | 机械清洁度、回归安全性 | command | 运行shell命令。 | 退出码为0 | | 测试正确性 | 反向经典 | 针对基础提交运行代理提交的测试。 | 测试失败 | | 复杂任务的行为正确性 | 自适应经典评分 | 使用LLM调整参考测试或应用代码以与实现对齐。 | 调整后的测试通过 | | 范围 | scope | 检查文件边界、差异大小约束以及可选的更改语义位置。 | 差异在约束内 | | 代码质量 | prompt | LLM根据自然语言提示审查代理的差异。 | LLM分数达到阈值 | 每个标准要么是**阻碍性**的，要么是**非阻碍性**的： - **阻碍性：** 代表可合并性要求，即维护者在代码审查中会视为硬性停止的标准。这些包括正确性检查，以及性能或范围限制等非正确性问题。 - **非阻碍性：** 代表质量信号，如代码风格、类型安全性和可读性，这些不一定会阻止合并。 如果解决方案满足所有阻碍性标准，则视为通过，其分数为所有通过的评分标准项目的加权总和。否则得分为零。 #### 新颖的评分方法 我们引入了三种主要技术来加强标准以防止分类错误，同时为多个有效解决方案留出空间： **反向经典：** 反向经典标准是确保代理编写的测试有意义的一种方法：当我们对原始、有缺陷的代码库运行这些测试时，它们**必须失败**。这为我们提供了一种自动化的、确定性的检查，确保代理足够理解问题以编写有效的测试。 **代码范围：** 一个好的PR应该展现**克制**：它只修改必要的内容，不触及不相关的文件或引入不必要的重构。`scope`标准是一种自动化的检查，用于强制执行这些边界。它结合了三种约束类型： - `files`：用于快速、确定性的检查，哪些文件可以**允许**、**拒绝**或必须**删除**。 - `size`：用于强制执行**更改行数**、**净行增长**或**修改的文件总数**的限制。 - `semantic`：用于基于LLM的检查，验证文件特定部分（例如，单个函数内部）更改的**位置**或**性质**。 **自适应经典评分：** 开放式编码任务可以有多种有效解决方案。静态单元测试过于僵化；好的解决方案可能因为函数名称或错误措辞等表面差异而失败。我们使用`mutagent`来解决这一冲突，这是我们构建的一个工具，它使用LLM精确修补测试环境（或应用代码）以与代理的实现细节对齐，从而允许我们对开放式解决方案进行严格的、确定性的测试。 ### 示例任务交互式演示 针对每个模型的输出运行FrontierCode评分流程，并检查补丁如何映射到评分标准的通过/失败。 Andrew He (ecnerwala) (https://en.wikipedia.org/wiki/Andrew_He) 是Codeforces上排名第二的美国参与者，两次IOI金牌得主，是Cognition的创始工程师，也是我们的C++专家。他个人审查了模型在此任务上的行为。 此任务基于用C++编写的`jsonschema`仓库。它要求实现一个新函数`auto LOG_WARNING() -> std::ostream &`，该函数应被用于代码库中每个打印`warning: `的地方。该辅助函数应将日志消息前缀为`warning:`，打印到`stderr`，并忽略`--verbose`标志。 任务看似简单：一个通过方案只需要识别给定代码库中所有打印`warning:`的地方，并用对新实现的`LOG_WARNING()`函数的调用来替换它们。 然而，模型以一种有点令人惊讶的方式失败在这个任务上。其中一个阻碍性标准要求多行警告消息习惯性地调用`LOG_WARNING`，如下所示： ```cpp LOG_WARNING() << "You are opting in to remove schema identifiers... \n" << "The only legit use case...\n" << "non-compliant...\n" << ... ; ``` 另一方面，Claude Opus 4.8 始终选择以下实现： ```cpp 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()`进行修改时会发生变化。 ### 质量控制 #### 我们如何迭代评分标准质量？ 改进二元验证器（如单元测试）相对容易处理，因为每个解决方案都落入两类之一——正确或错误。你可以检查每个执行，检查其所属类别，并相应地加强测试。 强化基于提示的标准是一个更困难的QC问题。评分标准引入了正确性的*谱系*：同一任务的两个解决方案可能在功能上都是正确的，但在每个标准上得分不同。我们不能再孤立地查看解决方案。我们必须在一个解决方案组内进行比较，并验证它们的相对分数是否确实能够将更好的解决方案与更差的解决方案区分开。 评分标准的设计也固有地具有主观性，需要领域专业知识。对于每个标准，维护者必须决定它是阻碍性的还是非阻碍性的，分配其在其他标准中的相对权重，并确保完全覆盖，以便模型无法利用评分标准中的漏洞。 #### 我们的评分标准创建流程 评分标准强化流程 1. ##### 设计 对于可以确定性检查的事项（如正确性），我们倾向于经典测试。对于复杂任务，我们倾向于行为测试，这些测试对实现细节的表面差异具有鲁棒性 (Note: The original text cuts off here. I will translate up to this point. The response might be incomplete if there is more content after "鲁棒性" but the source text ends with "鲁棒性"。)