Linus 怒怼 AI 反对派:Linux 不搞反 AI

2026 年 7 月 14 日，Linux 内核邮件列表里出现了一封语气很硬的回信。面对开发者对大语言模型工具的抵触，Linus Torvalds 直接表态：Linux 不是一个"反 AI 项目"，不认同的人可以按开源世界的方式 fork 内核，或者干脆离开。

这一表态被外界迅速放大成"AI 反对派滚去分叉"的标题党。但在把邮件列表上下文、SFC 立场、以及 Linux 7.0 / 7.1 期间的实际变化摆在一起看，会发现 Linus 真正反对的不是 AI，而是三类东西：未经验证的代码、没有附加价值的错误报告，以及把审核成本甩给维护者的工作方式。本文尝试回答三个问题：Linux 的 AI 路线为什么走到了这一步、谁要为 AI 输出担责、以及社区目前正在面对的"剪刀差"是什么。

把时间线拉长，会发现 Linus 对 AI 的看法并不是"突变"，而是随着工具本身的变化在调整。2024 年 10 月，在维也纳开源峰会期间，Linus 对《The Register》表示，自己非常讨厌围绕 AI 的炒作，市场上大约 90% 的 AI 叙事都是营销，真正有价值的部分可能只有 10%，他当时判断可能需要五年时间，人们才能看清 AI 在真实工作负载中的实际用途。他甚至把 ChatGPT 的演示与加密货币浪潮类比——漂亮的演示确实存在，但还不足以证明绝大多数宣传。

不到两年后，他在 7 月 14 日的邮件里写下："AI 是不是有用，已经毫无疑问，怀疑这一点的人可能根本没有真正使用过 AI。"这句话看起来像是 180 度翻转，但本质上是事实先变了。Linux 稳定版维护者 Greg Kroah-Hartman 今年 3 月的观察可以佐证：AI 生成的错误报告，在很长一段时间里质量很差，很多只是浪费维护者时间的"垃圾"；但到 2026 年初，情况发生了变化——AI 开始提交真实、可复现且质量较高的漏洞报告，这种变化不仅出现在 Linux 内核，也出现在多个开源项目的安全团队中。

Greg 曾亲自用相关工具做过测试，得到约 60 个问题与修复方案。其中约三分之一的修复方向不正确，但通常仍然指向一个相对真实的问题；另外约三分之二的补丁基本正确。AI 把"找出可疑代码"这件事的成本，降到了一个维护者自己复现一遍就能验证的水平。换句话说，Linus 的态度转变不是因为"他变了"，而是因为 AI 的输出形态从"演示级"走到了"可验证级"，他作为一个工具实用主义者，自然就改了口径。

二、真正的争议，不是"用不用 AI"

7 月 14 日这场争论的具体起因，是一个名叫 Sashiko 的项目。按照官方介绍，Sashiko 是一套面向 Linux 内核代码变更的智能体审查系统，可以从内核邮件列表或 Git 仓库读取补丁，结合 Linux 内核特定的提示词、协议和工具，对代码进行分析并生成审查意见，本身不绑定某一家模型提供商。

争议起点，是 Linux 开发者 Laurent Pinchart 提出的一个原则：维护者如果准备根据 Sashiko 生成的审查结果采取行动，就必须先自行筛选和验证这些结果，再去联系原补丁作者。他同时引用了软件自由保护组织 SFC(Software Freedom Conservancy)针对大语言模型辅助开源贡献发布的建议。

另一位开发者 Roman Gushchin 立即提出异议。如果要求使用 Sashiko 的维护者在联系作者之前，必须先完整验证 AI 生成的每条意见，那么 Sashiko 原本"帮助维护者"的目标就很难实现。问题不应被包装成如何在每个使用场景增加验证环节，而应直接讨论：Linux 究竟是不是一个原则上反对大语言模型的项目。

正是这一句，把 Linus 拉进了对话。他的回答非常清晰：不是，Linux 并不采取反 AI 立场；不认同的人可以 fork，也可以直接离开。 这一表态被外界解读成"AI 反对派滚出社区"，但邮件原文的实际语境，是在为"AI 是否能在 Linux 内核里被使用"这个问题划一条明确边界——可以使用，但责任链由人类承担。

三、SFC 的"中间路线"，被很多人误读了

值得注意的是，被卷入争论的 SFC 建议，并不是一份简单的"AI 禁令"。SFC 确实提出，开源社区应当支持那些完全拒绝使用大语言模型的开发者——没有人应该在雇主或项目压力下被迫使用 AI，项目也可以根据维护能力，决定不接收 AI 生成的贡献。

