Debian 一刀切、Ubuntu 拥抱、Linux 内核追责——Linux 世界正在被 AI 代码撕成三条路

Debian 一刀切、Ubuntu 拥抱、Linux 内核追责——Linux 世界正在被 AI 代码撕成三条路

2026 年 8 月 28 日，开源世界的同一个根系上长出了三种完全不同的治理路线。

这一天，Debian 项目 General Resolution 投票「Ban LLM contributions from Debian」正式截止——八项提案里，主战场是前两条：提案 A 一刀切移除所有 AI 生成的代码（包括 AI 辅助生成的代码），提案 B 允许使用 AI 但必须满足「提交者对代码承担全部责任 / 代码无版权问题 / 明确披露是否使用 LLM」三条。

同一天，Canonical（Ubuntu 背后的公司）走相反方向——Ubuntu 26.04 LTS 的 AI 转型战略明确表示「让 AI 以审慎、安全、符合开源价值观的方式融入系统」，Inference Snaps 让用户两条命令就在本地跑起大模型，官方文档甚至出现了让 LLM Agent 协助打包、人工 PR 确认的实验流程。

再往前推 4 个月，Linux 内核社区已经走过这条路：Linus Torvalds 2026 年 4 月 13 日拍板，允许 AI 代码进入内核，但出了事责任归人。

同一个 Linux 根系，三种完全不同的治理路线。 这不是谁对谁错的问题，是开源社区对「代码贡献」这件事的定义正在被 AI 撕裂。

配图位置 1（图床本时段 OSS 不可用，已预留位置）：三大治理路线象限图（横轴=AI 代码准入度 / 纵轴=披露严格度），六个社区样本分布见前文论证。

Debian 一刀切：不只是嫌代码质量差

提案 A 由 Matthias Geiger 牵头，态度相当鲜明。但它列出的「AI 代码四大弊病」里，第一条就超出了纯技术范畴：

版权问题：LLM 输出代码的「法律状态不明确」，Debian 倾向于接受版权条款清晰的代码。人工写的代码版权模糊照样被拒，LLM 生成的代码没理由例外。

代码质量问题：「LLM 永远无法『知道』自己的输出是否正确，因为它只是拼凑出训练数据中在语法上最可能的组合」——这种水平应付日常场景「倒也够用」，但「放在 Debian 里，不行」。

社区问题：Debian 极其重视社区协作，「新贡献者提交 LLM 生成的代码供审核，会给审阅者带来不必要的负担」，同时也没让提交者真正理解 Debian 的工作流程。

伦理问题：这一条最关键。提案 A 指责 LLM 公司在训练数据采集上「毫无道德底线」——「无视许可证、版权，甚至连 robot.txt 这类公认的惯例都不管」。还提到过去自动化爬虫曾对 Debian 服务器造成 DDoS 攻击，以及数据中心带来的环境影响。

所以提案 A 的真实立场不是「AI 代码质量不好」本身——它质疑的是整个 LLM 产业链的训练方式、资源消耗、以及自动化系统的外部性影响。这是个治理哲学问题，不是工程标准问题。

但 Debian 给提案 A 设的门槛相当高——需要 3:1 赞成票才能通过，其他提案简单多数即可。这反而让提案 A 成了「最不可能获胜的选项」。Debian 心里清楚一刀切不现实，但这场投票本身就是一种表态：开源世界对 AI 代码的疑虑不是个别项目的情绪。

Linux 内核：披露 + 追责，AI 是工具责任归人

Debian 提案 B 由前 Debian 项目负责人 Lucas Nussbaum 提交，态度温和得多。它的核心条款是：