IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
IDE-Bench 引入了一个全面的、基于 Docker 的评估框架，该框架通过一个结构化的、IDE 原生工具接口，利用分布在八个从未公开过的仓库中的 80 个任务，来评估 AI IDE 智能体在真实世界、多语言软件工程任务中的能力。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在为一个软件项目招聘一名新的初级开发人员。你想知道他们是否真的能胜任工作：发现漏洞、添加新功能，以及在不破坏其他部分的情况下修复损坏的代码。
长期以来，我们测试 AI 编程助手的方法是给它们一个空白房间里的单一谜题来解决。但现实中的软件开发并不是房间里的谜题；它更像是为一个充满工具、蓝图和其他工人的高科技车间工作。
IDE-Bench 是一个全新的“车间”，旨在按照 AI 在现实世界中被使用的真实方式来测试它们。以下是该论文研究结果的拆解，使用了简单的类比。
1. 新的测试：从“纸笔”到“全套车间”
之前的测试（如 SWE-Bench）就像是给学生一张写着数学题的纸，并要求他们写出答案。他们不能使用计算器或查阅公式；他们只能根据记忆来猜测答案。
IDE-Bench 则不同。它给了 AI 一个 Docker 化车间（一个安全、隔离的数字房间）和一套完整的工具，就像开发者在 Cursor 或 Windsurf 等应用中使用的工具一样。
- 工具： AI 可以搜索代码、读取文件、编辑行、运行测试，甚至检查数据库。
- 目标： AI 必须表现得像一名真正的工程师。它不能仅仅靠猜测；它必须进行探索、做出更改、检查这些更改是否有效，并在出错时修复它们。
2. “秘密配方”食谱
为了确保 AI 没有仅仅是记住了互联网上的答案，研究人员创建了 80 个全新的任务，分布在 8 个秘密代码库中。
- 类比： 想象一场烹饪比赛，评委们创造了 8 个全新的、从未见过的食谱。参赛者（AI 模型）必须烹饪这些菜肴。因为这些食谱从未在网上发布过，所以 AI 无法通过查看其训练数据来“作弊”。
- 多样性： 这些食谱涵盖了不同的“菜系”（编程语言）：C/C++（系统编程）、Java（企业级应用）和 MERN（现代 Web 应用）。
3. 结果：谁是大师级厨师？
研究人员测试了 15 种不同的 AI 模型。以下是他们的发现：
- 顶尖梯队（大师级厨师）： 少数模型以 GPT-5.2 为首，解决了约 95% 的任务。它们就像能够读懂食谱、拿起正确的工具并尝试一次就完美烹饪出菜肴的厨师。
- 中间梯队（称职的厨师）： 像 Claude Sonnet 和 Claude Haiku 这样的模型解决了约 85–88% 的任务。它们非常出色，但可能需要第二次尝试才能达到完美。
- 底层梯队（新手）： 许多开源模型表现挣扎，解决的任务不到 50%。它们经常在车间里迷失方向，或者在试图修复代码时把代码搞坏了。
4. “差一点就成功”的问题
一个最有趣的发现是，二元评分（通过/失败）隐藏了许多细微差别。
- 类比： 想象一个学生参加考试，答对了 11 道题中的 12 道。在严格的评分系统中，由于没达到 100%，他们会被判定为“不及格”。
- 现实情况： 在 IDE-Bench 中，许多模型掌握了代码的核心部分，但却因为微小的细节（例如缺失一个逗号或格式略有错误）而失败。论文将这些称为 “近失”（near misses）。
- 教训： 一个模型可能已经完成了 90% 的解决方案，但如果它忽略了微小的细节，测试仍会将其标记为完全失败。这表明在实际应用中，我们可能不需要丢弃代码并重新开始；我们可能只需要人类去修复那些小的格式错误。
5. 效率 vs. 彻底性
论文还研究了解决任务的“成本”有多高（以“token”，即思维词汇量来衡量）。
- 快速且廉价： 一些模型（如 Grok 4.1 Fast）非常高效。它们解决任务很快，使用的资源也较少，但失败率较高。
- 缓慢且彻底： 其他模型（如 Claude Opus）耗时很长，阅读了许多文件，并进行了深度思考。它们更有可能成功，但这也意味着在时间和计算能力方面的成本更高。
- 启示： 没有单一的“最佳”模型。如果你追求速度和低成本，你会选择一种类型；如果你需要高可靠性且不在乎成本，你会选择另一种。
6. 它们是如何失败的
研究人员对 AI 模型的失败进行了分类，这就像机械师诊断汽车为什么无法启动一样：
- 过早编辑（63% 的失败原因）： AI 在理解蓝图之前就开始修改代码。这就像是在没有打开引擎盖的情况下就试图修理汽车发动机。
- 无效循环/震荡（28%）： AI 不断地在同一个文件上反复修改，撤销自己的工作，就像一个人无法决定走哪条路，一直在原地转圈。
- 上下文丢失（27%）： AI 在任务进行到一半时忘记了原本要做什么，就像一位厨师开始做蛋糕，却忘了自己原本是要做披萨。
总结
IDE-Bench 证明了顶尖的 AI 模型现在已经能够在复杂的、工具丰富的环境中表现得像真正的软件工程师。然而，它也表明：
- 专业化很重要： 有些模型擅长 Web 应用，但对底层系统代码表现不佳。
- 完美很难： 完成 99% 是常见的，但最后 1%（微小的细节）正是大多数模型失败的地方。
- 策略很重要： 最好的方法可能是先使用一个“快速”模型，如果失败了，再切换到一个“彻底”的模型来完成工作。
论文的结论是，我们需要停止使用单一的“分数”来评判 AI，而应该开始观察它们是如何工作的、它们的擅长领域是什么，以及完成任务需要付出多少代价。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。