摘要：Debian通过一般决议，选择“负责任地使用生成式AI”方案。项目既不鼓励也不禁止开发者在软件、打包和文档工作中使用相关工具，但提交者必须理解、审查和测试产出，并继续承担质量、许可、安全与可维护性责任。该决议没有给AI代码设置一条独立通道，而是把它纳入Debian既有质量体系，为开源社区处理AI辅助贡献提供了务实样本。
摘要
Debian通过一般决议，选择“负责任地使用生成式AI”方案。项目既不鼓励也不禁止开发者在软件、打包和文档工作中使用相关工具，但提交者必须理解、审查和测试产出，并继续承担质量、许可、安全与可维护性责任。该决议没有给AI代码设置一条独立通道，而是把它纳入Debian既有质量体系，为开源社区处理AI辅助贡献提供了务实样本。
当生成式AI进入软件开发，最容易衡量的是代码生成速度，最难处理的却是责任。一个补丁可能在几秒内生成，但谁能解释它为何正确，谁核对它使用的接口和许可证，谁在几年后维护它，出现安全漏洞又由谁负责？对于商业公司，这些问题可以落到内部制度、雇佣关系和产品责任上；对于依靠全球志愿者协作的开源项目，责任链更松散，评审资源也更稀缺。
Debian在2026年的一般决议中正面处理了这个问题。投票包含九个选项，覆盖全面禁止、有条件接受、尽量排斥、谨慎使用、强调人类创作以及不采取立场等不同方向。最终胜出的是第5项“负责任地使用生成式AI”。它没有把生成式AI确立为推荐工具，也没有禁止开发者使用，而是重申所有进入Debian的贡献必须满足相同的质量、正确性、可维护性和法律合规标准。
这是一项克制但并不宽松的决定。Debian保留了开发者选择工具的自由，同时拒绝把“AI生成”当作降低标准的理由。提交者需要理解、审查、测试并在必要时修改AI辅助产出；盲目上传生成内容不符合项目既有开发实践。项目鼓励披露AI辅助使用情况，但没有将披露设为强制要求。
为什么一次工具使用会成为治理问题
Debian不是普通代码仓库。它维护庞大的软件包集合，承担依赖管理、架构适配、安全更新、可重复构建、许可证审核和长期维护工作。一个看似很小的打包脚本错误，可能在多个硬件架构或升级路径上产生后果。生成式AI善于根据已有模式补全内容，却未必理解某个软件包的历史约束，也可能混合不同时期的Debian规范、已经废弃的字段和并不存在的依赖。
更现实的压力落在评审者身上。低成本生成会增加提交数量，而验证成本不会同步下降。一个缺乏经验的贡献者可以在短时间内生成几十个补丁，维护者却必须逐个编译、测试、追溯并解释。若AI帮助提交者节省一小时，却让多个志愿维护者增加数小时审查，这种生产率提升只是把成本从生成端转移到了公共维护端。
因此，争论并不只围绕代码是否由机器写成。它涉及开源协作中的成本分配：谁制造变化，谁提供证据，谁承担后续维护。Debian最终方案把责任明确留在提交者一侧，要求工具使用者不能把不确定性转嫁给项目。
“不鼓励也不禁止”具体意味着什么
决议覆盖软件开发、维护、Debian打包、文档及项目发布的其他媒介。它承认生成式AI在负责任使用时可能提高志愿者效率，让有限的人力投入需要判断、协作和技术经验的工作。但这一表述没有赋予AI产出任何特殊资格。
首先，AI辅助代码必须像人工代码一样接受既有流程。包能否构建、测试是否通过、变更是否符合策略、是否影响反向依赖，都需要可验证证据。模型给出的解释只能作为线索，不能代替测试结果与维护者判断。
其次，提交者必须能够理解和捍卫自己的变更。若作者无法说明补丁改变了什么、为何采用该实现、可能影响哪些边界条件，即使代码碰巧通过测试，也不适合进入关键基础软件。这一点把生成式AI放回了“辅助工具”的位置：它可以建议方案，但不能成为无人承担责任的匿名作者。
再次，已有许可证与版权规则继续生效。Debian没有试图在一次投票中解决各法域对AI生成内容的著作权争议，而是要求贡献者避免提交其法律状态无法合理说明的内容。对项目而言，重要的不是对整个AI版权问题作出抽象裁决，而是确保每项具体贡献满足Debian自由软件准则和现行政策。
安全信息不能随意进入外部模型
决议还专门处理了数据边界。贡献者不得未经授权向第三方AI服务披露尚未公开的安全漏洞、私密通信、凭据、密码学密钥和其他非公开项目材料。这条规定看似常识，在AI编程工具逐渐嵌入编辑器、终端和代码托管平台后却非常关键。
传统搜索通常由开发者主动复制关键词，具备代理能力的编程助手则可能自动读取仓库、终端输出、环境变量和问题追踪记录。若权限配置过宽，一次“帮我修复这个错误”的请求就可能携带内部日志、访问令牌或安全补丁。开源项目虽然大量内容公开，漏洞协调和基础设施运维仍包含敏感阶段。
这也提示企业，AI编程治理不能止于批准某几个工具。需要进一步明确哪些仓库可访问外部模型、哪些数据必须在本地处理、日志保存多久、代理可执行哪些命令，以及发生越权读取后如何审计。工具名单只能回答“可以用什么”，数据分级与权限设计才回答“可以让它看到什么”。
大规模自动化要先获得共识
Debian没有因为工具换成生成式AI就放宽批量操作。大规模提交缺陷、批量发送补丁、跨软件包修改或其他影响广泛的自动化行动，仍需事先在适当渠道讨论并取得共识，而且必须由可问责的人类监督。
这一安排针对的是智能体时代的新风险。传统脚本通常执行确定规则，生成式代理可能自主选择文件、修改实现、提交问题并回复评审。单个动作看似合理，数千次连续动作却可能淹没问题系统和维护者邮箱。自动化的破坏力来自规模与速度，而不只来自单次输出是否正确。
企业内部也会面对类似场景：AI代理批量升级依赖、重构数百个仓库或自动修复安全告警。稳妥做法应包括变更范围上限、抽样复核、分阶段发布、可撤销提交、责任人签名和异常停止条件。AI提升了执行速度，治理系统必须相应提高制动能力。
Debian为何没有选择全面禁止
全面禁止看起来清晰，却面临识别与执行困难。现代开发工具中的代码补全、搜索、翻译和重构功能逐渐融合，贡献者可能难以准确区分哪些功能使用了生成模型。仅凭代码风格也无法可靠判断来源，强制检测容易形成误伤与形式主义。
更重要的是，工具来源并不能自动决定代码质量。一段人工代码同样可能错误、侵权或难以维护；一段AI建议经过资深开发者验证、重写和完整测试后，也可能成为合格贡献。Debian选择围绕可验证结果和提交者责任建立规则，绕开了难以证明的“生成过程侦测”。
这并不意味着社区内部的伦理、环境和劳动担忧已经消失。投票中的其他方案明确讨论了版权、能源消耗、训练数据来源、社区信任和评审负担。最终方案更像一个可执行的最小共识：保留争议，同时先把质量、安全和责任纳入现有制度。
对软件工程组织的三点启示
第一，AI生成内容不宜建立更低的验收标准。团队可以使用AI缩短实现时间，但合并条件仍应由测试覆盖、静态分析、性能指标、许可证扫描和人工审查决定。若AI产出数量增加，代码门禁还需要更严格，而非更宽松。
第二，责任必须绑定到具体的人。提交记录、签名、变更说明和评审意见应指向能够解释代码的开发者。企业可以要求AI辅助变更在合并请求中记录用途、关键提示来源或验证方法，但披露本身不能替代责任。
第三，要管理批量能力。未来AI编程的主要风险未必是一段幻觉代码，而是代理以机器速度制造大量“看起来合理”的变化。组织需要对跨仓库修改、自动提单、自动评论和自动部署设立单独权限，不能把聊天式辅助与自主执行视为同一风险等级。
Debian的决定没有给生成式AI盖上质量印章，也没有筑起一道禁止使用的围墙。它延续了自由软件长期形成的工作原则：进入公共软件的每一项变更都要有人理解、有人验证、有人负责。模型能力会继续变化，开发工具也会越来越自动化，这条责任链反而会成为最稳定的制度基础。