开源项目 AI 辅助代码提交政策指南

在提交 AI 辅助代码前应采取的措施

开源项目现已发布关于 AI 辅助代码的政策，但各项目间的规定并不统一。因此，习惯很简单：在编写补丁前先查阅政策，并在提交时准确披露。所有政策都遵循一条原则：不要提交你在代码审查中无法解释的任何一行代码。

如果项目禁止生成式代码，或者你隐瞒了代码来源，即使补丁本身正确也会被关闭。这会损害你的个人声誉，因为如果维护者事后发现你隐瞒了事实，他们将不再信任你的后续贡献。首先说明一些术语，因为政策中会用到它们。LLM（大语言模型）是编码代理背后的模型。GitHub 上的 PR（pull request）在 GitLab 上称为 MR（merge request），以下内容适用于两者。DCO（开发者原创声明）是提交信息底部的签名行，它已成为整个争议的核心。

开源 AI 代码策略的现状

各项目已形成四种处理模式。以下示例均标注了日期，因为相关规定处于变动中。

禁止使用。 Gentoo 理事会于 2024 年 4 月 14 日投票决定，“明确禁止向 Gentoo 提交任何由自然语言处理人工智能工具辅助创建的内容”。NetBSD 的提交指南将 LLM 输出称为“受污染代码”，规定“未经核心团队事先书面批准，不得提交”。截至 2026 年 8 月，QEMU 的代码来源文档仍声明该项目将“拒绝任何被认为包含或衍生自 AI 生成内容的贡献”。

仅限分析。 大多数禁令的范围比标题所暗示的更窄。QEMU 的文档指出，该策略“不适用于 AI 的其他用途，例如研究 API 或算法、静态分析或调试，前提是其输出不包含在贡献中”。你可以使用智能体来阅读代码，但不得发布其编写的内容。这种区分是大多数限制性项目内部的执行准则，也是人们最容易忽略的一点。

要求披露。 Fedora 理事会于 2025 年 10 月批准了一项关于 AI 辅助贡献的政策。该政策允许使用此类工具，并将责任归于个人：贡献者即作者，需对整个贡献承担全部责任，且必须在贡献中包含大量未经修改的 AI 生成内容时进行披露。Linux 内核于 2025 年 12 月在其流程文档中增加了编码助手页面，其中包含记录工具的附录，并对谁有权签署提交（sign off）作出了严格规定。

无书面规定。 这仍是目前最常见的情况。一份 2026 年 5 月的预印本调查了 1,000 个热门 GitHub 仓库，发现仅有 118 个制定了书面 AI 政策。沉默并不代表许可。在编写补丁之前，请在问题追踪系统中用一句话进行询问，得到的回复将成为你可以随时引用的公共记录。

维护者制定这些规则的原因

第一个原因是审查负担，且计算方式是单向的。AI 代理可以在一分钟内生成一个看似合理的 400 行合并请求（merge request）。维护者要正确审查该请求需要花费一个下午的时间，而大多数维护者都是志愿者。提交代码的成本已降至接近零，但审查的成本却丝毫未减。

curl 项目展示了这一趋势的极端情况。Daniel Stenberg 在 2025 年年中报告称，通过项目漏洞赏金计划收到的安全报告中，约有五分之一是他所称的“AI 垃圾”：这些报告指出了真实存在的函数和代码路径，描述了看似合理的攻击方式，但内容却毫无价值。该项目在 2026 年初终止了赏金计划，而不是继续为这种洪流买单。虽然这些是报告而非补丁，但正是同样的机制导致维护者在打开你的 PR 时已经感到疲惫。

GNOME Calendar 将这一问题定义为一个标签。2026 年 6 月，该项目为那些“主要或完全依赖人工智能生成代码”的合并请求引入了“概率性自动化”（Probabilistically Automated）标签，并准确指出了其症状：“通常伴随着缺乏适当的测试，且补丁的定稿是基于理论上的预期行为，而非代码的正确性”。请仔细阅读最后那句话。代码看起来应该能运行，但没人验证过它是否真的能运行。

第二个原因是来源证明，即代码来自何处以及在何种许可下发布。QEMU 明确指出了这一冲突：签署提交即表示你“完全理解所贡献内容的版权和许可状态”，而模型输出的版权状态尚无定论。Gentoo 理事会给出了同样的理由，并补充了质量和道德方面的考量。你不必认同这种法律解读，但你必须意识到，这是维护者的决定，而不是你的。

如何查找项目的 AI 政策？

请按以下顺序查找：

• CONTRIBUTING.md（位于仓库根目录），然后是 .github/CONTRIBUTING.md，最后是其旁边的任何 DCO 文件。
• 开发者文档。QEMU 将其规则保存在 docs/devel/code-provenance.rst 中。内核将其规则保存在 Documentation/process/coding-assistants.rst 中。
• 项目网站或 Wiki。Gentoo 的政策位于理事会的 Wiki 页面上，NetBSD 的政策则位于提交指南中。
• 问题追踪器和邮件列表归档。政策通常在写入仓库前已在这些地方讨论了数月。

在检出的代码库中，使用一条 grep 命令即可涵盖大部分内容：

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

