你让 AI 写一段代码，几分钟就能得到一份像模像样的修改。但把它交给开源项目后，维护者仍要逐行检查：功能对不对，会不会引入漏洞，以后是否容易维护。写代码像交作业，AI 缩短了答题时间，却没有替老师批卷。
10 月 20 日，Linux 基金会发布研究报告《Navigating Open Source Software Development in the Generative AI Era》。据 InfoQ 对报告的转述，受访者估计，生成式 AI 让代码编写任务的平均耗时减少了 52%；与此同时，维护者估计约四分之一的 Pull Request 属于低质量的“AI slop”。这组数字来自同一机构体系下的一项调查，反映的是受访者感受，并非对代码平台的全面检测。
省下的是编码时间，不是全部工期
Pull Request，简称 PR，是贡献者请求维护者审查并合并一组代码改动的标准流程。报告涉及六类开源开发活动，受访者在每一类中都报告了时间节省。代码编写的平均耗时降幅最大，为 52%；提案讨论等沟通任务也节省了约 19%。
但这不能写成“软件交付快了 52%”。代码只是软件工程的一环。面对复杂任务，21% 的受访者反而花了更多时间使用生成式 AI，说明生成、核对和返工可能抵消效率收益。
省下来的时间也没有全部变成更多代码。66% 的受访者把它用于治理技术债务——也就是处理过去为了赶进度留下、迟早要偿还的问题；63% 用于开发新功能，58% 用于学习和提升技能。AI 的确改变了开发者如何分配时间，只是个人提速不等于整个协作系统同步提速。
代码更便宜，审查没有
59% 的维护者表示，生成式 AI 兴起后，项目收到的代码贡献增加了；在报告所称的“大型项目”中，这一比例为 69%。与此同时，维护者主观估计约 25% 的 PR 属于低质量贡献，大型项目中为 31%。
这里的“AI slop”指看似完整，实际缺少验证、忽略项目约束，或需要维护者投入大量精力才能判断价值的改动。25% 不是研究人员逐项检查 GitHub PR 后得到的客观比例，也不能证明这些低质量改动全部由 AI 生成。它更像一个压力信号：提交变容易后，筛选工作迅速增加。
代码审查也不只是找语法错误。维护者还要判断改动是否正确、安全、可维护，是否符合项目原有设计。许多维护者以兼职或志愿方式工作，却要对最终合并承担责任。报告称，维护者倦怠已成为大型开源项目最突出的担忧之一。换句话说，AI 可能没有消除成本，只是把一部分成本从贡献者转给了维护者。
curl 项目的经历把这种错位表现得更直观。据项目负责人 Daniel Stenberg 的个人博客，AI 生成的夸大或虚构漏洞报告在 2025 年激增，真正成立的比例降到 5% 以下。团队后来终止漏洞奖金，并一度暂停接收报告。生成一份报告可以很快，逐条证明它为什么不成立却仍要真人花时间。
门槛降了，信任没有自动增长
71% 的维护者认同，生成式 AI 降低了参与开源的门槛。但 53% 不同意“生成式 AI 改善了社区信任”。原因不难理解：维护者不仅要知道代码能否运行，还要确认贡献者是否理解自己的修改、能否解释选择，并在出问题后继续维护。
关于新人指导，调查呈现的也不是单一方向。46% 的维护者认为指导需求增加，32% 认为减少。AI 可能帮助一些新人跨过编程门槛，也可能把指导工作从“怎么写”转成“怎么验证、怎么解释”。
治理规则则仍显滞后。只有 35% 的项目制定了正式政策，明确允许在代码贡献中使用生成式 AI；32% 既没有相关政策，也没有制定计划。贡献者中，61% 表示提交 AI 生成代码前会详细审查并进行完整功能测试，但项目仍缺少一致的披露标准。
Linux 基金会因此建议，项目明确 AI 辅助贡献政策，对测试、文档、AI 使用披露、贡献归属和验证机制提出要求。核心原则很朴素：谁提交代码，谁就应先理解和验证，不能把最后一道质量检查默认留给维护者。
真正该衡量什么
这份报告值得关注，不是因为它证明“AI 代码一定更差”，而是因为它改变了生产力问题的问法。生成速度上升之后，稀缺资源可能从写代码变成验证代码。衡量 AI Coding 的价值，也就不能只看生成了多少代码、节省了多少编码时间，还要看审查、返工和长期维护是否变得更重。
局限与未知
- 报告数据来自受访者估计；25% 的低质量 PR 不是平台级检测结果，因而不能坐实为“四分之一 PR 都由 AI 制造”。
- 材料没有给出“大型项目”的规模定义、样本量、误差范围和统计方法，31%、69% 等分组数字应谨慎理解。
- 审查瓶颈转移和长期维护负担增加，是基于调查结果作出的解释，材料没有提供直接的量化因果证据。