但同一份文件也强调，开源项目不应排斥使用 AI 的贡献者。在提交 AI 辅助或 AI 生成的代码之前，提交者必须花费充分时间进行审核，真正理解代码，并披露使用了什么模型、什么版本以及 AI 如何参与。对于能够显著加速开源软件改进的场景，SFC 甚至将使用专有 AI 工具描述为一种可以接受的"战略性妥协"。

把这两面放在一起，SFC 的立场实际上是一条非常清晰的"中间路线":既不强制推广 AI，也不一概拒绝 AI；把选择权交给提交者和维护者，但要求所有使用 AI 的人都把责任承担到位。 这种立场与 Linus 的强硬措辞并不矛盾，反而互相印证——Linux 不是反 AI 项目，但 Linux 也不是"免审核"的 AI 试验场。

如果把视角再拉远一点，可以看到开源生态里已经出现了两类不同的项目治理选择。Linux 选择了"开放 + 严格披露 + 责任归属人类";Zig 语言项目则选择了另一端——出台严格政策，直接禁止使用 AI 生成的代码进入仓库。两条路线都基于自身项目的维护能力、技术特征和社区文化做出判断，并不存在"哪一种更正确"的普遍答案。Linus 的"fork 或离开"，本质上是把这条路线选择的权力，交回到愿意承担维护责任的人手里，而不是交给某种抽象的社区共识。

四、Linux 内核官方已经写下的 AI 规则

Linux 并不是在 7 月 14 日才"接受 AI"。在 Linus 发声之前，内核文档已经形成了一套相当明确的 AI 贡献规则。

文档规定，使用 AI 参与内核开发，仍然必须遵守正常的内核开发流程、编码规范和补丁提交要求。AI 代理不能自行添加"Signed-off-by"标签，因为这一标签代表提交者对《开发者原创证书》(DCO)的法律确认，只能由人类完成。提交者必须审核所有 AI 生成的代码，确认许可证兼容性，并对贡献承担全部责任。涉及 AI 辅助时，文档还建议使用"Assisted-by"标签，标明 AI 工具名称、模型版本以及相关的专业分析工具。

这些规则看起来繁琐，实质上是在做一件事：把"AI 参与了哪一段、谁对哪一段负法律责任"这两件事，在代码层面固化下来。 一旦某段代码出了问题，可以反向追溯到具体的人类提交者、AI 工具、模型版本——这与开源协作里"代码即契约"的传统完全一致。

Linus 在邮件里用的措辞虽然强硬，但他没有主张 Linux 内核无条件接受 AI 生成的代码。他的核心判断是，AI 已经成为一种实际有效的工程工具，它会给维护者增加工作量，也会不断找出一些令人尴尬的漏洞，但解决办法不是假装这些工具不存在，更不是通过原则性禁令阻止其他人使用，而是设计流程，让大语言模型真正帮助维护者，而不是只给他们制造麻烦。"我们不会强迫任何人使用它。"Linus 表示，但他同样不会理会那些试图阻止其他开发者使用 AI 的人。

五、AI 发现漏洞的速度，正在超过维护者处理漏洞的速度

Linus 并非没有看到 AI 给维护者造成的负担。就在 7 月 14 日表态前两个月，他还在公开批评 AI 生成的重复报告和不必要的补丁。

今年 5 月，Linus 表示，Linux 内核的私密安全邮件列表正在收到大量由 AI 工具发现的问题。同一个漏洞可能被不同的人、不同的工具反复报告，导致原本用于处理敏感安全问题的邮件列表几乎无法管理。他给出的建议是：通过 AI 发现问题的人，不应该只是把原始输出直接扔给维护者。 报告者应该阅读相关文档，理解问题，检查是否已经有人报告，最好还能尝试编写补丁。提交者必须在 AI 结果的基础上增加人类价值，而不是进行一次"路过式报告"。

在另一次内核候选版本发布过程中，Linus 也批评了一些由 AI 代码审查触发的琐碎修复。这些修改从局部看可能没有错误，却没有必要在版本周期的后期进入内核。即使是看起来简单的改动，也可能引入回归风险。提交者需要回答的不是"AI 是否找到了一处可以修改的代码"，而是这个问题是否严重、是否会造成真实回归，以及是否值得在当前阶段修改。

