事件与背景

北京时间 8 月 29 日晚，Debian 项目公布了 2026 年度第二号 General Resolution（GR-2026-002，主题「LLM usage in Debian」）的投票结果：选项 5「Responsible Use of Generative AI（负责任地使用生成式 AI）」胜出。消息冲上 Hacker News 首页（436 分 / 348 条评论），LWN 主编 corbet 第一时间撰写长文解读。

这次公投的流程相当漫长：讨论期 7 月 23 日至 8 月 13 日（期间还延长过一次），投票期 8 月 15 日至 8 月 28 日，共收到 8 个提案（A–H），覆盖了从「写入 Social Contract 全面禁止 LLM 贡献」到「有条件允许 AI 辅助贡献」的完整光谱。以公开的提案文本为例：提案 A（选项 1）主张修订 Social Contract，明文禁止任何 LLM 辅助产出进入 Debian，理由是版权状态不清、质量不可靠、新人会被 AI 补丁「带偏」且审查者面临 burnout；提案 B（选项 2）则由 Lucas Nussbaum 牵头，主张有条件允许 AI 辅助贡献，要求工具条款兼容、许可证与归属可查、贡献者全责并披露 AI 使用。最终胜出的选项 5 措辞耐人寻味——Debian 既不背书也不禁止生成式 AI 工具，但明确提出三条硬约束：所有贡献（无论用什么工具产出）必须满足相同的质量、正确性、可维护性与法律合规标准；使用生成式 AI 不减轻贡献者的责任；贡献者必须理解、审查、测试并酌情修改 AI 辅助产出后再提交。

来源：

• LWN：Debian votes to allow “responsible use of generative AI”
• Debian 官方投票页：General Resolution: LLM usage in Debian
• 投票结果图（Lucas Nussbaum 整理）
• HN 讨论帖（436 分 / 348 评论）
• Gentoo AI 政策（对比参考）

为什么现在重要

1. 开源世界第一个「全项目公投级」AI 治理先例。 此前 Gentoo 有 Council 层面的 AI 政策、GNOME 的 Loupe 项目直接禁止生成式 AI 贡献、Zig 在行为准则中限制 AI 参与，但这些都是小范围或单项目决定。Debian 是贡献者规模最大、治理流程最重的志愿者社区，用完整 GR 程序（8 提案 + Condorcet 投票 + 公开计票）为「AI 辅助贡献」立下基准。影响判断：这份措辞将成为未来两年各类基金会、发行版、大型开源项目撰写 AI 贡献政策的模板——「不禁止 + 责任不转移」大概率成为主流范式。

2. 「AI 不减轻贡献者责任」从口头共识变成了成文规则。 选项 5 明确：贡献者必须理解、审查、测试 AI 产出，标准不因工具而降低。这意味着在 Debian 生态里，「这是 Claude/GPT 写的所以我不负责」的辩护空间被正式清零，法律合规（尤其是许可证与版权）的最终责任锚定在提交者身上。影响判断：对依赖 Debian 打包链的团队，AI 生成 packaging 代码的审查义务从此有据可查。

3. 两个「零容忍」提案连 NOTA 都没打过，信号强烈。 据 LWN 讨论区与 HN 评论，最激进的两个选项（修改 Social Contract 全面禁止、修改行为准则并含驱逐条款）在投票中败给了「None of the Above」，而选项 5 是明确的 Condorcet 赢家（有开发者用 Bradley–Davidson 模型算出其后验支持率 99.9993%）。影响判断：社区拒绝了「AI 警察」式治理——这对那些正被 AI 补丁淹没、考虑一刀切禁令的维护者是重要参照：禁令既难执行又伤社区，责任化 + 质量门槛是更可持续的路线。

4. 开源世界正在变成 AI 治理的天然实验场。 同一周内：Zig 行为准则限制 AI、GNOME Loupe 禁用、Gentoo 有政策、Debian 选择「负责任使用」——不同规模、不同治理结构的项目给出了不同答案。影响判断：未来 12 个月这些政策的效果对比（补丁质量、维护者 burnout、新人贡献曲线）会构成一份难得的实证数据，值得产品与技术决策者持续跟踪。

5. 版权与许可证的暗线仍在。 Debian 的 DFSG 要求版权与许可证绝对清晰，而 AI 产出的版权状态至今无定论；投票页侧栏还挂着一个已撤回的「DFSG 对 AI 模型解释」GR。选项 5 把法律合规的门槛保留在政策文本里，但并没有回答「AI 生成的代码到底归谁」这个根本问题。影响判断：这是埋在未来的一颗雷，政策层面绕开了它，法律层面绕不开。

工程师/产品人今天能做什么

1. 通读 GR-2026-002 全文与选项 5 原文（投票页有全部提案文本），特别是如果你的团队向 Debian 提交包、补丁或文档翻译——把「理解、审查、测试 AI 产出」写进自己的贡献 SOP。
2. 建立 AI 辅助贡献的留痕习惯：即使政策不强制披露，保留「AI 生成 + 人工修改」的记录、以及你自己对每段代码的验证结论，是对「责任自负」条款最便宜的自我保护。
3. 如果你是开源维护者：直接把选项 5 的措辞改造成自家 CONTRIBUTING.md 的 AI 政策段落——它经过了 8 提案博弈与全社区投票检验，比你自己拍脑袋写的更抗争议。
4. 审查存量 AI 生成的打包代码：GR 讨论中反复点名 LLM 产出的 packaging 常见病（watch 文件失效、copyright 字段虚构、override 脱离上下文）——趁政策落地，把仓库里可疑的 AI 痕迹过一遍。
5. 给团队内部定一条红线：AI 可以提速，但提交质量门槛不变、责任人不变——把这条写进 code review 的 checklist，别等出了事故再补。

待观察

1. 官方计票明细尚未在 vote.debian.org 落地：目前结果图托管在 people.debian.org（Lucas Nussbaum 个人页），标准的结果页（vote_002_results）返回 404——完整 Condorcet 矩阵与各选项得票待官方公布。
2. 「无强制披露」条款的后续演化：LWN 与 HN 讨论中两派意见尖锐对立——一派认为不要求披露等于回到「狂野西部」，另一派认为强制披露必然催生 AI 警察与寒蝉效应；维护者是否会自行在各自包内要求披露，值得观察。
3. bot/agent 补丁洪水的下一轮治理：有评论者指出真正的问题是「fire-and-forget agent 刷补丁骚扰维护者」，并预言这迟早会推动行为准则层面的新条款——若 Debian 收到大量 AI 生成的无效补丁，可能触发下一次 GR 或 CoC 修订。