“要么Fork，要么走人”：Linus为何对AI态度发生根本转变？

2026年7月18日

从“90%都是营销炒作”到承认AI价值“毫无疑问”，Linux内核最高层维护者Linus Torvalds在2026年7月的公开表态，标志着开源社区与AI关系进入新阶段。

一、核心事件：一封邮件引发的AI路线之争

2026年7月14日，Linux内核邮件列表中出现了一场关于AI代码审查工具的激烈讨论。争议的起点是一个名为 Sashiko 的项目——一套面向Linux内核代码变更的智能体审查系统。

根据Sashiko官方介绍，该项目可以从内核邮件列表或Git仓库中读取补丁，结合Linux内核特定的提示词、协议和工具对代码进行分析，并生成审查意见。项目本身不绑定某一家模型提供商，可配置不同的大语言模型（项目地址：https://github.com/sashiko-dev/sashiko）。

争论的核心在于责任分配：

开发者Laurent Pinchart 提出，维护者如果准备根据Sashiko生成的审查结果采取行动，就应当先自行筛选和验证这些结果，再去联系原补丁作者。他同时引用了软件自由保护组织（Software Freedom Conservancy，简称SFC）针对大语言模型辅助开源贡献发布的建议。
开发者Roman Gushchin 对此提出异议，认为如果要求使用Sashiko的维护者在联系作者之前必须先完整验证AI生成的每条意见，那么Sashiko原本"帮助维护者"的目标就很难实现。他的问题是：Linux究竟是不是一个原则上反对大语言模型的项目。

正是在这一背景下，Linus Torvalds给出了强硬回应：

"Linux不是那些反AI项目之一。如果有人对此有意见，他们可以按照开源的方式，把项目fork出去。或者干脆离开。"

Linus强调，自己愿意以Linux内核最高层维护者的身份在这一问题上"坚决表明立场"。在他看来，AI和编译器、静态分析器、代码搜索工具一样，首先是一种工具。它并不完美，也会制造新的问题，但到了今天，它是否有用，已经不再是一个值得争论的问题。

完整邮件存档：https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/

二、SFC建议：并非"AI禁令"，而是责任框架

值得注意的是，被卷入争论的SFC建议并非一份简单的"AI禁令"。根据材料内容，这份文件包含以下要点：

支持拒绝使用LLM的开发者：开源社区应当支持那些完全拒绝使用大语言模型的开发者，没有人应该在雇主或项目压力下被迫使用AI。
项目可自主决定：项目可以根据维护能力，决定不接收AI生成的贡献。
不应排斥AI贡献者：开源项目不应排斥使用AI的贡献者。
提交前必须充分审核：在提交AI辅助或AI生成的代码之前，提交者必须花费充分时间进行审核，真正理解代码，并披露使用了什么模型、什么版本以及AI如何参与。
"战略性妥协"：对于能够显著加速开源软件改进的场景，SFC将使用专有AI工具描述为一种可以接受的"战略性妥协"。

双方真正的分歧并不是简单的"支持AI还是反对AI"，而是谁应当为AI输出承担验证责任，以及这种责任应该在工具开发者、补丁提交者、维护者和原代码作者之间如何分配。

三、Linux内核的AI贡献规则：允许使用，但责任在人

Linux内核官方已经形成了一套相当明确的AI贡献规则。根据内核文档（https://docs.kernel.org/process/coding-assistants.html）：

基本规则

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

核心逻辑

Linux允许AI参与开发，但最终责任不能交给AI。

Linus在邮件中表示："我们不会强迫任何人使用它。"但他同样不会理会那些试图阻止其他开发者使用AI的人。

对于AI容易犯错的批评，他延续了自己一贯的表达方式："AI并不完美，但批评AI问题的人最好也照照镜子，因为'自然智能也并不总是那么出色'。"

四、态度转变：从"90%是炒作"到"毫无疑问有用"

有意思的是，Linus此次旗帜鲜明地赞扬AI的价值，与他2024年对AI的公开评价形成了鲜明对比。

