文章核心观点 - AI生成的低质量代码（AI Slop）正对开源软件（OSS）社区造成严重冲击，破坏了维护者与贡献者之间长期存在的社会契约，导致维护者不堪重负、项目质量下降，并可能终结“开放贡献”的时代 [2][3] AI Slop的定义与影响 - AI Slop特指将GitHub问题粘贴到ChatGPT等工具后，未经检查就直接提交的无效代码、虚假漏洞报告或修复不存在的项目的拉取请求，这些贡献看似合理但充满幻觉或质量低劣 [5] - AI工具破坏了传统的贡献筛选机制，使得任何人都能无需理解代码或付出努力即可生成看似合理的贡献，导致贡献数量激增，系统不堪重负 [3] - 大量低质量的“氛围编码”垃圾淹没了标记为“新手友好”的问题，占用了维护者宝贵的审查时间，损害了生产力和团队士气 [6] - 流入维护者收件箱的垃圾代码数量呈数量级增长，2025年1月似乎是问题全面爆发的临界点 [7] 维护者与项目的应对措施 - cURL项目：在连续六年支付8.6万美元后，于2026年1月终止了其漏洞悬赏计划，原因是AI Slop导致报告质量显著下降，2025年仅有5%的提交识别出真正漏洞 [2][10] - Ghostty项目：最初要求强制披露AI使用，后在2026年1月底采取零容忍政策，永久封禁提交AI生成糟糕代码的贡献者，仅允许维护者和已接受的问题使用AI [2][10] - tldraw项目：自动关闭所有外部拉取请求，完全停止外部贡献，创始人质疑在AI编码助手普及后外部贡献代码的价值 [11] - 观望与共识项目：如Debian和FluxCD等项目仍在观望，因AI工具生态变化快，且项目决策依赖社区共识而非命令，难以快速制定统一政策 [14] - 完全禁止AI贡献的项目： - Gentoo Linux于2024年4月完全禁止AI生成贡献，理由包括版权、质量、伦理问题及社区对“老派软件工程”的偏好 [18] - NetBSD将LLM生成代码归类为“已被污染”，需核心团队事先书面批准才能提交，部分出于避免意外合并GPL代码的担忧 [19] 开源基金会的政策立场 - Linux基金会：政策聚焦于许可兼容性，只要解决许可问题即允许AI生成代码作为贡献，未直接解决维护者面临的AI Slop危机 [16] - Apache软件基金会：建议贡献者在提交消息中使用“Generated-by:”标签披露AI使用，承认这是快速发展的领域 [16] - Eclipse基金会：指南强调AI易出错，提交者需确保代码准确性，并建议添加AI生成代码的免责声明 [17] - 开放基础设施基金会：要求使用“Generated-By:”和“Assisted-By:”标签，并将AI生成代码视为“不可信来源”加强审查 [17] - 总体而言，基金会政策多聚焦法律责任和许可问题，尚未有效解决维护者精疲力竭和质量控制等紧迫问题 [17] 平台激励与经济学问题 - GitHub的角色：2025年5月推出允许用户使用Copilot生成问题的功能，但生成的问题未标注为AI生成，且维护者无法屏蔽Copilot机器人，导致AI Slop问题加剧 [22] - 激励机制错位：平台（如GitHub）有动力夸大AI生成贡献以展示用户参与度和“价值”给股东，但这与维护者需要高质量、可管理贡献的需求相冲突 [24] - 维护者的反抗：一些维护者威胁要完全关闭问题与PR，或将项目迁移至Codeberg等未内置AI工具的非营利平台，但GitHub强大的网络效应可能使其选择留下 [23][25] - AI Slop危机被描述为对开源维护者的“分布式拒绝服务攻击（DDOS）”，而平台缺乏动机阻止 [24] 行业趋势与未来展望 - AI Slop目前较易识别（如幻觉函数调用、错误表述），但模型进化迅速，未来AI生成代码可能与人类代码无法区分，使检测和禁令执行变得几乎不可能 [20] - 部分项目（如Gentoo、NetBSD）的禁令表明，其优先考虑的是信任、溯源和社区文化，而非单纯追求贡献数量或生产力增益 [19] - 行业中存在将AI辅助开发视为对“协作式软件开发这一人类事业的根本性威胁”的观点，而不仅是一个需要管理的技术问题 [20] - 正确的AI使用范例存在：如贡献者使用AI辅助工具发现了“大量”潜在问题，最终帮助cURL修复了五十个真正的Bug，展示了AI与批判性思维结合的价值 [27]