FrontierCode：以可合并性衡量 AI 编码质量的基准

概述

FrontierCode 是 Cognition 在 2026 年发布的 AI 编码能力评测基准。与现有主流基准（如 SWE-Bench Verified/Pro）不同，它不再仅关注“模型能否写出通过单元测试的正确代码”，而是首次系统性地衡量“模型生成的补丁是否会被人类维护者实际合并进生产代码库”——即可合并性（mergeability）。基准由来自 36 个顶级开源仓库的 20 多位核心维护者花费每任务 40 小时以上手工构建，通过阻断标准（blocker）、非阻断标准（non-blocker）评分以及反向经典测试、自适应经典评分、代码范围检查等创新评测技术，将假阳性误判率相对 SWE-Bench Pro 降低了 81%。

评测结果显示，即使是当前最强的模型也远未胜任：在最难的 Diamond 子集上，Claude Opus 4.8 仅获得 13.4% 的加权评分，GPT-5.5 为 6.3%，Gemini 3.1 Pro 为 4.7%。最好的开源模型 Kimi K2.6 仅 3.8%。FrontierCode 为衡量语言模型的代码质量提供了目前最严酷、最贴近真实软件工程的信号，并已向所有模型制作者开放评估服务。

背景与问题

第一代编码基准（如 SWE-Bench Verified、SWE-Bench Pro）在早期模型能力不足时设计，主要存在以下局限：

1. 仅测试功能正确性，忽视代码质量
   SWE-Bench 系列依赖单元测试验证补丁是否修复了问题或实现了功能，但不考察代码风格、设计模式、可维护性、测试有效性、改动范围等软性质量维度。METR 的实验已证实，在这些基准上得分很高的模型，其生成的补丁常常不会被人类维护者接受。

2. 大量误分类

   • 假阳性：测试覆盖不全导致错误解法被接受。
   • 假阴性：测试过于严格（如检查具体错误字符串、函数名）或任务本身无法求解，导致正确解法被错误惩罚。
     文章通过分析 Agent 轨迹，指出 FrontierCode 的误分类率比 SWE-Bench Pro 低 81%。

3. 任务构造与实际脱节

   • 任务通过程序化抓取单个 PR 生成，缺乏真实世界由多条链式 PR 或自由格式请求产生的复杂度。
   • 提示过于详细、指明性强，长度约为 SWE-Bench Pro 的三分之一，更贴近人类贡献者收到的上下文。
   • 代表编程语言有限，FrontierCode 将语言种类扩大至 SWE-Bench Pro 的三倍。

4. 难度缩放方式单一
   以往通过增大补丁体积来提高难度，而 FrontierCode 使用质量评分维度（如重构要求、架构约束）提升挑战性，即使在较小补丁上也能难住模型。

核心内容解析

任务构建团队与流程

FrontierCode 邀请了 36 个旗舰开源仓库的 20 多位核心维护者，包括 Celery（28.6k stars）、Budibase（28k stars）、uppy（30.8k stars）、Mattermost（37k stars）等项目的 Tech Lead 或 CTO。每位维护者为每个任务投入 40 小时以上，经历多轮迭代，将自己的代码审查标准提炼为可执行的评分标准。

任务说明包含两部分：

• 简短的任务描述，略述意图，不给出过度指引；
• 代码库指南（类似 AGENTS.md 文件），涵盖通用测试、Lint、风格实践。

任务总数为 150 个，形成三个嵌套子集：

• Extended：全部 150 个任务；
• Main：较难的 100 个（含 Diamond）；
• Diamond：最难的 50 个。

评分维度与方法

评价围绕六个轴面展开：

每个标准被划分为：

• 阻断标准（Blocker）：代表代码审查时的硬性停止条件。若任何一条未通过，补丁得分为 0。
• 非阻断标准（Non-blocker）：体现代码风格、类型安全、可读性等质量信号，不影响“可合并”判定，但影响加权总分。

