Debian 开发者正在讨论一项关于大型语言模型与生成式 AI 使用边界的通用决议。其中一个方案主张，明确禁止向 Debian 提交任何由 LLM 或其他生成式 AI 工具编写、辅助编写的贡献。覆盖范围不只包括源代码包，也涉及 lintian 等 Debian 官方软件、项目网络资源，以及贡献者添加的其他内容。
这场讨论的核心并不是“AI 写的代码是否好用”，而是 Debian 能否继续对每一项贡献的版权、许可证、来源和维护责任作出可信承诺。在一个强调可再分发、可审计和长期维护的发行版中，这些问题比短期开发效率更重要。
禁止“生成”容易，界定“辅助”很难
如果规则只禁止直接复制模型生成的完整代码，边界相对清楚。但方案将“借助 LLM 编写”也纳入范围后，实际执行会遇到更复杂的情形：
- 使用模型生成一个完整补丁，显然属于生成式贡献。
- 让模型重构函数、补充测试或修改文档，也直接改变了提交内容。
- 使用模型解释编译错误，然后由开发者独立修改代码，是否仍算“借助”？
- 让编辑器自动补全一行代码，与传统符号补全的边界在哪里？
- 使用机器翻译、拼写修正或搜索摘要，是否应按相同标准处理？
因此，真正可执行的政策不能只写一句“禁止 AI”。它需要给出术语定义、适用范围和处理程序。否则，维护者既无法稳定审查，贡献者也难以判断自己的工作流是否合规。
还要注意，提交记录通常无法可靠证明一段代码是否由模型生成。所谓 AI 文本检测器存在误报和漏报，代码经过人工编辑后更难判断。项目最终仍需依靠贡献者声明、可追溯的开发过程和维护者审查，而不是把检测分数当作证据。
Debian 真正需要控制的是来源风险
生成式 AI 给软件发行版带来的风险，可以拆成几个更具体的问题。
版权与许可证来源不透明。 模型可能输出与训练材料相似的代码，但贡献者未必知道原始作者和许可证。Debian 需要判断软件是否能够合法分发，仅凭“模型生成”无法建立完整的权利链条。
责任主体模糊。 人类贡献者可以解释设计决定、修复回归并承担后续维护。如果提交者无法说明代码为何正确，只能表示“模型建议这样改”，评审和维护成本就被转移给了项目。
不可重复的生成过程。 相同提示词在不同模型、版本和参数下可能产生不同结果。即使保存提示词，也不等于获得可重复构建或可验证的开发过程。
敏感信息外泄。 把尚未公开的漏洞、私有邮件、日志或用户数据发送给第三方模型服务，可能造成独立于代码许可证之外的安全与隐私问题。
这些风险也说明，决议的影响不应只从“能否提高编码效率”来衡量。对于 Debian 这样的基础设施项目，来源证明和长期维护能力本身就是交付物的一部分。
可以这样实践：在提交前留下可审计证据
下面是一个可以改造的本地提交检查脚本。它不能判断代码是否由 AI 生成，也不应被当作检测器；它的作用是检查补丁质量、提示常见的生成式文本残留，并生成一份由贡献者确认的来源声明。
将以下内容保存为 debian-contribution-check.sh，然后在 Git 仓库根目录运行。执行前需要把基准分支 origin/main 改成项目实际使用的分支，例如 origin/master。
#!/usr/bin/env bash
set -euo pipefail
BASE_REF="${1:-origin/main}"
REPORT="contribution-attestation.txt"
if ! git rev-parse --verify "$BASE_REF" >/dev/null 2>&1; then
printf 'Unknown base ref: %s\n' "$BASE_REF" >&2
exit 1
fi
printf 'Checking commits against %s...\n' "$BASE_REF"
git diff --check "$BASE_REF"...HEAD
# 这里只检查常见残留，命中结果需要人工判断，不能证明使用了 LLM。
if git diff --unified=0 "$BASE_REF"...HEAD | grep -Ein \
'as an ai language model|generated by (ai|chatgpt)|placeholder implementation|insert code here'; then
printf '\nReview the matches above before submitting.\n' >&2
exit 1
fi
cat >"$REPORT" <<EOF
Contribution attestation
========================
Base reference: $BASE_REF
Commit: $(git rev-parse HEAD)
Author: $(git config user.name) <$(git config user.email)>
Confirm before submission:
[ ] I reviewed every changed line.
[ ] I can explain and maintain the submitted changes.
[ ] I verified the provenance and licensing of copied or adapted material.
[ ] I complied with the project's current policy on LLM and generative-AI use.
[ ] I did not disclose private project or user data to an external service.
Notes on tools and external sources used:
EOF
printf 'Created %s\n' "$REPORT"
printf 'Review it, complete the checklist, and attach it only if the project requests it.\n'
运行方式如下：
chmod +x debian-contribution-check.sh
./debian-contribution-check.sh origin/main
对于 Debian 源码包，还可以在提交前补上项目实际支持的构建与测试命令。例如，在已配置好 Debian 打包环境的前提下运行：
dpkg-buildpackage -us -uc
lintian ../*.changes
这些命令只能验证构建结果和部分政策问题，不能解决版权来源，也不能替代人工评审。来源声明同样不应被自动加入软件包，除非项目政策明确要求这样做。
决议落地时应回答哪些问题
无论 Debian 最终选择全面禁止、有限允许还是要求披露，都需要把抽象立场变成维护者能够执行的规则：
- 明确定义“生成”“辅助”和“仅用于查询”的区别。
- 说明代码、测试、文档、翻译、邮件和网络内容是否采用同一标准。
- 规定贡献者需要披露什么，以及披露信息保存在哪里。
- 为误提交、无法确认来源和善意违规设计处理流程。
- 禁止将机密信息、未公开漏洞和个人数据发送给未经批准的服务。
- 强调提交者必须理解、验证并维护自己的贡献。
- 定期复审规则，避免政策被某个模型、产品或检测器的名称锁死。
Debian 的讨论提醒所有开源项目：LLM 治理不能只是一份工具黑名单。可执行的政策必须围绕来源、许可证、数据边界和维护责任展开。只有当贡献者知道什么可以做、维护者知道如何审查、争议发生时也有明确程序，决议才会真正降低项目风险。