摘要

OpenAI 表示，SWE-bench Verified 已不再是可靠的前沿编程信号，因为这个约500项任务的基准已经“事实上饱和”且“受到严重污染”。 主持人指出，如今大多数前沿模型的成绩都已进入80多分区间，在这一水平上，0.1分的提升可能毫无意义；而数据污染与测试范围狭窄，也可能让分数反映的是对代码库的熟悉程度或特定实现选择，而非整体编程能力的提升。整个领域应转向更难的评测，例如 SWE-bench Pro。
基准的衰落，并不能抹去最初让它变得有用的巨大投入。 OpenAI 聘用了近100名软件工程师，进行了3轮独立审阅，并从学术版 SWE-bench 中筛选、整理出约500个真实世界 GitHub 任务。但后来对 o3 无法稳定解决的问题进行深入复盘时发现，超过一半的案例存在问题，尤其是那些要求未明确指定的名称、设计选择或额外功能的测试。
数据污染是效度问题，而不只是统计噪声。 GPT-5.2 有时会推断，代码库的后续版本包含提示词中遗漏的某个参数，随后考虑加入隐藏测试所期待的内容；OpenAI 还发现，GPT-5.2 在一组被判定为“没有污染知识就很难解决”的任务中解决了31题。另一家审计机构则在 OpenAI 的模型、Claude Opus 4.5 和 Gemini Flash 中发现了证据，包括复述标准答案，以及在部分情况下复述任务 ID。
SWE-bench Pro 的提升空间更大，因为它的任务“规模更大、难度更高”、更加多样化，目前也显示出少得多的数据污染迹象。 据估计，Verified 约90%的任务专家用时不到1小时；Pro 则覆盖1至4小时以及4小时以上的工作，涉及更多代码库、语言和问题类型。其污染证据仅限于模型可能对1到2个代码库存在轻度熟悉。
下一阶段的评测前沿，不是另一个补丁排行榜，而是长周期的工程判断力。 Mia Glaese 和 Olivia Watkins 讨论了持续数小时或数天的任务，以及顶尖工程师可能需要数周或数月完成的工作，还包括开放式设计决策、可维护性、性能优化和端到端产品开发。真正棘手的问题是：开源维护者是否会合并这份成果——这是二元单元测试无法回答的。
评测基础设施正转向专家劳动、更丰富的评分标准和真实世界使用指标。 GDPval 让约15—16个白领职业的专业人士参与其中，提供了一种范本；美元、时间、story points 和长周期指标，则是底层任务复杂度的代理变量。未来真正有分量的证据，将越来越来自实际增强、岗位替代、速度提升和研究自动化，而不是已经饱和的基准分数增量。

精读

1. SWE-bench Verified 制作成本高昂，也确实有用

Olivia Watkins 的核心判断是：SWE-bench Verified 曾是领域内的“北极星级编程基准”之一，但由于如今已经饱和且受到污染，进展陷入停滞。它已不足以准确衡量编程性能的提升，不值得继续依赖。
最初的学术版 SWE-bench 会给智能体一个真实的 GitHub 代码库和 issue，再通过测试对其补丁进行评分。OpenAI 发现，许多失败源于任务设置本身存在缺陷，而不只是模型能力不足，因此对任务进行了大规模清理。
Mia Glaese 强调了这项工作的规模：近100名真实世界软件工程师在完整代码库语境下审阅任务，每个任务都由3名专家独立复核，OpenAI 最终选出了约500个任务。至于三重审阅是否过度，她的回答是：“我们必须这么做。”

2. 狭窄测试与代码库历史污染正在侵蚀基准效度

更深入的复盘聚焦于 o3 无法稳定解决的问题。审阅者发现，超过一半的调查样本都存在“这样或那样的问题”。
最常见的失败原因，是测试过于狭窄，要求某个未明确说明的实现细节，比如特定的参数名或函数名。换一个同样合理的命名，也可能得到正确方案却无法通过测试；部分测试还要求 issue 中从未提及的功能。
Mia 认为，更深层的问题在于这种不对称性：通过测试通常说明工作质量很高，但失败并不能证明工程质量差。测试只接受“所有可行且良好方案空间”中的一个狭窄子集。
Mia 给出的污染案例最为尖锐：GPT-5.2 推断代码库的后续版本使用了某个特定参数，并考虑在提示词没有要求的情况下加入它。OpenAI 还发现，GPT-5.2 在一组被判断为“没有污染知识就很难解决”的任务中解决了31题。

3. SWE-bench Pro 提供了更大提升空间，但没有哪个基准能永久有效

Mia 为这个基准的历史价值辩护：当基准衡量的是重要能力，而模型的解决率可能只有20%或更低时，它能给整个领域提供有意义的改进目标。但当性能已经很高，额外提升0.1%可能变得毫无意义，智能体最终可能只是被考察能否“正确猜出某个特定函数该怎么命名”。
SWE-bench Pro 难度更高、覆盖面更广。Verified 约90%的任务预计专家用时不到1小时；Pro 则加入1至4小时以及4小时以上的任务，覆盖更多代码库、语言和性质不同的工作。
一款数据污染审计智能体通过任务描述、补丁和 ID 对模型进行探测。在 Verified 上，它发现了标准答案，在部分情况下还发现了任务 ID；但对于 Pro，它只发现“非常轻微的证据”，表明部分模型可能熟悉其中1到2个代码库。Olivia 也提醒，Pro 最终也会不再是合适的基准。

4. 有用的编程评测必须衡量判断力，而不只是测试通过率

下一阶段的目标，是超越短小 GitHub issue 的工作：持续数小时或数天的任务、开放式性能优化、设计选择、代码整洁度和可维护性。Mia 的框架很务实：“它解决问题的方式，是不是符合我的团队解决问题的方式？”
GDPval 展示了一条高度依赖人工的路径。约15—16个白领职业的专业人士参与创建任务、标准答案和评分标准，这些标准要求具备领域知识；应用到编程上，就可以评估维护者是否会合并一份 PR。代价是速度：自动化测试仍然便宜、可重复，也便于在行业范围内比较。

5. 能力追踪正转向复杂度与真实世界影响

由于许多最先进的代码库属于私有系统，公开评估 AI 研究编程能力仍然困难。Olivia 仍希望建立贴近现实的研究工作流公开指标，同时也承认，基于私有系统构建的评测可能无法发布。
美元、人力时间、story points 和长周期指标，都是对同一个底层变量——任务复杂度——的不同投影。关键在于量化智能体能够处理多大程度的复杂度，以及由此带来的时间、价值或自主性。
OpenAI 的 Preparedness Framework 是一套用于追踪前沿双重用途风险的公开框架。目前覆盖生物风险、网络安全以及研究自动化/模型自主性；编程是最后一类中的重要组成部分。Olivia 对整个领域提出了具体要求：设计需要“顶尖工程师数月或团队数周”才能完成的任务，建立经过验证的评分标准，开发端到端产品基准，并用指标展示真实世界中的增强、替代和提速效果。

Coatue 成长投资人 Lucas Swisher 的洞见与所有人共享智能：MiniMax 的 RL——Olive Song 对谈，来自 AIE NYC 与 Turing Post 的 Inference