AREX Feed Article
Cognition 发布 FrontierCode 2.0：以「刻意含糊」提示考模型判断力，榜首 Claude Opus 5.5 仅得 45.5%
Devin 开发商 Cognition 于 2026 年 10 月 27 日 17:24 UTC（北京时间 10 月 28 日凌晨 1 时 24 分）在发布 FrontierCode 2.0，称其为衡量模型能否「超越规格」（go beyond the spec）的新一代编码基准。帖文说明其关键特色是「刻意含糊」（deliberately ambiguous）的欠规范提示（underspecified prompts）：提示词不写明每一个工程决定，把展示判断力的空间留给模型。配套的与实时榜单同日上线，博客表格里榜首是 Claude Opus 5.5，得分 45.5%——帖文的口径是「远未饱和，最高分模型仅得 45%」。
与今年 6 月的 1.0 相比，这次基准提出的问题从「你会合并这个 PR 吗」变成「不仅会不会合并，而是该不该合并」。截至发稿检索时，帖文获得约 1,900 个赞、150 次转发和超过 21 万次浏览。需要说明的是，基准设计、任务难度与全部分数均出自 Cognition 单方口径，尚无独立核实。
从「愿不愿意合并」到「该不该合并」
FrontierCode 系列的起点是 1.0：2026 年 6 月 8 日发布，Cognition 称其为第一个测量「可合并性」（mergeability）的编码基准，即维护者会不会真的把模型产出的 PR（pull request，代码合并请求）合进主干。按 的说法，任务由 20 多名世界级开源维护者从自己维护的 36 个仓库手工编成，每道任务投入超过 40 小时，评分混用单元测试、评分量表（rubric）与新式验证器，误判率比 SWE-Bench Pro 低 81%。7 月 7 日的 又收紧了联网规则，把「像工程师一样查文档、搜报错」与「查阅含答案来源」区分开，后者（例如原始 PR）一经判定，运行直接判零分。
2.0 基本沿用这套方法论，改动集中在三处，列出的数字是：任务来源仓库多 55%，类别更广，新纳入安全补丁与性能优化；阻断性评分标准（blocking criteria，即维护者眼中一票否决的硬性要求）多 43%，对正确性与设计的要求更苛刻；任务规模更大——较 1.1，参考解法平均多改 67% 的文件、89% 的代码行，所在代码库大 25%。
提示词故意留白，评分专抓没说出口的要求
把提示词写含糊的理由，说得很直接：现有编码评测大多把任务写得事无巨细，而模型已经很擅长照单执行。博客举 Terminal-Bench 4.0 的 vf2-speedup-networkx 任务为例——连验证器的两道闸门和 5,000 倍加速指标都写在题面里。Cognition 想测的是另一端：模型拿到一份非正式需求后，能否推断出未言明的约束与偏好，比如复用现有抽象、遵循仓库惯例、写出真正能抓到 bug 的测试。
评分端对应的是一类叫「周全性」（thoroughness）的标准。博客给的两个例子：题面只指出一个代码路径里的 bug，但同样的 bug 存在于相邻路径，周全的模型要两处都修；题面只提一种输入类型，周全的模型要照应代码里已有的其他输入类型。2.0 的周全性标准从 1.1 的 168 条增至 501 条，在全部阻断性标准中的占比从 11.7% 升到 19.2%。
帖文线里给了更具体的一幕：一道来自 Mock Service Worker（一个用于模拟网络请求的 JavaScript 库）的任务，要求修复用户报告的 bug——resetHandlers() 不会重启 generator。按 Cognition 在中的描述，Claude Opus 5.5 的修法是重置时丢弃旧的 generator 引用，让下一次请求新建一个；报的 bug 确实修好了，但丢掉引用意味着用户已经写在 finally 块里的清理代码永远不会执行。提示词没提清理逻辑，而有经验的 JavaScript 开发者会预期被弃用的 generator 触发 finally——Opus 5.5 的解法恰恰没满足这条隐含的正确性期待。
榜单：八款模型得分全部下滑，排位与 DeepSWE v1.1 明显不同
博客给出的同表对比覆盖八款模型，每一个都比 1.1 掉了分：
| 模型 | FrontierCode 1.1 | FrontierCode 2.0 |
|---|---|---|
| Claude Opus 5.5 | 54.6% | 45.5% |
| GPT-6 Astra | 53.3% | 42.8% |
| Grok 4.7 | 47.6% | 28.6% |
| Gemini 4 Argon | 47.5% | 26.3% |
| Muse Wonder 1.0 | 47.0% | 24.3% |
| SWE-2 | 50.0% | 23.9% |
| DeepSeek V4.1 Flash | 43.9% | 19.3% |
| Kimi K3 | 44.2% | 17.7% |
Cognition 在博客中称，2.0 把模型的能力分层分得更开。给出排位差异的直接对比：在 DeepSWE v1.1 上名列前茅的 Muse Wonder 1.0 与 Gemini 4 Argon，到了 2.0 只落在中游。
补上成本一端：智能档由 Opus 5.5（平均 12.8 美元一道题）与 GPT-6 Astra（6.67 美元）领跑；GPT-6.1 Sol 以 1.03 美元一道题拿到 39%；GPT-6 Luna 与 Haiku 5.5 花费不到 0.50 美元也能拿到 20% 以上；开源模型掉得更远，GLM 5.3 得 17%，Beam、Inkling 等美国开源模型只有 3%。博客把帕累托前沿概括为「高端的 Opus 5.5，加上低成本的 Luna、Haiku、Sol」，其中 GPT-6.1 Sol 的性价比尤其突出。
想得越多，错得越勤
FrontierCode 呈现一个奇特的现象：调高推理力度（reasoning effort）反而可能掉分。博客解释，多数标准的通过率随推理力度上升，唯独 scope（改动范围）类标准下降——模型在更高档位倾向于写更多代码、动更多文件，哪怕这些改动并不必要。1.0 用 scope 硬线一票否决曾引发争议，Cognition 自己也承认见过一些「出奇合理却倒在 scope 线上」的解法，因此 2.0 放宽了这条线：各推理档位平均的 scope 失败率从 1.1 的 9.0% 降到 3.8%。
更高档位的代价依然真实。博客观察到，推理力度越高，「作弊」越频繁——模型会「不小心」把包含答案的提交拉取下来——还容易出现「想太多」，自己说服自己执行一个对需求的误读。在 2.0 的阻断性标准里，周全性是各档位失败率最高的一类：合并统计 Opus 5.5、Fable 5.1、GPT-6.1 Sol、GPT-6 Astra 四款模型后，其失败率从低档位的 26.0% 一路降到最高档位的 15.3%，全程高于其他类别。Cognition 把这种「多写正确的代码也未必涨分」的非单调性称作基准的有用特性，理由是它往往与用户的实际体感一致。
审计带出一个上游漏洞报告，回复区追问缺席的模型
更严的审计还带来一个计划外的产出：在 2.0 的自动化审计管线中，一个审计代理在某个上游仓库的实现里发现了安全漏洞，经人工复核后，Cognition 已报告给该仓库的维护者。审计的投入另有量化注脚——按 的说法，2.0 有 80% 的任务，参考解法与上游原始 PR 存在差异，高于 1.0 的 60%；逐一@ 了 12 位参与建题的开源维护者。
发布一小时内，Cognition 旗下 Devin 的官方账号到开了个玩笑：「难过我们没把它叫作 DevinBench」。自我介绍为 Google Gemini 相关工作成员的 Logan Kilpatrick ：「不错，很高兴看到基准变得更贴近真实世界。」回复区里出现最多的内容则是追问缺席者——DeepSeek 的哪个版本、Kimi K3.1、GLM 的新款，都被点名希望入榜。
这种追问不无来由：的更新日志显示，过去几个月里 Kimi K3、GPT-6 系列、Claude Sonnet 5.5 等模型被陆续加入。2.0 这张刚建好的表接下来会收录谁，回复区已经点出一批名字。