2024年10月：维也纳开源峰会

据《The Register》报道，在维也纳开源峰会期间的一次采访中，Linus承认AI很有意思，也可能改变世界，但他同时表示，自己非常讨厌科技行业围绕AI制造的炒作。

他当时判断，市场上大约90%的AI叙事都是营销，真正有价值的部分可能只有10%。
由于炒作过于严重，他选择暂时忽略AI。
他认为可能需要五年时间，人们才能看清AI在真实工作负载中的实际用途。
Linus将当时的AI热潮与此前的加密货币浪潮作比较，认为ChatGPT等产品能够制造漂亮的演示，也确实已经进入部分应用场景，但这些事实仍然不足以证明市场上绝大多数宣传。

2026年：AI价值已无需争论

不到两年后，Linus却表示，AI是不是有用已经"毫无疑问"，怀疑这一点的人可能根本没有真正使用过AI。

时间推进到了2026年，AI已经开始在内核漏洞发现、补丁检查和代码审查中提供可以验证的结果。Linus仍然厌恶炒作，也仍然会拒绝低质量的AI输出，只是不再认为"AI有没有用"是一个开放问题。

五、维护者视角：Greg Kroah-Hartman的实测数据

和Linus一样对AI有所改观的，还有Linux稳定版维护者 Greg Kroah-Hartman。

Greg今年3月的表态显示，AI生成的错误报告在此前很长一段时间里质量很差，很多只是浪费维护者时间的"垃圾"。但到2026年初，情况发生了变化：

AI开始提交真实、可复现且质量较高的漏洞报告，这种变化不仅出现在Linux内核，也出现在多个开源项目的安全团队中。

Greg曾使用相关工具进行测试，得到约60个问题和修复方案：

类别	占比	说明
修复方向不正确	约1/3	但通常仍然指向一个相对真实的问题
补丁基本正确	约2/3	但仍需人类进行清理、验证，并按内核流程完成整合

六、隐忧：AI发现漏洞的速度，正在超过维护者处理漏洞的速度

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

2026年5月：安全邮件列表面临管理危机

Linus表示，Linux内核的私密安全邮件列表正在收到大量由AI工具发现的问题。同一个漏洞可能被不同的人、不同的工具反复报告，导致原本用于处理敏感安全问题的邮件列表几乎无法管理。

他对此给出的建议是：

通过AI发现问题的人，不应当只是把原始输出直接扔给维护者。报告者应该阅读相关文档，理解问题，检查是否已经有人报告，最好还能尝试编写补丁。提交者必须在AI结果的基础上增加人类价值，而不是进行一次"路过式报告"。

琐碎修复的风险

在另一次内核候选版本发布过程中，Linus也批评了一些由AI代码审查触发的琐碎修复。他认为：

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

curl项目的观察

以curl项目为例，维护者 Daniel Stenberg 观察到：

明显低质量的AI垃圾报告有所减少。
但更加可信、需要认真验证的AI报告正在增加。
后者虽然质量更高，却也更加消耗时间。
AI让报告产生得更快，并不意味着维护者可以同样快速地完成复现、风险判断和修复。

因此，AI给开源社区带来的未必只是"垃圾内容泛滥"，还可能是一种更难处理的局面：大量报告都不是完全错误的，但每一份都需要人类花费时间判断究竟对了多少。

七、社区争议：务实支持 vs 工作量焦虑

在GamingOnLinux和Reddit等社区中，Linus的言论得到了大量支持，也引发了不少质疑。

支持观点

GamingOnLinux用户minus9：Linus的态度一如既往地务实。即使自己不喜欢AI，"精灵已经从瓶子里跑了出来"，人们无法继续假装它不存在。不过，他也庆幸自己不需要负责清理AI可能制造的混乱。
Reddit用户PlacidTurbulence：部分媒体使用"Linus让AI反对者滚去分叉"这样的标题，夸大了邮件的敌意。按照他的理解，Linus真正表达的是：AI在负责任开发者手中具有实际价值。

