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