Linus一句话说透AI局限：代码不能直接用，bug只能创可贴式地修

对谈背景

这场对话发生在一场开源技术会议上，由 DH Consulting 创始人、资深开源开发者 Dirk Hohndel 提问，Linus Torvalds 回答。两人关系并不陌生，Dirk 熟悉开源社区脉络，知道如何把 Linus 从技术细节引向更大的工程问题。对话从 Linux 7.1 发布聊起，一路谈到内核开发节奏、老旧硬件支持退出、Git 协作方式、C 与 Rust 语言取舍，以及 LLM 给 Linux 内核社区带来的真实变化。

Linus 始终从工程实践出发，没有把技术趋势包装成宏大叙事。这场对话呈现了开源世界面对新技术浪潮时最朴素的一面：工具可以变，语言可以变，AI 也可以加入流程，但真正支撑大型工程长期运转的，仍然是信任、经验、审查机制和对复杂系统的敬畏。

"我对技术不是特别怀旧"

Linux 7.1 与发布节奏：Linus 强调，Linux 版本发布并没有太多所谓"亮点"，真正的重点是持续、稳定的改进。自 2005 年切换到基于 Git 的开发模式以来，这个节奏运行了 20 多年。他们主动避免巨大、炫目的版本发布，追求增量式改进。

486 支持移除：Linus 坦言"对技术不是特别怀旧"。486SX 大约 1993 年发布，至今 30 多年。继续维护这类硬件的成本变成了负担——不只是 bug，更是特性支持。下一个 7.2 版本将移除浮点仿真代码，不再支持没有硬件浮点单元的 x86 机器。类似的还有业余无线电 packet layer、ISDN、ATM 等旧代码的逐步移除。

Linux 是一个非常庞大的代码库，它永远不会变得"容易维护"，但至少我们不应该让它比必要程度更难维护。

NTFS 子系统：现在出现了两个不同团队分别维护两个不同版本的 NTFS，而且都能工作。Linus 让他们先竞争，看最后哪个版本胜出。

"我几乎不写、也不读内核代码了"

Linus 坦承自己现在更像开发负责人而非程序员：

• 3500 万行代码，没有人能真正理解全部
• 处理 pull request 时想理解的是"大图景"，要求 PR 必须有非常好的解释说明
• 合并窗口两周内大约做 200 次合并，依赖的是对长期合作者的信任
• 仍然会看代码的情况：合并冲突、PR 解释不够充分时
• 偶尔发建议性 patch，但明确标注"未经测试"

真正让我紧张的不是代码，而是偶尔出现的人际问题。代码很容易修，人格问题、人际问题就不总是那么容易修了。

不要以为 Rust 能修掉所有 bug

Linus 对 Rust 的态度典型工程师式直白：

• 承认 Rust 能减少 C 语言中常见的几类错误
• 但语言无法替人思考，无法自动修复逻辑错误
• 最近内核里一些受关注的 bug 就是逻辑错误，不是内存安全问题
• C 像链锯，Rust 像带严格控制的 CNC 机床，不同人适合不同工具
• 更兴奋的是 C 代码验证工具、自动化补丁检查的进步

关于 Git 引入 Rust：Git 早就有多语言并存（Java 版本等），Rust 进入 Git 不像进入内核那样是巨大变化。

AI 可以带来 10 倍提效？

"10 倍"的出处：Linus 坦言那是随口拍出来的数，不是科学数字。

LLM 的真实价值：

• 目前阶段：希望它创造的生产力已经超过它消耗掉的生产力
• 直到今年年初，LLM 生成的垃圾内容比有用代码多
• 好的 bug 报告需要人去检查 AI 生成的报告，确认有效，并在开发者之间扮演中间人
• 反复提醒：用 LLM 找到 bug 不意味着让 LLM 写报告扔过来就够了——需要建议性补丁，需要人参与往返沟通

LLM 的局限：

它们更像是没有思考的"创可贴式"补丁。它们没有修复底层问题。可能修掉了眼前的问题，但同类 bug 还在那里，只是在走廊里等着从另一个地方跳出来打你。

• LLM 生成的补丁缺少来自经验的架构级知识
• 反复提示能改善质量，但今天还不能替代经验丰富的维护者的工程品味
• Linus 个人在玩具项目中使用 LLM 作为原型工具，但生成的代码通常不能直接使用

bug 发现的价值：

• LLM 能找到 bug 整体是好事，即使让人尴尬
• 有些是 20 年前就应该发现的长期严重 bug
• 一个人发现 bug 后，另一个人会问 LLM"那这个相似区域呢"——所以几周内会看到三四个紧密相关的 bug 变成大新闻

核心观点

原始来源

原视频：https://www.youtube.com/watch?v=YKkEe-PxW10

声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。