33k+ AI编码PR实证揭秘：为什么AI提交的代码常被拒绝？

论文信息

• 原标题：Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub
• 主要作者及研究机构：
  • Ramtin Ehsani（德雷塞尔大学，美国费城）
  • Sakshi Pathak（德雷塞尔大学，美国费城）
  • Shriya Rawal（德雷塞尔大学，美国费城）
  • Abdullah Al Mujahid（密苏里科技大学，美国罗拉）
  • Mia Mohammad Imran（密苏里科技大学，美国罗拉）
  • Preetha Chatterjee（德雷塞尔大学，美国费城）
• 引文格式（GB/T 7714）：Ehsani R, Pathak S, Rawal S, et al. Where do AI coding agents fail? An empirical study of failed agentic pull requests in GitHub[C]//Proceedings of MSR ’26: Proceedings of the 23rd International Conference on Mining Software Repositories. New York: ACM, 2018: 1-5.
• 会议信息：MSR 2026（第23届国际软件仓库挖掘会议），2026年4月，巴西里约热内卢

研究背景：AI编码代理“上岗”，但“通过率”为何参差不齐？

如今，GitHub Copilot、OpenAI Codex这类AI编码代理早已不是单纯的“代码助手”——它们能自主生成代码、响应评审反馈，甚至直接向开源项目提交拉取请求（PR），成为真正的“自主贡献者”。就像职场里的新员工，AI代理们干劲十足，提交的PR数量正飞速增长。

但问题也随之而来：这些AI贡献者的“工作表现”差异巨大。有的PR能顺利通过评审合并入项目，有的却被直接拒绝，还有的石沉大海无人问津。对于开发团队来说，面对AI提交的PR，常常困惑：这些AI的代码靠谱吗？为什么有的能直接用，有的却完全不符合需求？对于AI开发者而言，也急需知道：AI编码代理在真实的软件开发流程中，到底卡在了哪里？

此前的研究要么只关注AI在孤立任务中的表现（比如单独生成一段代码、修复一个简单漏洞），要么只分析人类提交PR的成功因素，却从未对AI代理提交的PR进行过大规模、系统性的复盘。就像我们想提升新员工的工作效率，却不知道他们到底是在沟通上出了问题，还是专业能力不足——AI编码代理的“失败原因”，始终是个模糊的谜团。而这个谜团，正是这篇论文想要解开的核心。

创新点：给AI编码代理做“全面体检”，从定量到定性的双重突破

这篇论文的亮点在于它跳出了“单一任务测试”的局限，真正走进了真实的软件开发场景，用数据说话，给出了兼具广度和深度的答案：

1. 规模突破：首次对33k+个AI代理PR进行大规模实证分析，覆盖5个主流编码代理和众多高星开源项目，样本量足够大，结论更具说服力；
2. 维度全面：不仅看代码本身的技术特征，还首次将“评审互动”“项目协作”等社会技术因素纳入分析，避免了“只谈技术不谈人”的片面性；
3. 分类清晰：通过定性分析构建了四级拒绝模式分类体系，把杂乱的“拒绝原因”整理成可理解、可复用的框架，为后续AI优化指明了明确方向；
4. 对比直观：不仅横向对比不同AI代理的表现，还纵向分析合并与未合并PR的核心差异，让“成功密码”和“失败陷阱”一目了然。

研究方法：一步步拆解AI PR的“成败密码”

这篇论文的研究思路非常清晰，就像侦探破案一样，先通过定量分析锁定“嫌疑范围”，再通过定性分析深挖“核心真相”，整个过程逻辑严密、步骤明确：

第一步：数据准备——筛选“研究样本”

研究团队采用了AIDev-pop数据集，这个数据集包含了GitHub上5个主流AI编码代理（OpenAI Codex、GitHub Copilot、Devin、Cursor、Claude Code）提交的33,596个PR，且涉及的项目均有100+星标，确保了样本的真实性和代表性。

第二步：定量分析（回答RQ1）——给PR“画群像”，找差异

为了搞清楚“合并与未合并的AI PR到底不一样在哪”，研究团队从4个核心维度展开分析，还用到了专业的统计方法确保结果靠谱：