随后阅读项目自身的历史记录，因为已提交的惯例优于任何总结：

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

追踪器值旁边的计数显示了该项目实际使用的格式。如果结果为空，说明此处无人以该格式进行披露，这也是一种信息。如果项目托管在 GitHub 上且你对工作流不熟悉，GitHub 上 Pull Request 和 Fork 的工作原理 涵盖了本节所假设的操作机制。

在提交信息的尾部声明，而非注释中

尾部（trailer）是提交信息最后一段中的 Key: value 行。Git 已将此格式用于 Signed-off-by: 和 Co-authored-by:，且工具会自动解析，因此这是唯一能随代码进入代码树的声明方式。

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

内核文档将其格式定义为 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]，并明确了该行的限制：“AI 代理不得添加 Signed-off-by 标签。只有人类才能合法证明开发者原产地证书（DCO）。” 代理名称应填入 Assisted-by。你的姓名应填入 Signed-off-by。切勿让工具填写后者，也切勿让其编造属于虚构人员的 Co-authored-by 地址。

姓名格式各异，请复制本地记录的格式，不要自行编造。2026 年 5 月发布到 QEMU 邮件列表的一个补丁建议放宽该项目的禁令，允许针对机械性变更、测试、文档以及 20 行以内的错误修复使用类似 AI-used-for: tests, docs 的尾部进行记录。截至 2026 年 8 月，这仍是邮件列表中的一项提案，且已提交的文档仍拒绝生成式内容。某项目在 2023 年至 2026 年间两次改变立场。下一次变动不会等你，因此方法比列表本身更重要。

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer 需要 Git 2.32 或更高版本。第二个命令应直接将值回显给你。如果输出为空，说明 Git 未能解析该尾部，这通常是因为在信息底部的尾部块中混入了空行或普通句子。对于已编写的提交序列，git rebase --signoff origin/main 可为每个提交添加签名，git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt 可用于编辑信息文件。

有两种故障模式需要预先规划。压缩合并（squash merge）会重写提交信息，因此在执行压缩的项目中，请在维护者阅读的 PR 描述中重复该声明。此外，评审评论并非记录，因为评论可以被编辑且永远不会进入 Git 历史。

准确性至关重要。在手动编写的提交上使用 Assisted-by 是无效信息，这会降低你真实声明的价值。而在代理编写的提交上遗漏该声明，则会终结信任关系。

Signed-off-by 究竟证明了什么？

DCO 是一段简短的文本，版本为 1.1，发布于 developercertificate.org，被 Linux 内核、QEMU 及许多其他项目采用。添加 Signed-off-by: Your Name <you@example.com> 即表示你对此进行了认证。请务必阅读你所认证的内容，因为大多数人在签署时从未阅读过它。

条款 (a) 声明该贡献“全部或部分由我创建，且我有权根据文件中指明的开源许可证提交它”。条款 (b) 涵盖了基于你拥有修改并分发权利的早期开源代码所完成的工作。条款 (c) 涵盖了由同样签署过此认证的人转交给你的代码。条款 (d) 声明你知晓该贡献以及你签名中的个人信息将被公开并永久保留。

注意其中缺失的内容。DCO 从未要求你输入每一个字符。它声明的是你有权根据此许可证提交代码。这就是为什么生成的代码在此处显得有些尴尬：问题不在于作者身份，而在于你是否能说明其来源。大多数要求签名认证的项目同时也要求使用真实姓名，因此使用化名无法通过检查。使用 git commit -s 添加该行，它会从你的 git 配置中读取 user.name 和 user.email。当 DCO 机器人拒绝你的 PR 并指出缺少该行的提交时，使用 git rebase --signoff origin/main 并强制推送（force push）到你的分支即可修复。

提交签名与签署提交（Sign-off）的区别

git commit -s 会添加一行文本。git commit -S 则使用您的 GPG 或 SSH 密钥对提交对象进行加密签名。它们解决的是不同的问题。签名证明该提交确实来自密钥持有者，且自签名后未被篡改。它无法证明代码来源，因此即便一个包含未披露生成代码的提交已完成签名，依然属于违规行为。签署提交（Sign-off）是对代码来源的声明。签名则是对身份的声明。同时要求两者的项目会明确提出双重需求。

提交代码前必须确保能够解释每一行

这是一项测试，其核心并非关于诚实。对于每一行代码，你都需要明确：它的作用是什么？如果删掉它，会导致什么功能失效？如果这两个问题中任何一个无法回答，说明补丁尚未就绪，因为评审意见迟早会到来，而你届时仍需重新生成代码。评审人员能够察觉这一点。一旦出现这种情况，贡献者就会成为项目的负担。对于边界条件、空输入、失败路径以及第二个调用者，也要进行同样的审视。

运行代码。构建项目、执行测试套件，并为你声称修复的 Bug 编写一个复现脚本。内核文档用直白的语言给出了诚实的后备方案：“如果修复无法构建或测试，或者无法提供复现脚本，请明确说明：维护者目前在分析未经核实的问题报告和未经测试的修复方案上浪费了太多时间。”写下“我无法在真实硬件上测试此代码”不会对你造成任何损失。但暗示你已经测试过，则会让你失去项目的信任。

