Debian 的 AI 岔路口：禁止 LLM 代码，还是给它们戴上镣铐？

目录

• 两条几乎同时发生的对话
• Debian 的岔路口：禁止，还是监管？
• Choice 1：「LLM 代码与 Debian 的稳定性背道而驰」
• Choice 2：「允许，但每一个字都要有人负责」
• 「软件都变烂了，但每个人都很兴奋」
• 银行 App 三次 FaceID，Slack 抢走 git pull，车载系统越修越糟
• 现场验证：这台服务器跑的是哪个 Debian？
• 所以，AI 代码的质量问题，和 Debian 的选择是同一个问题

---

两条几乎同时发生的对话

7 月 24 日，两个完全无关的讨论几乎同时开始。

一个在 Debian 邮件列表里。Debian 开发者们发起了两套竞争性的 General Resolution 提案，核心问题只有一个：LLM 生成的代码，还能不能进 Debian？

另一个在 Hacker News 上。一篇题为「Nothing Works and Everyone Is Euphoric」的博客获得了 337 分。作者抱怨他的银行 App 要三次 FaceID 才能付款，Slack 在后台抢走了他正在输入的 git pull 命令发到了群聊里，他的车载系统更新后转向灯声音随机消失。

两条线索，同一根绳。AI 让代码写得更快了，但软件——我们每天用的软件——正在变烂。

Debian 的岔路口：禁止，还是监管？

Debian 的 General Resolution 流程不是日常发生的。当一个争议大到邮件列表无法消化，开发者们才会启动 GR。上一次 GR 涉及非自由固件，那一次改变了 Debian 的发行版哲学。

这一次，是关于 LLM 生成的代码。

两套提案同时提交，这是 Debian 的「竞争性 GR」机制——不是先选一个方向再投票，而是把两个方向同时摆在桌面上，让社区选择。

Choice 1：「LLM 代码与 Debian 的稳定性背道而驰」

提案 A 由 Matthias Geiger 发起，七位开发者附议。核心诉求很明确：禁止任何使用 LLM 或其他生成式 AI 工具辅助编写的贡献进入 Debian。

范围覆盖 Debian 源码包、官方项目软件（如 lintian）、Web 资源、文档和翻译、以及官方通信。但不包括上游项目使用 LLM 开发、AI 相关软件、以及上游补丁和安全修复。

提案的 rationale 写得非常干脆：

Debian 有一个来之不易的稳定声誉。这种稳定性是 Debian 在自由软件生态中立足的关键。我们认为，LLM 的广泛使用来自「快速迭代，不怕打破东西」的态度——这种态度在行业很多地方很常见，但恰恰与 Debian 的本质背道而驰。

然后列出了几个具体问题：

• 版权不明：LLM 输出的法律地位不清楚——能不能版权化？训练数据中的许可证是否影响输出？Debian 的 DFSG 要求绝对清晰的版权和许可证信息，LLM 输出做不到这一点。
• 质量风险：LLM 生成看似合理但实际错误的代码。在 Debian 这种以稳定著称的发行版中，这种风险不可接受。
• 维护负担：没人能完全理解 LLM 生成的全部代码，但维护者需要对每一行代码负责。

Choice 2：「允许，但每一个字都要有人负责」

提案 B 采取了不同的路线。它承认 LLM 带来的所有担忧——版权、质量、环境影响、数据合规——但认为直接禁止是不现实的。

许多 Debian 贡献者发现 AI 工具在贡献 Debian 时很有帮助，最终目标是改善 Debian。

所以提案 B 选择了一条中间道路：允许 AI 辅助贡献，但需要满足六个条件。

1. 工具合规性：确保 AI 工具的条款不限制输出在 Debian 中的分发
2. 许可证和归属：如果输出包含第三方版权材料，贡献者需要确认有权以开源许可证提交
3. 责任归属：贡献者对自己的贡献承担全部责任——技术质量、安全、许可证合规
4. 披露义务：当贡献的「重要部分」由 AI 生成或辅助时，必须披露。建议用 Git trailer 如 Generated-By: 或 Assisted-By:
5. 批量变更事先讨论：类似 mass-bug filing 流程，贡献者需要先讨论意图
6. 保密和隐私：不能将非公开信息（比如 embargo 安全报告）传给不可信的 AI 服务

本质上，提案 B 说的是：AI 可以写，但人必须读、必须懂、必须负责。

「软件都变烂了，但每个人都很兴奋」

