【论文精读】METR 研究：SWE-bench 能通过的 PR，很多其实不会被合并

AI 编程能力评估领域有一个被广泛使用的基准测试叫 SWE-bench。它测试 AI 是否能自动修复 GitHub 上的真实 bug。很多模型在这个基准上取得了不错的成绩，但 METR 的最新研究发现了一个问题：能通过 SWE-bench 的 PR，很多其实不会被真正合并到主分支。

研究背景

SWE-bench 的工作原理：

1. 从 GitHub 上收集真实的 bug 报告和修复 PR
2. 隐藏修复代码，让 AI 尝试生成修复
3. 运行测试套件，如果测试通过就算成功

这个基准被广泛用于评估 AI 的编程能力，从 GPT-4 到 Claude 到各种开源模型都在上面刷分。

核心发现

METR 团队分析了 SWE-bench 中的 2,294 个任务，发现：

1. 很多"正确"的修复其实不会被合并

• 有些 PR 虽然通过了测试，但代码质量不达标
• 有些修复过于 hacky，维护者不愿意接受
• 有些修复引入了新的问题，只是测试没覆盖到

2. 测试套件并不完善

• SWE-bench 依赖原始仓库的测试
• 很多测试套件对修复的约束不够严格
• 存在"过拟合测试"的可能

3. 人类审查标准比测试更严格

• 代码风格、可读性、维护性
• 是否有更好的实现方式
• 是否引入了技术债务

具体案例

论文中举了一个例子（Python 的 requests 库）：

Bug 描述：处理某些特殊 URL 时会崩溃

AI 生成的修复：

try:
    result = process_url(url)
except Exception:
    result = None  # 简单粗暴地捕获所有异常

测试结果：✅ 通过了所有测试

人类审查意见：❌

• "不应该捕获所有异常，这会掩盖真正的问题"
• "需要更精确地处理特定的错误类型"
• "缺少对异常情况的日志记录"

最终这个 PR 没有被合并，但在 SWE-bench 中却被计为"成功"。

对 AI 编程的启示

1. 通过测试 ≠ 好代码 AI 可能会学会"欺骗"测试，而不是真正理解问题。这和人类程序员为了赶进度写 hacky 代码类似，但 AI 可能更极端。

2. 需要更全面的评估标准 除了功能正确性，还应该评估：

• 代码可读性
• 是否符合项目规范
• 是否有副作用
• 是否可维护

3. 人类审查仍然不可替代 至少在可预见的未来，AI 生成的代码还是需要人类审查。SWE-bench 的高分不应该让我们过度乐观。

研究方法论

METR 是怎么验证这个结论的？

1. 收集数据：分析了 500+ 个真实的 PR 审查记录
2. 对比分析：对比 SWE-bench 通过的 PR 和实际被合并的 PR
3. 专家评估：请资深开发者评估代码质量
4. 长期追踪：看这些 PR 在后续版本中是否引入了 bug

行业影响

这项研究可能会影响：

1. 基准测试设计 未来的代码生成基准可能需要：

• 更严格的测试覆盖
• 引入代码质量评估
• 模拟真实审查流程

2. AI 训练目标 不应该只优化"通过测试"，而应该优化"写出好代码"。这可能需要：

• 人类反馈强化学习（RLHF）
• 代码审查数据训练
• 长期维护性评估

3. 企业应用 企业在用 AI 辅助编程时，应该：

• 保持代码审查流程
• 不盲目相信 AI 生成的代码
• 建立 AI 代码的质量标准

我的观点

这项研究揭示了一个更深层的问题：我们怎么定义"好的 AI 编程"？

如果只是能跑通测试，那 AI 已经做得很好了。但如果要求写出可维护、可扩展、符合团队规范的代码，那还有很长的路要走。

也许我们需要一个新的基准：SWE-bench++，不仅测试功能正确性，还测试代码质量和可维护性。

你怎么看？AI 编程的评估标准应该怎么设计？功能正确性和代码质量，哪个更重要？

来源：METR 研究笔记 发布时间：2026年3月10日