필사 모드: GCC 的 AI 政策与开源世界的选择 —— 15 行这条边界线到底想守住什么

• 引言 —— 7 月 29 日，一条 15 行的界线
• 这项政策实际要求什么 —— 又没有禁止什么
• 为什么偏偏是 15 行 —— 版权转让、DCO，以及两条分岔的风险
• 其他项目把界线划在了哪里
• 对贡献者来说，实际会发生什么变化
• 这场争论的两边
• 结语 —— 这项政策关乎的是来源链条，不是代码质量
• 参考资料

引言 —— 7 月 29 日，一条 15 行的界线

2026 年 7 月 29 日，David Edelsohn 在 GCC 邮件列表上发布了一份 AI 政策公告。内容是：指导委员会原样通过了由 Jonathan Wakely 牵头的 AI 政策工作组提出的建议。工作组成员包括 Carlos O'Donell、Sudakshina Das、Jason Merrill、Joel Sherrill、Sam James、Robin Dapp、Arthur Cohen。

政策正文放在 gcc.gnu.org/ai-policy.html，压缩成一句话就是 ——具有法律意义的贡献，如果包含 LLM 生成的内容、或衍生自这类内容，一律不予接受。 而"具有法律意义"的判定基准，依照 GNU 维护者指南，大致定在 15 行左右。

媒体标题大多写成"GCC 禁止了 AI 代码"，但真正读一遍政策正文，会发现画面精细得多。没有被禁止的东西相当多，也有一些新增的要求，还有一个例外情形 —— 而这个例外恰恰是测试用例。本文要看的是：这项政策实际要求了什么，背后的法律结构是什么，其他主要项目各自把界线划在了哪里，以及站在贡献者的立场上，实际会发生什么变化。本文不打算评判哪一方正确 —— 双方的论据都有实质内容，搞清楚真正的分歧点在哪里，比评判输赢更有用。

这项政策实际要求什么 —— 又没有禁止什么

把政策拆开来看，一共四点。

被禁止的。 具有法律意义的贡献中，凡是包含 LLM 生成内容、或衍生自这类内容的。这里"衍生"这个词用得很宽，这一点很重要 —— 模型写出的代码经人手修改之后的结果，同样算作"衍生"。

被允许的。 不具有法律意义的贡献，大致是 15 行以下的部分，即使是 LLM 生成的，只要明确标注并满足其他常规要求，依然可以被接受。

例外情形。 对于具有法律意义的测试用例，维护者可以接受完全或部分由 LLM 生成的版本。这个例外背后的设计意图很清楚 —— 测试用例是可以由编译器来判定的产物，人工审查的负担较低，从版权角度看，表达空间通常也比较窄。前面提到的大规模迁移案例里，把测试套件当作机器裁判来用，用的正是同一套逻辑。

新增的义务。 借助了 AI 帮助的工作，必须在提交说明里附上 Assisted-by: 标签。而且必须有人类理解变更内容、能够回答相关问题、并对是否纳入做出批准。DCO 签署只能由人类完成。

这里有一点常被误解，需要说清楚。这项政策并不禁止个人使用 LLM 本身。 把它用于无障碍工具、调研、分析、发现和报告 bug、审查补丁，都是被明确允许的。条件只有一个 —— 那份输出不能原样提交进项目里。也就是说，这项政策想要管控的不是开发者的工作方式，而是进入代码仓库的每一个字节的来源。

最后，这项政策本身也是临时性的。正文写明，预计会随着社区或整个 GNU 项目的立场调整而变化，最迟会在 2027 年初重新审视。而且还附了一句关于态度的话 —— 不论个人对 LLM 持何种立场，都要尊重地对待贡献者，引导其走向合规，而不是简单拒绝。政策文件里出现这样一句话，本身就说明这场争论在社区内部有多激烈。

为什么偏偏是 15 行 —— 版权转让、DCO，以及两条分岔的风险

15 行这个数字并不是新发明的，而是 GNU 项目长期沿用的版权归属判定基准线。低于这个量，通常就很难被视为受版权保护的创造性表达，这是一条实务上的经验规则。AI 政策直接沿用这条既有的界线，这个事实本身就说明了这项政策的性质 ——这不是一项质量政策，而是一项版权政策。

