四分之一的 PR 是“AI 垃圾”：写代码快了 52%，开源维护者却更累了

AI 编程工具正在把“写代码”这件事变快，但开源社区正在为这种速度付出另一种代价。10 月 20 日，Linux 基金会发布研究报告《Navigating Open Source Software Development in the Generative AI Era》，调查生成式 AI 对开源开发、代码贡献与社区维护的影响。

报告里有一组反差极大的数字：受访者估计，使用生成式 AI 后，代码编写任务的平均耗时减少了 52%；与此同时，维护者估计收到的 Pull Request 中约 25% 属于低质量贡献，被称为“AI slop”（AI 垃圾）。在大型项目中，这一比例升到 31%。

一分钟速览

• 效率：六类开发活动全部提速，代码编写耗时降 52%，连提案讨论也省了约 19% 时间。
• 代价：约 25% 的 PR 被维护者视为低质量，大型项目达 31%；59% 的维护者称贡献数量增加，大型项目为 69%。
• 复杂任务例外：21% 的受访者表示，任务越复杂，用 AI 反而更费时间。
• 治理滞后：只有 35% 的项目制定了正式的 AI 贡献政策，32% 既没有政策也没有计划。
• 信任没跟上：71% 的维护者认为 AI 降低了参与门槛，但 53% 不同意“AI 改善了社区信任”。

省下来的时间去了哪里

报告由 LF Research 发布，Red Hat 赞助，Futurewei、OpenSSF、LF AI & Data 支持。研究覆盖六类开源开发活动，受访者均报告了不同程度的时间节省。但节省下来的时间并没有全部变成更多代码：66% 的人把它投入技术债务治理，63% 用于开发新功能，58% 用于学习与技能提升。

这组数据说明，AI 改变的不只是产出速度，还有开发者的时间分配。过去被写代码挤占的清理、重构、学习，现在有了空间。这对项目长期健康是好事，但它也意味着“AI 让代码产量翻倍”的简单叙事并不成立。

为什么 PR 变多了，维护者却更累

生成代码的门槛下降，是这份报告最关键的结构性变化。过去提交一份 PR，贡献者需要理解项目结构、写代码、跑测试；现在，AI 可以在几分钟内生成一版看起来能跑的补丁。提交成本降了，审查成本却没有降。

维护者要判断的仍然是那些老问题：代码是否符合项目架构、是否引入安全漏洞、边界条件有没有覆盖、贡献者是否理解自己提交的内容。大型项目还要考虑兼容性、长期维护成本和治理流程。报告指出，维护者倦怠已成为大型开源项目最突出的担忧之一。

这里需要说明：25% 与 31% 来自受访者的主观估计，不是研究人员逐条检测 GitHub PR 得出的客观统计，也不能证明这些低质量 PR 都由 AI 生成。但这组数字反映的压力是真实的。

门槛降低，信任没有同步降低

71% 的维护者认同 AI 降低了参与开源的门槛，更多缺少特定语言或框架经验的人，可以借助 AI 参与协作。但 53% 的维护者不同意“生成式 AI 改善了社区信任”。

开源协作依赖代码之外的东西：维护者需要知道贡献者是否理解修改、能否解释设计选择、出问题时有没有能力继续维护。AI 能生成补丁，却无法替贡献者建立这种信用。46% 的维护者认为，AI 增加了指导新贡献者的需求；只有 32% 认为需求减少。

治理缺口：三分之二的项目没有规矩

只有 35% 的项目制定了正式政策，明确允许在贡献中使用生成式 AI；32% 的项目既没有政策，也没有制定计划的打算。贡献者一侧，61% 表示会在提交 AI 生成代码前做详细审查和完整测试，但 AI 使用情况的披露仍缺乏统一标准。

这造成信息不对称：维护者收到补丁时，未必知道哪些部分由 AI 生成、贡献者做过哪些验证。Linux 基金会建议项目建立明确的 AI 辅助贡献政策，对测试、文档和 AI 使用披露提出要求，并完善贡献归属与验证机制。OpenSSF 也强调，AI 可以加快写代码，但贡献者仍需理解并测试自己提交的内容，维护者不应独自承担全部安全审查责任。

趋势洞察

AI 编程的效率红利，正在从“写”转移到“审”。当生成代码的成本趋近于零，瓶颈就落在验证、集成与长期维护上。未来衡量 AI 编程的价值，不能只看省了多少编码时间，还要看 PR 被接受的比例、审查耗时、缺陷修复成本和维护者负担。代码越来越容易生产，但让代码进入可靠系统，仍然要付成本。