本文来自微信公众号： InfoQ ，作者：冬梅，原文标题：《“要么Fork，要么走人”！Linus怒怼AI反对派：Linux不搞“反AI”》
Linux创始人、内核最高层维护者Linus Torvalds，再次用一种极具个人风格的方式，为Linux内核社区的AI路线划下了边界。
在7月14日的一场Linux内核邮件列表讨论中，面对部分开发者对大语言模型工具的抵触，Linus明确表示，Linux并不是一个“反AI项目”。
不认同这一方向的人，可以按照开源世界的方式将内核分叉，也可以直接离开。
“Linux不是那些反AI项目之一。如果有人对此有意见，他们可以按照开源的方式，把项目fork出去。”
“或者干脆离开。”
Linus强调，自己愿意以Linux内核最高层维护者的身份，在这一问题上“坚决表明立场”。在他看来，AI和编译器、静态分析器、代码搜索工具一样，首先是一种工具。它并不完美，也会制造新的问题，但到了今天，它是否有用，已经不再是一个值得争论的问题。
1一场围绕AI代码审查的争论
此次邮件列表争论涉及一个名为Sashiko的项目。
按照其官方介绍，Sashiko是一套面向Linux内核代码变更的智能体审查系统。它可以从内核邮件列表或Git仓库中读取补丁，结合Linux内核特定的提示词、协议和工具，对代码进行分析，并生成审查意见。项目本身并不绑定某一家模型提供商，可以配置不同的大语言模型。
争议的起点，是Linux开发者Laurent Pinchart提出，维护者如果准备根据Sashiko生成的审查结果采取行动，就应当先自行筛选和验证这些结果，再去联系原补丁作者。他同时引用了软件自由保护组织Software Freedom Conservancy，以下简称SFC，针对大语言模型辅助开源贡献发布的建议。
另一位开发者Roman Gushchin对此提出异议。
他认为，如果要求使用Sashiko的维护者在联系作者之前，必须先完整验证AI生成的每条意见，那么Sashiko原本“帮助维护者”的目标就很难实现。问题不应被包装成如何增加每个使用场景的验证环节，而应直接讨论：Linux究竟是不是一个原则上反对大语言模型的项目。
正是在这样的上下文下，Linus给出了强硬回应：不是，Linux并不采取反AI立场。
值得注意的是，被卷入争论的SFC建议，也并非一份简单的“AI禁令”。
SFC确实提出，开源社区应当支持那些完全拒绝使用大语言模型的开发者，没有人应该在雇主或项目压力下被迫使用AI，项目也可以根据维护能力，决定不接收AI生成的贡献。
但同一份文件也强调，开源项目不应排斥使用AI的贡献者。在提交AI辅助或AI生成的代码之前，提交者必须花费充分时间进行审核，真正理解代码，并披露使用了什么模型、什么版本以及AI如何参与。对于能够显著加速开源软件改进的场景，SFC甚至将使用专有AI工具描述为一种可以接受的“战略性妥协”。
因此，双方真正的分歧并不是简单的“支持AI还是反对AI”，是谁应当为AI输出承担验证责任，以及这种责任应该在工具开发者、补丁提交者、维护者和原代码作者之间如何分配。
2Linus承认AI有用，但没给AI完全开绿灯
Linus在邮件中用了相当强硬的措辞，却并没有主张Linux内核无条件接受AI生成的代码。
他的核心判断是，AI已经成为一种实际有效的工程工具。它会给维护者增加工作量，也会不断找出一些令人尴尬的漏洞，但解决办法不是假装这些工具不存在，更不是通过原则性禁令阻止其他人使用，而是设计流程，让大语言模型真正帮助维护者，而不是只给他们制造麻烦。
“我们不会强迫任何人使用它。”Linus表示，但他同样不会理会那些试图阻止其他开发者使用AI的人。
对于AI容易犯错的批评，他延续了自己一贯带有讽刺意味的表达：AI并不完美，但批评AI问题的人最好也照照镜子，因为“自然智能也并不总是那么出色”。
Linus随后将问题重新拉回Linux项目长期遵循的原则：Linux内核首先是一个技术项目。
在他看来，开源协作所产生的社会关系、社区认同和公共价值都很重要，也可以成为参与者的动力，但这些属于项目带来的附加收益，而不是Linux存在的首要目的。
Linux内核社区选择开源，是因为开源能够产生更好的技术，而不是因为某种宗教式信仰。因此，涉及AI的决策也应当主要依据技术效果，而不是对新工具的恐惧。
这正是理解Linus立场的关键。他没有论证AI公司是否合理使用了开源代码，也没有否认AI带来的环境、版权和就业问题。他只是拒绝让这些宏观争议，自动转化为Linux内核项目对AI工具的全面否定。
实际上，Linux内核官方已经形成了一套相当明确的AI贡献规则。
Linux内核文档规定，使用AI参与内核开发，仍然必须遵守正常的内核开发流程、编码规范和补丁提交要求。AI代理不能自行添加“Signed-off-by”标签，因为这一标签代表提交者对《开发者原创证书》的法律确认，只能由人类完成。
提交者必须审核所有AI生成的代码，确认许可证兼容性，并对贡献承担全部责任。涉及AI辅助时，文档还建议使用“Assisted-by”标签，标明AI工具名称、模型版本以及相关的专业分析工具。换句话说，Linux允许AI参与开发，但最终责任不能交给AI。
3从“90%是炒作”，到承认AI价值无法忽视
有意思的是，Linus此次旗帜鲜明地赞扬AI的价值，与他2024年对AI的公开评价形成了鲜明对比。
据《The Register》报道，2024年10月，在维也纳开源峰会期间的一次采访中，Linus承认AI很有意思，也可能改变世界，但他同时表示，自己非常讨厌科技行业围绕AI制造的炒作。
他当时判断，市场上大约90%的AI叙事都是营销，真正有价值的部分可能只有10%。由于炒作过于严重，他选择暂时忽略AI，并认为可能需要五年时间，人们才能看清AI在真实工作负载中的实际用途。
Linus还将当时的AI热潮与此前的加密货币浪潮作比较。在他看来，ChatGPT等产品能够制造漂亮的演示，也确实已经进入部分应用场景，但这些事实仍然不足以证明市场上绝大多数宣传。
不到两年后，Linus却表示，AI是不是有用已经“毫无疑问”，怀疑这一点的人可能根本没有真正使用过AI。
时间推进到了2026年，AI已经开始在内核漏洞发现、补丁检查和代码审查中提供可以验证的结果。Linus仍然厌恶炒作，也仍然会拒绝低质量的AI输出，只是不再认为“AI有没有用”是一个开放问题。
和Linus一样对AI有所改观的，还体现在Linux稳定版维护者Greg Kroah-Hartman今年3月的表态中。
Greg表示，AI生成的错误报告在此前很长一段时间里质量很差，很多只是浪费维护者时间的“垃圾”。但到2026年初，情况发生了变化。AI开始提交真实、可复现且质量较高的漏洞报告，这种变化不仅出现在Linux内核，也出现在多个开源项目的安全团队中。
Greg曾使用相关工具进行测试，得到约60个问题和修复方案。其中约三分之一的修复方向不正确，但通常仍然指向一个相对真实的问题；另外约三分之二的补丁基本正确。
当然，这些补丁仍然需要人类进行清理、验证，并按照内核流程完成整合。
4AI发现漏洞的速度，正在超过维护者处理漏洞的速度
Linus并非没有看到AI给维护者造成的负担。就在此次表态前两个月，他还曾公开批评AI生成的重复报告和没有必要的补丁。
今年5月，Linus表示，Linux内核的私密安全邮件列表正在收到大量由AI工具发现的问题。同一个漏洞可能被不同的人、不同的工具反复报告，导致原本用于处理敏感安全问题的邮件列表几乎无法管理。
他对此给出的建议是：通过AI发现问题的人，不应当只是把原始输出直接扔给维护者。报告者应该阅读相关文档，理解问题，检查是否已经有人报告，最好还能尝试编写补丁。提交者必须在AI结果的基础上增加人类价值，而不是进行一次“路过式报告”。
在另一次内核候选版本发布过程中，Linus也批评了一些由AI代码审查触发的琐碎修复。他认为，这些修改从局部看可能没有错误，却没有必要在版本周期的后期进入内核。即使是看起来简单的改动，也可能引入回归风险。提交者需要回答的不是“AI是否找到了一处可以修改的代码”，而是这个问题是否严重、是否会造成真实回归，以及是否值得在当前阶段修改。
这几次表态放在一起，勾勒出了Linus相对完整的AI观：AI可以寻找漏洞、检查代码并协助开发，但发现一个理论问题，不等于产生了一份值得提交的漏洞报告；生成一段能够编译的修改，也不等于形成了一份值得合并的补丁。
AI负责扩大搜索范围，人类仍然必须判断问题是否真实、修复是否必要、修改是否安全，以及它是否符合项目当前的开发节奏。
这也是整个开源行业目前正在面对的矛盾。AI降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同样的比例降低维护者验证、沟通和承担风险的成本。
以curl项目为例，维护者Daniel Stenberg观察到，明显低质量的AI垃圾报告有所减少，但更加可信、需要认真验证的AI报告正在增加。后者虽然质量更高，却也更加消耗时间。AI让报告产生得更快，并不意味着维护者可以同样快速地完成复现、风险判断和修复。
因此，AI给开源社区带来的未必只是“垃圾内容泛滥”，还可能是一种更难处理的局面：大量报告都不是完全错误的，但每一份都需要人类花费时间判断究竟对了多少。
5社区争议：“工具已经出现”不等于问题已经解决
在GamingOnLinux和Reddit等社区中，Linus的言论得到了大量支持，也引发了不少质疑。
GamingOnLinux用户minus9认为，Linus的态度一如既往地务实。即使自己不喜欢AI，“精灵已经从瓶子里跑了出来”，人们无法继续假装它不存在。不过，他也庆幸自己不需要负责清理AI可能制造的混乱。
另一位用户pb表示，如果一定要找一个可以接受的AI用途，那么让代码审查变得更容易，大概是最合理的场景。问题在于，许多人正在反过来使用AI：不是让AI帮助人类审查代码，而是让AI批量生产代码，再把审核压力交给其他人。
用户wytrabbit则采取了更有条件的立场。他并不笼统反对AI，也支持AI用于科学研究、高风险工作和代码漏洞检查，但反对企业以牺牲普通人为代价追逐利润，反对滥用AI进行大规模监控。在代码开发上，他可以接受AI帮助寻找漏洞，却不愿让大语言模型直接生成最终补丁。
Reddit用户PlacidTurbulence认为，部分媒体使用“Linus让AI反对者滚去分叉”这样的标题，夸大了邮件的敌意。按照他的理解，Linus真正表达的是：AI在负责任开发者手中具有实际价值。另有用户回应称，从Linus明确提出“可以fork或离开”来看，这类标题虽然带有修辞色彩，但也并非毫无依据。
更多开发者把注意力放在AI造成的工作量膨胀上。
一位自称从事软件开发的Reddit用户表示，部分同事对AI工具的滥用正在让自己的工作变得更困难。AI大幅提高了代码产出速度，也让一些使用者对输出结果过度自信，最终由其他工程师负责修复和重构。面对仓库中快速增长的代码变更，审查者甚至不得不使用同类AI工具，才能跟上提交速度。
也有人认为，“AI只是工具”是一种过度简化的表述。普通编译器、编辑器和静态分析工具，不会涉及同等规模的训练数据争议、算力消耗、基础设施控制权和就业替代压力。即使AI在代码审查中有效，也不能由此推导出围绕AI的其他社会和经济问题已经得到解决。”
参考链接：
https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/
https://github.com/sashiko-dev/sashiko
https://news.ycombinator.com/item?id=47427647
https://docs.kernel.org/process/coding-assistants.html
https://www.youtube.com/watch?v=RIZPuhzy0YU