📰 AI 资讯

Linus 再谈 AI：大模型能写 Demo，但对复杂系统要有敬畏之心

2026-07-06 18:19

如果只看技术履历，Linus Torvalds 是 Linux 和 Git 的创造者，是过去三十多年开源世界绕不开的人物。但在这场对谈里，更值得看的并不只是他如何评价 Linux 7.1、Rust、C 语言或 AI，而是一个长期站在复杂系统中心的人，如何理解软件、社区、工具和人。这场对话发生在一场开源技术会议上，由 DH Consulting 创始人、资深开源开发者 Dirk Hohndel 提问，Linus Torvalds 回答。两人的关系并不陌生，Dirk 熟悉开源社区的脉络，也知道该如何把 Linus 从“技术细节”引向更大的工程问题。于是，这场对话从 Linux 7.1 发布聊起，一路谈到内核开发节奏、486 等老旧硬件支持的退出、Git 与邮件驱动的协作方式、C 与 Rust 的语言取舍，以及 LLM 正在给 Linux 内核社区带来的真实变化。这场对话最有意思的地方在于，Linus 并没有把技术趋势包装成宏大的叙事，而是始终从工程实践出发。他谈到，Linux 内核已经不追求“惊艳发布”，而是依靠 20 多年来稳定运行的开发节奏持续演进；486、ISDN、ATM 等旧硬件和旧代码的逐步退出，也不是怀旧与否的问题，而是维护成本与代码可维护性的现实取舍。在语言之争上，Linus 依然保持了典型的工程师式直白。他承认 Rust 能减少一部分类 C 语言中常见的错误，但也提醒外界不要神化 Rust：语言无法替人思考，更无法自动修复逻辑错误。相比“Rust 会不会接管世界”，他更关注 C 代码验证工具、自动化补丁检查和代码审查体系的进步。在谈到 AI 和大语言模型时，Linus 的态度同样克制。他把 LLM 视为工具，而不是魔法。它们已经在发现 bug、生成原型、辅助验证方面展现出价值，尤其能把更多“眼睛”投向过去很少被充分审查的代码角落。但与此同时，AI 生成的错误报告、幻觉内容和“创可贴式补丁”也在消耗维护者资源。对 Linux 内核这样的复杂工程而言，LLM 目前还无法替代长期维护者的架构判断、工程经验和代码品味。从某种意义上说，这场对话不只是 Linus 对 Linux、Git、Rust 和 AI 的一次集中回应，也呈现了开源世界面对新技术浪潮时最朴素的一面：工具可以变化，语言可以变化，AI 也可以加入流程，但真正支撑大型工程长期运转的，仍然是信任、经验、审查机制和对复杂系统的敬畏。以下为完整对话内容，经 InfoQ 编译：<h2 data-type="heading" data-id="heading0">“我对技术不是特别怀旧”</h2>Dirk Hohndel：很高兴来到这里，也很高兴再次回到孟买。我已经大概 21 年没来过这里了。我叫 Dirk Hohndel，是一名开源开发者，从事开源的时间可能比在座很多人的年龄都长。你来介绍下你自己吧，Linus。Linus Torvalds：我是 Linus。之所以采用这种有点奇怪的炉边对谈形式，是因为我非常讨厌公开演讲。所以解决办法就是，不让我自己准备演讲内容，而是由别人来准备问题，然后问我一些我事先不知道的问题。这样对话会更自然一点，也让我没有那么讨厌这种公开场合。Dirk Hohndel：这是一个很有说服力的开场。你最近其实是在伦敦希思罗机场发布了 Linux 7.1。这个版本有哪些亮点？Linus Torvalds：我通常会说，从传统意义上讲，Linux 版本发布并没有太多所谓“亮点”。对我来说，真正的重点一直是持续、稳定的改进。我们已经用同样的方式做了 20 多年。2005 年，我们切换到了基于 Git 的新开发模式，也采用了新的发布节奏。一开始大家需要适应，但后来这个模式运行得非常可靠。这也意味着，我们不会做那种带有巨大、炫目新特性的版本发布。我其实会主动避免那种模式。我们想要的是持续的、增量式的改进，让项目一直稳定向前。最近这件事变得稍微困难了一些，因为 AI 找到了一些有意思的 bug，这也让社区里一些人感到压力。但总体而言，Linux 仍然保持着稳定的发布节奏：大约每 9 到 10 周发布一个新版本，并尽量确保它稳定，不让社区感到意外。当然，这个版本也有一些有趣的新东西。比如更新后的 NTFS 子系统，这应该是大家期待已久的，尤其是来自微软的演讲嘉宾可能会很关心。Linux 和 NTFS 的历史一直有点奇怪。多年来，NTFS 一直像个“问题孩子”，维护者也不总是好找。现在突然出现了两个不同的团队，分别维护两个不同版本的 NTFS，而且它们都能工作。所以我就让他们先竞争，看最后哪个版本胜出，也有可能两个版本都会长期存在。这确实算是比较有意思的变化之一。另一个很多人提到、也有点让人伤感的变化是：486 支持被移除了。Dirk Hohndel：是的，很多人都在讨论 486 被移除这件事。能跟我们展开讲讲吗？Linus Torvalds：现场有多少人是在 486 发布时已经出生的？这件事该发生了。可以这么说，我对技术并不是特别怀旧。我当然支持，只要还有用户，我们就应该尽量维护硬件支持。但到某个阶段，继续维护非常老旧硬件的成本会变成负担。这里的问题甚至不只是 bug，而是特性支持。我们终于要移除浮点仿真代码了。严格来说，这甚至不是这次 7.1，而是下一个 7.2 版本里的事情。我们将不再支持那些在 x86 上没有硬件浮点单元的机器。我印象中，最后一批这样的硬件大概是 30 年前发布的，也就是 486SX，大概是 1993 年左右。所以这真的是 30 多年前的硬件。过去我们仍然支持这类硬件平台。它本身也许不需要很多工作，但每次你做变更时，仍然要额外考虑它。因此，现在我们会稍微更主动地移除那些实际上已经没有人使用、只存在于博物馆环境里的硬件支持。最近类似的例子还有业余无线电 packet layer，以及一些无人维护的旧代码，比如 ISDN、ATM 等也在逐步移除。这也是持续改进的一部分。我们需要清理代码库，确保它仍然可维护。Linux 是一个非常庞大的代码库，它永远不会变得“容易维护”，但至少我们不应该让它比必要程度更难维护。<h2 data-type="heading" data-id="heading1">“我几乎不写、也不读内核代码了”</h2>Dirk Hohndel：说到维护的难度，合并窗口开启时，你其实正在飞往孟买的飞机上。也就是说，你坐在飞机座位上就开始合并代码了。过去几个内核版本里，我们看到后期 RC 阶段的补丁量明显增加。那么在这次合并窗口中，是否也出现了更大规模的 merge request 更早涌入的情况？Linus Torvalds：合并窗口确实稍微变大了一些，但没有后期 RC 增长得那么明显。这里面有一个显而易见的原因：现在有很多 AI 工具在发现问题，而这些问题随后会被修复。有些修复不只是下一个版本的常规开发内容，而是我们有时觉得必须比较积极地修掉的问题。但另一方面，我觉得这也有我的责任。我可能有点过于愿意接受那些并非绝对必要的修复了。上一个版本里，我基本上已经告诉大家：冷静一点。如果不是非常重要的修复，请把它排到下一个版本，不要在最后时刻发给我。在座很多人应该都是软件开发者，大家应该都知道：修复确实是在修问题，但偶尔一个修复也会引入新的问题。所以这里有一个平衡。你需要判断：是的，这是一个修复；但如果已经到了发布窗口很晚的阶段，这个修复是否值得承担它可能带来新问题的风险？所以我接下来会更明确地往回推一些。因为我觉得有些人已经太习惯在发布窗口很晚的时候提交修复了。尤其是内核社区的发布节奏本来就比较快，我们大约每 9 周就发布一次，所以说“我们等一下，把这个修复放到下个版本”并不是很大的问题。如果一个修复并不是特别严重，而我们又对它有一点担心，那完全可以先等几周。我觉得过去几个版本有点太大了，这让我担心方向不太对。所以现在我想把这个趋势纠正回来。Dirk Hohndel：那在合并 PR 的前两天里，有什么特别突出的东西吗？Linus Torvalds：没有。我一般会尽量避免在旅行期间遇上合并窗口，因为合并窗口是我最忙的时候。两周时间里，我大概要做 200 次合并，这是一个非常粗略的数字。这也意味着，我不想只是盲目合并。虽然我信任那些长期合作的主要开发者，有些人我甚至已经合作了 30 年，但我仍然觉得，我的工作不只是合并代码，还要从高层次理解正在发生什么。所以合并窗口是一个非常忙的阶段，在飞机上用笔记本做这件事当然谈不上有趣。但同时，它也不是一个特别让我紧张的阶段。我们的发布流程非常有组织，新代码是一个技术问题，而技术问题不会让我太焦虑，因为它们可以被修复。我会经历这两周非常忙的时间，当然最好不要是在飞机上。但真正让我紧张的不是代码，而是偶尔出现的人际问题。相信我，代码很容易修，人格问题、人际问题就不总是那么容易修了。这些事情往往更有压力。虽然大多数时候，希望它们在外界看来是不可见的，因为我们并不想把这些事情变成媒体喜欢的冲突戏码。Dirk Hohndel：你刚刚说到，你希望对进入内核的内容有一个更高层次的理解。但两周内有大约 200 个 merge request，你实际上有多少时间去读代码？你怎么理解这些代码触及了哪些领域？Linus Torvalds：老实说，我现在几乎不读代码了。我已经不是一个程序员了，我更像是一个开发负责人。我知道怎么写程序，也仍然会为了兴趣写代码。但我出于兴趣写的那些项目并不是内核，而是一些我私下玩的玩具项目。在 Linux 内核上，我依赖的是信任。我认为开源本身也依赖信任。我们彼此认识，一起工作了很多年，有时甚至是几十年。我合并的这大约 200 个 pull request，都是来自我长期合作、并且信任的人。当你面对 3500 万行代码时，没有人能真正理解全部代码。所以对我来说，处理 pull request 时，我想理解的是大图景。这也是为什么我要求 pull request 必须有非常好的解释说明，因为我会认真读这些说明。我想知道发生了什么。这样，当之后出现问题时，即便我当时没有读过具体代码，我也能想起来：好，我大概知道这是什么方向的问题，也知道应该去看哪部分代码。这就是我现在工作的层级。我已经很多年没有真正写“真实代码”了。Dirk Hohndel：但你还是写一些小东西吧？Linus Torvalds：我仍然会写代码，意思是我会给别人发 patch。有时我会发一个很小的建议性修复，然后说：也许可以这样做。但我会非常明确地说明：这只是一个建议，没有经过测试。也许我编译过它，有时甚至可能运行过它，但我期待真正维护那部分代码的人来判断，并最终把修复发回来。所以我现在很少直接提交自己的代码。当然，这种情况也会发生，但已经相当少了。Dirk Hohndel：你说你不怎么看代码，这一点很有意思。因为维护者想要获得你“全神贯注关注”的方式之一，就是提交一个会破坏构建的 pull request。那时你就会去看代码，而且你一向以非常“友好和理解”的方式指出问题。Linus Torvalds：我正在努力变得更好。但确实，我会看代码。比如在合并过程中出现冲突时，我会看代码。这种情况一直都会发生，也不是问题。有些人认为冲突很难，但这么多年下来，我已经处理过太多冲突，可能睡着了都能解决。我不担心这个部分。不过，当我看到冲突时，它通常意味着两个不同小组在同一块代码区域同时工作。这时我确实想看一看他们分别在做什么。很多时候，我看代码时会发现一些问题，而这些问题正是因为两个团队同时修改同一部分代码、但目标不同所造成的。另外，当某个 pull request 的解释不够充分时，我也会去看代码。有人给我发 pull request，但说明不清楚，我经常会直接看代码。然后有时我会觉得：哦，原来如此，这说得通。有时则完全说不通，那我就会反对。所以，是的，我也许已经不再是严格意义上的程序员，但我仍然有足够强的技术背景。看到代码时，我仍然能够做判断。<h2 data-type="heading" data-id="heading2">不要以为 Rust 能修掉所有 bug</h2>Dirk Hohndel：我们刚才谈到，Linux 在 20 年前切换到了现在这套开发模式，其中一个重要原因就是 Git 的出现。Git 现在仍然是你处理所有事情的主要工具吗？你还会使用其他工具吗？有没有你希望拥有但现在没有的工具？Linus Torvalds：对我个人来说，Git 和邮件基本上就是我真正使用的两个工具。当然，我也会用 Google 来查东西。也许你们中有人是超人，可以记住行业里所有三字母缩写，但我不是。有人给我发解释，他们可能工作在某个我不熟悉的角落，然后使用那个领域里的各种缩写和简写。我会想：这到底是什么？这时候我就会用 Google。所以从这个意义上说，Google 也是我使用的工具。但大部分时间，我就是读邮件，然后用 Git 做合并。这是我的主要工具。不过我也要指出，我是一个比较特殊的例子。大多数其他维护者会使用更多工具。我认为很多人已经开始使用 AI 工具做 patch 检查。但因为我声称自己是在更高的层次上工作，我面对的是人，而不是工具。这也是为什么我一直强调，最重要的是信任，是信任那个人。我信任的是具体的人。几十年来都是这样。开发者会从一家公司跳到另一家公司，我并不关心他们用什么邮箱，也不关心他们在哪家公司工作，因为我信任的是这个人，相信他能做出判断。我认为很多项目都是这样运作的，但在开源里尤其如此。在公司内部，你可能因为某个人和你在同一家公司，所以信任他；但在开源里，你信任一个人，是因为你和这个人一起工作了很长时间。Dirk Hohndel：Git 当然也是你启动的另一个重要项目。这个月，Git 决定让 Rust 成为默认开启的选项，虽然它目前仍然是可选的；而在下一个版本 Git 3 中，Rust 将成为要求。你认为这种情况会出现在更多领域吗？内核现在也已经把 Rust 作为官方允许和支持的编程语言之一。Linus Torvalds：我不确定 Rust 会接管整个世界。我仍然认为 Rust 非常有意思。但与此同时，我仍然觉得 C 是一个简单得多的工具。所以我个人其实更兴奋的是，现在我们有了很多用于验证 C 代码的工具。很多静态分析工具已经存在很多年了，但我很喜欢的是，现在我们开始有一些自动化补丁验证工具，它们确实带来了实际价值。它们不一定能带来 Rust 那种意义上的安全性，但它们相当于给传统 C 代码里人们常犯的错误多加了一双眼睛。所以，对正在出现的这类工具，我其实非常兴奋。Dirk Hohndel：我们现在也有一些针对补丁的自动邮件检查工具，比如 Sashiko。Linus Torvalds：对。我一直觉得，C 就像一把链锯，而 Rust 更像是一台带有严格控制的 CNC 机床。不同的人适合不同的工具。有些人就是更适合链锯，而我更像是喜欢直接上手、一路砍过去的那种人。我仍然喜欢 C

🔗 查看原文 ↗

← 返回资讯列表