据OpenAI于2026年2月23日发布的说明，其将不再使用SWE-bench Verified作为前沿编码模型能力评估的主要依据。来源显示，OpenAI认为该基准正在受到越来越明显的“污染”影响，并且在衡量前沿模型编码进展时出现偏差；其分析还指出，部分测试存在缺陷，同时可能存在训练数据泄漏问题。OpenAI建议转向SWE-bench Pro，以获得更可靠的评估参考。
这则信息对开发者和API使用者并非只是“排行榜变化”。在模型调用场景中，很多团队会依据公开基准选择OpenAI、Claude、Gemini等模型，尤其是代码修复、自动化开发、单元测试生成、Agent编程等工作流。如果一个被广泛引用的基准不能准确反映真实能力，那么围绕模型选型、预算分配、并发资源规划和中转接入策略的判断都可能受到影响。
SWE-bench Verified为何被质疑
SWE-bench Verified原本用于衡量模型在真实软件工程任务中的表现，关注模型能否理解代码仓库、定位问题并提交可通过测试的修复。来源摘要显示，OpenAI现在认为该基准已越来越容易受到污染影响。所谓污染，通常指评测样本、题目线索或相关答案可能已经进入模型训练或公开语料传播链条，使模型在评测中表现出“熟题优势”。
OpenAI还提到测试本身存在缺陷。对于代码任务而言，测试质量直接决定评测可信度：如果测试覆盖不足，模型可能提交看似通过但并不真正修复问题的补丁；如果测试设计有偏差，结果也可能误导外界对模型工程能力的判断。当基准无法区分真实泛化能力与对已知题目的记忆时，排行榜分数就会失去部分采购和接入参考价值。
- 测试污染：题目或相关信息可能被模型在训练阶段间接接触。
- 训练泄漏：评测集与训练数据边界不清，导致分数高估。
- 测试缺陷：用例覆盖和判定逻辑不足，不能完全代表真实修复质量。
- 前沿模型误测：越强的模型越可能在旧基准上出现“分数饱和”或排序失真。
对API选型与模型调用的影响
从API使用者角度看，OpenAI放弃继续评估SWE-bench Verified，意味着企业在选择代码模型时不应只盯单一榜单。尤其是通过Token中转站或API批发渠道接入多家模型时，真实业务测试比公开分数更重要。代码类任务往往包含私有仓库结构、内部依赖、CI流程、风格规范和安全约束，这些因素很难被一个公共基准完整覆盖。
对API中转和模型网关使用者来说，更稳妥的做法是建立自己的小型评测集：抽取历史bug、真实PR、失败测试和重构任务，在OpenAI、Claude、Gemini等模型之间进行相同提示词、相同上下文窗口、相同温度设置的横向测试。这比直接引用单一SWE-bench Verified分数，更能反映单位成本下的可用产出。
同时，基准变化也会影响成本测算。编码任务通常上下文较长，消耗Token高，且需要多轮工具调用、测试反馈和补丁迭代。若依据失真的排行榜选择模型，可能出现“分数高但实际修复率低”“单次便宜但重试成本高”“并发充足但稳定性不足”等问题。对于使用中转API的团队，评估时应同时观察成功率、平均调用轮次、上下文占用、超时率和失败重试成本。
SWE-bench Pro可能成为新的参考，但仍需业务验证
OpenAI在来源中建议使用SWE-bench Pro。虽然摘要未给出更多细节，但这一建议表明，评测体系正在从旧版公共基准向更严谨、更能反映前沿模型差异的方向迁移。对于模型厂商而言，新的评测集有助于避免旧题污染和分数饱和；对于开发者而言，它提供了一个更新的外部参考。
不过，任何通用基准都不能完全替代生产环境评测。在实际接入中，团队仍需要关注模型是否适合自己的代码语言、框架、仓库规模和权限流程。例如，有的模型更擅长解释和规划，有的模型在补丁生成上更直接，有的模型在长上下文仓库理解上更稳定。通过统一网关接入多模型时，可以把不同模型分配到代码审查、测试生成、Bug定位、提交说明生成等不同环节，而不是用一个模型覆盖全部流程。
给开发者的接入建议
此次变化提醒行业：编码模型评估正在进入更精细阶段。对开发者和API采购方来说，公开基准仍有价值，但应被视为初筛工具，而非最终决策依据。建议在接入前完成三类验证：第一，用内部真实任务做离线对比；第二，统计调用成本、延迟和失败率；第三，在小流量生产环境中观察模型对真实代码库的稳定表现。
总体来看，OpenAI不再评估SWE-bench Verified，反映出前沿代码模型竞争已经从“刷榜分数”转向“可靠泛化与真实工程可用性”。对API使用者而言，未来的关键不是谁在某个榜单上领先，而是谁能在可控成本、稳定额度和可观测调用链路下持续解决真实问题。