最终评分是所通过项目的加权聚合，阻断标准全部通过后才计算分数。

创新评分机制详解

文章介绍了三项核心技术创新，均旨在降低误判率并适应开放式任务的多解性：

1. 反向经典测试（Reverse-Classical Test）

验证 Agent 自己编写的测试是否真正有效。将 Agent 提交的测试运行在原始有问题的代码库（基线 commit）上，若这些测试统一失败，说明测试确实能捕捉到目标缺陷。反之则表明测试不够严格，不满足阻断标准。这是一种完全确定性、自动化的检查手段。

2. 代码范围检查（Code Scope）

用于约束补丁只修改必要文件，防止无关重构或文件越界。组合了三种限制：

• 文件白名单/黑名单：快速确定哪些文件可修改、禁止修改或必须删除；
• 修改行数/净行增长/总文件数：设定上限；
• 语义局部性：通过 LLM 验证改动是否仅发生在指定函数内部或某个局部区域。

3. 自适应经典评分（Adaptive Classical Grading）

开放式任务往往存在多个合法实现，固定单元测试过于僵化。为兼顾多解性与确定性测试，团队开发了内部工具 mutagent，利用 LLM 对外部测试环境或应用代码进行“外科手术式”微调（如调整函数名、错误措辞），使其与 Agent 的具体实现方案对齐。然后运行改编后的确定性测试，以严格验证行为正确性。这既保留了传统测试的确定性，又避免了因非关键性差异导致的假阴性。

模型评测结果

每个模型在每个推理努力等级（reasoning effort）下运行 5 次，报告最高努力级别下的平均分。主要数据如下（表中数据取自原文图表，精确到小数点后一位）：

Diamond 子集（50 个最难任务）

Main 与 Extended 子集概览：

• Main：Opus 4.8 得分 34.3%，Kimi K2.6 得分 16%；
• Extended：Opus 4.8 得分 51.8%，Kimi K2.6 得分 37%。

开源模型与闭源前沿模型之间存在巨大差距。

Token 经济性对比（Diamond 子集）：GPT-5.5 平均每次 rollout 的输出 Token 数仅为 Opus 4.8 的约 1/4，但得分更低，揭示出不同的成本‑智能权衡曲线。

示例任务：jsonschema 仓库的 LOG_WARNING 函数

以 C++ 编写的 jsonschema 仓库为例，任务要求实现一个 auto LOG_WARNING() -> std::ostream & 函数，并替换代码库中所有输出 warning: 的实例。所述函数需为日志消息添加前缀 warning:、输出到 stderr 并忽略 --verbose 标志。

阻断标准要求：对于多行警告消息，必须惯用地使用链式调用，如：

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() 与 std::cerr：

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 为同一流，未来修改该函数时可能导致不一致。这不符合可维护性要求，因此被阻断标准判为不通过。

质量控制流程

为使主观性极强的评分体系可信，FrontierCode 设计了一套五阶段质量控制管线，每项任务可能经过多次迭代：

1. 设计：创建者明确每条评分标准的依据，优先使用经典测试，若不行则选用操作性更强的行为测试，对软性质量采用 LLM 评分。
2. “破坏”报告：任务作者扮演懒惰/恶意程序员，尝试用错误或残缺的解法骗过评分，以此暴露假阳性漏洞；同时也写出一个与原解完全不同的正确解答，若被误判则说明标准过严（假阴性）。还引入 Devin 以新颖方式“攻击”标准。
3. 校准：为确信评分具有足够分辨率，作者必须写出四份故意使得分分布在 0% 到 100% 之间的不同解答。
4. 评审：每个贡献者属于一个由经验丰富的组长（pod lead）领导的评 pod，组长作为第一道质量门审查任务；通过后 Cognition 研究员进行终审。部分任务由研究员亲自解答，验证指令清晰度和评分公平性。
5. 回溯重审：任何阶段评审者均可退回修改。大部分任务经历多轮回溯才最终通过。

关键概念与机制