质疑观点

GamingOnLinux用户pb：如果一定要找一个可以接受的AI用途，那么让代码审查变得更容易，大概是最合理的场景。问题在于，许多人正在反过来使用AI：不是让AI帮助人类审查代码，而是让AI批量生产代码，再把审核压力交给其他人。
GamingOnLinux用户wytrabbit：并不笼统反对AI，也支持AI用于科学研究、高风险工作和代码漏洞检查，但反对企业以牺牲普通人为代价追逐利润，反对滥用AI进行大规模监控。在代码开发上，他可以接受AI帮助寻找漏洞，却不愿让大语言模型直接生成最终补丁。
Reddit用户：更多开发者把注意力放在AI造成的工作量膨胀上。一位自称从事软件开发的Reddit用户表示，部分同事对AI工具的滥用正在让自己的工作变得更困难。AI大幅提高了代码产出速度，也让一些使用者对输出结果过度自信，最终由其他工程师负责修复和重构。面对仓库中快速增长的代码变更，审查者甚至不得不使用同类AI工具，才能跟上提交速度。
关于"工具论"的质疑：也有人认为，"AI只是工具"是一种过度简化的表述。普通编译器、编辑器和静态分析工具，不会涉及同等规模的训练数据争议、算力消耗、基础设施控制权和就业替代压力。即使AI在代码审查中有效，也不能由此推导出围绕AI的其他社会和经济问题已经得到解决。

八、对AI从业者和创业者的启示

1. AI工具的价值已被主流开源项目确认

Linux内核社区的态度转变具有风向标意义。从"90%是炒作"到"毫无疑问有用"，仅用了不到两年时间。这意味着：

AI在代码审查、漏洞发现、补丁生成等软件工程环节的价值已从理论走向实践验证。
开源社区的接受度正在快速提升，这将为相关工具的商业化铺平道路。

2. 责任框架将成为产品设计的核心

无论是Linux内核的"Assisted-by"标签机制，还是SFC建议中的"充分审核+披露"要求，都指向同一个逻辑：

AI可以辅助，但不能替代人类的最终责任。
工具设计必须内置审核、追溯和责任归属机制。

3. 维护者成本是AI工具落地的最大瓶颈

Greg Kroah-Hartman的实测数据和Daniel Stenberg的观察共同揭示了一个矛盾：

AI降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同样的比例降低维护者验证、沟通和承担风险的成本。

这意味着：

面向开发者的AI工具如果只关注"生成效率"，而不解决"审核成本"，将面临巨大的落地阻力。
能够帮维护者减少验证时间、提高报告质量、避免重复报告的工具，才可能真正被社区接受。

4. "负责任使用AI"将成为分水岭

Linus强调的"提交者必须在AI结果的基础上增加人类价值"，不仅是开源社区的要求，也将成为AI工具能否被广泛采用的关键标准：

单纯批量生成代码/补丁的工具，将面临越来越大的审核压力和社区抵制。
能够提供可解释性、可追溯性、辅助决策能力的工具，将获得更长的生命周期。

结语

Linus Torvalds在2026年7月14日的表态，并非简单地"拥抱AI"，而是为Linux内核社区划下了一条清晰的技术路线：AI是有用的工程工具，但使用它的责任必须由人类承担。

这条路线的背后，是开源社区在两年时间内的快速试错和认知迭代。从质疑到验证，从排斥到规范，Linux内核社区的经验或许可以为整个AI行业提供一个参考框架：

工具的价值不在于它能生成多少代码，而在于它能否在人类的监督下，真正提升工程的效率和质量。

参考链接：

邮件列表讨论原文：https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/
Sashiko项目：https://github.com/sashiko-dev/sashiko
Hacker News讨论：https://news.ycombinator.com/item?id=47427647
Linux内核AI贡献规则文档：https://docs.kernel.org/process/coding-assistants.html
YouTube视频：https://www.youtube.com/watch?v=RIZPuhzy0YU

声明：本文基于公开材料整理，不代表任何平台或机构观点。