1. 维度1：任务类型：把PR分为功能开发、漏洞修复、文档更新、CI配置等11类，统计每类任务的合并率，看AI在哪些任务上更擅长；
2. 维度2：代码变更：测量PR的新增/删除代码行数（LOC）和修改文件数，判断代码变更规模是否影响合并概率；
3. 维度3：CI构建结果：通过GitHub API查询PR的自动化测试、代码规范检查结果，看“机器验证”是否能预测PR命运；
4. 维度4：评审动态：统计PR收到的评审注释数、评审修订次数，分析人类评审者的互动情况对结果的影响；
5. 统计验证：用Cliff’s delta测量差异的“效应量”（避免因样本大导致的虚假显著性），用逻辑回归预测合并概率，用核密度图可视化数据分布，让差异更直观。

第三步：定性分析（回答RQ2）——给拒绝PR“分类诊断”，找模式

定量分析发现了“差异”，但没说清“为什么”。于是研究团队又做了深度拆解：

1. 抽样：从所有未合并PR中随机抽取600个，按5个AI代理分层抽样，确保每个代理都有足够样本，误差控制在±5%；
2. 编码：两名研究者采用“开放式编码”方法，独立给每个PR标注拒绝原因，过程中不断讨论、修订分类标准；
3. 校准：第一轮编码后，通过讨论解决分歧，还新增了“代理层面”的分类，最终 Cohen’s kappa系数达到0.91（表示标注一致性极高）；
4. 归类：最终形成了四级拒绝模式分类体系，把所有未合并原因整理成清晰的框架。

一段话总结

该研究对GitHub上5个AI编码代理提交的33k+个拉取请求（PR） 开展大规模实证分析，聚焦合并与未合并PR的差异及未合并原因：定量层面，文档、CI和构建更新类任务合并率最高（分别为84%、79%、74%），性能优化（55%）和漏洞修复（64%）类最低，未合并PR多涉及更大规模代码变更、更多文件修改且CI构建失败率更高；定性分析600个未合并PR后，构建了包含评审者层面、PR层面、代码层面、代理层面的四级拒绝模式分类体系，其中评审者放弃（38%）、重复PR（23%）、CI/测试失败（17%） 是主要原因，研究结果为提升AI编码代理与软件开发工作流的适配性、协作性提供了实证支撑。

---

思维导图

---

详细总结

一、研究基础

1. 研究背景：GitHub Copilot、OpenAI Codex等AI编码代理已超越代码辅助角色，成为开源项目的自主贡献者，直接提交PR并参与软件开发生命周期，但这类代理提交的PR合并率差异显著，其失败原因及特征缺乏大规模实证分析。
2. 核心问题：
   • RQ1：合并与未合并的AI代理PR在任务类型、代码变更、CI构建结果、评审互动方面存在哪些差异？
   • RQ2：真实软件仓库中，AI代理PR未被合并的模式有哪些？
3. 数据规模：基于AIDev-pop数据集，涵盖GitHub上5个主流编码代理提交的33,596个PR，涉及星标≥100的项目，其中有效分析PR数量为33k+（定量）和600个（定性，最终有效562个）。

二、研究方法

分析类型	核心内容	技术手段/指标
定量分析（RQ1）	任务类型分布	11类任务标签（功能、修复、文档等）+ 合并率统计
	代码变更规模	新增/删除代码行数（LOC）、修改文件数
	CI构建结果	失败检查次数、GitHub提交状态（成功/失败）
	评审动态	评审注释数、评审修订次数
	统计验证	Cliff’s delta（效应量）、逻辑回归（预测合并概率）、核密度估计（分布可视化）
定性分析（RQ2）	抽样方法	分层抽样（覆盖5个代理）、95%置信度±5%误差
	编码流程	开放式编码→初始分类体系→讨论修订→最终分类（Cohen’s kappa从0.55提升至0.91）
	分类体系	四级拒绝模式（评审者层面、PR层面、代码层面、代理层面）

三、关键研究结果

（一）RQ1：合并与未合并PR的定量差异