亲自回复评审意见，使用你自己的语言，并安排好你的时间。如果在评审意见发出后 30 秒内就回复一段五段话的重述，维护者一眼就能看出发生了什么。同时，保持 diff 的规模精简。你完全理解的 40 行代码，其价值远高于你监督下完成的 400 行重构。如果你的代理程序总是提供超出你需求的内容，掌握将变更限制在最小可行范围内的技巧是确保补丁规模可控、且每一行都能经得起推敲的有效方法。

将 Agent 指令保存在仓库中

你提供给 Agent 的指令属于工具链的一部分，因此请像对待代码一样对待它们。仓库根目录下的一个文件（通常为 AGENTS.md）应包含构建命令、测试命令、提交信息格式、签名要求以及项目已有的风格规范。该文件经过版本控制且可供审查，确保其在不同时间保持一致。如果每次会话都凭记忆重新输入指令，生成的补丁会各不相同，你将无法确定被拒绝的补丁源自哪次会话。编写一份人类与 Agent 均可阅读的 AGENTS.md 涵盖了该文件的具体内容。

关于他人仓库的一点提醒：不要在非你维护的项目中，将添加 Agent 指令文件作为你的首次贡献。这会被视为试图从外部干预项目的工具策略，极易导致你的账号被关联到维护者反感的事物上。请将该文件保留在你的分支中，直到有人主动询问。

运行 Agent 的位置同样重要，原因如上。如果 Agent 能够在受控的沙箱中构建项目并运行测试，你得到的补丁就是经过验证的成果，这与“提供辅助”和“盲目猜测”有着本质区别。在自己的 VPS 上运行编码 Agent 涵盖了相关设置，而 Claude Code、Cursor、Codex 和 Copilot 之间的实际差异 则介绍了这些工具在日常使用中的区别。

策略变更后的处理方法

1. 在编写任何内容前，先查找既定策略：查看仓库、开发者文档、网站或跟踪系统。
2. 若无相关策略，请在 issue 中用一句话询问，并保留回复。
3. 按照项目使用的格式进行披露，将其写入 commit trailer，若项目执行 squash 合并，则需在 PR 正文中重复该内容。
4. 使用真实姓名签署（Sign-off），并明确该行代表你拥有提交此代码的权利。
5. 像审阅陌生人的代码一样审阅自己的补丁，因为代码确实出自他人之手。

本页面提及的所有项目在你阅读时可能已经迁移。但这五个步骤不会改变。

FAQ

我是否必须披露使用了 AI 编码助手？

请查阅项目文档，因为该要求由本地设定。Fedora 要求在贡献的很大一部分由工具生成且未经修改时进行披露。Linux 内核要求添加 Assisted-by 尾注。截至 2026 年 8 月，Gentoo 和 QEMU 则完全不接受此类贡献。若项目未作明确规定，也请在提交尾注中主动披露。维护者若事后发现隐瞒，其反感往往针对的是隐瞒行为而非工具本身，且这种负面印象会波及你提交的所有其他内容。

哪些开源项目禁止 AI 生成的代码？

截至 2026 年 8 月的快照：Gentoo 自 2024 年 4 月起禁止；NetBSD 将 LLM 输出视为受污染代码，需核心团队批准；QEMU 拒绝接受源自生成内容的贡献；此外还包括 Loupe 和 Calendar 等多个 GNOME 应用程序。请阅读各项目自身的文档而非仅参考此列表，因为信息会过时。注意大多数项目共有的豁免条款：使用模型研究 API、运行静态分析或辅助调试通常是被允许的，前提是其输出内容未包含在补丁中。

Signed-off-by 与签名提交（signed commit）有何区别？

Signed-off-by 是由 git commit -s 添加的一行纯文本。它证明了开发者来源证书（DCO），即你拥有在该项目许可协议下提交此代码的权利。签名提交则使用 git commit -S 完成，是对提交对象进行的 GPG 或 SSH 密钥加密签名。它证明了提交确实来自你的密钥且未被篡改。来源证明与身份验证是两个独立的概念，因此即使是签名提交，也可能违反 AI 使用政策。

我可以将披露信息写在合并请求（pull request）描述中，而不是提交信息里吗？

请将其写在提交信息中，因为这是进入 git 历史记录并随代码一同传递给后续所有克隆仓库者的记录。合并请求描述可以在事后编辑，且仅存在于托管平台上。如果项目采用压缩合并（squash merge），由于压缩操作会重写提交信息并可能丢弃尾注，此时也应将披露信息添加到合并请求的正文中。

我的合并请求因 AI 生成而被关闭，现在该怎么办？

不要在讨论帖中争论政策，因为关闭请求的人并非规则的唯一制定者，且该讨论帖也不是修改规则的地方。请阅读政策原文，然后决定你是否能满足要求。如果项目禁止生成式补丁，提交一份带有复现步骤且不含补丁的清晰 Bug 报告依然受欢迎，且这往往是更有价值的贡献。如果你再次提交代码，请确保提交的是你能逐行解释的小型变更。