前沿代码评测FrontierCode介绍如今的编码评测标准已证实模型可以编写出“正确”的代码。但随着 AI 生成代码逐渐成为代码生产的主流方式代码正确性已成为基本要求。现在应该思考的问题是模型能否编写出“优质”的代码推出的前沿代码评测FrontierCode是一个衡量模型是否真正符合高质量生产代码标准的评测基准。其独特之处在于一是首个衡量代码可合并性的评测基准评估标准涵盖端到端的代码质量包括正确性、测试质量、范围控制、代码风格以及对代码库标准的遵循采用了一系列新颖的评分方法包括单元测试、评分细则和新型验证器二是由开源维护者精心打造20 多位世界级开源开发者从他们维护的代码库中设计出逼真、多样且具挑战性的编码任务每个任务投入超过 40 小时明确了在各自代码库中“可合并”代码的定义三是有严格的质量控制构建了一套全面的质量控制流程包括对抗性测试、校准和多阶段审核每个任务都由 Cognition 研究人员手动审核与 SWE - Bench Pro 相比误报率降低了 81%。该评测基准为衡量模型编写高质量、可维护代码的能力提供了有力依据发现即使是目前最强大的模型在这个新标准下也面临挑战。20 多位世界级开源维护者每个任务投入 40 小时由 Cognition 研究人员手动审核每个任务误报率比 SWE - Bench Pro 低 81%是首个衡量代码质量和微妙人为偏好的评测基准。评测结果推出了 FrontierCode 的三个嵌套子集难度逐渐递增扩展版Extended、标准版Main和钻石版Diamond。钻石版包含 50 个最难的任务标准版包含 100 个最难的任务包括钻石版的任务扩展版则涵盖全部 150 个任务。报告两个指标通过率和得分。通过率是指如果一个解决方案通过了所有关键标准即维护者在代码审查时会视为不可通过的标准则判定为通过否则判定为失败。得分是评分细则各项得分的加权总和未通过关键标准的解决方案得分为 0。每个模型在每个可用的推理工作量下运行 5 次。对于每个推理工作量对 5 次试验的指标进行平均然后报告每个模型在其最佳推理水平下的得分。FrontierCode 钻石版的评测结果显示即使是表现最佳的模型也远未达到饱和状态。表现最佳的 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 倍在成本 - 智能权衡方面表现更优。在 FrontierCode 标准版和扩展版中Opus 4.8 仍保持明显领先得分分别为 34.3% 和 51.8%。还发现开源模型与前沿模型之间存在较大差距。表现最佳的开源模型 Kimi K2.6 在钻石版中仅得 3.8%在标准版中得 16%在扩展版中得 37%。构建 FrontierCode 的原因第一代编码评测基准如 SWE - Bench Verified 和 Pro是为能力较弱的模型设计的在现实性和鲁棒性方面存在不足。从根本上说它们仅测试代码的“功能正确性”而非代码质量。此外这些评测基准容易出现分类错误。[METR 的实验]发现在这些评测基准中得分较高的模型其生成的代码补丁往往无法被人类维护者接受。分类错误主要分为两类一是误报False Positives验证器不应认可错误的解决方案测试覆盖可能不完整导致模型编写的错误解决方案仍被接受二是漏报False Negatives验证器不应惩罚正确的解决方案测试可能过于具体例如检查精确的错误字符串或函数名或者无法解决即测试的行为在指令或代码库中并未明确要求。通过对代理轨迹的分析发现 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 的评价“与 FrontierCode 背后的团队合作是一种荣幸。解决 AI 评估问题就像一门艺术……其他评测像 CI 一样评分而 FrontierCode 像技术主管一样评分。”—— Tomer NosratiCelery28.6k 星的 CEO 和技术主管“FrontierCode 的独特之处在于对细节的关注。每个任务的校准深度是 LLM 评测中前所未有的。我们应该摒弃那些容易被钻空子的评测基准转而使用像 FrontierCode 这样的基准来展示模型真正的智能和创造力。”—— Martin McKeaveneyBudibase28k 星的联合创始人兼 CTO“我很感激能与开源社区的顶尖专家合作。我们深入讨论了正确性与质量的区别以及在他们的代码库中‘可合并性’的含义。FrontierCode 是 AI 模型尊重现实世界主观质量的一个里程碑。”—— Merlijn Vosuppy30.8k 星的核心维护者“FrontierCode 的独特价值在于其评估中融入的人类经验多年来对什么是高质量、值得合并的代码的判断。对每个标准近乎执着的关注让我相信这个评测基准为软件工程评估树立了新的标杆。”—— Claudio CostaMattermost37k 星的核心维护者。超越单元测试FrontierCode 从以下几个方面评估代码的可合并性行为正确性即代码补丁是否成功解决了问题回归安全性即是否破坏了现有代码库中的任何功能代码整洁度即是否通过了项目的构建、代码检查和风格检查测试正确性即代理编写的测试是否真正捕捉到了所需的行为范围控制即代码补丁是否仅修改了必要的部分代码质量即代码是否符合代码库的约定遵循合理的设计模式并且对协作者来说易于阅读。下表描述了如何使用经典单元测试和新颖的方法如自适应经典评分、范围检查和反向经典测试来评估这些标准。类别方法工作原理通过条件行为正确性经典方法将测试文件注入代码库运行测试然后清理所有注入的测试通过代码整洁度、回归安全性命令方法运行 shell 命令退出代码为 0测试正确性反向经典方法在基础提交上运行代理提交的测试测试失败复杂任务的行为正确性自适应经典评分使用 LLM 调整参考测试或应用代码以与实现对齐调整后的测试通过范围控制范围检查检查文件边界、差异大小限制以及可选的更改的语义局部性差异在限制范围内代码质量提示方法LLM 根据自然语言提示审查代理的代码差异LLM 评分达到阈值每个标准分为关键标准和非关键标准。关键标准代表可合并性要求即维护者在代码审查时会视为不可通过的标准包括正确性检查以及性能或范围限制等非正确性问题。非关键标准代表代码风格、类型安全和可读性等质量信号这些不一定会阻止代码合并。如果一个解决方案满足所有关键标准则判定为通过其得分是所有通过的评分细则项的加权总和。否则得分为 0。新颖的评分方法引入了三种主要技术来加强标准减少分类错误同时为多种有效解决方案留出空间。一是反向经典测试Reverse - Classical反向经典标准是确保代理编写的测试有意义的一种方法当在原始的、有问题的代码库上运行这些测试时它们必须失败这为提供了一个自动化、确定性的检查确保代理充分理解问题能够编写有效的测试。二是代码范围检查Code Scope一个好的 PR 应该有所节制只修改必要的部分不触及无关文件或进行不必要的重构。scope 标准是一个自动化检查用于强制执行这些边界它结合了三种类型的约束files 用于快速、确定性地检查哪些文件可以允许、禁止或必须删除size 用于限制更改的行数、净行数增长或修改的总文件数semantic 用于基于 LLM 的检查验证文件特定部分例如单个函数内更改的局部性或性质。三是自适应经典评分Adaptive Classical Grading开放式编码任务可能有多种有效解决方案静态单元测试过于僵化好的解决方案可能因为函数名或错误措辞等表面差异而失败通过 mutagent 工具解决了这个问题该工具使用 LLM 精确地调整测试环境或应用代码使其与代理的实现细节对齐从而能够对开放式解决方案进行严格、确定性的测试。示例任务Opus 4.8 GPT - 5.58 个文件 53 - 11运行评估。任务描述在 src/logger.h 中封装一个新的 auto LOG_WARNING() - std::ostream 方法用于处理所有警告日志要求警告信息始终打印到标准错误输出无论 --verbose 选项如何警告信息都要打印该辅助函数自动添加 warning: 前缀。在整个代码库中将所有 warning: 消息的打印处替换为使用这个新函数。测试指南运行 make 命令确保没有代码更改残留。如果还有代码更改说明代码格式化不正确。除非确定代码更改已经被现有测试用例覆盖否则始终在 ./test 目录中编辑或创建相关测试以确认更改有效并防止回归问题。测试使用 GoogleTest 和 POSIX shell 脚本非 bash编写并且必须在 test/CMakeLists.txt 构建定义中注册才能运行。代码检查指南运行 make configure compile 命令来编译并格式化代码。编译步骤包含大量类似代码检查的操作。风格指南你已经处于正确的基础提交上。从这个提交创建你的分支。不要进行变基操作也不要从 master、main 或其他分支开始。点击“运行评估”为该任务生成 Opus 4.8 的代码补丁。运行后这里将显示评分细则。交互式操作针对每个模型的输出运行 FrontierCode 评分流程检查代码补丁如何对应评分细则的通过或失败情况。[Andrew He (ecnerwala)] 是 Codeforces 上排名第二的美国选手两次获得国际信息学奥林匹克竞赛IOI金牌是 Cognition 的创始工程师和 C 专家他亲自审查了模型在这个任务上的表现。这个任务基于用 C 编写的 jsonschema 代码库要求实现一个新函数 auto LOG_WARNING() - std::ostream 并在代码库中所有打印 warning: 的地方使用该函数。该辅助函数应在日志消息前添加 warning: 前缀将消息打印到 stderr并忽略 --verbose 标志。这个任务看似简单一个通过的解决方案只需识别给定代码库中所有打印 warning: 的地方并将其替换为对新实现的 LOG_WARNING() 函数的调用。然而模型在这个任务上的失败方式有些出人意料。其中一个关键标准要求多行警告消息以符合习惯的方式调用 LOG_WARNING。而 Claude Opus 4.8 始终采用另一种实现方式这两种实现方式在行为上是相同的都会将多行错误消息打印到 stderr。然而代理的解决方案在调用处假设 LOG_WARNING() 和 std::cerr 是同一个流而在未来对 LOG_WARNING() 进行修改时这种假设可能会出现问题。质量控制如何迭代评分细则的质量改进像单元测试这样的二进制验证器相对容易因为每个解决方案只有两种情况正确或错误。可以检查每次测试结果根据情况加强测试。强化基于提示的标准则是一个更具挑战性的质量控制问题。评分细则引入了一个正确性的范围同一任务的两个解决方案可能在功能上都是正确的但在每个标准上的得分可能不同。不能再孤立地看待解决方案而必须在一组解决方案中进行比较验证它们的相对得分是否真正区分了优劣。评分细则的设计本质上是主观的需要领域专业知识。对于每个标准维护者必须决定它是关键标准还是非关键标准确定其相对于其他标准的权重并确保覆盖全面防止模型利用评分细则的漏洞。评分细则创建过程1. 设计对于可以确定性检查的内容如正确性优先使用经典测试。对于复杂任务倾向于使用对实现细节的表面差异具有鲁棒性的行为测试。对于软质量如代码的惯用性、可读性或对首选架构模式的遵循优先使用 LLM 评分。基于这些原则首先要求任务创建者手动审核每个评分细则项并记录其依据。2. 漏洞报告为防止误报任务作者模仿懒惰或恶意的程序员尝试用故意错误或不完整的解决方案获得通过分数以暴露需要改进的标准。为防止漏报任务作者尝试编写一个与标准解决方案不同但完全有效的替代解决方案。如果这个解决方案未能通过评估说明评分细则过于严格。还请 Devin 提出新颖的方法来攻击评分细则以增强漏洞报告过程。3. 评分细则校准为确保评分细则有足够的区分度作者必须编写四个不同的解决方案使其得分覆盖从 0 到 100% 的范围。4. 审核每个贡献者属于一个由经验丰富的组长领导的评估小组组长作为第一道质量关卡。组长审查完整的评估候选方案并与贡献者进行多轮迭代。一旦评估候选方案通过所有小组级别的检查Cognition 研究人员将与组长和贡献者一起进行最终审核。对于随机抽取的一部分任务研究人员还会亲自解决任务以验证说明是否清晰评分是否公平。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。
前沿代码评测 FrontierCode：衡量模型代码质量，降低分类错误率 81%
发布时间：2026/6/10 14:24:00
前沿代码评测FrontierCode介绍如今的编码评测标准已证实模型可以编写出“正确”的代码。但随着 AI 生成代码逐渐成为代码生产的主流方式代码正确性已成为基本要求。现在应该思考的问题是模型能否编写出“优质”的代码推出的前沿代码评测FrontierCode是一个衡量模型是否真正符合高质量生产代码标准的评测基准。其独特之处在于一是首个衡量代码可合并性的评测基准评估标准涵盖端到端的代码质量包括正确性、测试质量、范围控制、代码风格以及对代码库标准的遵循采用了一系列新颖的评分方法包括单元测试、评分细则和新型验证器二是由开源维护者精心打造20 多位世界级开源开发者从他们维护的代码库中设计出逼真、多样且具挑战性的编码任务每个任务投入超过 40 小时明确了在各自代码库中“可合并”代码的定义三是有严格的质量控制构建了一套全面的质量控制流程包括对抗性测试、校准和多阶段审核每个任务都由 Cognition 研究人员手动审核与 SWE - Bench Pro 相比误报率降低了 81%。该评测基准为衡量模型编写高质量、可维护代码的能力提供了有力依据发现即使是目前最强大的模型在这个新标准下也面临挑战。20 多位世界级开源维护者每个任务投入 40 小时由 Cognition 研究人员手动审核每个任务误报率比 SWE - Bench Pro 低 81%是首个衡量代码质量和微妙人为偏好的评测基准。评测结果推出了 FrontierCode 的三个嵌套子集难度逐渐递增扩展版Extended、标准版Main和钻石版Diamond。钻石版包含 50 个最难的任务标准版包含 100 个最难的任务包括钻石版的任务扩展版则涵盖全部 150 个任务。报告两个指标通过率和得分。通过率是指如果一个解决方案通过了所有关键标准即维护者在代码审查时会视为不可通过的标准则判定为通过否则判定为失败。得分是评分细则各项得分的加权总和未通过关键标准的解决方案得分为 0。每个模型在每个可用的推理工作量下运行 5 次。对于每个推理工作量对 5 次试验的指标进行平均然后报告每个模型在其最佳推理水平下的得分。FrontierCode 钻石版的评测结果显示即使是表现最佳的模型也远未达到饱和状态。表现最佳的 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 倍在成本 - 智能权衡方面表现更优。在 FrontierCode 标准版和扩展版中Opus 4.8 仍保持明显领先得分分别为 34.3% 和 51.8%。还发现开源模型与前沿模型之间存在较大差距。表现最佳的开源模型 Kimi K2.6 在钻石版中仅得 3.8%在标准版中得 16%在扩展版中得 37%。构建 FrontierCode 的原因第一代编码评测基准如 SWE - Bench Verified 和 Pro是为能力较弱的模型设计的在现实性和鲁棒性方面存在不足。从根本上说它们仅测试代码的“功能正确性”而非代码质量。此外这些评测基准容易出现分类错误。[METR 的实验]发现在这些评测基准中得分较高的模型其生成的代码补丁往往无法被人类维护者接受。分类错误主要分为两类一是误报False Positives验证器不应认可错误的解决方案测试覆盖可能不完整导致模型编写的错误解决方案仍被接受二是漏报False Negatives验证器不应惩罚正确的解决方案测试可能过于具体例如检查精确的错误字符串或函数名或者无法解决即测试的行为在指令或代码库中并未明确要求。通过对代理轨迹的分析发现 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 的评价“与 FrontierCode 背后的团队合作是一种荣幸。解决 AI 评估问题就像一门艺术……其他评测像 CI 一样评分而 FrontierCode 像技术主管一样评分。”—— Tomer NosratiCelery28.6k 星的 CEO 和技术主管“FrontierCode 的独特之处在于对细节的关注。每个任务的校准深度是 LLM 评测中前所未有的。我们应该摒弃那些容易被钻空子的评测基准转而使用像 FrontierCode 这样的基准来展示模型真正的智能和创造力。”—— Martin McKeaveneyBudibase28k 星的联合创始人兼 CTO“我很感激能与开源社区的顶尖专家合作。我们深入讨论了正确性与质量的区别以及在他们的代码库中‘可合并性’的含义。FrontierCode 是 AI 模型尊重现实世界主观质量的一个里程碑。”—— Merlijn Vosuppy30.8k 星的核心维护者“FrontierCode 的独特价值在于其评估中融入的人类经验多年来对什么是高质量、值得合并的代码的判断。对每个标准近乎执着的关注让我相信这个评测基准为软件工程评估树立了新的标杆。”—— Claudio CostaMattermost37k 星的核心维护者。超越单元测试FrontierCode 从以下几个方面评估代码的可合并性行为正确性即代码补丁是否成功解决了问题回归安全性即是否破坏了现有代码库中的任何功能代码整洁度即是否通过了项目的构建、代码检查和风格检查测试正确性即代理编写的测试是否真正捕捉到了所需的行为范围控制即代码补丁是否仅修改了必要的部分代码质量即代码是否符合代码库的约定遵循合理的设计模式并且对协作者来说易于阅读。下表描述了如何使用经典单元测试和新颖的方法如自适应经典评分、范围检查和反向经典测试来评估这些标准。类别方法工作原理通过条件行为正确性经典方法将测试文件注入代码库运行测试然后清理所有注入的测试通过代码整洁度、回归安全性命令方法运行 shell 命令退出代码为 0测试正确性反向经典方法在基础提交上运行代理提交的测试测试失败复杂任务的行为正确性自适应经典评分使用 LLM 调整参考测试或应用代码以与实现对齐调整后的测试通过范围控制范围检查检查文件边界、差异大小限制以及可选的更改的语义局部性差异在限制范围内代码质量提示方法LLM 根据自然语言提示审查代理的代码差异LLM 评分达到阈值每个标准分为关键标准和非关键标准。关键标准代表可合并性要求即维护者在代码审查时会视为不可通过的标准包括正确性检查以及性能或范围限制等非正确性问题。非关键标准代表代码风格、类型安全和可读性等质量信号这些不一定会阻止代码合并。如果一个解决方案满足所有关键标准则判定为通过其得分是所有通过的评分细则项的加权总和。否则得分为 0。新颖的评分方法引入了三种主要技术来加强标准减少分类错误同时为多种有效解决方案留出空间。一是反向经典测试Reverse - Classical反向经典标准是确保代理编写的测试有意义的一种方法当在原始的、有问题的代码库上运行这些测试时它们必须失败这为提供了一个自动化、确定性的检查确保代理充分理解问题能够编写有效的测试。二是代码范围检查Code Scope一个好的 PR 应该有所节制只修改必要的部分不触及无关文件或进行不必要的重构。scope 标准是一个自动化检查用于强制执行这些边界它结合了三种类型的约束files 用于快速、确定性地检查哪些文件可以允许、禁止或必须删除size 用于限制更改的行数、净行数增长或修改的总文件数semantic 用于基于 LLM 的检查验证文件特定部分例如单个函数内更改的局部性或性质。三是自适应经典评分Adaptive Classical Grading开放式编码任务可能有多种有效解决方案静态单元测试过于僵化好的解决方案可能因为函数名或错误措辞等表面差异而失败通过 mutagent 工具解决了这个问题该工具使用 LLM 精确地调整测试环境或应用代码使其与代理的实现细节对齐从而能够对开放式解决方案进行严格、确定性的测试。示例任务Opus 4.8 GPT - 5.58 个文件 53 - 11运行评估。任务描述在 src/logger.h 中封装一个新的 auto LOG_WARNING() - std::ostream 方法用于处理所有警告日志要求警告信息始终打印到标准错误输出无论 --verbose 选项如何警告信息都要打印该辅助函数自动添加 warning: 前缀。在整个代码库中将所有 warning: 消息的打印处替换为使用这个新函数。测试指南运行 make 命令确保没有代码更改残留。如果还有代码更改说明代码格式化不正确。除非确定代码更改已经被现有测试用例覆盖否则始终在 ./test 目录中编辑或创建相关测试以确认更改有效并防止回归问题。测试使用 GoogleTest 和 POSIX shell 脚本非 bash编写并且必须在 test/CMakeLists.txt 构建定义中注册才能运行。代码检查指南运行 make configure compile 命令来编译并格式化代码。编译步骤包含大量类似代码检查的操作。风格指南你已经处于正确的基础提交上。从这个提交创建你的分支。不要进行变基操作也不要从 master、main 或其他分支开始。点击“运行评估”为该任务生成 Opus 4.8 的代码补丁。运行后这里将显示评分细则。交互式操作针对每个模型的输出运行 FrontierCode 评分流程检查代码补丁如何对应评分细则的通过或失败情况。[Andrew He (ecnerwala)] 是 Codeforces 上排名第二的美国选手两次获得国际信息学奥林匹克竞赛IOI金牌是 Cognition 的创始工程师和 C 专家他亲自审查了模型在这个任务上的表现。这个任务基于用 C 编写的 jsonschema 代码库要求实现一个新函数 auto LOG_WARNING() - std::ostream 并在代码库中所有打印 warning: 的地方使用该函数。该辅助函数应在日志消息前添加 warning: 前缀将消息打印到 stderr并忽略 --verbose 标志。这个任务看似简单一个通过的解决方案只需识别给定代码库中所有打印 warning: 的地方并将其替换为对新实现的 LOG_WARNING() 函数的调用。然而模型在这个任务上的失败方式有些出人意料。其中一个关键标准要求多行警告消息以符合习惯的方式调用 LOG_WARNING。而 Claude Opus 4.8 始终采用另一种实现方式这两种实现方式在行为上是相同的都会将多行错误消息打印到 stderr。然而代理的解决方案在调用处假设 LOG_WARNING() 和 std::cerr 是同一个流而在未来对 LOG_WARNING() 进行修改时这种假设可能会出现问题。质量控制如何迭代评分细则的质量改进像单元测试这样的二进制验证器相对容易因为每个解决方案只有两种情况正确或错误。可以检查每次测试结果根据情况加强测试。强化基于提示的标准则是一个更具挑战性的质量控制问题。评分细则引入了一个正确性的范围同一任务的两个解决方案可能在功能上都是正确的但在每个标准上的得分可能不同。不能再孤立地看待解决方案而必须在一组解决方案中进行比较验证它们的相对得分是否真正区分了优劣。评分细则的设计本质上是主观的需要领域专业知识。对于每个标准维护者必须决定它是关键标准还是非关键标准确定其相对于其他标准的权重并确保覆盖全面防止模型利用评分细则的漏洞。评分细则创建过程1. 设计对于可以确定性检查的内容如正确性优先使用经典测试。对于复杂任务倾向于使用对实现细节的表面差异具有鲁棒性的行为测试。对于软质量如代码的惯用性、可读性或对首选架构模式的遵循优先使用 LLM 评分。基于这些原则首先要求任务创建者手动审核每个评分细则项并记录其依据。2. 漏洞报告为防止误报任务作者模仿懒惰或恶意的程序员尝试用故意错误或不完整的解决方案获得通过分数以暴露需要改进的标准。为防止漏报任务作者尝试编写一个与标准解决方案不同但完全有效的替代解决方案。如果这个解决方案未能通过评估说明评分细则过于严格。还请 Devin 提出新颖的方法来攻击评分细则以增强漏洞报告过程。3. 评分细则校准为确保评分细则有足够的区分度作者必须编写四个不同的解决方案使其得分覆盖从 0 到 100% 的范围。4. 审核每个贡献者属于一个由经验丰富的组长领导的评估小组组长作为第一道质量关卡。组长审查完整的评估候选方案并与贡献者进行多轮迭代。一旦评估候选方案通过所有小组级别的检查Cognition 研究人员将与组长和贡献者一起进行最终审核。对于随机抽取的一部分任务研究人员还会亲自解决任务以验证说明是否清晰评分是否公平。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。