1. 代理提交量与合并率排名
   | 编码代理 | PR提交量 | 合并率 | 排名 |
   |----------|----------|--------|------|
   | OpenAI Codex | 21,799 | 82.59% | 1 |
   | Cursor | 1,541 | 65.22% | 2 |
   | Claude Code | 459 | 59.04% | 3 |
   | Devin | 4,827 | 53.76% | 4 |
   | GitHub Copilot | 4,970 | 43.04% | 5 |

2. 任务类型与合并率关联

   • 高合并率任务（跨代理平均）：文档（84%）、CI（79%）、构建更新（74%）
   • 低合并率任务（跨代理平均）：性能优化（55%）、漏洞修复（64%）
   • 代理特异性表现：Codex在10类任务中合并率≥80%（仅性能类68%）；Copilot所有任务合并率均＜65%（性能类最低27%）

3. 代码变更与合并概率

   • 未合并PR的LOC变更量比合并PR高17%（Cliff’s δ=-0.17）
   • 未合并PR修改的文件数比合并PR多10%（Cliff’s δ=-0.10）
   • 逻辑回归显示：LOC每增加1单位，合并概率下降1%；文件数每增加1单位，合并概率下降1%

4. CI构建与评审动态

   • CI失败检查：未合并PR的失败检查分布更分散（效应量24%），合并PR多集中于0失败
   • 评审互动：未合并PR平均获5%更多评审注释、3%更多评审修订，且部分PR经历多次迭代后仍被拒绝

（二）RQ2：未合并PR的拒绝模式分类（基于562个有效PR）

拒绝层面	占比	核心子模式	具体描述
评审者层面	38%	评审者放弃	无有意义人类互动、长期闲置后自动关闭或手动关闭
PR层面	31%	重复PR	23%，与现有PR功能重复，被标记为“替代”
		无用功能	4%，与项目目标不符或修改冗余
		非功能性PR	2%，仅含配置测试，无实际功能改进（如“测试用，请勿合并”）
		任务描述不当/分支错误	1%+＜1%，描述无意义或提交至错误分支
代码层面	22%	CI/测试失败	17%，代码变更导致自动化构建、测试或代码规范检查失败
		实现错误/不完整	3%+2%，代码逻辑错误、功能未完成或存在技术缺陷
代理层面	2%	指令失配	1%，多次反馈后仍无法遵循评审者要求或误解需求
		许可协议违规	＜1%，未签署贡献者许可协议（CLA）等项目法律要求

研究结论与启示

1. 核心结论：AI代理PR失败是技术因素（代码错误、CI失败）与社会技术因素（评审协作、项目适配）共同作用的结果，代理在任务选择、项目规则适配、协作沟通方面存在显著不足。
2. 改进方向：
   • 技术层面：优化代码变更粒度（拆分大型PR）、提交前自动执行CI验证、减少逻辑错误；
   • 协作层面：增强现有PR检索能力（避免重复）、理解项目贡献规范、提升对评审反馈的响应准确性；
   • 设计层面：开发更具上下文感知能力的AI编码代理，适配不同项目的工作流与质量标准。

---

关键问题

问题1：不同类型任务中，AI编码代理提交的PR合并率差异显著，哪些任务最容易被合并，哪些最困难？背后的核心原因是什么？

答案：最容易被合并的任务类型为文档更新（84%）、CI配置（79%）、构建更新（74%）；最困难的是性能优化（55%）和漏洞修复（64%）。核心原因：① 文档/CI/构建更新任务多为格式化、规则化修改，复杂度低、评审成本小，且不易引入功能冲突；② 性能优化和漏洞修复需要深度理解项目架构、业务逻辑及潜在影响，对代码准确性、兼容性要求极高，AI代理易出现逻辑偏差或优化不达标，导致评审者谨慎对待，合并门槛更高。

问题2：从技术特征来看，未合并的AI代理PR与合并的PR相比，最显著的差异是什么？这些差异对PR合并概率的影响程度如何？

答案：最显著的技术差异集中在三点，且均对合并概率有负向影响：① 代码变更规模：未合并PR的LOC变更量比合并PR高17%，文件修改数多10%（Cliff’s δ分别为-0.17、-0.10），每增加1单位LOC或文件修改，合并概率约下降1%；② CI构建结果：未合并PR的失败检查次数显著更多（效应量24%），每增加1次CI失败，合并概率下降15%；③ 评审迭代成本：未合并PR平均获5%更多评审注释和3%更多修订，反映出代码需要更多人工修正，降低了合并效率。其中，CI构建失败对合并概率的负面影响最大。

