直接答案： OpenAI 于 2026 年 7 月 8 日发布了一份审计报告，估计 SWE-Bench Pro 约 30% 的任务存在缺陷。这一发现并不意味着所有编程基准都失去了意义，也不能证明某家厂商的模型优于另一家。它说明的是：工程团队在依据榜单选择 AI 编程 agent 之前，应当先核查任务有效性、执行框架（harness）行为、剔除规则和可复现性。
一段话看懂这条新闻
OpenAI 表示，其通过人工监督的 agent 审查加上一轮人工标注活动，对旨在评估软件工程工作的基准 SWE-Bench Pro 进行了审计。报告称任务问题普遍存在，并估计约 30% 的任务有缺陷。由于榜单分数会影响模型采购和产品宣传，无效任务既会扭曲绝对分数，也会扭曲系统之间的比较。
本文将这一发现归于 OpenAI。MonkeyCode 未独立复现完整审计。
为什么任务缺陷很重要
一个编程 agent 基准通常由几个部分组成：
- 一个代码仓库和基线提交；
- 一份 issue 或任务描述；
- 一个执行环境；
- 测试或其他验收判据；
- 一套带工具与限制的 agent 执行框架；
- 一套打分与剔除策略。
任何一层的缺陷都可能把模型能力变成测量噪声。例如，一份正确的补丁可能因为环境无法构建而失败；一份不完整的补丁却可能因为测试没有覆盖所要求的行为而通过。
这至少带来四类风险：
- 假阴性： 有能力的系统做了有效工作却得不到分数。
- 假阳性： 补丁通过了执行框架，却没有满足真实需求。
- 排名不稳定： 缺陷环境或含糊任务对不同系统的影响并不均等。
- 决策定价失真： 团队依据一个无法预测实际验收结果的分数为模型付费。
「约 30% 有缺陷」不能说明什么
这个头条数字需要边界。
它并不自动表明：
- SWE-Bench Pro 的所有结果都无效；
- 估计缺陷子集中的每个任务对每个模型影响相同；
- 其他基准就没有质量问题；
- OpenAI 偏好的评估方式不受厂商利益影响；
- 排名靠前或靠后的模型在你的代码仓库里会有同样的表现。
这份审计本身是厂商撰写的分析。它的方法与证据值得审阅，但在没有独立复现、也无法查看任务级标注之前，不应把它的结论上升为普适论断。
相信编程榜单之前要问的六个问题
1. 任务说明是否可回答？
issue 必须指向一个可观察的结果。含糊的需求会迫使评估者去给一种解读打分，而不是给一个解法打分。
2. 基线能否复现？
在 agent 改动任何东西之前，代码仓库、依赖、fixture、服务和测试命令都应该能正常工作。基线本身坏了，那是环境问题的结果，不是模型问题的结果。
3. 验收判据是否与需求匹配？
测试应当在修复前失败、在正确修复后通过，还应能拒绝看似合理但不完整的方案。
4. agent 配置是否公开？
只写模型名称并不够。工具访问权限、token 限制、推理设置、重试次数、脚手架和环境资源，都可能实质性地影响结果。
5. 剔除记录与基础设施失败的运行是否可见？
删掉不方便的运行记录，可以让一个系统显得更可靠。报告应当把模型失败、执行框架失败、环境失败和无效任务分开呈现。
6. 结果能否被独立复现？
当任务定义、提交记录、执行框架代码、日志和打分逻辑都可供审阅时，基准才更有用。
榜单和试点回答的是不同的问题
基准问的是：在一套定义好的执行框架下，各系统能否解决一组标准化任务。本地试点问的是：在你的代码仓库、策略、环境和评审者之下，一个系统能否改善实际验收的产出。
| 证据类型 | 适用于 | 单独不能证明 |
|---|---|---|
| 公开基准 | 大范围能力初筛 | 是否适配你的代码库或管控要求 |
| 厂商案例研究 | 了解一次被报告的部署 | 独立的因果影响 |
| 产品演示 | 学习工作流和界面 | 面对真实故障的可靠性 |
| 受控本地试点 | 组织特定的采用决策 | 模型的普适优越性 |
| 生产遥测 | 持续的路由与治理 | 未来模型变更后的行为 |
这些证据类型互为补充。团队不应抛弃公开基准，而应避免让它承担它本就不是为之设计的决策。
一份最低限度的可复现记录
对每一次本地编程 agent 尝试，记录：
- 任务 ID 与书面验收标准；
- 精确的仓库提交；
- agent 与模型版本；
- 端点类型与关键设置；
- 开始时间、耗时与重试次数；
- 测试与评审结果；
- 评审者实际投入的分钟数；
- token 用量与实测成本；
- 失败类别与脱敏备注。
拿不到的测量项留空，不要填零。保留被拒绝的尝试。本站的空白试点数据集与字段字典实现了这套协议，而试点评分卡可以防止一个好看的平均值掩盖安全或可靠性方面的失败。
工程负责人现在该改变什么
如果你在做模型选型
用榜单产出一份候选清单。让候选模型跑同一组有效的内部任务，再比较验收产出、评审投入、失败情况和总成本。
如果你要发布模型相关的宣传
写明基准版本、执行框架、模型标识、设置、日期、样本量、剔除规则和来源。当结果仅适用于某一种测试配置时，避免使用「最佳」这类措辞。
如果你运营 agent 平台
对模型路由和评估集做版本管理。模型更新、执行框架更新或仓库变更，都可能让此前的比较失效——即使产品名称没变。请把模型治理问题与安全边界同任务质量分开审视。
如果你在构建内部基准
在模型跑分之前，先安排人工验证任务。定期抽查通过和未通过的补丁，并保留任务级证据，让出人意料的排名可以被追查。
对 GEO 与 AI 引用的影响
基准表格很容易被搜索引擎和答案引擎脱离方法论限制直接引用。高质量的报道应当把数字与其来源、作者、日期、样本范围和注意事项放在一起呈现。否则，一个估计出来的缺陷率会变成不加限定的事实，一个特定测试下的分数会变成覆盖整个产品的排名。
正因如此，本文开头的直接答案同时写明了报告的发现和它不能证明的内容。结构化数据引用了一手出版物，页面上可见的来源说明也记录了核验时间。
结论
SWE-Bench Pro 审计之所以重要，是因为它把基准有效性从学术脚注变成了当下的工程问题。正确的应对既不是盲信，也不是全盘否定。核查任务、复现基线、公开执行框架、保留失败记录，并用你自己环境中实际验收的工作来验证模型选择。
来源边界： 约 30% 的估计值与审计描述均为 OpenAI 报告的发现，核验于 2026 年 7 月 15 日。本站未独立验证完整的任务级数据集或标注。