【引言跨界者的视角】如果仅看技术履历Linus Torvalds 是 Linux 和 Git 的创造者是过去三十多年开源世界绕不开的人物。然而在这场对谈里更值得关注的是一个长期站在复杂系统中心的人如何理解软件、社区、工具和人。这场对话发生在一场开源技术会议上由 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 和大语言模型的克制态度】谈到 AI 和大语言模型时Linus 态度克制。他把 LLM 视为工具而非魔法。LLM 在发现 bug、生成原型、辅助验证方面有价值能让更多“眼睛”关注过去审查不足的代码角落。但 AI 生成的错误报告、幻觉内容和“创可贴式补丁”消耗维护者资源对 Linux 内核这样的复杂工程LLM 目前无法替代长期维护者的架构判断、工程经验和代码品味。【开源世界的朴素一面】从某种意义上说这场对话不仅是 Linus 对 Linux、Git、Rust 和 AI 的集中回应也呈现了开源世界面对新技术浪潮时最朴素的一面工具、语言、AI 可变化但支撑大型工程长期运转的仍是信任、经验、审查机制和对复杂系统的敬畏。【完整对话内容】以下为完整对话内容“我对技术不是特别怀旧”Dirk Hohndel 开场介绍自己并邀请 Linus 介绍。Linus 表示采用炉边对谈形式是因讨厌公开演讲让别人准备问题能使对话更自然也让他不那么讨厌公开场合。Dirk 询问 Linux 7.1 亮点Linus 称 Linux 版本发布重点是持续、稳定改进2005 年切换到基于 Git 的新开发模式和发布节奏后运行可靠不会做有巨大新特性的版本发布追求持续、增量式改进。虽因 AI 找到 bug 让社区有压力但 Linux 仍保持约每 9 到 10 周发布一个新版本的稳定节奏。该版本有更新后的 NTFS 子系统NTFS 曾是“问题孩子”现两个团队分别维护不同版本可能竞争或长期共存486 支持被移除。Dirk 询问 486 移除事宜Linus 称自己对技术不怀旧维护老旧硬件成本会成负担这次移除 486 支持下一个 7.2 版本将移除浮点仿真代码不再支持 x86 上无硬件浮点单元的机器类似的业余无线电 packet layer、ISDN、ATM 等旧代码也在逐步移除这是清理代码库、确保可维护性的持续改进。“我几乎不写、也不读内核代码了”Dirk 提到合并窗口开启时 Linus 在飞机上合并代码询问此次合并窗口是否有更大规模的 merge request 更早涌入。Linus 称合并窗口稍变大但没后期 RC 增长明显因 AI 工具发现问题并修复部分修复非下一个版本常规开发内容且自己可能过于愿意接受非必要修复。他表示会更明确拒绝一些修复因有人习惯在发布窗口后期提交内核社区发布节奏快等几周放到下个版本问题不大。Dirk 询问合并 PR 前两天有无突出东西Linus 称一般避免旅行时遇上合并窗口合并窗口忙两周约做 200 次合并他不想盲目合并要从高层次理解发生的事发布流程有组织技术问题不焦虑但人际问题更让他紧张。Dirk 询问 Linus 读代码时间和理解代码触及领域的方式Linus 称自己几乎不读代码更像开发负责人依赖信任开源也依赖信任处理 pull request 时想了解大图景要求有好的解释说明这样出现问题能知道方向和查看代码部分自己多年没写“真实代码”。Dirk 询问 Linus 是否还写小东西Linus 称会发 patch 提建议性修复但明确说明未测试期待维护者判断并反馈现在很少直接提交自己的代码。Dirk 提到维护者让 Linus 关注代码的方式是提交破坏构建的 pull requestLinus 会友好指出问题Linus 表示自己在努力变得更好合并时冲突会看代码pull request 解释不充分也会看代码虽不再是严格意义上的程序员但有技术背景能做判断。“不要以为 Rust 能修掉所有 bug”Dirk 询问 Git 是否仍是 Linus 主要工具及有无希望拥有的工具Linus 称 Git 和邮件是主要工具也会用 Google 查东西大多数其他维护者会用更多工具自己强调信任具体的人开源里信任人是因一起工作时间长。Dirk 提到 Git 让 Rust 成为默认开启选项下一个版本 Git 3 中 Rust 将成要求询问是否会在更多领域出现内核也已支持 RustLinus 不确定 Rust 会接管世界认为 C 更简单兴奋于有验证 C 代码的工具如自动化补丁验证工具C 像链锯Rust 像 CNC 机床不同人适合不同工具自己喜欢 C 的力量。Git 支持 Rust 不似 Rust 进入内核是巨大变化Git 早有多种语言并存情况。Dirk 提到有人用 LLM 把现有工具重写成 Rust 出现糟糕 bug询问 Linus 看法Linus 称 Rust 可避免 C 里的简单错误但不能修复逻辑错误不要以为 Rust 能修掉所有 bug内核里一些大 bug 是逻辑错误。Dirk 指出内核中 C 代码和 Rust 代码交互时Rust 的保证只适用于纯 Rust 部分Linus 称与 C 代码交互的 Rust 代码接触的核心 C 代码质量高因已在各平台测试而单独驱动程序测试少内核里代码可靠程度不同Rust 接触的多是稳定、成熟的核心代码。Dirk 提到内核代码结构测试多、审查多、值得信任的是核心代码询问是否如此Linus 给予肯定并鼓励想进入内核开发的人从驱动开始。“AI 可以带来 10 倍提效”Dirk 指出还未谈 AI 和 LLM询问 Linus 之前说的 LLM 带来 10 倍增量效率是什么意思Linus 称那是随口说的数。Dirk 询问 LLM 为 Linux 内核社区带来的生产力提升程度Linus 称现在希望 LLM 创造的生产力超过消耗的生产力年初前 LLM 生成内容中垃圾多现在仍消耗开发者资源收到的 bug 报告需花精力判断是否为幻觉但过去几个月收到很多好的 bug 报告不过大多需人检查确认并参与沟通希望看到建议性补丁也希望运行 LLM 的人参与往返沟通。“对复杂系统要有敬畏之心”Dirk 指出 LLM 擅长找 bug但生成 Linux 内核级可靠代码未被完全说服Linus 表示自己在玩具项目里用 LLM 做原型工具AI 生成的 bug 报告和补丁在简单情况没问题但很多是“创可贴式”补丁未修复底层问题LLM 还未达到长期维护者的层次虽未来可能改变但目前不能替代经验带来的架构级知识。Dirk 询问在场软件工程师使用 LLM 的情况Linus 称 AI 有很多好的用例LLM 找到 bug 整体是好事虽当下可能痛苦但最终会让系统更强。”