Cognition 发布 FrontierCode 2.0 编程基准：考察"该不该合并"，最强的 Claude Opus 5.5 也只有 45.5%

核心背景与行业痛点

多数编程基准考的是"按详细规格写出能通过测试的代码"，而且很快会被刷满。Cognition 在部署 Devin 时发现，模型真正的短板在于推断用户意图、遵守没写出来的约束、预见改动的长期后果，这些都需要人来兜底。FrontierCode 1.0 首次把问题换成"你真的会合并这个 PR 吗"，2.0 进一步追问"你应该合并吗"。

架构亮点与底层机制

2.0 沿用 1.0 方法：20 多位知名开源维护者在自己维护的仓库里出题，每题投入 40 小时以上，并制定能否合并的评分细则，未过阻断项直接记 0 分。新版有三项改进：任务来自更多仓库（多 55%），覆盖安全补丁和性能优化；阻断性判定项多 43%，更强调周全性，例如同一个 bug 在兄弟代码路径里也要一起修；任务规模更大。提示词刻意不写全，留给模型发挥判断。官方还放宽了 1.x 中有争议的"越界改动"判定，越界失败率从 9.0% 降到 3.8%。

权威 Benchmark 与实测跑分对比

以下均为 Cognition 官方口径（各模型取最佳推理档位）：Claude Opus 5.5 45.5%、GPT-6 Astra 42.8%、Grok 4.7 28.6%、Gemini 4 Argon 26.3%、Muse Wonder 1.0 24.3%、SWE-2 23.9%、DeepSeek V4.1 Flash 19.3%、Kimi K3 17.7%。与 1.1 版相比分数普遍下降，梯队拉得更开；在 DeepSWE v1.1 上领先的 Muse Wonder 1.0 和 Gemini 4 Argon 到这里落入中游。需要注意的是，出题方 Cognition 自家的 SWE-2 也在榜内，目前尚无第三方复现。

开发者实战落地与开箱指南

选编程 agent 底座时，这份榜单比"按规格过测试"类基准更接近日常体验：它会惩罚漏修、乱改无关文件和测试写得敷衍。官方还发现更高推理档位并不总是更好，模型往往写更多代码、改更多文件，这与不少开发者的体感一致，可据此给不同任务配置推理档位。完整排行和成本对比见 Cognition 官方博客与 FrontierCode 排行榜页。