把这几次表态拼在一起，可以看到 Linus 的 AI 观已经相对完整：AI 可以寻找漏洞、检查代码并协助开发，但发现一个理论问题，不等于产生了一份值得提交的漏洞报告；生成一段能够编译的修改，也不等于形成了一份值得合并的补丁。 AI 负责扩大搜索范围，人类仍然必须判断问题是否真实、修复是否必要、修改是否安全，以及它是否符合项目当前的开发节奏。

这也是整个开源行业正在面对的结构性矛盾。AI 降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同样的比例降低维护者验证、沟通和承担风险的成本。以 curl 项目为例，维护者 Daniel Stenberg 观察到，明显低质量的 AI 垃圾报告有所减少，但更加可信、需要认真验证的 AI 报告正在增加。后者虽然质量更高，却也更加消耗时间。AI 让报告产生得更快，并不意味着维护者可以同样快速地完成复现、风险判断和修复。

六、社区争议的本质：工具已经出现，不代表问题已经解决

在 GamingOnLinux 和 Reddit 等社区中，Linus 的言论得到了大量支持，也引发了不少质疑。支持者通常持务实立场——AI 既然已经从瓶子里跑了出来，继续假装它不存在既不现实也无必要；反对者担心的并不是 AI 本身，而是工作分配的不平衡——AI 让一部分人产出的速度大幅提升，却把验证和返工的成本转嫁到了其他人头上。

一位自称从事软件开发的 Reddit 用户描述了一种越来越普遍的工作场景：部分同事对 AI 工具的滥用，正在让自己的工作变得更困难。AI 大幅提高了代码产出速度，也让一些使用者对输出结果过度自信，最终由其他工程师负责修复和重构。面对仓库中快速增长的代码变更，审查者甚至不得不使用同类 AI 工具，才能跟上提交速度。

另一些讨论则把视角拉到 AI 行业整体的社会成本上。"AI 只是工具"是一种过度简化的表述——普通编译器、编辑器和静态分析工具，不会涉及同等规模的训练数据争议、算力消耗、基础设施控制权和就业替代压力。即使 AI 在代码审查中有效，也不能由此推导出围绕 AI 的其他社会和经济问题已经得到解决。

这些争议的共同点，是它们都不是简单的"支持 AI 还是反对 AI"，而是工具普及之后，工作流程、权责分配、职业结构如何重新安排。Linus 的"fork 或离开"，不是在回应这些宏观争议，而是在内核项目层面把决策权收回到维护者手中——你愿意承担这一类责任，就继续；不愿意，就分叉出去另起炉灶。

七、Linux 的回答，给所有开源项目的启示

把 7 月 14 日的邮件、SFC 的中间路线、以及 Linux 内核文档已经写下的规则拼在一起，可以提炼出三条对所有开源项目都适用的判断。

第一条，是把"是否使用 AI"与"如何承担 AI 输出的责任"分成两件事讨论。 这两件事如果混在一起，任何一方的声音都会盖过另一方。Linus 的表态之所以有效，是因为他只回答了前者("Linux 不反 AI")，把后者留给了已有的内核规则、文档要求和社区惯例。

第二条，是给 AI 贡献设置"可追溯"的具体形式。 Linux 的做法是要求 Signed-off-by 仍由人类完成、Assisted-by 标签要写明工具与模型版本。这些形式看似琐碎，实际是为未来出现争议时，提供可重建的责任链条。开源项目之间技术栈差异很大，但"留下可追溯痕迹"这一原则是可以通用的。

第三条，是承认 AI 改变了维护者的负担结构，但不要把这种改变包装成"新常态"接受下来。 Daniel Stenberg 在 curl 项目里观察到的"高质量报告越来越多、维护时间反而增加"，是一个真实的剪刀差。它不是某一类项目特有的问题，而是 AI 把"发现"与"验证"两件事的成本同时拉低、但拉低的幅度不均衡的直接结果。维护者真正需要的不是更多的 AI 报告，而是降低验证成本的工具和工作流——这恰恰是 AI 在代码审查场景里，下一个值得投入的方向。

Linus 在邮件结尾留下了一句带讽刺意味的话："AI 并不完美，但批评 AI 问题的人最好也照照镜子，因为'自然智能'也并不总是那么出色。"这句话既是他对反对者的回击，也提醒所有依赖 AI 的人：AI 不会替你做判断，也不会替你在出问题时承担后果。 Linux 的 AI 路线，本质上不是对工具的态度，而是对"谁负责任"这个古老问题的重新声明。