作者：Eric Lu, Ben Pan, Deniz Birlikci, Sam Lee, Ray Wang, Rohan Choudhury, Fermi Ma, TC Qin, Carlo Baronio, Silas Alberti 等 → 06.08.26 提升从正确性到质量 当前的编码基准已经表明，模型可以编写正确的代码。但随着 AI 生成的代码逐渐成为生产的主流，正确性现在已成为基本要求。我们应该问的问题是：模型真的能编写出优质代码吗？我们很高兴地介绍前沿代码，这是一项衡量模型能否真正满足高质量生产代码库标准的基准。 我们的独特之处：维护者真的会合并这个 PR 吗？我们是第一个测量代码可合并性的基准。我们的标准评估端到端的代码质量——正确性、测试质量、范围控制、风格和遵循代码库标准。这采用了一种新颖的评分技术组合，包括单元测试、评分细则和新类型的验证者。 由开源维护者精心制作。 20 多位世界级的开源开发者从他们维护的代码库中构建了现实、多样和具有挑战性的编码任务，每个任务投入超过 40 小时。他们定义了他们代码库中“可合并”的含义。 严格的质量控制。 评分细则评分是主观的，因此我们建立了一条广泛的 QC 管道，带有对抗性测试、校准和多阶段审核，每个任务都由认知研究人员进行人工审核。与 SWE-Bench Pro 相比，我们的假阳性率降低了 81%。我们的基准提供了模型编写高质量、可维护代码的能力的最强可用信号。我们发现即使是今天最先进的模型在这个新标准下也面临困难。 20 多位世界级开源维护者 每个任务花费 40 小时精力 由 Cognition 研究人员手动审核每个任务 假阳性率降低 81% 相比 SWE-Bench Pro 第一个测量代码质量和细微人类偏好的基准 结果 我们展示了三个逐渐增加难度的前沿代码嵌套子集：扩展版、主版和钻石版。钻石版包括 50 个最困难的任务，主版包括 100 个最困难的任务（包括钻石版），而扩展版则是全部 150 个任务。我们报告两个指标，及格率和分数：如果解决方案通过所有阻止标准（即维护者在代码审核中视为硬停止的标准），则视为一次通过，否则视为失败。解决方案的分数是评分细则条目的加权总和。未通过阻止标准的解决方案得 0 分。每个模型在每个可用推理努力中运行 5 次。对于每个努力，我们在 5 次试验中平均该指标，然后报告每个模型在其最佳性能推理水平下的分数。 前沿代码钻石版仍未饱和：表现最佳的模型 Claude Opus 4.8 仅取得了 13.4% 的分数。其他模型得分显著较低：GPT-5.5 得到 6.3%，Gemini 3.1 Pro 4.7%，其他更低。然而，GPT 5.5 的 token 使用量比 Opus 4.8 少多达 4 倍，实现了更好的成本智能平衡。在前沿代码主版和扩展版中，Opus 4.8 分别保持在 34.3% 和 51.8% 的清晰领先地位。我们还观察到开源模型与前沿之间存在很大差距。表现最佳的开源模型 Kimi K2.6 在钻石版上仅取得 3.8%，主版上 16%，扩展版上 37%。这篇文章的其余部分将深入探讨我们为什么以及如何构建前沿代码。 我们为何构建前沿代码 第一代编码基准（例如 SWE-Bench Verified 和 Pro）是为能力较弱的模型设计的，它们在许多现实性和健壮性指标上都存在不足。从根本上讲，它们只测试功能正确性，而非质量。此外，这些基准容易出现错误分类。METR 的实验发现，这些基准上得分高的模型往往会生成不会被人类维护者接受的补丁。 我们如何定义错误分类？这些分为两类： 假阳性：验证者不应当奖励错误的解决方案。测试覆盖可能不完整，允许模型编写出的不正确解决方案仍被接受。 假阴性：验证者不应惩罚正确的解决方案。测试可以过于具体，例如检查确切的错误字符串或函数名称，或不可解的，测试一种指令或代码库中未包含的行为。 我们通过对代理轨迹的分析表明，前沿代码产生的错误分类率比其他领先基准低 81%。这意味着前沿代码的分数是当前可用的最准确排名。 现有基准在多个方面也缺乏多样性。尽管其他基准通过程序抓取生成来自单一 PR 的问题，前沿代码是由代码库维护者从多 PR 链和自由格式请求中手动选择的。我们还将代表语言的数量从 SWE-Bench Pro 进行了三倍的增加。众所周知，现有基准提供过多的指导……