了解了这个背景，就能理解为什么 GCC 格外保守。根据 GCC 贡献指南，FSF 对于大型贡献依然更倾向于要求版权转让，作为替代方案，也接受在提交中附上 Signed-off-by: 标签的 DCO 方式。版权转让之所以存在，理由只有一个 —— 把原告资格集中在一处，让 GPL 违规诉讼真正具备可执行性。Copyleft 是架在版权之上的一份合约，一旦版权本身站不住脚，GPL 也会跟着一起动摇。

LLM 生成的输出，恰恰在这里制造出一个会分岔成两条路的问题。不管走哪条路，对 copyleft 项目都是坏消息。

第一条岔路 —— 如果没有版权。 如果不具备人类作者身份的纯机器生成物不被认定拥有版权，那么给这段代码附加 GPL 条件的依据就会变弱，也就意味着要求再分发者公开源代码的筹码消失了。(美国版权局一直要求具备人类作者身份，这是广为人知的背景，但本文并未直接核实一手资料。)

第二条岔路 —— 如果有版权。 那问题就变成了这份版权到底属于谁。目前没有办法排除它衍生自训练数据里的 GPL 代码或专有代码的可能性，贡献者也就无法诚实地做出 DCO 所要求的那句声明 ——"我有权贡献这段代码"。Gentoo 在政策正文中给出的第一条理由，正是这个 —— 使用这类素材不仅有侵犯版权的风险，还可能削弱 Gentoo 自身的 copyleft 保护。

总结一下，GCC 划下的这条线，并不是在判断"AI 代码不好"，而是在判断"来源链条断裂的代码不能进入 GPL 代码库"。所以基准是 15 行，所以测试用例是例外，所以个人使用是自由的。

其他项目把界线划在了哪里

面对同一个问题，主要项目给出了不同的答案。这里只整理已确认的信息。

Linux 内核与 GCC 之间的对比，最能说明这片格局。内核的官方文档允许 AI 辅助的贡献，但要求以 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] 的格式公开说明，并明确规定 Signed-off-by 只能由人类署名。也就是说，内核选择用把责任固定在人身上的方式来解决问题，而 GCC 选择从源头限制什么能进来。内核这一侧的共识，建立在 Sasha Levin 在 2025 年维护者峰会上推动确立的三条原则之上 —— 人类的责任不可协商、没有人类审查的纯机器提交不受欢迎、工具使用必须公开。

Debian 目前仍在进行中。2026 年 7 月 24 日开始讨论期的这次全体表决中，共有五套方案在台面上，从 Matthias Geiger 的全面禁止方案，到 Lucas Nussbaum 的有条件允许方案、Ian Jackson 的自我克制建议方案、Pierre-Elliott Bécue 的附指南允许方案，再到 Marc Haber 的中立方案，跨度相当大。其中一个有意思的设计是，适用范围仅限于 Debian 自身的工作，不涉及上游 —— 毕竟一个需要打包 Linux 内核的发行版，没办法反过来规范内核本身的 AI 政策。

关于 Qt，我没能确认。 截至本文写作时，我在 Qt 项目的贡献指南里没有找到关于 AI 生成代码的明确条款，因此没有足够的依据把它和其他项目放进同一张表里，就没有列入。

从数字上看整体格局，GCC 这一派其实是少数。根据 Andre Hora 和 Romain Robbes 对 GitHub 星标数前 1,000 的代码仓库所做的研究，在拥有 AI 政策的 118 个仓库中，78% 允许 AI 辅助的贡献(其中 51% 明确表示欢迎，27% 不鼓励但允许)，22% 明确要求克制。51% 要求公开说明，74% 要求必须有人类参与。

对贡献者来说，实际会发生什么变化

把政策文件翻译成实务操作，大致是这样。

如果要给 GCC 提交补丁，对于 15 行以上的代码或文档，不能靠修修补补模型的输出来完成。这不是"改到看不出来就行"的问题，而是 DCO 签署诚实与否的问题。反过来，为了理解代码、寻找 bug、或审查别人的补丁而使用模型，完全没有问题。测试用例可以由维护者自行决定是否接受，所以最好提前问一下。

# GCC: 如果人类写的补丁得到了 AI 工具的辅助
Signed-off-by: Your Name <your@email>
Assisted-by: <工具与模型标注>

# Linux 内核: 格式已经明确规定
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Signed-off-by: Your Name <your@email>

