Debian 关于生成式 AI 的投票，很容易被误读成“放行”。项目确实选择了“Responsible Use of Generative AI”，而不是全面禁止。但它的实际含义更严格：如果你向 Debian 提交工作，你仍要负责理解、测试、维护、许可合规、保护私有数据，并且不能把自动化产生的成本丢给维护者。

维护者桌面上有 AI 节点、代码审核队列和治理清单

Debian 关于 LLM 使用的 General Resolution 于 2026 年 8 月 28 日结束投票。官方页面列出八个提案和 “None of the above”，讨论期为 7 月 23 日至 8 月 13 日，投票期为 8 月 15 日至 28 日。LWN 和 Phoronix 报道，获胜的是 Marc Haber 的 Choice 5。Hacker News 和 LWN 的讨论很快集中到一个所有 AI 编程团队都要面对的问题：当代码和文字更容易生成时，谁来承担审核成本？

获胜文本既不背书也不禁止在 Debian 开发、维护、文档、打包和其他材料中使用生成式 AI。它承认负责任使用可以提高志愿者效率，但同时要求所有贡献都满足同样的质量、正确性、可维护性和法律合规标准。披露 AI 协助被鼓励，但不是强制。未经适当人工审核就盲目上传生成内容，被明确视为不符合 Debian 既有实践。

重点是责任，不是许可

“Debian 允许 AI”这个说法太粗糙。Debian 没有降低生成内容的门槛，没有要求维护者接受含糊补丁，没有用决议解决版权问题，也没有允许把机密项目材料贴进第三方服务。

核心原则是：提交者对提交内容负责。如果 AI 工具帮助写了补丁，人必须能解释它。如果模型起草了文档，人必须核对事实、命令和包名。如果代理准备了大规模修改，审核的社会成本仍在项目里。

这也是很多公司需要的边界。“模型这么写的”不是理由；“AI 帮过忙”也不自动说明工作有问题。关键是证据：改动是否小、是否测试过、是否能解释、是否安全、许可是否清楚、是否值得审核者投入时间。

禁止看似干净，却很脆弱

全面禁止回应了真实担忧：低质量补丁、虚构解释、来源不清、审核负担增加，以及提交者不理解代码带来的文化伤害。许多维护者已经看到大量缺乏上下文的 PR 和冗长生成说明。

但在 AI 已进入编辑器、搜索、翻译、命令行助手和文档流程后，禁令很难执行。自动补全算不算？本地模型解释代码算不算？生成测试后人工重写算不算？边界模糊，执法本身会制造冲突。

禁令还可能惩罚负责任的使用：起草测试、比较 API、总结旧讨论、翻译说明或查找错误模式。问题不是辅助本身，而是未经审核、无人负责的工作进入项目。

无规则放开同样危险

AI 改变了提交成本。补丁、问题评论和文档修改更容易生成，代理还能一次生成很多。维护者仍要阅读、理解、测试、拒绝、解释或合并。

如果作者不理解改动，工作并没有消失，只是转移给审核者。Debian 因此保留既有标准，并特别提醒大规模自动化：批量报 bug、批量提交补丁和大范围修改，应先在合适渠道讨论并取得共识。

对企业来说，这条规则很直接：不要让工具把审核债务转嫁给没有同意承担的团队。

安全和数据边界

获胜文本具体提到机密信息、私人通信、安全敏感信息、仍在 embargo 的安全漏洞、加密密钥、凭据和其他非公开材料。除非明确授权并符合安全和隐私要求，否则不应发送给第三方 AI 服务。

企业可以直接借鉴这一点。仅列出允许工具不够，还要按数据类别制定规则。公开代码、专有代码、客户日志、安全通告、含凭据的失败测试、NDA 设计文档，风险并不相同。

好的政策要说明哪些数据可以离开组织、在什么合同下、保留多久、是否用于训练、谁批准例外。

披露有用，但不能替代质量

Debian 鼓励披露 AI 协助，但不强制。披露在降低审核负担时有价值：例如说明测试矩阵由 AI 起草并人工检查，或大重构由代理辅助并列出命令、测试和人工检查。若标签只引发“自动补全算不算 AI”的争论，就会浪费时间。

公司也不应把标签当质量。真正需要的是审核证据：运行过哪些测试，碰到哪些风险，许可如何检查，生成文本由谁负责编辑。披露是元数据，不是质量保证。

真正瓶颈是审核

开发者讨论中最强的反应是审核负担。开源项目里，代码不是唯一稀缺资源；维护者注意力、项目上下文、信任、分流和发布纪律更稀缺。

AI 也能帮助维护者，但如果主要效果是增加低上下文提交，生态就更低效。提交者的生产力会变成审核者的无偿劳动。

负责任流程因此要求更多证据：小 diff、清晰问题、复现步骤、测试、风险解释，以及确认生成结果已被理解。

给团队和开发者的做法

工程管理者应围绕责任写政策，而不是只列工具名。哪些工作可由 AI 协助：调研、测试草稿、文档、内部脚本、生产代码？谁拥有结果？进入仓库、工单或部署前需要什么证据？

要区分“辅助人”和“自动行动”。向模型询问方案不同于代理打开五十个 PR。文档草稿不同于安全事件摘要。批准的本地模型也不同于第三方网页服务。

维护者可以围绕行为更新贡献指南：提交你理解的代码，保持改动小，提供测试，不经讨论不要大规模修改，不把私有安全信息贴进外部服务，不用生成文本填满 issue。

开发者应把 AI 用来增加理解：探索代码、起草测试、比较 API、寻找边界情况、翻译文档、提出重构方案。提交前读 diff、跑测试、查许可、删掉虚构说法。

结论

Debian 的决定说明 AI-assisted development 正在成熟。真正的问题不再是开发中是否存在 AI 工具，而是如何使用它们，同时不损害代码质量、法律合规、安全边界和贡献者学习。

对开源来说，要接受符合标准的工作，并保护维护者免受无人负责的自动化冲击。对公司来说，政策要围绕责任、数据和规模，而不只是工具名称。对开发者来说，AI 应让你更有效，而不是更不负责。