System76 COSMIC 项目全面禁用 LLM 代码提交，开源社区效仿

System76 公司于 2026 年 10 月 5 日宣布，其维护的 COSMIC 桌面环境项目将不再接受任何由大语言模型（LLM）生成的内容，包括代码、注释和 Pull Request 描述。这一禁令立刻在开源社区引发热议，成为继 Godot、KDE 之后又一起针对 AI 生成代码的“封杀”事件。据 GamingOnLinux 报道，System76 的首席工程师 Jeremy Soller 在 Reddit 帖子中解释了决策背后的核心原因：审查团队不堪重负。

政策内容与触发原因

新规已正式写入 COSMIC 项目的贡献指南和 PR 模板。贡献者必须在提交时声明内容非 LLM 生成，否则 Pull Request 将被直接拒绝。Soller 表示：“首要原因是我们团队的审查负荷。”他指出，大量来自首次贡献者的 LLM 生成代码涌入，这些改动“常常未经规划，接受率极低”。他补充道：“我们更希望优先处理自家团队和长期贡献者的工作。”该策略模仿了先前 Godot 引擎的做法——Godot 在 2026 年 7 月也因类似问题收紧了对 AI 贡献的审核。

首席工程师 Jeremy Soller 的原话引语

“我们收到了数量远超以往的、来自首次贡献者使用 LLM 生成的更改。这些更改通常没有经过社区讨论，质量参差不齐，维护团队需要花费大量时间逐一审查，结果只有极少部分被合并。”Soller 在 Reddit 上写道。他还强调：“这项政策并不是针对个人，而是为了确保 COSMIC 项目的长期健康。我们不希望因低质量的人工智能输出稀释掉真正有价值的贡献。”这一表述与 Godot 团队此前的声明高度一致，该引擎在 2026 年 7 月的新规中同样指出，AI 生成代码导致维护者“被迫在大量垃圾内容中寻找金子”。

开源界的连锁反应：Godot、KDE 等纷纷跟进

开源项目对大语言模型的不信任并非孤例。2026 年 7 月，Godot 引擎宣布对 AI 贡献实施更严格的审查，要求贡献者标记由 LLM 辅助编写的代码。到了 9 月，KDE 团队尝试起草一份详细的 LLM 使用指南，但因内部激烈争论而未能达成共识。据 Al Jazeera 报道，KDE 开发者内部调查显示，约 73% 的受访者支持完全禁止 LLM 生成的代码，但仍有 27% 认为应有限允许。System76 的新规直接采取了最严格版本，只对 cosmic-flatpak 项目中的 Flatpak 清单文件给予例外——因为这些文件仅指向各自代码，且审查时会特别注意沙箱配置。

主要开源项目 AI 代码政策对比

从表格可见，各项目对 AI 的态度差异明显：游戏引擎和桌面环境倾向于严格限制，而安全领域则利用 AI 加快漏洞发现。Canonical 曾公开表示，2026 年 9 月以来，大量 AI 生成的安全报告促使其将 Ubuntu 内核安全更新的平均响应时间从 12 天缩短至 5 天。

社区反应与开发者观点

在 Reddit 讨论帖中，多数用户支持 System76 的决定。一位昵称 devland 的资深贡献者评论道：“大量未经验证的 LLM 代码正在腐蚀开源协作的信任基础。那些号称‘AI 自动生成’的提交，往往只是关键词堆砌，连基本语法都难以过关。”但也有声音担忧，全面禁止会阻碍新技术带来的创新。不过 Soller 亲自回应称：“我们不反对使用工具，但我们坚持所有贡献必须经过人工思考。如果某个功能真的需要 AI 来写，那么提交者至少应该先理解代码做了什么。”

Q&A 常见问题

Q1: System76 的禁令是否适用于所有 Pop!_OS 项目？

A1: 是的。根据更新后的贡献指南（CONTRIBUTING.md），任何 Pop!_OS 项目（包括 COSMIC 桌面环境及其衍生组件）的 Issue 或 Pull Request 中，均不得包含由 LLM 生成的内容。仅 cosmic-flatpak 项目的 Flatpak 清单文件因审查流程特殊而获得豁免。

Q2: 这条规定是否完全禁止开发者使用任何 AI 编程辅助工具？

A2: 不是。政策禁止的是“直接提交 LLM 生成的代码、注释或描述”，但允许开发者将 AI 作为辅助学习工具。Soller 强调：“如果你用 ChatGPT 学习某个 API，然后自己重写代码，那没问题。但你不能将 AI 生成的代码块原封不动地贴进 PR。”

System76 的禁令标志着开源社区对 AI 代码质量的警惕进一步升级。随着更多项目出台类似规则，开发者需重新思考如何平衡自动化工具与人工审核。未来，开源协作或将迎来一个“不信任 AI 默认输出”的新常态。