两天前，一篇博客在 HN 上获得了 337 分。作者列出了他上周遇到的几个问题：

• 银行 App 平均需要三次 FaceID 才能弹出 3D Secure 验证界面
• 打开 Slack，图标在 Dock 弹跳了几秒，他没耐心，切换到 Ghostty 开始打字。结果 Slack 窗口这时弹出来，抢走了焦点，他正在输入的 git pull 命令被发到了群聊
• LG 冰箱发出怪声，他想提交保修 claim，填写了无数字段的表格在最后一步提交失败——他看了一眼 JavaScript 控制台才发现
• 车载系统更新后，转向灯提示音随机消失，点屏幕想打开 Google Maps 却弹出收音机

作者说了一句很到位的话：

我无法知道全部故事，但我敢打赌这些团队中的大多数都能访问最新的模型，并且有慷慨的 token 预算。LLM 如果给机会，真的很擅长修 bug。

但 bug 并没有被修。因为修 bug 不是一个「能不能」的问题，是一个「想不想」的问题。

软件厂商一直是 KPI 导向的，让东西更稳定并不总是直接影响数字。在演示中不够好看：「本季度我们不会发布任何新功能，也没有计划重新设计任何东西——我们将专注于修复 bug。」

银行 App 三次 FaceID，Slack 抢走 git pull，车载系统越修越糟

这些例子放在一起，能看出更深的模式。

不是 AI 写不出好代码。Claude 和 GPT-4 能写出的代码质量，在大多数情况下已经超过 Junior 甚至 Mid-level 工程师。问题是：

AI 写代码的速度，让「写更多代码」比「写更好的代码」在 KPI 上更划算。

银行 App 的 3D Secure 需要三次 FaceID——这不是写不出来一次通过的代码，这是没人觉得需要修。Slack 抢焦点——这不是技术难题，这是优先级不够。车载系统越更新越糟——这不是能力问题，是 PM 的 KPI 里没有「用户满意」。

AI 在这套体系里扮演的角色不是修理工，而是加速器。它让公司能在更短的时间内推出更多功能，堆更多的复杂度。但加速器不改变方向——如果方向是「更多功能，更快交付」，AI 只是让这个方向更有效。

现场验证：这台服务器跑的是哪个 Debian？

Debian 的 GR 讨论的是「Debian 自己要不要用 LLM 写代码」，但这个问题的辐射范围比 Debian 本身大得多。

这台服务器上跑的是 Ubuntu 22.04（基于 Debian testing/Sid），我查了一下：

bookworm/sid

我的整个博客栈——Nuxt 4、SQLite、Nginx——都跑在 Debian 系的发行版上。如果 Debian 的维护者开始用 LLM 写包，或者如果 Debian 因 LLM 代码引入的质量问题需要更多维护，这两个方向都会直接影响我。

但更直接的问题是：在这台服务器上，我写的代码有多少用了 AI 辅助？

答案很尴尬：我在写这篇文章的时候，就在用 AI 整理素材、组织结构、校验事实。Debian 提案 B 的第六条（保密和隐私）我确实遵守了——没有把服务器信息传给外部 API。但第四条（披露义务）——坦白说，我没有在每篇博客文章里加 Assisted-By:。

这不是狡辩。Debian 的 GR 指向的问题适用于所有写代码的人：当 AI 成为你工作流的一部分，你的责任边界在哪里？

所以，AI 代码的质量问题，和 Debian 的选择是同一个问题

Debian 在讨论「要不要禁止 LLM 代码进入发行版」，HN 那篇博客在问「为什么代码变多了，软件却变烂了」。两个问题看似不同，但指向同一个焦虑：

我们正在生产比以往任何时候都多的代码，但我们对这些代码的理解和信任却在下降。

Debian 的 Choice 1 是对这种焦虑的防御性回应：既然搞不清楚 LLM 代码的版权和质量，那就直接不要。Choice 2 是一种务实回应：既然挡不住，就定规则。

「Nothing Works」博客的作者给出了第三种可能性：当公司集体陷入 AI 债务，个人开发者反而有机会用 AI 做出真正的好软件——因为大公司不在乎修 bug，但你在乎。

我不确定这三种路径哪个是对的。Debian 的投票还没结束，行业对 AI 代码质量的态度也还在变化。但有一件事是确定的：

AI 不是让代码变烂的原因。让代码变烂的，是那个用 AI 写了更多代码却不再检查的人。