据来源显示，OpenAI于2026年2月23日发布说明，表示其将不再使用SWE-bench Verified作为前沿代码能力评估的主要依据。原因在于该基准正面临越来越明显的污染问题，并可能无法准确衡量新一代编程模型的真实进展。OpenAI在摘要中提到，其分析发现该基准存在测试缺陷以及训练数据泄漏风险，因此建议转向SWE-bench Pro。
对于开发者和API使用者而言，这一变化并不只是“换一个榜单”那么简单。代码模型的评测结果常被用于选择模型、估算调用成本、规划自动修复流程，甚至作为企业采购API额度和并发资源的参考。如果基准被污染或测量失真，基于分数做出的模型选型就可能偏离真实生产环境表现。
SWE-bench Verified为何被质疑
SWE-bench Verified此前被广泛用于观察模型在软件工程任务上的能力，尤其是围绕代码理解、缺陷修复、测试通过等场景。但来源指出，该评测正在变得“越来越受污染”，并且对前沿编码能力进步的衡量出现偏差。
所谓污染，通常意味着模型在训练阶段可能接触过与评测相关的信息，导致测试成绩无法完全代表泛化能力。来源还提到测试本身存在缺陷，这会进一步削弱评测的可信度。对于需要在真实仓库、真实依赖和复杂CI环境中使用模型的团队来说，一个高分模型未必等同于更可靠的工程助手。
这也是OpenAI推荐SWE-bench Pro的背景：评测体系需要更好地区分“记住答案”与“真正解决未知工程问题”的能力。来源未披露更多细节数字，因此目前可以确认的是，OpenAI认为SWE-bench Verified已不足以作为其评估前沿代码模型进展的可靠标准。
对API调用与模型选型的影响
从API使用者角度看，代码模型评测变化会直接影响采购与接入策略。很多团队在选择OpenAI、Claude、Gemini等模型API时，会把公开基准成绩作为第一层筛选条件，再结合价格、上下文长度、响应稳定性、并发限制和工具调用能力做综合判断。若某个基准失真，就需要把测试重心迁移到更贴近业务的私有评测。
尤其在Token中转、API批量调用和多模型路由场景中，平台或企业往往会根据任务类型自动分发请求：简单代码补全走低成本模型，复杂Bug修复走更强模型。如果底层路由规则过度依赖受污染的榜单，可能出现成本上升但效果没有提升的情况。
- 模型选型：不宜只看SWE-bench Verified分数，应结合私有代码库任务测试。
- 成本评估：代码修复类任务通常消耗较多上下文，错误选型会放大Token成本。
- 稳定性验证：需要观察模型在多轮修改、测试反馈、依赖分析中的持续表现。
- 接入策略：可采用多模型灰度、A/B测试和失败回退，而不是一次性绑定单一模型。
开发者应如何调整评测方法
对于正在建设AI编程助手、自动代码审查、工单修复机器人或内部DevOps Agent的团队，公开基准仍有参考价值，但不应直接等同于生产可用性。更稳妥的做法是建立自己的任务集，例如历史缺陷、真实单元测试、代码规范检查、依赖升级案例和安全修复样本。
在API接入层，也可以把评测结果转化为更细颗粒度的路由指标：哪些模型适合生成补丁，哪些适合解释错误日志，哪些适合重构建议，哪些在长上下文仓库中更稳定。这样即便某个公开基准发生变化，业务系统也不会被单一分数牵着走。
此次OpenAI停止评估SWE-bench Verified，释放出的信号是：代码模型竞争正在从“刷榜”转向更接近真实工程环境的验证。对API中转和批量调用用户来说，未来更重要的不是追逐某个榜单第一，而是在价格、额度、并发、稳定性和实际任务成功率之间找到可持续的组合。