Canonical 副总裁 Jon Seager 在博客中写道：“整个 2026 年，我们将努力以审慎、安全，并符合开源价值观的方式，让 Ubuntu 用户接触前沿 AI。”

具体怎么落地？Ubuntu 的 AI 策略明确聚焦于本地推理——所有模型运行均在设备端完成，不依赖云端服务。用户可以通过 Inference Snaps 一键安装针对当前硬件优化过的本地模型，系统会自动检测硬件并安装对应的 NVIDIA CUDA 或 AMD ROCm 驱动。

在 Ubuntu官方文档中，甚至还出现了利用 Agent 协助创建 Inference Snap 的实验性流程：开发者准备模型和配置文件后，可以让 LLM Agent 参与打包，并在最终提交 Pull Request 前进行人工确认。

换句话说，Ubuntu 的思路越来越像是：AI 会成为软件生态的一部分，与其挡在门外，不如想办法让它以更规范的方式进入系统。

Debian 却准备设一道门槛

然而，就在 Ubuntu 大步迈向 AI 的同时，它的上游 Debian，现在讨论的问题却正好站在另一端。

Debian 最近正式发起了一项题为「Ban LLM contributions from Debian」的 General Resolution（全体决议）讨论。虽然共有八项不同的提案，但目前主要讨论的是前两种方案：

● 提案 A：移除所有 AI 生成的代码，包括 AI 辅助生成的代码；

● 提案 B：允许使用 AI 生成代码，但需要满足一定条件。

其中，提案 A 的态度相当鲜明，由 Matthias Geiger 牵头。该提案认为，Debian 一直以来都以稳定性著称，这也是 Debian 能在自由软件生态中占据重要地位的关键：

“Debian 长期以来建立了稳定可靠的声誉，而这种稳定性对于 Debian 在自由软件生态系统中的地位至关重要。我们认为，LLM 的广泛使

用源于一种‘快速行动，即使打破一切’的理念。虽然这种理念在行业的许多领域十分常见，但它与 Debian 的核心价值相违背，因此并不适合 Debian 的贡献者。”

除此之外，提案 A 还列出了 AI 生成代码的四大弊病：

第一，版权问题。 LLM 输出代码的“法律状态不明确”，而 Debian 更倾向于接受版权条款清晰的代码。人工编写的代码如果版权归属模糊，照样会被拒之门外，LLM 生成的代码没理由例外。

第二，代码质量问题。“LLM 永远无法‘知道’自己的输出是否正确，因为它只是拼凑出训练数据中在语法上最可能的组合”——这种水平应付日常场景“倒也够用”，但“放在 Debian 里，不行”。提案 A还称，AI 跟不上 Debian 不断更新的规范指南，只会依赖那些过时的陈旧代码库。

第三，社区问题。 提案 A 强调 Debian 极其重视社区协作，而“新贡献者提交 LLM 生成的代码供审核，会给审阅者带来不必要的负担”，同时也没能让提交者真正理解 Debian 的工作流程和编码规范。

第四，伦理问题。提案 A 指责 LLM 公司在训练数据采集上“毫无道德底线”——“无视许可证、版权，甚至连 robots.txt 这类公认的惯例都不管”。提案中还提到，过去曾有自动化爬虫行为意外对 Debian 服务器造成 DDoS 攻击，同时也提到了数据中心带来的环境影响。

因此，提案 A 的立场并不是简单地认为「AI 写的代码质量不好」，而是进一步质疑整个 LLM 产业链的训练方式、资源消耗以及自动化系统可能带来的外部影响。

相比之下，提案 B 的态度要温和许多，由前Debian项目负责人Lucas Nussbaum提交。从目前的内容来看，它与 Linux 内核社区对于 AI 生成代码的处理方式比较接近：AI 可以参与编程，但最终责任必须由人类承担。

按照提案 B 的要求，如果开发者提交了 AI 生成或 AI 辅助生成的代码，那么至少需要满足几个条件：

（1）提交者必须对代码承担全部责任；

（2）确保提交的代码不存在版权问题；

（3）明确披露在开发过程中是否使用了 LLM。

也就是说，提案 B 并不阻止开发者使用 AI，而是希望建立一套明确的责任机制。

AI 可以作为工具存在，但不能成为无人负责的代码来源。如果最终出现 Bug、版权纠纷或其他问题，不能简单地用一句「这是 AI 写的」来推卸责任。提交AI 代码的人，需要像提交自己亲手编写的代码一样，对代码的正确性、安全性和合法性负责。

根据 Debian 官方消息，这场投票将于 8 月 28 日截止。不过有一点要注意：“提案 A 需要 3:1 的赞成票才能通过，而其他提案则只需