OpenAI 炮轰 SWE-Bench Pro：三成评测存在缺陷，AI 编程能力被严重低估？

最近 AI 编程圈子里有个大瓜，OpenAI 居然直接“撕”了业界最火的一个代码能力评测基准——SWE-Bench Pro。

AI模型编程能力评测排行榜对比图

各大模型在 SWE-Bench Pro 等编程评测基准上的得分对比图

事情的起因是 OpenAI 在最新的研究中发现，这个被无数大模型厂商拿来跑分、证明自己“编程能力超神”的测试集，居然有大约 30% 的用例是存在缺陷的！换句话说，你辛辛苦苦训练出来的模型，可能代码写得没问题，纯粹是被这个坑爹的评测标准给误判了。

今天咱们就来扒一扒这事儿，看看这些评测陷阱到底长啥样，以及这对我们普通开发者看待 AI 编程能力有什么启发。

SWE-Bench Pro 本来是用来衡量 AI 解决真实 GitHub 问题能力的，听起来很靠谱对吧？但 OpenAI 眼尖，发现里面充满了各种各样的坑。

1. 并不是所有 Bug 都是 Bug 有些测试用例本质上是在测试代码是否完美符合某些特定的风格，或者通过一些极其边缘的路径。如果 AI 修复了核心逻辑问题，但因为格式、注释或者非关键的逻辑差异没通过测试，就被判定为失败。这就好比你修好了汽车引擎，却因为没给轮胎打气被判定为“车没修好”。

2. 环境配置的噩梦 很多开源项目的历史 Bug 是特定历史环境下的产物。现在的测试用例往往无法完美复现当年的环境依赖。OpenAI 发现，不少 AI 提交的 Patch 在逻辑上是完全正确的，失败仅仅是因为测试环境缺少某个特定的库版本，或者 Python 版本冲突。这导致模型被冤枉。

开发者面对复杂代码报错感到困惑

环境配置与测试依赖往往是导致 AI 修复失败的真实原因

3. 非确定性测试 最搞心态的是有些测试本身就不稳定。也许你跑十次，有三次能过，七次过不了。AI 生成了正确的代码，结果运气不好撞上了那失败的 70%，直接判定为“Fix Failed”。这种评测根本无法反映真实的代码能力。

4. 已废弃的逻辑 还有更离谱的，有些被测试的功能在后续版本中已经被废弃或者重写了，但测试用例还在要求 AI 按照旧逻辑去修复。这种测试不仅过时，甚至会误导模型的判断方向。

OpenAI 这番操作，表面是在找茬，实则是在重塑行业标准。

以前大家看榜单，谁分数高谁就牛。现在大家都知道 SWE-Bench Pro 漏洞百出，单纯跑分的参考价值直线下降。这也解释了为什么有时候模型 A 在榜单上吊打模型 B，但在实际写代码时，感觉并没有差那么多，甚至模型 B 用起来更顺手。

这对行业是个好事。这说明厂商们开始意识到，真实世界的代码能力和刷题能力是两码事。 一个真正好的 AI 编程助手，不仅要能写出通过测试的代码，更要能理解复杂的上下文、处理环境依赖、甚至发现测试用例本身的不合理性。

1. 别迷信 Benchmark 排行榜 当你看到某某模型又在评测榜单上“屠榜”时，心里要多打个问号。尤其是涉及编程能力的，看看它在你的具体项目里的表现，比看分数实在。如果可以，自己拉几个仓库实际跑一跑 Demo。

2. 理解 AI 的局限性 如果 AI 没有解决你的某个 Issue，不一定是它“智障”。有可能是 Issue 描述不清、环境配置复杂，甚至是原有的测试用例就是错的。我们需要学会排查是代码的问题，还是环境的问题。

3. 关注“泛化能力”而非“解题能力” 未来的 AI 编程工具竞争点，不再是单纯过测试集，而是看它能不能读懂复杂的业务逻辑，能不能维护庞大的遗留代码。那些只会刷 LeetCode 风格题目的模型，在实际工程落地中可能会遇到巨大的水土不服。

OpenAI 挑战 SWE-Bench Pro 这事儿，可以说是给狂热的 AI 圈泼了一盆冷水，但也让大家更冷静地去思考：我们到底需要什么样的编程 AI？

评测标准肯定会随着这次质疑而迭代和改进，未来的 SWE-Bench 或者是新的基准测试，肯定会把环境一致性、测试有效性纳入考量。对于我们来说，看清榜单背后的水分，理性选择工具，才能在 AI 辅助开发的道路上少走弯路。

这波“祛魅”，来得很及时。