Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
本文通过分析 AIDev 数据集，识别了导致近半数 AI 生成的拉取请求（pull requests）被拒绝的 14 个具体原因，并将这些失败模式进行分类，旨在为提升智能体性能、任务优先级排序以及将其整合进软件开发工作流提供具有操作性的指导。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你雇佣了一支由超快、超热情的机器人实习生组成的团队来修复软件中的漏洞。你给他们一个问题，他们便立即开始敲击代码，构建一个“拉取请求”（Pull Request，这就像是一份修改代码的提案）。
这篇论文基本上是一份成绩单，记录了这些机器人实习生（具体指 Copilot、Devin、Cursor 和 Claude）在尝试修复问题时的表现。研究人员发现了一个惊人的统计数据：近一半的时间里（46.41%），人类老板都会把机器人的工作扔进垃圾桶。
以下是为什么会发生这种情况的详细分析，使用了简单的类比：
核心问题：“浪费精力”的账单
每当机器人生成的修复方案被拒绝时，都是一次双重损失。首先，机器人浪费了自己的“脑力”（计算资源和 Token）。更重要的是，人类必须停止手头的工作，阅读机器人杂乱无章的工作，意识到它是错的，然后写下一段评论来解释原因。这是对人类时间的浪费。
研究人员查看了这 306 个被拒绝的提案，以弄清楚人类为什么说“不”。他们发现了四个主要的拒绝原因：
1. “工具不对症”（实现问题）
有时机器人试图修复问题，但使用了错误的方法。
- 类比： 想象你的汽车无法启动。你请了一位修理工来修，结果他跑来修收音机而不是引擎，或者他试图用一把锤子而不是扳手去修引擎。
- 实际情况： 机器人经常误解指令、修错了东西，或者提出了一个技术上不可能实现或不完整的解决方案。
2. “测试失败”（技术问题）
在软件开发中，在修复程序被接受之前，它必须通过一系列自动化测试（就像安全检查）。
- 类比： 机器人建造了一座新桥，但当检查员开车经过时，桥塌了。机器人没有检查它自己造的桥是否能承重。
- 实际情况： 机器人编写的代码经常无法通过自动化“安全测试”（CI 流水线），或者破坏了原本已经在正常运行的其他部分。
3. “幽灵实习生”（供应商问题）
有时机器人只是突然停止工作或中断了。
- 类比： 你让实习生写一份报告，但写到一半，实习生直接走出了大楼，或者网络连接中断了，留下了一张空白页。
- 实际情况： AI 服务本身崩溃了，机器人遇到了“速率限制”（用完了允许的请求次数），或者会话在完成任务前就直接结束了。
4. “无用之举”（相关性问题）
有时机器人正在处理一个已经不再重要的问题。
- 类比： 你让实习生去修厨房里的漏水问题。等到实习生完成修理时，厨房已经重新装修过了，漏水也消失了，或者别人已经用更好的方法修好了。
- 实际情况： 机器人正在修复的问题优先级很低，问题已被他人解决，或者机器人闲置时间过长，导致项目进度已经向前推进，无需该修复。
“错误”的代价
论文还衡量了机器人在被拒绝前制造了多少“混乱”。
- 代码变更（Code Churn）： 这是一个高级说法，意指“被编写后又被删除的代码量”。研究人员发现，被拒绝的修复方案涉及中位数为 81 到 293 行的代码。对于一个错误来说，这可是大量的打字量！
- 评论： 人类平均需要写 1 到 4.5 条评论来解释为什么这个修复不好。由于近一半的机器人修复会被拒绝，这意味着一半的人类评论仅仅是在对这些机器人说：“不，这行不通。”
启示：如何更好地训练这些实习生
作者建议，为了停止浪费时间，人类需要在机器人开始工作之前给出更好的指令。具体包括：
- 给一张地图： 明确告诉机器人如何修复问题，以及哪些做法是禁止的。
- 设置好测试： 告诉机器人如何检查自己的工作，以确保在向老板展示之前能通过安全测试。
- 挑选合适的任务： 不要让机器人去修复那些微不足道、不值得人类花费时间去审查的小 Bug。
简而言之：AI Agent 功能强大，但目前它们就像是充满热情的实习生，需要非常清晰、具体的指令，以避免浪费大家的时间和精力。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。