Debian 正式表决 LLM 贡献规则：九个选项争的是责任，而非检测
作者：林岚｜OC 开发者生态编辑
作者：林岚｜OC 开发者生态编辑
据 Debian 项目公告，Debian 开发者已于 8 月 15 日开始就 LLM 使用规则进行正式投票，投票将在 8 月 28 日结束。选票共有九项，从禁止直接提交 LLM 输出，到允许使用但由提交者承担全部责任，再到维持现状，跨度很大。
一句话结论：Debian 没有在表决一个万能的“AI 开关”，而是在决定贡献者能否证明来源、承担维护责任，并让社区有办法拒绝不可审查的批量输出。
此前 OC 已报道 Debian 社区准备把争论交给正式表决。今天的新事实是提案已进入投票，而且分歧被拆成了九种可排序选择。
最严格的方案要求把禁止 LLM 直接贡献写进《社会契约》；另一些方案原则上拒绝模型输出，却允许翻译、搜索或辅助分析。较宽松的方案允许 AI 辅助，只要求贡献符合法律、许可证和质量标准，并由人类提交者负责。还有方案鼓励披露但不强制披露，或者专门以气候成本为由反对使用。
为什么没有一个简单答案？因为“LLM 生成”很难可靠检测。强制披露依赖贡献者诚实，自动检测器又会误伤正常代码。另一方面，Debian 不能接受一个维护者无法解释、上游来源不清、许可证兼容性未知的补丁。即使代码能通过测试，未来的错误修复和安全响应仍需要人来负责。
Debian 的排序投票也不等于简单多数决。开发者会对方案排序，最终结果需要比较各方案之间的偏好关系。这能找到更广泛接受的折中，但也意味着最终文本可能不像“支持 AI”或“反对 AI”那样醒目。
关键事实
- 投票时间：2026 年 8 月 15 日至 8 月 28 日
- 选项数量：九项，包含全面禁止、有限辅助、责任制和维持现状
- 核心问题：许可证、披露、质量、批量贡献与长期维护责任
- 进展：这是此前讨论的正式投票阶段，不是已经生效的新政策
OC 判断
最可执行的规则不会依赖“识别 AI 味”，而会要求可解释来源、明确责任和可控提交规模。代码到底由谁敲出来并不是唯一问题；当补丁出错、侵权或无人维护时，项目能否找到一个真正负责的人，才是开源治理要解决的事情。
为什么重要
- 对贡献者：使用模型不一定被禁止，但“模型生成的”不能成为无法解释代码的免责理由。
- 对维护者：规则会影响审查负担、批量补丁处理和拒绝贡献的依据。
- 对开源项目：Debian 的正式决议可能成为其他大型社区制定 AI 政策的参考。
评论
围绕这篇文章补充信息、提出问题或分享观察。