COSMIC桌面全面封禁AI生成代码：维护者过载还是开源身份危机

2026年10月，System76旗下的COSMIC桌面项目更新了贡献规则，在拉取请求模板中新增强制声明清单，要求所有贡献者承诺：未在本次PR中包含任何LLM生成的内容，包括代码、注释和PR描述本身。这一禁令几乎覆盖整个代码库，仅cosmic-flatpak因上游项目自行管理清单而获豁免。

COSMIC是Pop!_OS操作系统背后的下一代桌面环境，由System76以Rust语言从头构建，目前正处于密集开发阶段。该项目的贡献者协议要求勾选以下每一条：未使用LLM生成任何内容；完整理解所提交的改动并能回应代码审查意见；提交说明准确描述改动；改动已经过测试；已阅读并遵守开发者来源证明的所有条款。

维护者过载：禁令背后的直接触发点

System76首席工程师Jeremy Soller在解释这一决定时，直指一个现实困境：LLM工具的普及让大量此前从未参与过项目的贡献者涌入，但他们提交的内容“计划外且鲜被接受”。问题不在于这些提交质量有多差，而在于每一条PR无论质量如何，都需要维护者花时间审阅、测试和回复——当提交量大幅增加而接受率偏低时，维护者承受的边际负担会急剧上升。

这一困境并非COSMIC独有。Linux内核维护者同样反映被AI辅助提交淹没，Ubuntu也因涌入的问题报告数量加快了更新节奏以处理积压。差别在于，Linux和Ubuntu选择了“有条件接受”——只要质量达标就允许AI生成内容通过审查；COSMIC则选择了直接封堵入口。

COSMIC的禁令并非针对AI工具本身，而是针对“生成型”用途。使用AI辅助查找缺陷、理解代码等非生成性场景并不在禁止范围之内。这一区分说明System76试图封堵的是“AI替人写代码然后提交”这一特定行为，而不是全面排斥AI工具。

法律层面的深层隐患：DCO能否覆盖AI生成代码

维护者负担是表面原因，但开源社区讨论这个问题时始终绕不开一个更根本的法律疑问：开发者来源证明是否能合法地适用于AI生成代码？

DCO要求贡献者签名并证明：自己有权在项目许可证下提交该代码，且该代码来源清晰。问题在于，主流大语言模型均使用海量开源代码训练，这些训练数据涵盖GPL等限制性许可证约束下的代码。当一名开发者让AI生成一段代码后提交，他实际上无法追溯这段代码的真实来源，也就无法诚实地完成DCO签名所要求的权属声明。

Red Hat在一份分析中指出，DCO历来不要求每一行代码都是贡献者本人的创作表达，但多位法律观点持有者认为，对于来源根本无法追溯的AI输出，签署DCO存在诚信风险。NetBSD项目更以“版权污染”为由，早于COSMIC封禁了AI生成的提交——其维护者认为，训练数据的授权状态不透明使得AI输出从法律意义上属于“来源不明”的内容。

开源生态的路线分裂

COSMIC的选择让开源社区内部的分歧更加清晰。从已有报道来看，当前Linux生态在AI政策上已形成两个明显阵营。

一侧是明确封禁的项目群：aerynOS明确禁止“ChatGPT、Claude和Copilot等概率性工具生成的内容”；Chimera Linux规定“被发现使用LLM的贡献者将被永久禁止参与项目”；Elementary OS不允许“LLM和聊天机器人生成的贡献”；Gentoo封禁了“自然语言处理AI工具辅助创建的任何内容”；Nura禁止“部分或全部由生成式AI创建的贡献”；secureblue则规定“任何形式的AI生成代码或内容均属禁止”。

另一侧是以Linux内核为代表的务实路线。Linux内核已于2026年建立正式的AI辅助代码政策，核心机制是引入新的“Assisted-by”标签——AI辅助的代码不能使用具有法律约束力的“Signed-off-by”标签，而须改用“Assisted-by”标注，并将所有责任明确压在提交该代码的人类开发者身上。这一政策的形成经历了数月激烈争论：Intel的Dave Hansen和Oracle的Lorenzo Stoakes曾公开交锋，Linus Torvalds最终以一贯直白的风格结束争论，称针对AI的全面封禁是“毫无意义的姿态表演”，并将AI定位为“又一种工具”——坏人提交垃圾代码本来就不会读规则，关键是让人类开发者为自己的提交承担后果。

这两种路线背后的逻辑差异值得细究。Linux内核的方案将问题重新定义为“问责制”问题：AI用还是不用不重要，重要的是人要为代码质量负责。COSMIC的方案则将问题定义为“运营成本”问题：无论AI代码质量如何，筛选成本本身就是不可接受的负担，因此从源头截断比审查更经济。两种答案都有内在自洽之处，但适用前提不同——Linux内核有数十年积累的高门槛审查文化和庞大维护者队伍，COSMIC是一个仍在快速构建期的相对小型项目。

对不同利益相关方意味着什么

对于希望参与COSMIC贡献的个人开发者，这一规则意味着他们必须在提交前对所有代码来源保持清醒认知。那些习惯使用AI辅助“快速上手”开源项目的开发者，将面临更高的入场门槛。这会筛掉那些对项目本身了解浅薄、主要依赖AI生成提交的贡献者，而这恰恰是System76希望达到的效果。

对于企业用户和组织贡献者，情况则更为复杂。越来越多的公司已将AI辅助编程工具深度集成进开发流程，要求员工在向特定开源项目贡献时“手动关掉”这些工具，在执行层面存在一定模糊性。贡献者如何证明自己的代码完全未经AI生成，目前并没有可靠的技术手段——禁令在本质上依赖社区的诚信自律，而非技术强制。

对于开源生态的整体竞争格局，这一分裂意味着在选择参与项目时，开发者将面临一个新的维度：这个项目的AI政策是什么？封禁派和开放派项目可能逐渐形成不同的贡献者社区风格，进而影响各自的开发速度和代码风格。