开源操作系统Debian的委员会近日提出了一份关于是否允许使用大语言模型辅助贡献的一般性决议草案，涵盖支持与反对两类提案，引发开源开发者广泛关注。

支持禁令的立场

由Matthias Geiger署名的提案以Debian"稳定性声誉"为出发点，认为广泛使用大语言模型折射出"快速行动、打破常规"的开发文化。提案明确表示："尽管这种态度在业界颇为普遍，但与Debian的立身之本相悖，对Debian贡献者而言并不适当。我们不允许直接向Debian提交使用大语言模型或其他生成式AI工具编写或辅助编写的代码。"

七项对立提案

与此同时，另有七项反驳性提案被同步提交，内容涵盖：有条件允许AI辅助贡献；在更新行为准则的前提下尽量排除大语言模型；接受专门针对Debian工作的AI贡献；制定生成式AI负责任使用指南；以"Debian由人类创造"为宗旨的声明；以及一项措辞直接的最终提案——"避免使用大语言模型：气候破坏是底线"，该提案指出地球正面临气候危机。

禁令范围与例外情形

若最终获批，全面禁令将适用于Debian源码包及其开发的软件、官方网页资源、打包等直接代码贡献、lintian软件包检查器等原生Debian软件，以及Debian贡献者编写的文档与翻译。

值得注意的是，禁令不适用于使用生成式AI的上游软件工程项目，也不涵盖来自上游的补丁和安全修复（无论这些内容是否借助AI生成）。Debian开发者仍可为第三方AI编写的工具打包，但不得将这些工具用于新的直接项目工作。

业内人士的不同声音

混合劳动力标准（Hybrid Workforce Standard）作者Joe Phillips向The New Stack表示，这场八方投票的本质不是原则之争，而是"代码来源上贴多大标签"的格式之争。他认为，Debian社区最有力的论据在于技能退化风险——"依赖模型的贡献者永远学不会打包，也就无法接替精疲力竭的维护者"，而这种伤害会持续复利叠加。Phillips认为，简单的禁令无法解决问题，真正的答案在于"学徒制而非禁令"：让新贡献者在导师监督下工作、接受如同初级开发者般的严格审核，逐步建立权限。

AI原生合规管理平台Strike Graph的CEO兼创始人Justin Beals则认为，此举是"用错了药"。他指出，Debian的禁令本质上承认了一个现实：目前没有人建立起可靠的机制，能在代码进入如此多关键系统（包括在轨运行的基础设施）之前，有效验证AI智能体究竟生成了什么。他强调，简单禁止AI贡献只是治标不治本，不会消除AI辅助代码，只会让其使用更难以披露——"什么能阻止有人把AI生成的内容复制粘贴过来，甚至手动逐字敲进去？"他认为，真正领先的项目应将验证机制嵌入贡献流程：追踪代码来源、根据实际风险调整审查深度，并要求人类对最终交付内容进行实质性确认。

Endor Labs首席AI架构师Matt Brown也表达了类似观点。他理解Debian团队的顾虑，但认为"一刀切的禁令容易将工具本身与代码质量混为一谈，尤其是在模型能力持续提升、使用日益普及的当下。"他主张，真正应该追问的不是AI是否参与其中，而是贡献者是否充分理解、验证并愿意为提交的代码承担责任。他建议采用更透明的方式，辅以人工问责、严格测试，以及对所有贡献统一适用的高标准审查机制。

投票节点

目前，上述提案仍处于讨论阶段。提案A（通过社会契约禁止大语言模型贡献）需获得三比一的多数票方可通过，其余七项提案（B至H）仅需简单多数。投票截止时间为2026年8月28日23时59分59秒（UTC）。

Q&A

Q1：Debian为什么要禁止使用大语言模型辅助贡献代码？

A：Debian支持禁令的一方认为，广泛使用大语言模型体现了"快速行动、打破常规"的开发文化，与Debian注重稳定性的一贯传统相悖。此外，有观点指出，依赖大语言模型的贡献者可能无法真正掌握打包技能，导致技能退化，长期影响项目的可持续维护能力。

Q2：Debian大语言模型禁令如果通过，具体会限制哪些内容？

A：禁令将覆盖Debian源码包及其开发的软件、官方网页资源、打包等直接代码贡献、lintian等原生Debian软件，以及贡献者编写的文档与翻译。但禁令不适用于上游软件工程项目、来自上游的补丁和安全修复，Debian开发者仍可为第三方AI工具打包，只是不得将其用于新的直接项目工作。

Q3：业界人士为何认为Debian禁止AI代码贡献的做法是"治标不治本"？

A：多位业内专家认为，简单禁止AI贡献无法从根本上解决代码质量和信任问题。有人指出，禁令只会让AI辅助使用变得更难披露，而无法真正杜绝——贡献者完全可以将AI生成内容复制粘贴后提交。更有效的做法应是将验证机制嵌入贡献流程，包括代码来源追踪、基于风险的审查深度以及人工实质性确认，而非依靠禁令。