• 可合并性（Mergeability）
  指一个 PR 是否满足人类维护者在功能、风格、范围、测试质量、架构一致性等方面的综合标准，从而被正式合并进仓库。这一概念将评测从“机器可接受”提升为“人类可接受”。

• 阻断标准（Blocker Criteria）
  代码审查中被视为硬性停止的条件，一旦违反则补丁整体得 0 分。可能包括：功能不达标、破坏已有测试、改动范围越界、违反强制性设计模式等。非阻断标准则影响最终加权分但不影响通过与否。

• 反向经典测试
  将 Agent 撰写的测试反向运行于缺陷基线代码上，必须全部失败才证明测试有效。它是一种自动化的、确定性的测试质量校验方法，用于防止 Agent 编写无意义测试。

• 自适应经典评分与 mutagent
  利用 LLM（mutagent 工具）对参考测试或应用代码做最小必要修改（如调整函数名、字符串模板），使得固定单元测试能够与 Agent 的多方案实现对齐，从而在执行确定性测试的同时避免因非本质差异造成的假阴性。

• 代码范围检查
  结合文件级、行数级约束和语义局部性验证（由 LLM 检查改动是否限定在指定函数内），强制 Agent 遵循“最小改动”原则，防止冗余重构和破坏性越界修改。

优势、局限与适用场景

优势

1. 重构代码评价天花板
   将“质量”而非“正确性”作为核心指标，更贴近真实世界的生产级要求。可合并性直接对接维护者的主观审核标准，是当前最严酷的公众评测。

2. 极低的误判率
   通过组合多种验证法及严格的 QC 流程，假阳性率比 SWE-Bench Pro 降低 81%，排名更加可靠。

3. 顶尖领域专家把关
   36 个仓库的资深维护者亲自定义“可合并”内涵，将多年代码审查经验编码为可复现的评分规则。

4. 多样且真实的任务设计
   任务源自多 PR 链、自由格式请求，提示简短且贴近实际，代表语言种类扩大三倍，迫使模型自行推断意图。

5. 开放式任务评测能力
   自适应经典评分为多解问题提供了确定性验证手段，是现有基准难以做到的创新。

局限与风险

1. 数据集未公开
   Cognition 为避免污染故意不发布任务，仅向模型制作者开放私有评估。这削弱了可复现性和学术界独立审计的可能性。第三方无法自行验证指标是否持续准确，平台方可能产生选择偏倚。

2. 主观性残留
   尽管 QC 流程异常严格，LLM 评分准则和阻断标准的设定仍然包含人类主观判断。当模型行为处于边界情况时，不同审查者或时间点的评分可能存在波动。

3. 覆盖面有限
   合作仓库集中于 36 个特定项目，150 个任务是否能代表所有类型代码库（如嵌入式系统、数据科学、前端框架等）仍有疑问。构建成本极高（每任务 40+ 小时维护者时间），短期内难以大规模扩展。

4. 静态评分规则可能滞后
   代码风格和架构偏好会随时间演变，评标准一旦固定，可能在未来对模型产生不公平的惩罚或奖励。除非持续维护规则，否则有效性将衰减。

5. 对模型成本的不完全衡量
   仅报告 Token 输出量，未考虑输入 Token、计算时间或推理努力等级对应的实际成本，性价比对比不够完整。

适用场景

• 模型研发者：获取当前最强模型的短处，用于针对性改进训练数据、奖励模型和后训练流程。
• 企业技术选型：评估不同 AI 编码助手在真实生产环境中生成高质量、可维护代码的能力。
• 学术界：推动超越正确性的代码智能研究方向，如如何使 LLM 学习隐式的人类规范。
• 开源维护者：为其仓库定制化的可合并性工作流提供参考框架。

关键要点总结

参考资料

• Cognition Blog, “Introducing FrontierCode”, 2026-06-09.
  URL: https://cognition.com/blog/frontier-code

（文章未提供外部可验证的论文或数据链接，因此以该篇博客为唯一索引源。）