📰 AI 资讯

反转？Linus 亲自为 AI 站台并怒怼反对派：AI和编译器一样是工具，不爽就walk away

2026-07-16 17:00

从“90%都是营销炒作”，到明确承认 AI 已经成为有效工具，Linux 创始人 Linus Torvalds 对 AI 的态度似乎发生了明显变化。但如果把他过去两年的公开表态放在一起看，会发现 Linus 真正反对的从来不是 AI 本身，而是未经验证的代码、没有价值的错误报告，以及把审核成本甩给开源维护者的人。Linux 创始人、内核最高层维护者 Linus Torvalds，再次用一种极具个人风格的方式，为 Linux 内核社区的 AI 路线划下了边界。在 7 月 14 日的一场 Linux 内核邮件列表讨论中，面对部分开发者对大语言模型工具的抵触，Linus 明确表示，Linux 并不是一个“反 AI 项目”。不认同这一方向的人，可以按照开源世界的方式将内核分叉，也可以直接离开。“Linux 不是那些反 AI 项目之一。如果有人对此有意见，他们可以按照开源的方式，把项目 fork 出去。”“或者干脆走开。”Linus 强调，自己愿意以 Linux 内核最高层维护者的身份，在这一问题上“坚决表明立场”。在他看来，AI 和编译器、静态分析器、代码搜索工具一样，首先是一种工具。它并不完美，也会制造新的问题，但到了今天，它是否有用，已经不再是一个值得争论的问题。<h2 data-type="heading" data-id="heading0">一场围绕 AI 代码审查的争论</h2>此次邮件列表争论涉及一个名为 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 输出承担验证责任，以及这种责任应该在工具开发者、补丁提交者、维护者和原代码作者之间如何分配。<h2 data-type="heading" data-id="heading1">Linus 承认 AI 有用，但没给 AI 完全开绿灯</h2>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。<h2 data-type="heading" data-id="heading2">从“90%是炒作”，到承认 AI 价值无法忽视</h2>有意思的是，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 个问题和修复方案。其中约三分之一的修复方向不正确，但通常仍然指向一个相对真实的问题；另外约三分之二的补丁基本正确。当然，这些补丁仍然需要人类进行清理、验证，并按照内核流程完成整合。<h2 data-type="heading" data-id="heading3">AI 发现漏洞的速度，正在超过维护者处理漏洞的速度</h2>Linus 并非没有看到 AI 给维护者造成的负担。就在此次表态前两个月，他还曾公开批评 AI 生成的重复报告和没有必要的补丁。今年 5 月，Linus 表示，Linux 内核的私密安全邮件列表正在收到大量由 AI 工具发现的问题。同一个漏洞可能被不同的人、不同的工具反复报告，导致原本用于处理敏感安全问题的邮件列表几乎无法管理。他对此给出的建议是：通过 AI 发现问题的人，不应当只是把原始输出直接扔给维护者。报告者应该阅读相关文档，理解问题，检查是否已经有人报告，最好还能尝试编写补丁。提交者必须在 AI 结果的基础上增加人类价值，而不是进行一次“路过式报告”。在另一次内核候选版本发布过程中，Linus 也批评了一些由 AI 代码审查触发的琐碎修复。他认为，这些修改从局部看可能没有错误，却没有必要在版本周期的后期进入内核。即使是看起来简单的改动，也可能引入回归风险。提交者需要回答的不是“AI 是否找到了一处可以修改的代码”，而是这个问题是否严重、是否会造成真实回归，以及是否值得在当前阶段修改。这几次表态放在一起，勾勒出了 Linus 相对完整的 AI 观：AI 可以寻找漏洞、检查代码并协助开发，但发现一个理论问题，不等于产生了一份值得提交的漏洞报告；生成一段能够编译的修改，也不等于形成了一份值得合并的补丁。AI 负责扩大搜索范围，人类仍然必须判断问题是否真实、修复是否必要、修改是否安全，以及它是否符合项目当前的开发节奏。这也是整个开源行业目前正在面对的矛盾。AI 降低了发现可疑代码、撰写报告和生成补丁的成本，却没有以同样的比例降低维护者验证、沟通和承担风险的成本。以 curl 项目为例，维护者 Daniel Stenberg 观察到，明显低质量的 AI 垃圾报告有所减少，但更加可信、需要认真验证的 AI 报告正在增加。后者虽然质量更高，却也更加消耗时间。AI 让报告产生得更快，并不意味着维护者可以同样快速地完成复现、风险判断和修复。因此，AI 给开源社区带来的未必只是“垃圾内容泛滥”，还可能是一种更难处理的局面：大量报告都不是完全错误的，但每一份都需要人类花费时间判断究竟对了多少。<h2 data-type="heading" data-id="heading4">社区争议：“工具已经出现”不等于问题已经解决</h2>在 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 的其他社会和经济问题已经得到解决。”参考链接：<a href="https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/" title data-type="link">https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/</a><a href="https://github.com/sashiko-dev/sashiko" title data-type="link">https://github.com/sashiko-dev/sashiko</a><a href="https://news.ycombinator.com/item?id=47427647" title data-type="link">https://news.ycombinator.com/item?id=47427647</a><a href="https://docs.kernel.org/process/coding-assistants.html" title data-type="link">https://docs.kernel.org/process/coding-assistants.html</a><a href="https://www.youtube.com/watch?v=RIZPuhzy0YU" title data-type="link">https://www.youtube.com/watch?v=RIZPuhzy0YU</a>

🔗 查看原文 ↗

← 返回资讯列表