Debian投票通过生成式AI负责任使用
Debian votes to allow "responsible use of generative AI"
Debian社区刚刚完成了关于大型语言模型使用的公投，最终结果选择了“负责任地使用生成式AI”这一选项。决议明确指出，Debian既不背书也不禁止在软件开发、维护及文档撰写中使用生成式AI工具。社区认可这些工具在提升贡献者生产力方面的潜力，让志愿者能将宝贵时间投入到需要技术判断和协作的核心工作中。然而，决议也划定了清晰红线：无论使用何种工具，所有提交给Debian的贡献都必须满足同等的质量、正确性、可维护性及法律合规标准。使用AI并不意味着贡献者可以免除责任，他们必须理解、审查、测试并在必要时修改AI生成的内容，确保其符合Debian的高标准。
使用生成式AI工具并不会减轻贡献者对其提交工作的责任。
HN 评论区
465- chuckadams
新政策的核心就是：“不管是不是 AI 写的，代码终究是你的，责任也由你承担”。这点我完全能接受。
- GZGavinZhao
相关话题：我发现这个针对贡献内容的自评 AI 辅助等级 [1] 非常有用，无论是在职业还是个人层面，它都能帮助传达 AI 辅助的程度，让接收方评估需要花多少时间和精力来理解我的代码。
[1]: https://www.visidata.org/blog/2026/ai/#self-assessed-ai-leve...
- jhack
很高兴看到最符合常识的选项胜出。其他一些提案简直脱离现实，我甚至惊讶于它们竟然被提上日程。
- edward
Joey Hess 对此并不买账。参见 https://joeyh.name/blog/entry/Debian_and_the_sirens/
- firefax
我对编程了解不够深入，无法从开发者角度谈论 Debian，只能作为一个老用户发言。
我觉得 AI 在编写那些可以肉眼检查的小型 Shell 脚本时很有用。
我稍后想做一个 GIF，如果 MKV 文件的路径是 X，时间戳是 Y 和 Z，我可能会问 Duck.AI 该怎么写命令。
这样我就能自己造个小工具，而不必下载那些给 Imagemagik（拼写对吗？）或其他东西套个 UI 的来路不明的二进制文件。
我只稍微接触过一点 AI，主要关注本地 LLM，但即使是像我写的那个匿名 FTP 扫描器这样简单的事情，我也花了很多时间，而比我稍微熟练一点的人可能早就搞定了。
总之，我一直很尊重 Debian 对代码准入的严格把控——有些形式的“守门”是酷且有益的，很多年轻人总爱跟开发者争辩以显示自己有多聪明——我自己年轻时也犯过这种毛病。
- kurthr
开源项目对版权的依赖程度有多高？
那些限制 AI 生成内容版权保护的法院判决会给开源带来麻烦吗？使用这类工具时，代码输出是否必须具备某种“精神构思”（Mental Conception）？哪怕是复制粘贴（copypasta），你也得大致知道自己在做什么，而“自动化漏洞查找”似乎就不需要了。
- Tubelord
一个好的经验法则是：把你提交的生成代码当作是你自己亲手敲下的每一个字符来理解。那种“我不确定，是 AI 写的”的情况属于严重失误。
- stillpointlab
有人在追踪不同发行版在这个问题上的立场吗？
我很好奇 Fedora 在这方面的动向，但不知道去哪看。如果人们想根据对 AI 的态度选择或更换发行版，有一个地方能查看相对采用情况会很不错。
Linux 发行版正是提供一个广阔市场、提供多样化选项以满足每个人的完美场所，从完全反 AI 到完全 YOLO 风格的 vibe-coding 应有尽有。
- tulio_ribeiro
结果不错，大体上。
选项 E 击败了所有其他选项，因此它是毫无争议的孔多塞胜者（Condorcet winner）。
Bradley–Davidson 分析：https://gist.github.com/tulior/74479b28ddd1e191e5b2d89b8b68c...
Bradley-Davidson 模型显示，选项 5 排名第一的后验概率为 99.9993%。
选项 2 和 6 实际上并列第二。
选项 5 在每一场一对一的较量中都击败了对手。它最接近的对决是面对选项 2，结果为 57.8% 对 42.2%，因此尽管最接近的成对竞争并非压倒性胜利，但整体结果依然具有决定性。
- dooglius
投票结果似乎与提案的亲 LLM 程度呈线性关系。有趣的是，所有提案本质上都是反 LLM 的，而最终选中的那个是最中立、仅略带反 LLM 倾向的。没有任何亲 LLM 提案的存在，表明提案撰写者与投票者的步调不一致。