AI生成的拉取请求对生产软件维护来说足够可靠吗？

何时可以信任AI生成的拉取请求？

AI拉取请求最适合处理范围明确、重复性高的任务，例如更新依赖项或生成描述性摘要。一项针对2904个JavaScript项目的研究发现，Dependabot自动生成的安全拉取请求有65.42%被接受，通常会在一天内合并，且仅有3.2%导致构建失败[7]。这表明，对于常规的依赖项更新，AI具有很高的可靠性。

类似地，GitHub的拉取请求Copilot功能可自动生成PR描述。在18,256个PR中，该功能缩短了审查时间，并提高了合并率[4]。使用该工具的开发者通常会在AI生成的文本基础上添加手动输入，这表明AI更适合作为起点，而非最终成品[4]。

然而，即便在这些成功案例中，人类的判断依然不可或缺。Dependabot的研究发现，拒绝安全补丁请求的主要原因并非机器人错误，而是人类同时对同一依赖项进行了修改[7]。这意味着AI的建议在技术层面是正确的，但人类的具体情境否决了它。

AI 拉取请求在哪些环节容易引发问题？

与人类编写的代码相比，AI生成的代码随着时间的推移往往得到的维护更少，这对于需要持续维护的生产软件来说是一个危险信号。一项对来自100个热门代码仓库的1000多个AI生成文件的分析发现，这些文件的更新频率较低，且即便更新，也主要是功能添加而非错误修复——这与人类维护的代码恰恰相反[6]。这表明AI代码可能会引入隐藏的技术债务。

另一项研究发现，像Copilot和Devin这样的AI编程助手常常需要审阅者明确介入——在已合并的AI拉取请求中，有15.4%需要人工反馈或直接提交才能被接受[1]。这意味着，即便AI生成的PR最终被合并，它往往也无法独立达到可接受的标准。

代码审查代理同样存在信噪比低的问题：当被要求找出所有隐藏问题时，它们会产生大量误报，从而浪费开发者的时间[5]。该研究的作者警告称，仅以“发现的问题数量”来衡量成功，可能会掩盖虚假发现带来的实际成本[5]。

团队应如何在生产环境中使用AI拉取请求？

证据指向一种混合模式：用AI完成初稿或常规任务，但始终需要人工审核。AI拉取请求的驳回率高得具有误导性——仅有35.7%的驳回源于实际代理故障，而31.2%是由合并冲突或CI失败等工作流限制导致的[1]。这意味着许多被驳回的AI拉取请求在技术上是合理的，却成了流程问题的牺牲品。

像GitHub Actions这类自动化工具实际上可能会提高PR的拒绝率并延长审查时间，因此在AI之上叠加更多自动化反而可能适得其反[3]。关键在于设计一个工作流程，让AI的建议先经过人工审查者过滤，从而筛除干扰信息并捕捉细微错误。

最后，由于AI编程代理会留下可检测的行为特征——例如特定的提交信息模式或代码结构——团队可以利用这些特征追踪哪些贡献是由AI生成的，并对其采用不同的审查标准[2]。这种治理方式有助于在保持代码质量的同时，依然享受AI带来的速度优势。

关于这些来源

该答案基于7项研究（3篇经同行评审，4篇为预印本）构建而成——这些研究发表于2021年至2026年间，其中5项为2024年或之后发表，1项发表于Q1–Q2期刊，累计被引用76次——从通过质量筛选的8项研究中选为最相关成果，这些研究又源自从超过5亿篇论文的数据库中检索出的37篇文献。

本文引用的文献

相关研究问题