问题3：在AI代理PR的各类拒绝模式中，占比最高的三类分别是什么？这反映了AI编码代理在实际软件开发协作中存在哪些核心短板？

答案：占比最高的三类拒绝模式为：① 评审者放弃（38%）、② 重复PR（23%）、③ CI/测试失败（17%）。这反映出AI编码代理的三大核心短板：① 协作衔接不足：缺乏与项目评审者的有效互动能力，无法主动推进PR评审流程，导致大量PR因闲置被关闭；② 项目感知缺失：未能检索识别项目中已存在的同类PR，也未充分理解项目需求边界，导致重复提交或开发无用功能；③ 质量控制薄弱：提交前未有效验证代码的兼容性、正确性，无法通过项目CI/测试 pipeline，凸显AI代理在代码质量自检环节的不足。

主要成果和贡献：AI编码代理的“成败清单”，让优化有迹可循

这篇论文的核心价值在于：首次用大规模数据揭露了AI编码代理在真实开发场景中的表现规律，把“为什么AI的PR会被拒”从模糊猜测变成了可落地的优化方向，不管是对AI工具开发者、开源项目维护者，还是普通开发者，都有极强的实用价值。

一、核心成果（RQ对应结论）

研究问题（RQ）	核心发现	实用价值
RQ1：合并与未合并PR的差异是什么？	1. 任务适配：文档/CI/构建更新合并率最高（74%-84%），性能优化/漏洞修复最低（55%-64%）； 2. 代码特征：未合并PR多是“大改动”（LOC多17%、文件改多10%）； 3. 机器验证：CI失败是“致命伤”，每多1次失败，合并概率降15%； 4. 代理表现：Codex最靠谱（合并率82.59%），Copilot有待提升（43.04%）	1. AI工具可优先强化高合并率任务的支持； 2. 开发者用AI提交PR时，尽量拆分“小而精”的改动； 3. 项目维护者可优先审核AI提交的文档/CI类PR，效率更高
RQ2：未合并PR的拒绝模式有哪些？	1. 最常见：评审者放弃（38%）——PR没人管直接关闭； 2. 第二常见：重复PR（23%）——AI“闭门造车”，做了别人已做的工作； 3. 技术硬伤：CI/测试失败（17%）——代码过不了自动化验证； 4. 其他：无用功能、实现错误、指令理解偏差等	1. AI工具需新增“检索现有PR”“CI预验证”功能； 2. 项目维护者可给AI PR加专属标签，减少“无人问津”的情况； 3. 开发者可提前规避AI易踩的坑（如重复开发、不做测试）

二、领域贡献

1. 理论贡献：构建了首个“AI代理PR拒绝模式分类体系”（四级分类），为后续研究提供了统一的分析框架，不再是“各说各的失败原因”；
2. 实践贡献：给AI编码代理优化指明了4个明确方向——拆小PR、预跑CI、检索重复工作、理解项目需求，相当于给开发者一张“避坑指南”；
3. 数据贡献：公开了研究的复现包，方便其他研究者进一步拓展，推动整个领域进步。

三、开源资源

• 复现包地址：https://anonymous.4open.science/r/MSR2026_AIDev035B/
• 数据集来源：AIDev-pop数据集（含33k+ AI代理PR，覆盖5个主流编码代理）

总结

这篇论文通过对33k+个AI编码代理PR的定量+定性分析，清晰回答了“AI提交的PR为什么能成、为什么会败”：AI在简单、规则化的任务（如文档、CI配置）中表现出色，但在复杂任务（如性能优化、漏洞修复）中容易“翻车”；未合并的核心原因不仅有技术硬伤（CI失败、代码错误），还有协作问题（评审者放弃、重复提交）。研究结果为AI编码工具的优化、开源项目的PR管理提供了实打实的参考，让AI从“能写代码”真正升级为“能做好贡献”的开发伙伴。