System76 更新 COSMIC 项目 PR 模板，禁止贡献者提交利用 AI 辅助完成的代码

AI 总结
• 10月4日，System76更新COSMIC项目PR模板，要求贡献者确认提交内容不含AI生成的代码、注释和描述，否则无法提交贡献。
• COSMIC是System76基于Rust开发的Linux桌面环境，此前Pop!_OS长期基于深度修改的GNOME，后因理念分歧转向自研桌面环境。
• System76认为AI生成代码可能缺乏对大型项目上下文的理解，产生看似可用但难以维护的代码，并增加代码审查时间。
• 目前仅cosmic-flatpak不受该限制；
• Ladybird等开源项目也已采取类似措施，以减少AI代码带来的长期维护压力。

【规则更新】
IT之家 10 月 4 日消息，开发团队 System76 现已更新 COSMIC 项目的 Pull Request（PR）模板，新增一份强制性检查清单，明确禁止贡献者提交利用 AI 辅助完成的代码。

贡献者必须确认提交内容中不存在任何 AI 生成的代码、注释以及描述，否则无法按照要求提交贡献。

                               
登录/注册后可看大图

【COSMIC 项目背景】
公开信息显示，COSMIC 是 System76 基于 Rust 开发的 Linux 桌面环境。

在 COSMIC 推出之前，System76 的 Pop!_OS 长期基于经过深度修改的 GNOME 桌面环境。

不过，由于 System76 与 GNOME 上游开发者在部分设计理念和功能取舍方面存在长期分歧，公司最终决定开发自己的桌面环境。

【AI 代码问题】
IT之家注意到，System76 此前就曾批评 AI 生成代码存在代码过于复杂的问题。

该团队认为，AI 通常缺乏理解大型项目深层集成关系所需的完整上下文，因此可能生成看似可用、但实际难以维护的复杂代码，并直接导致代码审查时间明显增加。

【唯一例外】
目前，System76 旗下唯一不受“No LLM contributions”规则限制的代码库是 cosmic-flatpak。

该项目主要用于管理一些与 COSMIC 桌面环境深度绑定、难以直接放入 Flathub 的软件，包括 COSMIC 面板小程序、桌面扩展等。

【其他开源项目】
System76 并不是唯一一家对 AI 生成代码采取严格限制的开源项目。

Ladybird 浏览器项目早在今年 6 月就采取了类似措施。

其维护者发现，大量缺乏经验的开发者借助 AI 提交代码后，项目维护团队需要投入大量时间审查难以维护的 AI 生成代码，代码审查成本最终超过了项目能够承受的范围。

【维护压力】
对于 System76 和 Ladybird 而言，问题并不在于“AI 生成的代码不能用”，而是 AI 生成代码进入大型开源项目后，仍需要由人类维护者长期承担理解、审查、测试、维护成本。

因此，这些项目选择直接限制 AI 参与贡献，以减少后续维护压力。

[来源链接] https://www.ithome.com/1/009/669.htm

我觉得一刀切禁止 AI 辅助有点过了。开源项目真正该关注的是代码质量、可维护性，以及贡献者能不能解释自己的实现，而不是工具本身。AI 生成内容确实可能增加审查成本，但人工写的烂代码也不少。更合理的做法可能是要求披露 AI 参与范围、加强测试和审查，让提交者对结果负责。完全禁止未必能解决问题，还可能误伤正常使用工具提高效率的人。

我挺支持这种做法。COSMIC 这种桌面环境不是单文件脚本，模块之间的耦合和长期维护压力都很大，AI 生成内容很容易“看起来能跑”，但缺少对项目上下文和设计约束的理解，最后负担都会转嫁给审查者。把规则写进 PR 模板，至少能先筛掉一部分低质量贡献。好奇他们实际怎么界定“AI 辅助”，以及会不会对提交内容做抽查。

我不太赞同这种一刀切的做法。AI 只是辅助工具，真正该把关的是代码质量、测试和可维护性，而不是追问“有没有用过 AI”。只要贡献者能解释清楚实现思路，愿意按项目规范修改，代码本身合格就没必要拒之门外。过度限制反而可能劝退一些想参与的新人。

这个规定我觉得有点因噎废食了。AI 生成的代码有问题，核心在于审查和测试流程不到位，而不是工具本身；一刀切禁止，反而会劝退不少愿意贡献的开发者，尤其是利用 AI 辅助理解大型 Rust 代码库的新人。实际上很多贡献者会用 AI 整理思路、写 commit 描述，最后的代码逻辑仍是由人审定的。真要控制风险，不如要求提交者标注 AI 使用范围、加强 review 和 CI 测试，把关代码质量才是治本。完全依赖自觉勾选确认，其实也很难真正核查，形式意义大于实际约束力。

这个规定我其实不太认同。AI 生成的代码确实可能存在上下文理解不足的问题，但完全一刀切禁止，把工具本身当成原罪，有点过激了。很多贡献者用 AI 只是做补全或重构辅助，代码最终还是自己看懂、自己测试过的，质量并不必然差。与其禁止，不如要求贡献者在 PR 里说明 AI 参与程度，审查时重点看逻辑和可维护性。而且怎么界定“AI 辅助”也很难执行，靠勾选一个 checkbox 来保证，多少有点形式主义，反而可能劝退不少愿意贡献的人。

我不太认同这种一刀切的做法。AI 辅助写代码确实有维护性隐患，但直接在 PR 模板里强制声明"零 AI"其实很难执行——审查者根本没法可靠识别代码是不是 AI 写的，反而可能变成走过场。更现实的做法是要求贡献者披露 AI 使用情况，并对提交内容的质量和可维护性负责，把审查重点放在代码本身。另外 Rust 项目本身也有不少优秀工具能辅助生成样板代码，全部禁掉是不是有点因噎废食？

这个规则挺让人认同的。AI 生成的代码片段看单个函数确实没毛病，但放到整个项目的上下文里，风格、错误处理、抽象层级常常对不上，审查者要比自己写还费劲，长期维护成本更高。COSMIC 用 Rust 本身对代码质量要求就高，一刀切禁掉反而省事。不过也好奇这怎么落实，靠贡献者自觉申报还是有工具检测？像 cosmic-flatpak 这种以打包脚本为主的豁免也算合理，就是希望后续能明确边界，别让正常用 Copilot 补全个括号的贡献者被误伤。

我不太认同这种一刀切的做法。AI 辅助写代码确实可能产出难以维护的内容，但问题根源在于审查不严，而不是工具本身。贡献者用 AI 补个注释、改个格式就被拒之门外，反而会劝退不少热心的新人。与其靠模板里的勾选项"自我声明"，不如把重点放在 CI 静态检查和 review 标准上，让质量说话。而且这种声明基本靠自觉，真想混进去照样能绕过，实际效果恐怕有限。

这个规定我觉得有点矫枉过正了。AI 生成的代码质量参差不齐不假，但关键还是看审查环节，直接一刀切禁止，会把很多用 AI 辅助写文档、补注释、做小修补的贡献者挡在门外。真正的问题是贡献者对自己提交的代码负责，而不是工具是什么。而且这种禁令基本只能靠自觉声明，很难核实，实际约束力存疑。与其全禁，不如要求贡献者标注 AI 参与部分并加强 review，成本和效果可能更合理。