AI 编程排行榜不等于真实能力：OpenAI 审计 SWE-Bench Pro 给团队的提醒

很多人看 AI 编程工具，第一反应是看排行榜。

哪个模型 SWE-Bench 分数最高？哪个 Agent 通过率更高？哪个工具宣传“真实工程能力”更强？

但 OpenAI 最新发布的 Separating signal from noise in coding evaluations 提醒我们：AI 编程评测本身也会有噪音。如果评测任务不干净，排行榜分数就可能让人误判。

这件事不是学术圈内部争论。对正在选 AI 编程工具的小团队来说，它直接影响预算、流程和安全边界。

OpenAI 发现了什么

SWE-Bench Pro 的目标，是比 SWE-bench Verified 更好地追踪 coding agent 能力。它希望使用更长周期、更接近真实的软件开发任务，让模型不只是修一个小 bug，而是完成更复杂的功能变更。

问题在于，真实任务越复杂，评测越难做干净。

OpenAI 审计后报告了几个关键数字：

• 在 731 个公开 split 任务中，前沿模型 8 个月内通过率从 23.3% 提到 80.3%；
• OpenAI 的自动数据质量管线标记了 200 个破损任务，占 27.4%；
• 人工标注活动识别了 249 个破损任务，占 34.1%；
• OpenAI 最终估计约 30% 的 SWE-Bench Pro 任务存在破损问题；
• OpenAI 撤回了此前建议采用 SWE-Bench Pro 的推荐。

这些数字的重点不是“某个榜单不行”，而是说明：当模型越来越强，评测数据质量会直接决定我们看到的是能力信号，还是噪音。

评测为什么会坏

OpenAI 总结的问题主要有四类。

第一，测试过严。
测试要求了 prompt 里没有说明的实现细节，导致功能正确的方案也可能被判错。

第二，提示欠规范。
题目没有告诉模型必要要求，但隐藏测试却会检查这些要求。

第三，测试覆盖不足。
模型写了不完整的修复，但因为测试太弱，仍然能通过。

第四，提示误导。
题目把模型引向一个方向，但测试真正要求的是另一个方向。

这四类问题，在真实团队里也经常出现。很多时候，AI 写不好代码，不一定是模型不行，也可能是需求不清、测试不准、验收标准互相矛盾。

排行榜不能替代真实仓库验证

公开 benchmark 有价值。它能帮助我们粗略比较模型方向，也能推动研究社区改进方法。

但公开 benchmark 不能替代你的真实仓库。

原因很简单：你的代码库有自己的历史包袱、命名习惯、权限边界、测试缺口、业务规则和部署方式。一个模型在公开题目里表现好，不代表它能理解你们项目里的隐含约定。

更现实的风险是：你以为买到的是“能独立交付的 AI 工程师”，实际得到的是“在公开评测上优化得不错的代码生成器”。

两者差别很大。

代码生成器只要给出答案。
工程协作者要理解上下文、做最小修改、补测试、解释失败、接受审查、能回滚。

小团队应该怎么评估 AI 编程工具

不需要一开始搭一个很复杂的评测平台。先做一个小型、固定、可复跑的仓库评测集。

可以从三类任务开始：

1. 真实 bug：选 10 个历史 bug，保留原始需求、失败现象和修复后的测试。
2. 小功能：选 10 个边界清楚的小需求，要求 AI 修改真实代码并补测试。
3. 重构任务：选 5 个低风险重构，检查 AI 是否保持行为不变。

每个任务固定记录：

• 输入给 AI 的需求；
• 允许读取的文件范围；
• 是否允许运行命令；
• 必须通过的测试；
• reviewer 关注点；
• 是否引入额外依赖；
• 是否修改了不该动的文件；
• 失败后能不能解释原因；
• 回滚是否简单。

这样做的价值不是追求一个漂亮分数，而是让你知道哪个工具适合你的团队。

有的模型适合快速写脚本。
有的工具适合大仓库导航。
有的 Agent 适合跑测试和修 CI。
有的模型回答漂亮，但改真实项目时容易扩大改动范围。

公开榜单告诉你“它大概强不强”。
仓库评测告诉你“它在你这里能不能用”。

评测 AI 编程，最容易漏掉什么

第一，漏掉长期维护成本。

AI 一次性写出能跑的代码，不等于以后好维护。你要看它是否遵守项目结构、命名习惯和已有抽象。

第二，漏掉测试质量。

只要测试弱，很多错误代码也能通过。AI 编程评测必须同时评估“代码”和“测试是否真的验证需求”。

第三，漏掉审查成本。

如果 AI 改了太多文件、引入复杂抽象、解释不清原因，人类 reviewer 的负担会变重。一个工具让你少写代码，但多花两倍时间审查，不一定划算。

第四，漏掉失败处理。

真正的工程任务不会每次一次通过。AI 失败后能不能收敛，能不能看日志，能不能提出最小修复，比第一次生成是否漂亮更重要。

对 Codex、Claude Code、Cursor 这类工具的判断

这些工具都值得用，但不要把它们当成同一种东西。

Codex、Claude Code、Cursor、Copilot、OpenClaw 这类工具的差别，不只在模型分数。更重要的是它们怎么读仓库、怎么运行命令、怎么展示 diff、怎么接入测试、怎么处理权限、怎么让人类接管。

所以选型时可以分两层：

第一层，看公开能力。
包括模型推理、代码理解、长上下文、工具调用、生态集成。

第二层，看你的本地评测。
让它们在同一组真实任务上跑，看谁改得少、过得稳、解释清楚、回滚容易。

很多团队的问题，不是没有强模型，而是没有自己的验收标准。

今天的结论

OpenAI 这次审计提醒我们：AI 编程已经进入一个新阶段。

过去模型弱，大家关心“它能不能写出来”。
现在模型强，大家更应该关心“评测是不是可信，交付是不是可控”。

排行榜可以看，但不要迷信。
演示可以看，但不要只看。
真正可靠的判断，来自你的真实代码库、真实测试、真实 review 和真实上线反馈。

AI 编程工具不是用来替代工程纪律的。
它越强，你越需要清楚的评测、边界和验收。

参考来源

• Separating signal from noise in coding evaluations - OpenAI
• SWE-Bench Pro
• Rewriting Bun in Rust - Simon Willison
• Beyond Attack-Success Rate: Action-Graded Severity Scale for Tool-Using AI Agents - arXiv