22 个经过验证的开源项目已公开拒绝 AI 生成贡献，覆盖代码、文档、翻译和问题报告；这说明争议焦点正从“能不能用 AI 写代码”，转向“谁来承担维护成本”。

这是什么

Open Source Says No 是一个集中展示相关政策的目录站。yt-dlp、Godot、QEMU、immich 等项目划出明确红线：未经许可，不接受 AI 生成的功能代码、大规模重构和社区文本。Godot 允许补全、查找替换等机械性辅助，但要求披露，并保留关闭违规提交及封禁账号的权力。

这里的 vibe coding，指主要依靠自然语言指令，让 AI 生成完整程序或修改代码。不同项目采取封禁、披露和允许但负责三种立场，但共同底线是：提交者必须理解代码、完成测试，并能对每项改动作出解释。

行业怎么看

我们认为，Linux Foundation 调研中“约四分之一新进 PR 被维护者估计为低质量 AI 内容”，比单纯的模型能力争议更值得关注。AI 让提交近乎免费，却没有同步增加审查人手；当生成速度超过审核速度，维护者不得不收紧入口。

反对封禁的声音同样有依据。AI 辅助代码的检测并不可靠，自动封禁可能误伤认真使用补全工具的开发者；一刀切政策还可能劝退新贡献者。风险不只是“垃圾代码变多”，也包括优质贡献被错误挡在门外，以及规则执行依赖平台判断和社区举报。

此外，严格限制可能把训练数据、文档和本地化工作转移回个人、小团队或闭源项目，未必能减少整个软件生态的总成本。封禁能够保护部分维护者，却不是可长期依赖的质量方案。

对普通人的影响

对企业 IT：企业需要把 AI 辅助纳入代码治理，包括来源披露、测试责任和提交审核；不能只问“能不能生成”，还要问“团队是否有人真正看懂并负责”。

对个人职场：AI 会继续提高起草代码和文档的速度，但岗位价值会更多体现在判断、验证和承担结果上。职业经历中的工程能力，仍比单纯会写提示词更重要。

对消费市场：开源软件维护变得更谨慎，部分项目的协作效率可能下降；不过高质量工具若因此获得更稳定的人工维护，用户长期获得的软件质量未必更差。