据 OpenAI 于 2026 年 2 月 23 日发布的文章显示，其已不再使用 SWE-bench Verified 作为前沿代码模型能力评估的主要依据。来源摘要指出，SWE-bench Verified 正变得越来越容易受到“污染”影响，并且在衡量前沿编码进展时出现偏差；OpenAI 的分析还提到，该基准存在测试设计缺陷以及训练数据泄漏问题，因此建议转向 SWE-bench Pro。对于依赖代码模型 API 的开发者、企业团队和中转服务使用者而言，这一变化意味着：仅凭单一公开榜单判断模型编程能力，风险正在上升。
SWE-bench Verified为何被质疑
SWE-bench 系列长期被用于观察大模型在真实软件工程任务中的表现，尤其是让模型阅读代码库、定位问题、生成补丁并通过测试。相比一般算法题或静态代码补全，这类评估更接近开发者日常遇到的 Bug 修复和项目维护场景，因此一度成为代码模型能力对比的重要参考。
但来源显示，OpenAI 认为 SWE-bench Verified 已经难以准确反映最新模型的真实进步。所谓“污染”，通常指评测题目、答案、测试用例或相关讨论在公开环境中被广泛传播后，可能进入模型训练语料或被模型间接记忆；而“训练泄漏”则会使模型在评测时并非完全依靠推理和代码理解，而可能受已见过内容影响。若这种情况扩大，评测分数就可能高估模型在未知项目中的可迁移能力。
此外，来源摘要还提到测试本身存在缺陷。对软件工程评测而言，测试用例质量尤其关键：如果测试覆盖不足，模型可能提交看似通过但并不健壮的补丁；如果测试与任务描述不匹配，也可能导致能力衡量失真。OpenAI 因而推荐使用 SWE-bench Pro，暗示其希望评测向更难污染、更接近真实开发流程的方向演进。
对开发者和API使用者的影响
从 API 调用角度看，这一事件提醒开发者：选择代码模型时，不应只看某个公开基准的排名。尤其在通过 OpenAI、Claude、Gemini 等模型进行代码生成、自动修复、单元测试生成、PR 审查或 Agent 化开发时，模型在自有代码库、私有规范和真实 CI 环境中的表现，往往比单一榜单更重要。
对于企业团队，评估流程也需要升级。过去“看榜单选模型”的方式成本低，但可能忽略上下文长度、工具调用、并发稳定性、错误恢复、代码风格一致性等实际问题。若基准存在污染或泄漏，团队可能误判模型能力，进而在生产环境中承担更高返工成本。
对 API 中转和模型调用服务而言，评测口径变化同样重要。用户关心的不只是某个模型在公开测试中的得分，还包括调用成功率、延迟、额度稳定性、价格结构、上下文窗口以及多模型切换能力。当公开评测可信度下降时，平台更需要提供面向场景的测试报告，例如针对代码修复、脚本生成、依赖升级、SQL 生成、前端组件改写等任务进行横向比较。
建议如何重新评估代码模型
结合来源信息，开发者在评估代码模型 API 时可以采用更稳妥的方法：
- 使用私有或半私有任务集：选择团队真实历史 Issue、内部工具脚本、业务代码片段，避免完全依赖公开样例。
- 关注端到端结果：不仅看生成代码是否可读，还要看是否能通过测试、是否引入副作用、是否便于维护。
- 区分补全、修复与 Agent 能力：代码补全强不等于能独立完成跨文件 Bug 修复，需分别测试。
- 记录成本与稳定性：同一任务下比较 token 消耗、重试次数、响应时间和失败率。
- 保留多模型路由：在复杂任务中让不同模型承担规划、检索、生成、审查等角色，可降低单模型误判风险。
总体来看，OpenAI 放弃继续评估 SWE-bench Verified，并推荐 SWE-bench Pro，反映出代码模型评测正在进入“反污染、重真实场景”的阶段。对开发者而言，公开基准仍有参考价值，但不应成为唯一决策依据；对需要批量调用模型 API 的团队而言，更可靠的做法是建立自己的评测集，并结合成本、额度、并发和接入稳定性综合选择。未来代码模型竞争的重点，可能不只是榜单分数，而是谁能在真实工程链路中持续、稳定、低成本地解决问题。