Debian项目在2026年8月投票通过了一份新的AI使用政策。政策明确允许开发者在开发、维护和文档工作中使用生成式AI工具,但不要求提交者主动披露自己用没用AI。

政策原文写得很直接:生成式AI"既不豁免于现有标准,也不需要额外的特殊规则"。用不用AI,审查的门槛都一样。这不是Debian对AI代码的背书,而是把"能不能用"这个问题,换成了"审查能不能扛住"。

Debian投票通过了什么

这次投票不止一个方案在桌上。参与讨论的提案里,曾经出现过全面禁止AI生成贡献的选项,也有人提议强制披露,两个都没过。

投票选项结果
全面禁止AI生成的贡献未通过
强制要求披露AI使用情况未通过,改为"鼓励"
AI贡献适用现有标准,不特殊对待通过,成为新政策

政策公布后,已经有一名贡献者在邮件列表上宣布退出,称自己"对Debian出来的任何东西都不再感兴趣"。这更像一次个体表态,目前看不出会带动多少人跟进。

不强制披露,审查者拿不到关键信息

新政策鼓励贡献者说明是否用了AI辅助,但不作强制要求。这意味着审查者看到一段代码或文档时,默认拿不到"这是不是AI写的"这个信息。

作为交换,责任压得更重了。不管用什么工具做出来的贡献,都要满足同样的质量、正确性、可维护性和法律合规标准。政策要求贡献者理解、审查、测试并在必要时修改AI输出的内容——盲目接受或直接上传AI生成物,被明确认定为"不符合Debian既有开发实践"。

对贡献者来说,短期内不用变工具,也不用改流程。真正变的是提交习惯:如果用了AI辅助,最好自己先跑一遍测试、通读一遍逻辑,而不是直接粘贴。对维护者来说,以前可以问一句"这是你自己写的吗",现在这个问题的答案不具约束力,判断还是得靠代码本身,不是来源标签。

对打算基于Debian做供应链评估的团队,材料里没有出现专门的AI检测或版权追踪机制。这一点目前只能靠自己在采购或合规流程里加一道人工检查,等Debian后续版本更新给出更明确的答案。

使用AI的门槛没变,审查的门槛也没变——变的只是审查者能拿到的信息。

和Ubuntu的相似处境,不是同一场争议

今年早些时候,Canonical旗下的Ubuntu在AI立场上也遇到过类似的社区反弹。两件事经常被放在一起说,但争的不是同一件事——Ubuntu当时争的是产品层面的AI功能取舍,Debian这次争的是贡献流程该不该接纳AI生成的代码和文档。

两个项目分别撞上AI议题,说明的是整个Linux生态都在补同一门课,不是某个社区单独踩了坑。

接下来最该盯的,是政策通过之后维护者的实际做法:会不会有维护者开始要求PR描述里注明AI使用情况,会不会出现因AI生成代码引发的可维护性或版权纠纷案例。这些目前都还没有答案,也是判断这份政策是不是纸面文章的关键。