如果说过去两年，开源社区对 AI 的态度还停留在"争论要不要用"；那么现在，这个问题已经被现实彻底改写成了——如何在不可避免使用 AI 的前提下，把风险降到最低？
就在最近，围绕 AI 生成代码的长期争议，终于在 Linux 内核社区落下帷幕：Linus Torvalds 以及 Linux 内核维护者们，正式制定了一套项目级别的 AI 代码使用规范，并将其写入内核官方文档树——Documentation/process/coding-assistants.rst。
简单来说就是一句话：AI 可以用，但你必须对它的一切负责。
一、为什么是现在？三个事件改变了历史走向
过去几个月，Linux 内核社区其实一直处在一种微妙的拉扯中：一方面是越来越普遍的 AI 编程工具，另一方面则是维护者对代码质量、法律风险以及社区文化的深层焦虑。这场争论的最终解决，离不开三个标志性事件的推动。
1. Sasha Levin 事件：一枚硬币的两面
2025 年初，NVIDIA 工程师、知名 Linux 内核开发者 Sasha Levin 向 Linux 6.15 提交了一个完全由大模型生成的补丁——包括变更日志和测试代码。Levin 本人审查并测试了代码，但未向审阅者披露该代码由 AI 编写。
事后证明，这段代码引入了性能回退问题，并在评审阶段误导了其他维护者。连 Linus Torvalds 也承认：因为没有标注 AI，这段代码没有被充分审查。
这一事件成为整个社区讨论的转折点。Levin 本人在 2025 年北美开源峰会上开始倡导正式的 AI 透明度规则，并在同年 7 月提出了内核 AI 政策的首版草案。他最初建议使用 Co-developed-by 标签，但经过激烈讨论，最终改为了更精确的 Assisted-by。
2. cURL 的崩溃：AI 垃圾报告泛滥成灾
如果说 Linux 内核的争议还停留在"开发者之间"；那么 cURL 项目面临的困境，则让整个开源社区看清了 AI 失控的真正代价。
• 2025 年 5 月起，AI 生成的漏洞报告数量激增
• 大量报告包含虚假 CVE（如伪造 CVE-2020-19909）
• 代码片段函数签名不匹配实际 API，无法编译
• 维护者 Daniel Stenberg 公开警告："若在垃圾报告上浪费我们的时间，我们将封禁你并公开嘲讽"
3. GZDoom 社区分裂：透明性一旦被打破，分裂不可避免
同样的冲突并不只发生在服务器端。2025 年 10 月，经典游戏 Doom 的开源引擎 GZDoom 社区爆发严重分裂。
• 项目创始人 Christoph Oelckers 使用未披露的 ChatGPT 生成代码
• 代码注释明确标注："This is what ChatGPT told me for detecting dark mode on Linux"
• 被指出代码质量极低（通过名称是否含 "dark" 判断，被评价为"impressively wrong"）
• 当社区质疑时，Oelckers 直接回应："不满意就分叉（feel free to fork the project）"
二、Linux 内核 AI 政策：三条硬规则
在充分吸收了这些教训之后，Linux 内核社区终于在 2026 年 4 月正式发布了官方 AI 政策文档——coding-assistants.rst。
Assisted-by 标签规范详解
这是整个政策最核心的技术细节。与传统 Signed-off-by 不同，Assisted-by 专门用于标注 AI 参与的工具链信息。
为什么最终选用了 "Assisted-by"？
| 曾考虑的方案 | 最终选择 |
|---|---|
Generated-by — 过于强调 AI 生成，暗示代码可疑 |
Assisted-by — 准确反映 AI 作为工具而非共同作者的角色 |
Co-developed-by — 暗示 AI 是共同作者，引发法律歧义 |
|
AI-assisted — 非标准化，与现有元数据格式不统一 |
三、Linus 的态度：务实主义者的终局
在整个讨论过程中，Linus Torvalds 的立场始终鲜明而务实。
"讨论 AI 垃圾代码这件事，其实毫无意义，这完全就是在犯蠢。在我看来，AI 本质上和编辑器、编译器一样，只是工具。真正需要监管的是'人'，而不是他们用什么工具。"
他对政策文档本身也有明确的期望：
"我不希望任何内核开发文档成为某种 AI 声明。我们有足够多的人站在'天要塌了'和'它将彻底改变软件工程'两边。我不希望内核开发文档采取任何一边的立场。这就是为什么我强烈希望这只是'只是一个工具'的声明。"
四、政策背后的深层法律问题：DCO 的生死劫
如果只看到表面，很容易把这场争论理解为"老派工程师 vs 现代新工具"的代际冲突。但实际上，这场争议的真正内核是法律问题。
开源世界长期依赖一个关键机制：DCO（Developer Certificate of Origin，开发者原创性声明）。开发者在提交代码时，需要声明："据我所知，这段代码受适当的开源许可证保护，我有权在该许可证下提交这段作品，无论是全部还是部分由我创建。"
像 GitHub Copilot、Claude 这样的 AI，是基于海量开源代码训练的，其中包括 GPL 等强限制许可证，以及各种版权不明的数据。这意味着：开发者其实无法完全证明 AI 生成代码的"来源合法性"。
Red Hat 此前曾明确警告：使用 AI 生成代码，可能会在无意中导致开源许可证违规，甚至可能从根本上冲击 DCO 体系。
Linux 内核政策选择绕过这个难题，把问题重新拉回到最传统的工程原则上：谁提交，谁负责。无论代码是你写的，还是 AI 帮你生成的，只要是你提交的——出了 Bug、性能问题，甚至安全漏洞——责任都在你。
五、为什么开源社区对 AI 如此焦虑？
除了法律风险，还有一个更现实的问题：AI 代码太多了，而且质量参差不齐。开源社区甚至给它起了个名字——AI Slop（AI 垃圾代码）。
这些代码往往看起来结构完整、语法正确，但在逻辑上充满漏洞，甚至夹杂大量"幻觉"。
Linus Torvalds 指出的真正难题是：
| 问题类型 | 特征 | 可处理性 |
|---|---|---|
| 明显的 AI 垃圾代码 | 语法错误、逻辑混乱、风格不一致 | 容易识别和拒绝 |
| 看似可信的补丁 | 满足规范、符合风格、干净编译 | 编码了微妙漏洞或长期维护负担 |
社区的执行哲学是："被抓到的后果足够严重"。他们不依赖 AI 检测软件，而是依靠深厚的技术专业知识、模式识别和传统的代码审查。Torvalds 以 2021 年明尼苏达大学学生事件为例警告：试图向内核偷偷塞入劣质代码的人，将永远失去成为任何受人尊敬的开源项目程序员的机会。
六、整个开源圈都在震荡
Linux 内核的政策并非孤例。从 cURL 到 GZDoom，从 Node.js 到 OCaml，开源社区正在集体面对 AI 带来的系统性冲击。
对比来看，Linux 内核社区给出的最终答案，非常"工程师思维"：
代码好不好，比是不是 AI 写的更重要。
你可以用 AI 生成代码，但如果代码有问题、如果它是"AI 垃圾"、如果它把内核搞崩了——点下"提交"的那个人，要亲自向 Linus 负责。
在 Linux 的开源世界里，这大概已经是最强的约束机制了。
七、给国内开源社区的启示
对于国内正在快速成长的开源社区和 DevOps 团队而言，Linux 内核的 AI 政策提供了几个关键参考：
| 维度 | Linux 内核的做法 | 建议借鉴 |
|---|---|---|
| 透明度 | 强制 Assisted-by 标签 | 在项目规范中明确 AI 使用披露要求 |
| 责任归属 | 谁提交谁负责，与工具无关 | 将 AI 生成代码纳入提交者绩效考核 |
| 许可证合规 | 所有代码必须与 GPL-2.0-only 兼容 | 评估 AI 训练数据的许可证风险 |
| 质量门控 | 遵循标准开发流程和代码风格 | 加强 AI 生成代码的 Code Review 环节 |
AI 编程工具的普及已不可逆转。开源社区的选择不是"禁止"或"放任"，而是在承认现实的前提下，建立清晰的责任框架。这或许是 Linux 内核 AI 政策最深刻的意义。