Linux Foundation Report: AI Makes Coding 52% Faster, but a Quarter of PRs Are Low-Quality Contributions

10 月 20 日，Linux 基金会发布最新研究报告《Navigating Open Source Software Development in the Generative AI Era》，调查生成式 AI 对开源软件开发、代码贡献和社区维护的影响。

报告给出了一组颇具反差的数据：受访者估计，使用生成式 AI 后，代码编写任务的平均耗时减少了 52%；与此同时，开源项目维护者估计，收到的 Pull Request（PR，拉取请求）中约有 25% 属于低质量贡献，被称为“AI slop”（AI 垃圾内容）。在大型开源项目中，这一比例进一步上升至 31%。59% 的维护者表示，自生成式 AI 兴起以来，项目收到的代码贡献数量有所增长；在大型项目中，这一比例达到 69%。

1 AI 写代码更快了，复杂任务却未必省时间

Linux 基金会这份研究由 LF Research 发布，获得 Red Hat 赞助，以及 Futurewei、OpenSSF、LF AI & Data 的支持。

Linux 基金会在官方新闻中表示，生成式 AI 对开源开发效率的提升已经覆盖多个环节，远不止代码生成。在研究涉及的六类开源开发活动中，受访者均报告了不同程度的时间节省。其中，代码编写的平均耗时降幅最大，达到 52%；即使是提案讨论等沟通性任务，也实现了约 19% 的时间节省。

不过，这种效率提升并不适用于所有场景。对于复杂度较高的任务，21% 的受访者表示，使用生成式 AI 反而需要花费更多时间。这意味着，AI 在生成代码、处理常规开发任务时表现出的效率优势，未必能够直接转化为复杂软件工程任务的整体效率提升。

节省下来的时间也并没有全部转化为更多代码产出。66% 的受访者表示，他们将效率收益投入技术债务治理，63% 用于开发新功能，58% 用于学习和技能提升。

2 四分之一的 PR 被认为是“AI 垃圾”，维护者压力增加

相比代码编写效率，报告中更值得关注的是开源维护环节正在承受的压力。

59% 的维护者报告代码贡献数量增加，但这些新增贡献并不都能直接转化为项目价值。根据维护者的估计，收到的 PR 中约四分之一属于低质量内容。在大型项目中，这一比例达到 31%。

这里的“AI slop”通常指质量较差、缺少充分验证，或者需要维护者投入大量精力才能判断其价值的 AI 辅助贡献。需要强调的是，这一比例来自调查受访者的估计，并非研究人员对 GitHub 等平台上的 PR 进行逐项检测后得到的客观统计，也不意味着所有低质量 PR 都能被确认由 AI 生成。

但这组数据反映出的维护压力值得重视。

过去，开发者需要花费相当多的时间理解项目结构、编写代码、运行测试，才能提交一份 PR。随着 AI Coding 工具普及，生成代码和提交修改的门槛明显降低。对于贡献者来说，提出一次代码修改可能只需要很短时间；对于维护者而言，判断这些代码是否正确、是否符合项目架构、是否引入安全问题，仍然需要投入精力。

尤其是在大型开源项目中，维护者还需要处理代码兼容性、长期维护成本、贡献者沟通以及项目治理等问题。

Linux 基金会在报告中指出，维护者倦怠已经成为大型开源项目最突出的担忧之一。

这一变化也让 AI Coding 的生产力问题出现了新的衡量维度：如果代码生成成本大幅下降，但代码验证、审查和维护成本没有同步下降，那么效率收益可能会在不同角色之间重新分配。

3 71%认为 AI 降低了开源门槛，但社区信任并未同步提升

但与此同时，53% 的维护者不同意“生成式 AI 改善了社区信任”这一说法。

开源社区的协作依赖代码之外的许多因素。维护者不仅需要知道一段代码能否运行，还需要判断贡献者是否理解修改内容，能否解释设计选择，以及在后续出现问题时是否有能力继续维护。

报告还发现，46% 的维护者认为，生成式 AI 增加了对新贡献者进行指导的需求；32% 则认为这种需求有所减少。

这也说明，AI 虽然降低了新开发者进入开源社区的技术门槛，但新人仍然需要理解项目规范、协作流程和软件工程实践。部分原本用于指导代码编写的工作，可能正在转向代码验证、问题解释和贡献质量管理。

4 只有 35%的项目制定了正式 AI 贡献政策

Linux 基金会的调查结果显示，只有 35% 的项目制定了正式政策，明确允许在代码贡献中使用生成式 AI。另有 32% 的项目既没有相关政策，也没有制定政策的计划。在贡献者一侧，61% 的受访者表示，他们会在提交 AI 生成代码之前进行详细审查和完整的功能测试。但 AI 使用情况的披露仍然缺乏一致标准。

这带来了一个现实问题：维护者收到一份代码贡献时，未必清楚其中哪些部分由 AI 生成、贡献者进行了哪些验证，以及代码修改是否经过充分测试。对于依赖志愿维护者的开源项目而言，这种信息不对称可能进一步增加审查成本。

Linux 基金会建议，开源项目应建立明确的 AI 辅助贡献政策，对代码测试、文档说明和 AI 使用披露提出要求，同时完善贡献归属与验证机制。OpenSSF 相关负责人也在官方发布的声明中强调，AI 可以加快代码编写，但贡献者仍然需要理解并测试自己提交的内容，维护者不应独自承担全部安全审查责任。

5 AI Coding 的效率红利，谁来承担验证成本？

过去两年，AI Coding 的讨论很大程度上围绕代码生成速度、任务完成率和开发者生产力展开。从代码补全到能够自主修改仓库、执行测试并提交 PR 的 Coding Agent，自动化能力正在不断增强。

Linux 基金会这份报告提供了另一个观察角度：当代码生产速度提升之后，软件工程流程中的瓶颈可能逐渐向审查、验证和维护环节转移。

这种变化对开源项目尤其明显。开源项目的代码贡献可以来自全球任何开发者，但维护权限通常集中在相对有限的核心维护者手中。AI 工具能够让更多人快速生成代码，却无法保证维护者的时间和精力以同样速度增长。

问题在于，随着 AI 生成代码成为常态，开源社区需要建立与之匹配的验证和治理机制。未来衡量 AI Coding 的价值，除了开发者节省了多少编码时间、Agent 完成了多少任务，还需要关注代码最终被接受的比例、审查所需的时间、缺陷修复成本，以及长期维护负担。

Linux 基金会报告链接：

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：蔡芳芳，36氪经授权发布。