FeatureBench：63 分悬崖——当 SWE-bench 满分选手碰上真实功能开发

基准分数通胀的问题

Claude Opus 4.5 在 SWE-bench Verified 上得分 74.4%。这个数字在过去两年里反复出现在各种供应商的宣传页和企业采购评估里。

同一个模型，在 FeatureBench 上得分 11.0%。

差了 63 分。这不是难度差异——这是两种完全不同的任务形态之间的断层。

SWE-bench 的本质：单 commit 粒度的 bug 修复。median patch 是几十行代码，改一两个文件，任务描述清晰，测试用例完备。这是一个精心设计的「解谜题」环境。

FeatureBench 的本质：跨越多个 commit 和 PR 的完整功能实现。平均 790 行代码，跨多个文件，要求架构决策（新增模块放哪里、复用哪些现有抽象）、测试覆盖扩展（新功能需要新的测试用例）、跨模块不变量的保持（非目标功能的 P2P 测试仍然通过）。

两种任务的核心差异不在难度，在性质。Bug fix 是可逆的、边界清晰的；feature 开发是开放式的、需要权衡的、会影响代码库长期结构的。

FeatureBench 的 200 个任务来自 24 个开源仓库，测试驱动的任务生成流程：

这个流程生成的任务更像一个工程 ticket，而不是 bug 报告。Agent 必须做出架构决策，必须理解跨模块依赖，必须扩展测试覆盖。

失败的典型模式：模型会把新功能放在错误的模块、破坏已有点的 P2P 测试、遗漏跨模块依赖链上的某个文件。SWE-bench 风格的单 patch 生成能力在这里几乎无用。

之前的 SWE-bench 变体（Live-SWE-agent、SWE-rebench）把差距拉大到 20-30 分，那些仍然是 bug fix 任务，只是规模更大一点。

FeatureBench 改变的是任务分布，不是任务难度。这是一个根本性的形态转变：从「修复已知问题」到「交付未知边界的功能」。

这意味着现有的 post-training 策略存在系统性偏差。模型在 SWE-bench 风格数据上大量训练，在那个分布上达到了饱和（top 6 模型相差不超过 0.8 分，80.0%-80.9%）。但这个「饱和」是一个假象——它在测的能力和应用场景需要的能力之间有很大的错位。

我在用 coding agent 处理真实任务时见过类似的现象。给 agent 一个「这个 API 要加一个参数」的指令，它完成得很好。给它一个「实现一个批量导入功能，包含错误处理和进度回调」，它会交出看起来完整但运行时在某些边缘情况崩溃的代码——因为它没有真正理解跨模块的不变量边界在哪里。

SWE-bench 高分模型在 FeatureBench 上崩到 11%，和这个现象是同一个根因：模型的强项是「根据给定的 diff 学习目标状态」，而不是「根据高层需求自己规划目标状态并保持全局约束」。

如果企业在评估 coding agent 时只看 SWE-bench 分数，他们买的是一个在「给定 patch 的情况下逆向还原 patch」任务上表现出色的系统，而不是一个能交付功能的系统。

FeatureBench 的价值不是证明当前模型不够好，而是重新定义了「好」应该怎么测：用多 commit 的功能级任务替代单 commit 的 bug fix 任务，用可执行测试替代相似度评分，用自动化生成替代人工标注。

ICLR 2026 接收这篇论文，说明学术界也在认真对待这个 messenging space。

参考