[论文阅读] AI + 软件工程 | 33k+ AI编码PR实证揭秘：为什么AI提交的代码常被拒绝？
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编码代理做“全面体检”，从定量到定性的双重突破
这篇论文的亮点在于它跳出了“单一任务测试”的局限，真正走进了真实的软件开发场景，用数据说话，给出了兼具广度和深度的答案：
- 规模突破：首次对33k+个AI代理PR进行大规模实证分析，覆盖5个主流编码代理和众多高星开源项目，样本量足够大，结论更具说服力；
- 维度全面：不仅看代码本身的技术特征，还首次将“评审互动”“项目协作”等社会技术因素纳入分析，避免了“只谈技术不谈人”的片面性；
- 分类清晰：通过定性分析构建了四级拒绝模式分类体系，把杂乱的“拒绝原因”整理成可理解、可复用的框架，为后续AI优化指明了明确方向；
- 对比直观：不仅横向对比不同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：任务类型：把PR分为功能开发、漏洞修复、文档更新、CI配置等11类，统计每类任务的合并率，看AI在哪些任务上更擅长；
- 维度2：代码变更：测量PR的新增/删除代码行数（LOC）和修改文件数，判断代码变更规模是否影响合并概率；
- 维度3：CI构建结果：通过GitHub API查询PR的自动化测试、代码规范检查结果，看“机器验证”是否能预测PR命运；
- 维度4：评审动态：统计PR收到的评审注释数、评审修订次数，分析人类评审者的互动情况对结果的影响；
- 统计验证：用Cliff’s delta测量差异的“效应量”（避免因样本大导致的虚假显著性），用逻辑回归预测合并概率，用核密度图可视化数据分布，让差异更直观。
第三步：定性分析（回答RQ2）——给拒绝PR“分类诊断”，找模式
定量分析发现了“差异”，但没说清“为什么”。于是研究团队又做了深度拆解：
- 抽样：从所有未合并PR中随机抽取600个，按5个AI代理分层抽样，确保每个代理都有足够样本，误差控制在±5%；
- 编码：两名研究者采用“开放式编码”方法，独立给每个PR标注拒绝原因，过程中不断讨论、修订分类标准；
- 校准：第一轮编码后，通过讨论解决分歧，还新增了“代理层面”的分类，最终 Cohen’s kappa系数达到0.91（表示标注一致性极高）；
- 归类：最终形成了四级拒绝模式分类体系，把所有未合并原因整理成清晰的框架。
一段话总结
该研究对GitHub上5个AI编码代理提交的33k+个拉取请求（PR） 开展大规模实证分析，聚焦合并与未合并PR的差异及未合并原因：定量层面，文档、CI和构建更新类任务合并率最高（分别为84%、79%、74%），性能优化（55%）和漏洞修复（64%）类最低，未合并PR多涉及更大规模代码变更、更多文件修改且CI构建失败率更高；定性分析600个未合并PR后，构建了包含评审者层面、PR层面、代码层面、代理层面的四级拒绝模式分类体系，其中评审者放弃（38%）、重复PR（23%）、CI/测试失败（17%） 是主要原因，研究结果为提升AI编码代理与软件开发工作流的适配性、协作性提供了实证支撑。
思维导图
详细总结
一、研究基础
- 研究背景：GitHub Copilot、OpenAI Codex等AI编码代理已超越代码辅助角色，成为开源项目的自主贡献者，直接提交PR并参与软件开发生命周期，但这类代理提交的PR合并率差异显著，其失败原因及特征缺乏大规模实证分析。
- 核心问题：
- RQ1：合并与未合并的AI代理PR在任务类型、代码变更、CI构建结果、评审互动方面存在哪些差异？
- RQ2：真实软件仓库中，AI代理PR未被合并的模式有哪些？
- 数据规模：基于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的定量差异
-
代理提交量与合并率排名
| 编码代理 | 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 | -
任务类型与合并率关联
- 高合并率任务（跨代理平均）：文档（84%）、CI（79%）、构建更新（74%）
- 低合并率任务（跨代理平均）：性能优化（55%）、漏洞修复（64%）
- 代理特异性表现：Codex在10类任务中合并率≥80%（仅性能类68%）；Copilot所有任务合并率均＜65%（性能类最低27%）
-
代码变更与合并概率
- 未合并PR的LOC变更量比合并PR高17%（Cliff’s δ=-0.17）
- 未合并PR修改的文件数比合并PR多10%（Cliff’s δ=-0.10）
- 逻辑回归显示：LOC每增加1单位，合并概率下降1%；文件数每增加1单位，合并概率下降1%
-
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）等项目法律要求 |
研究结论与启示
- 核心结论：AI代理PR失败是技术因素（代码错误、CI失败）与社会技术因素（评审协作、项目适配）共同作用的结果，代理在任务选择、项目规则适配、协作沟通方面存在显著不足。
- 改进方向：
- 技术层面：优化代码变更粒度（拆分大型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易踩的坑（如重复开发、不做测试） |
二、领域贡献
- 理论贡献：构建了首个“AI代理PR拒绝模式分类体系”（四级分类），为后续研究提供了统一的分析框架，不再是“各说各的失败原因”；
- 实践贡献：给AI编码代理优化指明了4个明确方向——拆小PR、预跑CI、检索重复工作、理解项目需求，相当于给开发者一张“避坑指南”；
- 数据贡献：公开了研究的复现包，方便其他研究者进一步拓展，推动整个领域进步。
三、开源资源
- 复现包地址：https://anonymous.4open.science/r/MSR2026_AIDev035B/
- 数据集来源：AIDev-pop数据集（含33k+ AI代理PR，覆盖5个主流编码代理）
总结
这篇论文通过对33k+个AI编码代理PR的定量+定性分析，清晰回答了“AI提交的PR为什么能成、为什么会败”：AI在简单、规则化的任务（如文档、CI配置）中表现出色，但在复杂任务（如性能优化、漏洞修复）中容易“翻车”；未合并的核心原因不仅有技术硬伤（CI失败、代码错误），还有协作问题（评审者放弃、重复提交）。研究结果为AI编码工具的优化、开源项目的PR管理提供了实打实的参考，让AI从“能写代码”真正升级为“能做好贡献”的开发伙伴。
