~/yomxxx/posts/2026-10-04-cosmic-bans-ai-generated-code-maintainer-economics-long-form.mdx
Long-form

$ cat COSMIC 禁止 AI 生成代码:评审带宽成稀缺资源之后

-- 5 min read ·

10 月 2 日,System76 的 COSMIC 桌面环境——Pop!_OS 背后那个用 Rust 写成的新一代桌面——更新了它的 PR 模板,加入了一条在开源世界引发热议的强制声明:贡献者必须证明自己没有在提交中包含任何 LLM 生成的内容,包括代码、注释和描述。这条新闻在 Hacker News 上迅速拿下近百分,但比起「又一个项目反 AI」的表面解读,它真正值得写下来的是另一件事:开源维护者经济学正在被迫公开定价。

禁令的原文与执行方式

先看规则本身。除 cosmic-flatpak 等由上游项目自管清单的例外,任何向 COSMIC 提交 PR 的人都要在模板里确认一组声明:未包含任何 LLM 生成的代码、注释与描述;完全理解这些改动,并能回应评审意见;提交信息准确描述了变更;贡献经过测试且按描述工作;阅读并接受开发者来源证书 DCO 的条件。

注意这组声明的设计:AI 禁令不是孤立的一条,而是和「理解改动」「能回应评审」「提交信息准确」「改动已测试」捆在一起。换句话说,COSMIC 把「你提交的东西你负责」这条古老的开源礼仪重新显式化了,AI 只是这条礼仪最新、也最容易被打破的试探者。

理由:维护者被淹了

System76 的 Jeremy Soller 给出的理由毫不掩饰:LLM 提交的代码与文档让维护者不堪重负。更微妙的观察是后半句——AI 让许多首次贡献者得以在 COSMIC 上「留下印记」,但这些提交是未经规划的、极少被接受的。

这句话值得展开。AI 没有降低「写代码」的门槛的同时,也没有降低「写出值得合并的代码」的门槛。恰恰相反:能生成看起来体面的 PR 的工具,让大量并不理解项目规划、也不理解代码本身的贡献涌向评审队列。每个被拒绝的 PR 都要消耗真实的维护者时间去读、去解释拒绝理由。当拒绝成本高于接受成本时,项目只能选择在入口处设闸。

同类困境的三种解法

COSMIC 不是孤例。Linux 内核社区同样被 AI 提交冲击,但选择了另一种路线:不禁止,只要质量达标就接受——代价是部分维护者公开表达倦怠。Ubuntu 的困境略有不同:涌入的不是代码而是 AI 发现的缺陷报告,海量低质量报告迫使 Canonical 加快内核更新节奏,用流程提速来消化。

三种路线对应三种资源结构。内核有充足的评审人力储备,可以承受质量筛选;Ubuntu 的问题在报告侧,用自动化与节奏调整对冲;COSMIC 是一个相对精干的团队在写一个大型 Rust 桌面环境,评审带宽最紧张,于是选择了最保守的入口管制。没有哪条路线是普适答案,但三条路线共同确认了一件事:瓶颈不在生产侧。

真正的问题:验证成本没有跟着下降

把镜头拉远,这是 AI 时代反复出现的成本剪刀差在开源场景的投影。生成一段代码的成本趋近于零,但验证这段代码是否正确、是否合乎项目规划、是否值得长期维护的成本几乎没变——它仍然由有经验的工程师的时间构成,而这个时间是刚性的。

商业软件可以用 CI、测试覆盖率、代码所有者评审流程来部分自动化验证,开源项目只有志愿者的注意力。当外部环境突然把生成成本打到地板,注意力就成了硬通货。COSMIC 的声明本质上是一种准入定价:想占用我们的评审带宽,请先证明你带来的不是噪声。

对 AI 辅助开发者的三个实际建议

第一,把 AI 当草稿工具,别当投稿工具。自己机器上用 AI 理解代码、找线索、生成初稿都没问题,COSMIC 也没有禁止非生成式的 AI 用途。红线在于:提交的东西必须完全理解、能独立回应评审追问。如果一段 diff 你解释不了,无论它是不是 AI 写的,都不该进 PR。第二,主动披露与政策优先。这个生态正在快速分化:有的项目欢迎 AI 贡献,有的要求披露,有的像 COSMIC 一样禁止。投稿前花一分钟读贡献指南,比自己想象政策宽容度便宜得多。

第三,为评审者省时间。准确的提交信息、最小化 diff、附上测试结果——这些老建议在 AI 时代反而更值钱,因为它们直接对冲了维护者对「AI 噪声」的戒心。当维护者无法分辨谁是认真贡献者时,你的提交质量就是唯一的信号。

还有一个容易被忽略的细节:COSMIC 把 AI 声明与开发者来源证书 DCO 捆绑在同一个清单里。DCO 的本质是贡献者以个人信誉为提交的来源与权利背书,而 AI 提交恰恰瓦解了「来源可追溯」这个前提——生成内容的真实作者既不是署名者,也无法为设计决策负责。从这个角度看,COSMIC 的禁令不是新技术保守主义,而是对开源治理既有契约的一次重申:提交权与责任必须落在同一个可追责的人身上。这个原则在纯人类协作时代是默认成立的,AI 只是让它第一次需要被写下来。

结语

COSMIC 的禁令会被争论,也可能会被效仿或修正,但它标志着一个转折:开源社区开始不再羞于把「我们的注意力有限」说出口。过去几个月我们看到智能体越来越能干,也在同一周看到一篇论文指出多智能体协作会留下被污染的共享状态,看到一个工作台产品专门给编码智能体做隔离与评审。三条新闻拼在一起,指向同一个判断——AI 时代的稀缺资源不是生成能力,而是验证与信任。谁先围绕这个稀缺性重新设计流程,谁就先受益。

Frequently asked questions

COSMIC 的禁令具体覆盖什么?
除 cosmic-flatpak 等上游自管清单的例外项目外,所有向 COSMIC 提交的 PR 都要求贡献者勾选声明:未包含任何 LLM 生成的代码、注释与描述,完全理解改动并能回应评审意见,提交信息准确描述变更,且改动经过测试。禁令覆盖 PR 的全部文本内容。
禁令是否意味着不能用 AI 辅助开发?
不是。COSMIC 并未严格禁止非生成式的 AI 用途,比如用 AI 找缺陷。它禁止的是把 LLM 生成的内容直接作为贡献提交。在自己机器上用 AI 理解代码、定位问题,然后自己动手写补丁,仍然在规则允许的范围内。
Linux 内核和 Ubuntu 是怎么应对的?
两者都没禁止 AI 内容,而是设置质量门槛:内核社区同样被 AI 提交困扰但选择接受高质量 AI 代码;Ubuntu 则因为收到海量 AI 发现的缺陷报告而被迫加快内核更新节奏,用流程提速消化涌入量。COSMIC 是主流项目里最早 outright 禁止的之一。
为什么评审带宽突然不够用了?
AI 把生成代码的成本压到接近零,但验证代码的成本没有下降,评审仍靠人类维护者的空闲时间。生产与验证的成本剪刀差导致提交量暴涨而消化能力不变,队列积压、维护者倦怠。COSMIC 的声明本质上是给这条稀缺资源设准入门槛。
AI 辅助开发者该怎么自处?
把 AI 当草稿工具而非投稿工具:理解每一行改动,确保能独立回应评审追问;提交前自己跑测试、写准确的提交信息;尊重目标项目的 AI 政策,有的放矢。真正稀缺的不是产出能力而是信任,能对改动负全责的贡献者永远受欢迎。
// next.txt ›

Some outbound links in this post are affiliate links — see disclosure.