当最尖端的模型在 SWE-bench Verified 上获得 80% 的评分时，这听起来像是问题已经解决了。五分之四的真实 GitHub issue 都能被自动处理。直接交付给你的团队吧。但事实是：同一个模型在 SWE-bench Pro（一个专门设计用于防止数据污染、包含来自私有代码库的长程任务的基准测试）上的得分仅为 23%。此外，一项针对经验丰富开发者的严谨对照研究发现，使用 AI 编程工具反而让他们慢了 19%，而不是变快了。
这些数字并不矛盾。它们反映了基准测试衡量的内容与生产环境软件工程实际需求之间的差距。如果你正在构建或打算采用智能体编程（agentic coding）工具，那么这个差距就是最值得关注的事情。
为什么 SWE-bench 不再具有参考价值
SWE-bench Verified 已成为评估 AI 编程智能体的事实标准。从理论上看，这是一个合理的基准测试：从开源 Python 仓库中提取真实的 GitHub issue，为智能体提供 issue 文本和代码库，并测量其修复方案是否能通过现有的测试套件。
问题在于过去 18 个月里评分的变化。2024 年 8 月，最高分在 20% 左右。到 2026 年初，多个系统已经超过了 80%。这并不是因为 AI 编程能力提升了四倍，而是因为基准测试被“刷分”了。
OpenAI 已经停止将 SWE-bench Verified 作为其尖端模型的评估标准，并明确指出“评分的提升不再反映模型在现实世界软件开发能力上的实质性进步，而是越来越多地反映了模型在训练期间接触该基准测试的程度。”这个基准测试的问题是公开的，解决方案就存在于 GitHub 上，任何在 2024 年年中之后使用 GitHub 数据训练的模型很可能已经见过其中大部分内容。至少 59% 经过审计的问题存在测试用例缺陷，会导致功能正确的提交被拒绝。尖端模型甚至可以逐字复刻人类最初编写的补丁。
同一个模型在独立运行（standalone）时可能得分 69%，但在配合能够重试失败并迭代探索文件的复杂智能体框架（agent harness）时，得分可以达到 81%。你无法将模型能力与系统工程脱离开来。
Scale AI 的 SWE-bench Pro 试图通过 1,865 个需要跨私有和预留代码库进行多步推理的任务来解决这一问题。顶级模型在该测试中的得分为 23%。这才是真实的数据。80% 和 23% 之间的差距就是基准测试饱和后的现状。
Epoch AI 的另一项分析发现，87% 的 SWE-bench 问题属于 bug 修复，超过 80% 的问题来自五个 Python 仓库，一半的 issue 早于 2020 年，且任务难度中位数是经验丰富的工程师在不到一小时内就能完成的工作。多文件修改、架构决策和模糊的需求——这些现实工程工作中的主体部分——在其中基本缺失。
受控研究发现了什么
迄今为止最严谨的现实世界评估来自 AI 安全研究组织 METR。他们招募了 16 名经验丰富的开发者，这些开发者目前正在积极维护大型开源项目（平均代码量 100 万行，GitHub Star 数 2.2 万）。开发者们完成了 246 个任务，每个任务平均耗时两小时，使用的是配有 Claude 3.5/3.7 Sonnet 的 Cursor Pro。
结果：使用 AI 让任务完成时间增加了 19%。
认知差距使得这组数据尤为珍贵。在研究开始前，开发者预测 AI 能为他们节省 24% 的时间。在通过客观的时间测量完成所有 246 个任务后，他们依然认为 AI 节省了 20% 的时间。使用 AI 工具的主观体验——那种移动速度更快、建议瞬间生成的快感——创造了一种持久的效率错觉，即使客观数据指向了相反的方向。
开发者采纳的 AI 生成代码建议比例不足 44%。他们的大量时间被耗费在理解智能体的意图、验证其正确性，以及清理不符合现有代码库规范的输出上。
这个结论基于特定的前提：经验丰富的开发者，在成熟且复杂的代码库中，处理需要深度熟悉现有代码的任务。作者明确表示，这并不适用于所有场景。但这种情况最接近于高风险的生产环境工程。
Faros AI 分析了真实组织的生产数据，并发现了一个平行的悖论。在 AI 采用率高的团队中，开发者合并的拉取请求（PR）增加了 98%。但 PR 审查时间增加了 91%，PR 的平均体积增长了 154%，每个开发者的 bug 数量增加了 9%。最终结果是：公司层面的绩效没有可衡量的提升。个人速度虽然提高了，但系统吞吐量却陷入停滞，因为代码审查和测试流水线无法匹配 AI 加速后的生成速度。
智能体在哪些领域真正发挥作用
这并不意味着编程智能体没有用，而是意味着它们在不同类型的任务中表现并不均衡。在任何对结果保持诚实的数据源中，这种模式都是一致的。
具有明确规范的安全漏洞修复是一个真正的突破。 Devin 报告称，修复漏洞仅需 1.5 分钟，而人类工程师需要 30 分钟——效率提升了 20 倍。关键的前提条件是：漏洞类型已知，且修复模式定义明确。当智能体确切知道要修复什么以及如何修复时，它可以以机器速度应用“在此处添加输入校验，在彼处使用参数化查询”等模式。
数据库迁移和现代化升级也表现出类似的增益。 将 Java 应用程序迁移到新版本或在数据框架之间迁移的团队报告称，速度提升了 10 到 14 倍。这种任务结构是成功的关键：起始状态明确，结束状态明确，具有机械化的转换模式，且输出可验证。智能体不需要做出主观判断。
样板代码（Boilerplate）和脚手架工程表现出色也是出于同样的原因。 CRUD 层、API 路由处理器、序列化类、测试用例（fixtures）——这些都遵循既定的模式，智能体可以可靠地应用。这类代码风险低且易于验证。
具有可复现测试用例的 bug 修复是可以可靠解决的。 当存在失败的测试且对原因有明确假设时，智能体可以高效地迭代修复方案。Devin 的 PR 合并率在 18 个月内从 34% 提升到了 67%——虽然仍有三分之一被拒绝，但这确实是实质性的进步。Cognition 自己的内部应用中，大约三分之一的提交来自智能体。
共同点在于：范围狭窄、成功标准明确、输出可验证、机械化转换。只有在这些条件下，基准测试评估与现实世界的表现才会真正趋于一致。
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部