Linux 基金会报告：AI 让写代码快 52%，但四分之一 PR 成了“AI 垃圾”
Linux 基金会最新调查报告显示，生成式 AI 让开源开发者的代码编写时间平均缩短 52%，但维护者估计约四分之一的 PR 属于低质量“AI 垃圾”，大型项目中这一比例达 31%。代码提交变容易了，审查和信任的成本却没有同步下降。
写代码快了，复杂任务不一定省时间
10 月 20 日，Linux 基金会发布报告《Navigating Open Source Software Development in the Generative AI Era》，调查生成式 AI 对开源软件开发、代码贡献和社区维护的实际影响。
报告覆盖六类开源开发活动，受访者均表示有不同程度的时间节省。其中代码编写的平均耗时降幅最大，达到 52%；即便是提案讨论这类偏沟通的工作，也节省了约 19% 的时间。
但效率提升并非在所有场景都成立。面对复杂度较高的任务，21% 的受访者表示使用生成式 AI 反而更花时间。换句话说，AI 在常规编码任务上的提速，未必能直接转化为复杂软件工程的整体效率。
省下来的时间也没有全部变成更多代码。66% 的受访者把效率收益投入技术债务治理，63% 用于开发新功能，58% 用于学习和技能提升。AI 正在改变开发者的时间分配方式，但个人效率提升不等于整个协作流程等幅受益。
四分之一 PR 被视作“AI 垃圾”，维护者更累了
报告更值得关注的部分，是开源维护端承受的压力。
59% 的维护者表示，自生成式 AI 兴起以来，项目收到的代码贡献数量有所增长；在大型项目中，这一比例达到 69%。但这些新增贡献并不都能转化为项目价值。维护者估计，收到的 PR 中约 25% 属于低质量内容，大型项目中这一比例升至 31%。
这里说的“AI slop”（AI 垃圾内容），通常指质量较差、缺少充分验证，或者需要维护者花大量精力才能判断价值的 AI 辅助贡献。需要说明的是，这一比例来自受访者的主观估计，并非研究人员逐条检测 GitHub 等平台 PR 后得出的客观统计，也不代表所有低质量 PR 都能确认由 AI 生成。
但这组数字反映出的维护压力值得重视。过去，开发者要花不少时间理解项目结构、写代码、跑测试，才可能提交一份 PR；随着 AI 编程工具普及，生成代码和提交修改的门槛明显降低。对贡献者来说，提出一次修改可能只要很短时间；对维护者来说，判断代码是否正确、是否符合项目架构、是否引入安全问题，仍然要投入实打实的精力。大型项目还要额外处理兼容性、长期维护成本、贡献者沟通和项目治理。
Linux 基金会在报告中指出，维护者倦怠已经成为大型开源项目最突出的担忧之一。
这也给 AI 编程的生产力讨论添了一个新维度：如果代码生成成本大幅下降，而代码验证、审查和维护成本没有同步下降，效率收益就会在不同角色之间重新分配。对习惯“氛围编程”（vibe coding，即借助 AI 快速生成代码、边跑边改）的开发者来说，提交代码越来越轻松；对维护者来说，筛掉不靠谱改动的负担反而更重了。
门槛降低了，社区信任却没同步提升
AI 对开源社区的影响还有另一组矛盾。
调查显示，71% 的维护者认同生成式 AI 降低了参与开源项目的门槛。更多缺少特定语言、框架或项目经验的开发者，可以借助 AI 工具参与协作。
但与此同时，53% 的维护者不同意“生成式 AI 改善了社区信任”这一说法。
开源协作依赖代码之外的因素。维护者不仅要确认一段代码能否运行，还要判断贡献者是否理解修改内容、能否解释设计选择、后续出问题时有没有能力继续维护。AI 可以帮开发者快速生成修改方案，却没法自动建立贡献者和维护者之间的信任。
报告还发现，46% 的维护者认为生成式 AI 增加了指导新贡献者的需求，32% 则认为这种需求有所减少。这说明 AI 虽然降低了技术门槛，新人仍需要理解项目规范、协作流程和软件工程实践。部分原本用于指导写代码的精力，可能正在转向代码验证、问题解释和贡献质量管理。
只有 35% 的项目有正式 AI 贡献政策
面对 AI 辅助代码贡献的快速增长，开源社区的治理机制还没完全跟上。
调查结果显示，只有 35% 的项目制定了正式政策，明确允许在代码贡献中使用生成式 AI。另有 32% 的项目既没有相关政策，也没有制定政策的计划。
在贡献者一侧，61% 的受访者表示会在提交 AI 生成代码前进行详细审查和完整功能测试，但 AI 使用情况的披露仍缺乏一致标准。
AI Coding 的效率红利，谁来承担验证成本？
过去两年，围绕 AI Coding 的讨论大多集中在代码生成速度、任务完成率和开发者生产力上。从代码补全，到能够自主修改仓库、运行测试并提交 PR 的编程智能体（Coding Agent），自动化能力一直在增强。
Linux 基金会的这份报告提供了另一个观察角度：代码生产速度提升之后，软件工程流程中的瓶颈可能逐渐转移到审查、验证和维护环节。
这种变化在开源项目中尤其明显。开源项目的代码贡献可以来自全球任何开发者，但合并权限通常集中在少数核心维护者手中。AI 工具能让更多人快速生成代码，却无法保证维护者的时间和精力也同步增长。
信息不对称推高审查成本
这带来一个现实问题：维护者收到一份代码贡献时，未必清楚其中哪些部分由 AI 生成、贡献者做过哪些验证，以及修改是否经过充分测试。对于依赖志愿维护者的开源项目来说，这种信息不对称会进一步抬高审查成本。
Linux 基金会建议，开源项目应建立明确的 AI 辅助贡献政策，对代码测试、文档说明和 AI 使用披露提出要求，同时完善贡献归属与验证机制。OpenSSF 相关负责人在官方声明中也强调：AI 可以加快代码编写，但贡献者仍需理解并测试自己提交的内容，维护者不应独自承担全部安全审查责任。
门槛降低不等于质量必然下降
这并不意味着 AI 辅助贡献一定会降低开源软件质量。报告同样显示，AI 正在降低参与门槛，帮助开发者偿还技术债务、开发新功能，并提升学习效率。
真正的问题在于：随着 AI 生成代码成为常态，开源社区需要建立与之匹配的验证和治理机制。未来衡量 AI Coding 的价值，除了看开发者节省了多少编码时间、智能体完成了多少任务，还要关注代码最终被接受的比例、审查所需的时间、缺陷修复成本，以及长期维护负担。
AI 让代码越来越容易生产，但要让这些代码真正进入可靠的软件系统，仍然需要付出成本。对正在尝试“氛围编程”的开发者而言，这也是一个提醒：生成只是起点，可审查、可测试、可维护，才是代码进入协作流程的通行证。
关键要点
- Linux 基金会报告指出，AI 让代码生产更快，但瓶颈正转向审查、验证与维护环节。
- 维护者难以判断 PR 中哪些部分由 AI 生成、经过哪些测试，信息不对称会推高开源项目的审查成本。
- 建议开源项目建立 AI 辅助贡献政策，明确测试、文档与 AI 使用披露要求，并由贡献者承担理解与测试责任。
- 衡量 AI Coding 的价值，不能只看生成速度，还要看代码接受率、审查耗时与长期维护负担。