如果同时给多个项目做贡献，需要留意标签在不同项目之间并不一样。Assisted-by: 事实上正在收敛成一种通用做法，但格式和含义还没有统一。在内核里，这个标签不是一种规范性的批准，更接近于日后追踪特定模型引发的 bug 集群时用的取证手段。同一个标签在不同项目里承担着不同的用途。

还留有一块灰色地带。 IDE 的自动补全该算在哪一边？单行补全达不到 15 行的门槛，但一个会话里接受了几十次补全拼出来的结果，又该怎么计算？没有哪个项目的政策对这个问题给出干净利落的答案。实务上唯一真正管用的自我检验标准是"我能不能从头把这段代码解释清楚，能不能回答审稿人的提问"。巧合的是，GCC 政策明确要求的，正是这一点。

这场争论的两边

不倾向任何一方，只梳理真正的分歧所在。

支持限制的一方的论据。 Copyleft 建立在版权之上，来源不明的代码会侵蚀这个根基。一旦不可逆的污染进入一个积累了三十多年的代码库，后面就没有办法把它过滤出去。而且审查负担是真实存在的 —— 过滤掉那些看起来靠谱、实则有问题的补丁，这份成本转嫁给了维护者，curl 在政策里写下"无法证明审查时间合理的贡献"这句话，正是这份负担的证据。Gentoo 给出的三条理由(版权、质量、伦理)中，前两条从项目运营的角度很难反驳。

支持允许的一方的论据。 第一，不可执行性。没有可靠的方法判断提交上来的代码是不是 AI 做的，所以一纸禁令只会过滤掉诚实的贡献者，不诚实的贡献者反而能原样通过。第二，定义的模糊性。把"衍生"读得宽一点，搜索得到的 Stack Overflow 答案和模型告诉你的 API 用法之间的界限就会变得模糊。第三，无障碍访问 —— GCC 政策明确允许无障碍工具，说明这条反对意见确实被提出过。第四，上游早就已经在用了。Debian 把范围限定在自身工作上，正是承认这个现实的一种设计。

两大阵营其实也有共识。 人类要负责任、工具使用要公开、不接受没有人类审查的机器提交物。内核的三条原则和 GCC 的要求，在这一点上实质相同。真正的差异不在原则，而在把门槛设在哪里。内核把门槛设在人类的签名上，GCC 把门槛设在代码的来源上。

在我看来，造成这个差异的真正变量，是项目的法律结构。一个维持着 FSF 版权转让这种执行机制的项目，和一个只靠 DCO 运转的项目，承担同样的风险的方式并不一样。所以与其问"谁是对的"，不如先问一句 ——自己的项目属于哪一种结构。

结语 —— 这项政策关乎的是来源链条，不是代码质量

压缩成三行。

• GCC 划下的界线是 15 行，依据不是 AI 代码的质量，而是要执行 GPL，来源链条就不能断。所以测试用例是例外，个人使用是自由的，提交标签成了新增的要求。
• 格局是分裂的。内核和 curl 以公开说明为条件允许使用，GCC、Gentoo、NetBSD、QEMU 加以限制，Debian 正在就五套方案投票。以前 1,000 个代码仓库为样本，允许属于多数派。
• 两大阵营的共识是人类负责、工具公开、拒绝未经审查的提交。分歧在于门槛设在哪里，而这个位置由项目的法律结构决定。

作为贡献者，眼下能做的最实用的准备，不是把政策文件背下来，而是始终让自己处在能够从头到尾解释清楚所提交补丁的状态。不管哪个项目的政策怎么写，说到底，表达的都是同一件事，只是措辞不同罢了。

参考资料

• GCC AI Policy Announcement —— 邮件列表原文 (2026-07-29)
• GCC AI policy —— 政策正文
• GCC Contributing —— 版权转让与 DCO 要求
• LWN — GCC steering committee announces AI policy
• Phoronix — GCC To Decline Any Significant Contributions Made Via AI/LLMs
• Linux Kernel —— AI Coding Assistants 文档
• Debian — General Resolution: LLM usage in Debian(进行中)
• Gentoo Council — AI policy (2024-04-14)
• melissawm/open-source-ai-contribution-policies —— 各项目政策汇总
• Hora & Robbes — AI Policy, Disclosure, and Human in the Loop (arXiv, 2026-07-13)