2026年7月24日，Debian 项目正式进入一项 General Resolution 的讨论期。议题直指这个时代最尖锐的冲突之一：LLM 生成的代码，能不能进入 Debian？
这不是 Debian 第一次讨论这个问题。五个月前，前任项目领导人 Lucas Nussbaum 提出过一份允许 AI 辅助贡献的决议草案，经过数周邮件列表的激烈辩论，社区最终选择了“不决定”——继续按现有政策逐案处理。但这一次，战火重新燃起，而且战线更加清晰：一份提案要彻底封杀，另一份提案要谨慎开放。两股力量在同一个社区内正面碰撞，没有任何中间地带可以躲藏。
Debian 不是第一个面对这个问题的开源项目，也不会是最后一个。但作为全球最具影响力的自由软件发行版之一，它的选择将在整个开源生态中产生连锁反应。然而，在笔者看来，这场辩论的真正意义不在于“谁赢了”，而在于它暴露了一个更深层的结构性矛盾：一个靠共识驱动的志愿者社区，有没有能力回应一种不可检测、不可强制、不可定义的技术变革？
两条道路，一种分裂
本次 GR 的两份提案，代表了开源世界对 AI 代码的两种截然不同的态度。
提案 A 由 Matthias Geiger 提出，态度明确而强硬：全面禁止任何使用 LLM 或其他生成式 AI 工具贡献的代码进入 Debian。覆盖范围包括 Debian 源码包、官方项目软件、Web 资源、文档和翻译、官方通信。唯一豁免的是个人使用和不涉及 Debian 项目本身的第三方内容。
Geiger 在提案序言中写道：“本提案旨在明确禁止任何使用 LLM 或其他生成式 AI 工具撰写或辅助撰写的贡献进入 Debian。”这不是建议，不是指南，而是一条红线。
提案 B 则由 Simon Josefsson 提出，走了一条完全不同的路线。它不禁止 AI 辅助贡献，而是设定了六项条件：工具合法合规、贡献者承担责任、透明披露、事先讨论批量变更、保护机密信息。核心逻辑是“透明而非禁止”——如果你用了 AI 工具，说清楚就行，在 Git 提交信息里加一个 Generated-By: 或 Assisted-By: 标签就够了。
两条路看似都有道理。但问题在于，它们同时出现在同一个社区里，而 Debian 的决策机制要求投票选出一个胜者。这意味着，无论结果如何，都有一部分核心开发者会感到被忽视。
为什么 Debian 无法“决定”？
要理解这场僵局，必须回到 Debian 的决策基因。
Debian 是一个以 Debian 社会契约为宪章、以共识为运作方式的志愿者社区。它没有 CEO，没有 CTO，没有可以拍板说“就这么干”的权威。任何重大决策都需要通过 General Resolution——一种耗时数周、动员全社区的投票机制——来达成。
但投票的前提是共识。而 Debian 社区在 AI 问题上，恰恰不存在共识。
2026年2月至3月的第一次大辩论已经清晰地揭示了这一点。根据 LWN 的详细报道，社区分裂成了三个无法调和的阵营。
版权派以 Charles Plessy 为代表，将商业 AI 工具称为“版权洗钱机器”——它们吸收自由软件社区积累的代码能量，再将其转移到专有作品中。Plessy 表示他会投票反对在 Debian 中使用商业 AI，但不会反对基于合法数据训练的生成式 AI。
务实派以 Ansgar Burchardt 为代表，认为 AI 不过是“另一种工具”，和编译器、代码检查器没有本质区别。Russ Allbery 则指出 Gentoo 的 AI 禁令实质上“无法执行”，与其制定无法执行的政策，不如采取反应式的个案处理。
中间派以 Sean Whitton 为代表，提出需要区分 LLM 的不同使用场景。用 AI 做代码审查，和用 AI 生成生产代码，是两件完全不同的事。把所有这些混在一个“AI 政策”里，本身就是一种误导。他敦促 Nussbaum“不要试图在一个比 LLM 更宽泛的概念上争论得太用力，因为这可能会疏远你想与之求同存异的人。”
这三种立场之间没有交汇点。当一方看到的是版权侵权，另一方看到的是工具效率，第三方认为问题本身就被问错了，你不可能通过投票找到一个让所有人都满意的答案。
你无法阻止你无法检测的东西
但更深层的问题在于：即使 Debian 通过了禁令，它能执行吗？
答案是：不能。
Gentoo 在 2024 年 4 月 14 日就禁止了 AI 贡献。但 Gentoo 委员会成员 Michał Górny 自己也承认，这项政策的真正目的是“明确什么可以接受、什么不可以，然后礼貌地请贡献者尊重这一点”。禁令的执行完全靠自觉。
你无法可靠地检测 AI 生成的代码。GPTZero 这类工具在自然语言文本上都不够可靠，在代码上更是几乎无效，尤其是经过人工修改后的代码。QEMU 的 AI 禁令也只能在“已知或怀疑”AI 参与时才拒绝贡献，这意味着要么有人主动承认，要么留下了明显的痕迹。
2026年2月，Gentoo 迁移到 Codeberg 平台，部分原因正是 GitHub 的 Copilot 提示让他们感到“像在推销他们禁止的工具”。当平台本身就在鼓励 AI 使用，你再怎么禁止也没有用。
Debian 的“逐案处理”策略，在某种意义上比那些无法执行的禁令更诚实。
亚马逊能做的，Debian 做不到
2026年3月5日，亚马逊的电商网站因 AI 辅助代码变更导致了一次大规模中断。根据内部文件，北美市场订单量一度下降 99%，损失约 630 万笔订单。亚马逊随后启动了一项为期 90 天的“代码安全重置”，覆盖 335 个关键零售系统，并强制要求所有 AI 辅助的代码变更必须经过高级工程师审批。
约束力截然不同。亚马逊可以控制工作流闸门、CI/CD 管道和代码审查系统。高级工程师审批成了一个技术执行点，而不仅仅是政策条文。违反规则的人可能被解雇。
Debian 没有这样的手段。你不能开除一个志愿者。你只能拒绝他们的补丁，但前提是你得先发现那是 AI 写的。
这个差距不是“开源不如商业”那么简单，而是两种治理模式的根本差异。企业用层级结构解决分歧，开源社区只能用共识。当价值观出现分歧时，层级结构可以通过命令来统一行动，而共识模式只能不断讨论直到达成一致，或者像 Debian 二月份那样，选择不讨论。
法理困境：DCO 和 AI 之间的裂缝
更深层的冲突，藏在法律层面。
许多核心开源项目使用开发者原创证书（Developer Certificate of Origin, DCO）。贡献者必须声明“我创作了这项工作”或“我有权提交这项工作”。但 AI 输出的版权状态在法律上仍然悬而未决。
QEMU 在 2025 年 6 月禁止 AI 贡献，正是因为“在许多司法管辖区，AI 生成的代码不被视为受版权保护的作品。因此，在法律上很难证明存在人类作者。”如果有人说你的 AI 输出侵犯了他们的代码，你无法证明“这是 AI 生成的，不携带版权，与你的工作无关”。
在版权法、DCO 和 AI 输出之间，存在一个巨大的灰色地带。没有一个开源项目能通过投票来解决这个问题。这需要法院的判决和立法机构的更新。
碎片化的开源 AI 政策版图
根据 RedMonk 分析师 Kate Holterhoff 的追踪，截至 2026 年中期，已有 86 个开源组织制定了 AI 相关政策，从 Linux 基金会、Apache 到单一项目如 curl、Matplotlib。政策方向高度碎片化：有的全面禁止、有的允许但要求披露、有的仍在观望。
Debian 的二度辩论，恰逢一个更广泛的制度性时刻。欧盟 AI 法案要求在 2026 年 8 月 2 日前对高风险 AI 系统实施人工监督。APEC 经济体刚刚在成都发表了支持开源 AI 的联合声明。微软和 20 多家科技公司联合呼吁政策制定者支持开源 AI。OpenAI 和 Anthropic 在“开放权重”问题上找到了罕见的共识。
开源世界正在被 AI 从各个方向拉扯。一方面是政策制定者和企业的推动，另一方面是社区维护者对自己劳动成果被“洗钱”的恐惧。Debian 的困境，只是一个缩影。
真正的考验还没开始
2026 年 7 月 24 日开启的讨论期，将决定 Debian 在 AI 时代的姿势。但无论这次投票结果如何，真正的问题都不会消失。
如果提案 A 通过，Debian 将成为主流发行版中最激进的 AI 禁令者。但禁令无法执行，只会把 AI 辅助的贡献者推向暗处。
如果提案 B 通过，Debian 将成为开源世界中最开放的 AI 接纳者之一。但透明披露机制同样无法验证，谁会在提交中主动标注“这是 AI 写的”？
两种方案都有内在缺陷，因为问题本身就不适合用投票来解决。Debian 需要的不是“选 A 还是选 B”，而是先回答一个更根本的问题：在一个 AI 可以写出让人类无法分辨的代码的世界里，“贡献者”这个身份到底意味着什么？
这个问题没有简单的答案。但至少，Debian 正在问它。而绝大多数开源项目，连问的勇气都没有。
开源社区正在用 20 世纪的治理工具，应对 21 世纪最深刻的技术变革。投票箱不是答案，但它是我们能找到的起点。
快报