作者：韩启明｜OC 政策与安全记者

Debian 项目 已进入关于 LLM 使用的一般决议讨论期。开发者面对三套差异很大的方案：全面禁止直接的 LLM 辅助贡献；允许使用但要求许可核验、责任承担和显著披露；或者在现实可行范围内尽量拒绝，并允许各项目自行实施更严格禁令。

一句话结论：Debian 还没有禁止 AI，争议的核心也不只是代码由谁输入，而是一个依赖志愿者审查、要求许可证清晰的软件发行版，能否让贡献者把理解和责任外包给模型。

方案 A 最严格，拟禁止 Debian 源码包、官方软件、网站、文档、翻译和官方通信中的直接 LLM 辅助内容，但不排除包含 AI 软件，也不自动拒绝上游项目中的 AI 辅助代码。提案承认检测很难，主要依靠社区成员诚信遵守。

方案 B 允许部分或全部 AI 生成的贡献，但附加五类条件：工具条款不能妨碍 Debian 再分发；贡献者要核验第三方版权；对技术、安全和许可证承担全部责任；大量 AI 辅助内容要披露；批量自动提交必须事先讨论并由人监督。非公开漏洞和私人通信也不得交给不可信模型服务。

方案 C 认为彻底禁止现实上不可行，因此要求 Debian 尽量抵制 LLM。它禁止用 LLM 起草面向人的邮件、Bug 报告和讨论，要求所有 Debian 工作中的 LLM 使用都披露，并允许单个维护者或项目完全拒收相关贡献。

三套提案都指向同一个压力：AI 能快速生成代码和文字，却把验证成本留给维护者。Debian 不能只确认代码能编译，还要确认补丁可维护、版权可追溯、提交者理解变化，并愿意在几年后继续负责。一个漂亮的补丁如果没人能解释，就是新的供应链负债。

韩启明认为，全面禁令最大的问题是不可验证，完全放开最大的问题是审查成本外部化。更可执行的控制点是身份明确、显著披露、禁止自动倾倒、敏感信息隔离，以及让提交者对每一行承担和人工贡献相同的责任。

关键事实

• 来源：Debian 2026 年一般决议页面和邮件列表
• 当前状态：自 7 月 24 日进入讨论期，尚未形成项目最终政策
• 三种路线：全面禁止、附条件允许、尽可能拒绝并分项目治理
• 共同问题：质量、许可、审查负担、隐私和贡献者责任

OC 判断

Debian 的选择不会解决“代码是否由 AI 写成”的检测难题，却会决定出现问题时由谁解释和修复。开源治理最重要的不是生成过程纯洁，而是责任链不能断。

为什么重要

• 对开发者：AI 辅助提交可能需要披露工具、验证许可证并证明自己理解代码。
• 对维护者：项目可以把自动提交、批量改动和敏感信息处理设为独立控制点。
• 对用户：Debian 的政策将影响发行版供应链的可审计性和长期维护质量。

参考来源

• Debian：General Resolution on LLM usage
• Debian 邮件列表：Allow AI-Assisted Contributions
• Debian：一般决议提交流程