4000万行的Linux怎么管？Linus爆料：两周合并1.2万次提交、7周专门抓Bug，“我不是世界之王，只能给内核定规矩”
Linux 内核的宏大叙事：在 4000 万行代码中驾驭复杂性与演进
核心论点
Linux 内核，作为全球最庞大、最关键的开源项目之一，其维护模式深刻体现了在极端复杂性下实现稳定演进的治理哲学。Linus Torvalds 及其维护团队通过高度结构化的发布周期、严格的质量控制（特别是“无回归”原则）以及对流程的精细管理，成功驾驭了每年数百万行代码的迭代。Linus 的角色已从代码贡献者转变为核心流程的架构师和冲突的最终仲裁者，其工作重心在于维护高层次的系统一致性、协调跨领域的交互，以及确保社区对质量标准的共同承诺。同时，面对新兴技术如 AI，内核社区展现出务实而审慎的态度，将其视为提升现有流程效率的工具，而非颠覆性的革命。
一、 维护的密度与节奏：9 周一个版本，1.2 万次提交的挑战
Linux 内核的维护节奏是其复杂性的直接体现。Linus 透露的“9 周一个发布周期”和“合并窗口期处理 1.2 万次提交”的数据，揭示了一个高强度、高吞吐量的维护模式。
1.1 合并窗口期的结构化管理
合并窗口期（Merge Window）是 Linux 内核发布周期中的关键阶段。Linus 将这个阶段严格划分为两个部分：
- 前两周：代码的快速整合（The Integration Phase）：这是 Linus 个人工作最密集的时期。他需要处理来自数百个子维护者的、包含大约 1.2 万次提交的拉取请求（Pull Requests）。这个过程并非简单的“一键合并”，而是涉及对冲突的解决和对高层次架构一致性的确认。
- 后七周：稳定与质量保证（The Stabilization Phase）：在合并窗口结束后，Linus 停止接收新功能，转而专注于发布候选版本（Release Candidates, RC）。这段时间的核心任务是回归测试、Bug 修复和系统稳定性提升。
这种清晰的阶段划分，是应对规模化挑战的有效策略。它将“引入变化”与“稳定变化”的过程物理性地分离，确保在功能整合的混乱期后，有一个专门的时间段用于质量收敛。
1.2 冲突处理的艺术与经验的价值
Linus 强调，他之所以坚持亲自处理合并冲突，是因为经验积累带来的对系统交互的深刻理解。在 4000 万行代码的复杂系统中，不同子系统之间的修改冲突是必然的。
- 信息密度与上下文理解：Linus 认为，虽然子维护者可能比他更了解自己的模块，但他对整个内核的宏观视图和历史上下文的掌握，使他能更好地判断冲突的修复是否会影响到其他不相关的部分。
- 预合并的检验：他提到，有时会要求子维护者进行“预合并”（Pre-merge）测试，并对比自己的结果。这种双重验证机制，体现了对流程严谨性的追求，即便是在高度信任的社区中，也需要交叉验证来捕获潜在的错误。
1.3 维护者的角色转变：从程序员到架构师
Linus 坦言自己“不再是程序员”，这标志着其角色已完全演变为项目治理者和流程的守护者。他的核心职责不再是编写新的功能代码，而是：
- 高层次的系统一致性维护：确保不同团队引入的创新不会在架构层面上相互破坏。
- 流程的执行与仲裁：设定并严格执行发布时间表、质量标准和行为准则。
- 信任网络的管理：依赖其建立的、经过数十年考验的子维护者网络来处理具体的模块级工作。
这种角色转变是任何超大规模、长期存续的开源项目的必然趋势，类似于大型企业中首席架构师或技术委员会主席的职能。
二、 质量控制的基石：“无回归”原则的哲学与实践
Linux 内核维护中“No Regressions”（不允许功能倒退）的铁律，是其得以被全球关键基础设施信赖的根本原因。
2.1 “无回归”的复杂性：时间延迟与依赖链
Linus 深入剖析了“无回归”为何如此难以实现：
- 时间延迟的隐蔽性：一个看似微小的行为改变，可能在数年后才被依赖它的应用发现并暴露为“回归”。例如，一个两年前的变更在当时未被察觉，但随着用户升级到新内核，依赖旧行为的旧应用（可能已无人维护）会崩溃。
- 依赖的不可逆性：一旦回归被引入，社区面临两难：修复它会破坏那些已经适应了“错误”行为的新应用；不修复则违背了核心原则。
2.2 应对回归的“丑陋”解决方案
为了维护稳定性，内核社区不得不采取一些在纯粹工程美学上不那么优雅的手段：
- 行为差异化：Linus 提到，内核有时必须对不同程序表现出不同的行为，以兼容那些依赖旧有行为的遗留系统。这是一种实用主义的妥协，用以平衡创新与兼容性。
- 接口隔离：新的功能应通过新的接口实现，而旧接口保持稳定。这确保了创新不会以牺牲现有稳定性的代价进行。
2.3 社区文化与责任感：对错误的认知
Linus 对社区成员行为的评价，揭示了内核文化的核心价值观：
- 承认错误是底线：Linus 无法容忍的是“不愿意承认自己引入了 Bug”。这表明，在内核的治理结构中，责任归属的透明度比 Bug 本身更重要。一个已知的、可控的 Bug 优于一个隐藏的、不可追踪的错误。
- “前进一步，后退两步”的危害：引入新 Bug 来修复旧 Bug 的行为被视为破坏系统信任的根本原因。这种行为使得维护者无法对系统的当前状态建立可靠的信心。
这种对质量的近乎偏执的坚持，是 Linux 能够成为服务器、嵌入式系统和超级计算机基石的根本保障。
三、 AI 在内核维护中的角色：工具论与历史类比
Linus 对 AI 的看法是务实且去浪漫化的，他将其置于软件工程工具演进的历史长河中进行审视。
3.1 对“AI”一词的厌恶与技术价值的认可
Linus 明确表示对“AI”这个词的炒作感到反感，但他对 AI 作为工具的潜力持高度肯定态度。
- 类比编译器革命：他将 AI 的出现类比于编译器的诞生。几十年前，编译器已经完成了一次“革命”，极大地抽象化了底层细节，使程序员的工作效率呈指数级提升。AI 被视为在这一基础上的又一次效率提升，而非彻底的范式转移。
- 关注点转移：从“生成”到“审查”：Linus 对 AI 编写代码的兴趣远低于 AI 辅助代码审查和维护。对于内核维护者而言，识别和验证代码的正确性（即审查）比生成代码更具价值。
3.2 AI 在代码审查中的实际应用前景
Linus 对 AI 在代码审查中的应用前景表示乐观，并引用了实际案例：
- 发现专家遗漏的问题：他提到一个案例，AI 工具不仅发现了 Linus 已经注意到的问题，还额外发现了一些专家未察觉的 Bug。这证明了 AI 在模式识别和大规模数据分析方面的优势，能够作为强大的“第二双眼睛”。
- 提升工作流效率：如果 AI 能够在代码到达 Linus 之前就拦截掉低级错误和已知的回归模式，将极大地减轻他合并窗口期的压力，使他能专注于更复杂的架构决策。
3.3 AI 对新贡献者的潜在帮助
关于 AI 是否能降低新人参与内核开发的门槛，Linus 认为是有帮助的，但保持了审慎：
- 抽象层级的提升：AI 提供了更高层次的交流界面。贡献者可以用更自然、更少底层细节的方式表达意图，AI 可以将其转化为更符合内核规范的代码或补丁，从而降低了新手理解复杂规范的难度。
- 内核的特殊性：尽管 AI 有帮助，Linus 依然提醒，Linux 内核是一个高度专业化和复杂的领域，不一定是编程入门的最佳起点。
Linus 总结道，AI 带来的不是“魔法”，而是更强大的工具，它将使人类能够构建更多、更好的项目，但其本质仍是工具论。
四、 治理的边界与社区的责任
Linus 对其权力的界定——“我不是世界之王，只能给内核定规矩”——是理解 Linux 治理模式的关键。
4.1 权力范围的自我约束
Linus 的权威性源于其对内核的最终控制权（Merge Authority），但他明确将这种权力限定在 Linux 内核项目本身。
- 流程的制定与执行：他制定了关于发布节奏、质量标准和行为规范的“规矩”。
- 不对外扩张：他无法干预其他开源项目（如 Python 社区）的行为，即便这些行为可能间接影响到依赖 Linux 的用户。这种自我约束，是开源治理健康运作的体现，避免了中心化权威的过度膨胀。
4.2 社区的共同责任
Linus 对“回归”的坚持，实际上是在要求社区成员承担起对整个生态系统的责任：
- 超越个人兴趣：内核开发者不能仅仅追求“有趣”或“创新性”的改动，而必须考虑其代码对数百万依赖者的影响。
- 长期维护的承诺：一个被广泛依赖的基础设施项目，要求贡献者具备长期、负责任的维护心态，而不是“写完就走人”的心态。
结论
Linux 内核的成功，并非源于某一个天才程序员的持续编码，而是源于 Linus Torvalds 建立的一套精妙的、以质量为核心的、高度结构化的维护体系。在 4000 万行代码的背景下，Linus 的核心工作是流程管理、信任维护和冲突仲裁。他通过严格的发布周期和“无回归”原则，将不可避免的复杂性转化为可预测的演进路径。
面对 AI 浪潮，内核社区的态度是审慎的工具采纳者，专注于利用 AI 来增强现有的审查和稳定化流程，而非盲目追求生成式编程的炒作。Linus 的言论清晰地描绘了现代大型开源项目维护者的画像：他们是流程的工程师，是质量的守护者，也是在宏大叙事中，为无数依赖者构建稳定基石的幕后英雄。
今年年初，Linux 内核的代码行数突破了 4000 万行。
而作为这个庞大项目的掌舵者，Linus Torvalds 对外宣称自己“已经不再是程序员”、“不再编程”了，那么，他在整个项目中到底负责什么？
又是如何把控、维护这个项目的？
他会用 AI 来做内核工作吗？
近日，Linus Torvalds 出席了 Linux 基金会在日本举办的开源峰会，与 Verizon 开源项目办公室负责人 Dirk Hohndel 展开了第 29 次对谈（https://www.youtube.com/watch?v=yEzdHYjY_RU）。
其二人聊到了 Linux 内核维护的高密度节奏、合并窗口期的挑战，以及 AI 在代码中可能扮演的角色。
Linus 表示，在 Linux 内核的世界里，没有捷径可走，他们每 9 周发布一个版本，一个合并窗口期里，自己通常要处理大约 12,000 次提交，算上合并后的提交大约在 11,000 到 13,000 次之间。
其中，他会花两周时间用来合并代码，接下来的七周则用于查找并修复 bug。
值得关注的是，Linux 内核维护中有条铁律：no regressions——不允许功能倒退、不允许引入回退性问题，也不能破坏向后兼容性。
Linus 称，真正让自己完全不能接受的行为是，是有人不愿意承认是自己引入了 bug。
至于 AI，Linus 也直言自己的态度：“我其实很讨厌‘AI’这个词，不是因为讨厌技术本身，而是因为它被炒得太厉害，好像现在所有事情都非 AI 不可。
”他指出，「AI 和当年编译器的出现，本质上是一样的。
别觉得 AI 会突然彻底改变编程，这件事我们早就经历过了——几十年前写编译器的那些人已经完成过一次革命。
」以下是这场对话的完整内容：最新的 Linux 版本还是一如既往的“枯燥”Dirk Hohndel：早上好，我是 Dirk Hohndel，在 Verizon 负责开源业务，Verizon 是美国最大的移动运营商。
Linus Torvalds：我是 Linus Torvalds。
我们已经这样对谈过很多次了。
我不喜欢做演讲，也不做 Keynote。
对我来说，更愿意和 Dirk 进行这种对我来说“毫无准备”的问答环节，而且我们已经这样聊了很多年了。
Dirk Hohndel：没错，这是我们的第 29 次对谈。
那，Linus，你的职业版图是不是又扩展了？
听说你现在成了 YouTube 明星了？
Linus Torvalds：不不不。
我确实在几周前录了一个 YouTube 视频，大概是上周发布的。
但说实话，这也确实是我在 Linux 事业中乐在其中的一点——我可以去做一些平时通常不会做的奇怪事情。
我拍了这个 YouTube 视频，我觉得对我来说这已经足够了。
Dirk Hohndel：总之，看到你在一种完全不同的对话场景中出现真的很有趣。
但现在我们还是回到我们更常规的交流方式上。
Linux Kernel 6.18 上周发布了，你能给我们介绍一些亮点吗？
有什么值得关注的内容？
Linus Torvalds：对我来说，亮点就是它“一如既往，还是老样子”。
我喜欢“枯燥”、平淡无奇。
当你开发的内核被所有人依赖时——无论是手机还是超级计算机——你真的不希望有太多的意外和刺激。
我已经做了 35 年了，我觉得核心词应该是“稳步推进”。
我们最近做了相当多的清理工作。
当然，其中很大一部分依然是对新硬件的支持，这是不断更迭的部分。
内核的工作大约有一半实际上就是硬件驱动程序。
Dirk Hohndel：我觉得关于 6.18 很重要的一点是，它是下一个 LTS（长期支持）版本。
它做了大量的清理、许多细小的改进，而不是巨大的、颠覆性的生态系统变动，这也是项目目标的一部分。
这是设计的有意为之，还是仅仅是巧合？
Linus Torvalds：这是设计使然，虽然这种“设计”也是多年来逐渐演变而成的。
我相信 Greg（Greg Kroah-Hartman）现在就在观众席的某个地方，他负责维护长期支持版本，并接手特定版本，进行多年的维护，这样无论是大公司、小公司还是个人，都能有一个可以长期依赖的标准版本。
Dirk Hohndel：Linux 过去通常不会预先宣布哪个版本将是下一个 LTS 版本，但这在几年前改变了，现在一般是每年的最后一个版本。
Linus Torvalds：我不认为这是官方提前公布的事情，但大家大概能猜到会发生什么。
我们有计划，但它也是灵活的。
Dirk Hohndel：过去我们不预先宣布的原因是为了避免那种“为了赶上版本而匆忙合入代码”的情况吗？
Linus Torvalds：我们曾经遇到过这样的问题：当人们知道某个版本将成为下一个 LTS 时，就会拼命想把功能塞进去。
这会导致问题，因为原本应该是最稳定的内核，有时反而因为人们急于合入新代码而变得不稳定。
但我觉得大家现在已经非常习惯我们的工作方式了。
即便你知道预期是什么，那种“冲刺感”也没那么强了，因为大家已经见证这种机制运行了这么久。
他们知道如果错过了一个 LTS 版本，下一个总会到来。
而且大多数依赖 LTS 的公司也知道，一年的时间其实很短。
9 周一个发布周期，大约会收到 12,000 次提交
Dirk Hohndel：就像你说的，这个流程已经持续了很久，大约 20 年了。
现在你正处于下一个内核的合并窗口期，大约完成了三分之二。
我今天真的很想聊聊这个：请带我们了解一下这个过程，对你来说，“合并窗口期”意味着什么？
Linus Torvalds：合并窗口期间是我非常忙碌的一段时期。
我会接收维护者们认为已经为下一个内核准备就绪的所有新代码，并没有一个硬性的“功能规则”来规定下一个内核必须包含什么。
它本质上是关于“这些代码现在准备好了”，所以当合并窗口开启时，我们就可以进行整合。
事实证明，这对我这个维护者以及开发者来说，压力都小得多。
因为没有一个绝对的截止日期说“你的代码必须在某月某日准备好”。
它更像是“代码什么时候准备好了，它就会被合并”。
既然我们大约每两个月（确切地说是 9 周）发布一个版本，如果有人错过了一个版本，他也知道再过 9 周下一个发布周期就会开始。
这真的减轻了开发过程中的很多压力。
不过，对我个人而言，那两周确实很忙。
我需要合并所有新代码。
如果其中一周正好赶上出差，而且明天还要参加内核维护者峰会，这意味着上周我在赶飞机前尝试完成所有工作，压力确实比平时大一点。
Dirk Hohndel：但你刚才略过了我真正想了解的部分。
那你具体是做什么的？
Linus Torvalds：我现在已经不写代码了，如果你是想问这个的话。
实际上，我做的事情是：把别人开发的、由别人维护的代码整理起来，然后当这些子维护者觉得某个代码模块准备好了，就会发给我一个 pull request。
我来合并它。
一个合并窗口，我通常会收到大约 12,000 次提交。
如果算上合并后的提交，大约在 11,000 到 13,000 次之间。
它们是通过几百个 pull request 发给我的。
所以在第一个星期，我几乎一直在合并代码，这不只是朝九晚五，是从早到晚，整整一周都在做。
第二周我会放慢节奏，处理一些滞后的提交，有些是因为我需要仔细检查，有些只是提交晚了。
总之，两周时间处理所有新功能，然后我就停止接收新功能。
在之后的 7 周时间里，我们会尝试找出所有的 Bug，尝试修复所有的 Bug，并让内核处于尽可能好的状态。我们做这个流程已经很久了，也越来越熟练。在那个阶段，我会发布每周的候选版本（Release Candidates），直到发布最终版本。对于 LTS 版本和所有版本，之后都会有一段时间的稳定维护期。
“在合并窗口的前一天收到 PR，会惹毛我，却也总有人想试试”Dirk Hohndel：我觉得很有意思的是，要让你真正讲你在做的有趣的事情，可不容易。
因为凡是合并过不同 pull request 的人都知道，这从来不是“点一下就好了”。
你要在两周内合并 12,000 个提交、几百个 pull request，不可避免会遇到冲突和各种挑战。
Linus Torvalds：我合并这么多次了，现在几乎可以闭着眼睛合并了。
很多人应该也都了解，当两个人修改了同一片代码区域，出现冲突时会发生什么。
我几乎每天都在处理这种情况，对这种合并已经很熟练了，以至于我让子维护者不要帮我提前合并。
即便他们比我更了解自己的模块，我合并的经验也比绝大多数人都丰富，所以我更喜欢自己来合并。
原因有两点：一是我能清楚知道哪些地方发生过冲突，这对我很重要，我想知道不同团队在同一区域的交互情况；二是如果冲突比较复杂，我有时会让子维护者先在测试目录里做预合并，然后我再比对我的结果。
这样我有时候会发现自己合并的问题，但更常见的是发现他们的预合并有问题。
所以这就是我做的事情。
我很久没真正写代码了，我会给别人发代码片段说“嘿，可以这样改”。
但我真正做的，是保持对整个项目的高层次理解，合并不同团队的代码，知道大局发生了什么，也能判断什么时候两组代码冲突。
你想想，Linux 内核里面有 4000 万行代码和文档、几百个维护者、每次发布都有几千个开发者参与，每九周一次，这就足够我跟进了。
我不会纠结小细节，那交给我信任的开发者和子维护者去做。
我关注的是维护、流程，确保发布计划合理、内核运作正常。
这就是我的工作。
Dirk Hohndel：这很有趣，因为我接下来的问题正是：你多久会看一次这些代码，即进行代码审查？
多久会遇到合并冲突，然后说“嗯，这里不对”？
Linus Torvalds：当冲突发生时，我不仅想知道冲突本身，还要理解代码，这样我才能确保冲突修复是正确的。
现在我看得最多的就是冲突代码。有时候我看完代码就会说：“哦，这里写错了。”这种情况几乎每个合并窗口都会发生。就几天前，我合并一个提交时出现冲突，我看了冲突的代码，发现问题出在有人提交的代码上有明显错误，然后我就从 tree 上撤回那段代码，并要求发送代码的人给出解释。
所以这就是我现在仍然涉及的编程部分——我会看代码、会修改代码，但我是以维护者的身份，而不是开发者身份去做。Dirk Hohndel：我想在场有不少人都做过 Git 合并。哪怕只是偶尔做一次，但想到要在两周内处理几百个 merge，都会觉得压力很大。那在你做了这么多年、流程也这么成熟、大家也都很有经验的情况下，有没有什么“雷点”？哪些事情最容易把你惹毛？
Linus Torvalds：有那么几个。
一个是时间点。
我偶尔会收到别人在星期六发来的拉取请求，也就是我正准备结束合并窗口的前一天。
我心里就会想：“不是说好代码应该在合并窗口前就准备好的吗？
现在我正准备收尾、让节奏慢下来、准备第一个 RC，你却在这时候发过来。
”有时候我会直接说：“不行，等下一个版本吧，再等九周。
因为你太晚了，你本该更清楚。
”其实大家都知道这个道理，但有时候还是会有人这样试一试。
我觉得大概就是这么回事。
另外一件让我比较恼火的事是——我不只是合并代码，我每天都会运行自己的内核。
我不会每合并一次就重启，但我会在自己所有机器上用最新的内核。
也就是说，每一个版本我都会自己用一遍，而几乎每次发布我都会发现 bug。
这本不该发生。
我做的事情并不奇怪，我的机器也很普通。
如果我都能遇到 bug，那说明有人在提交前根本没有好好测试。
如果问题严重到我是第一个发现的人，我确实会有点不爽，有时也会给维护者发邮件，直接说：“你这次没把工作做好。
”Dirk Hohndel：语气会很客气吗？
Linus Torvalds：不一定。
我通常还是尽量保持礼貌的，但有些人我已经合作了几十年，当我觉得他们明明应该更清楚的时候，语气确实会变得有点冲。
真正让我完全不能接受的，是有人不愿意承认自己引入了 bug。
出 bug 本身没问题，这是不可避免的。
我们并不完美，再小心也会犯错，这很正常，我不会为这个生气。
但当别人指出 bug 时，你应该站出来说：“抱歉，那是我的错，我会修复它。
”可有时候我收到的回应是：“我修了另一个 bug。
”这就不行了。
这不是“前进一步、后退两步”的问题。
你不能拿“我修了一个 bug，但又引入了另一个”当借口。
这只会让系统变得不可信。
说实话，我宁愿有一个大家都知道、可以绕开的老 bug，也不愿意 bug 到处跑、让人完全没法应对。
所以内核里一直有一个非常严格的原则：不允许产生回归（no regressions）。
这并不意味着回归不会发生，而是说一旦发生，我们就要认真对待，而不是说一句“是回归，不过……”就算了。
所以确实有几件事特别容易触发我的情绪。
我也一直在努力让自己更克制一点，让自己变得有礼貌。
如果我曾经伤到过在座某些人的感情，我在这里道歉。
我也会有压力，大家都会有。
归根结底，我们都是人，犯错是难免的，而我们建立这些流程，就是为了尽量把错误的影响降到最低。
“我很讨厌‘AI’一词，但我非常相信 AI 作为工具的价值”Dirk Hohndel：你刚才也提到，你做这件事做了这么久，已经非常熟练了。
但我在想：有没有什么工具能让这件事更轻松？
毕竟现在是 AI 的时代，大家都在谈 AI……Linus Torvalds：好一个转折（笑）。
Dirk Hohndel：我觉得这并不突兀。
其实正好呼应了你刚才讲的那些内容：代码合并、冲突处理、bug 处理。
有没有可能，用一些工具，甚至是 LLM 这样的现代 AI 系统，来减轻你的工作负担？
Linus Torvalds：当然可以。
我们本来就是一个高度依赖工具的开发环境，用来检查代码的工具非常多。
明天我们要参加年度维护者峰会，其中一个重要话题就是：在使用 AI 工具这件事上，我们该如何扩展现有工具链和相关规则。
我其实很讨厌“AI”这个词，不是因为我讨厌 AI 技术本身，而是因为它被炒得太厉害了，好像现在所有事情都非 AI 不可。
但话说回来，我非常相信 AI 作为工具的价值。
我们已经有一些项目在用 AI 做代码审查。
就我个人来说，因为我是维护者，代码审查对我非常重要，所以我对“用 AI 写代码”反而没那么感兴趣。
很多人一谈编程就想到用 AI 写代码，但在我看来，这远没有“用 AI 来帮助维护代码”有意思。
这是完全不同的方向，而且我们已经有好几个相关项目在推进了。
我不确定哪些已经公开讨论过，其中不少是在公司内部，把 AI 作为现有工具链之上的一层，用来检查补丁、避免发布有问题的代码。
理想情况下，它们甚至能在代码到我这里之前就把问题拦下来，那我的工作流也会轻松很多。
这件事其实已经讨论了很久，现在我也开始看到一些 AI 代码审查的实际案例，其中有些非常有前景。
所以我对这件事很有信心，希望明年它能成为我们工作流程中一个相当重要的组成部分。
Dirk Hohndel：出于保密原因我就不点名了，不过现在确实有一个工具正在开发中。
你最近刚好用分析了一个有 Bug 的改动。
那个 AI 工具在识别和解释问题方面表现得非常出色。
Linus Torvalds：对，那次其实不是我亲自用的，而是在某家公司内部完成的，我只是看到了最终结果。
当时我就想：“对，这个工具我想要。
”那确实是个很好的例子，而且事情就发生在这一次合并窗口里——我对那个改动本身就有意见，而那个 AI 工具不仅找出了我提出的那些问题，还额外发现了一些。
这一直是个非常好的信号：当一个工具连专家没注意到的东西都能发现，那就说明它真的有价值。
所以这一点毫无疑问——炒作确实很多，甚至有点过头，但技术本身也确实很有意思。
当然，现在所有 AI 公司基本都在用 Linux，Linux 也是大多数 AI 工作负载的基础。
但反过来，用 AI 来帮助 Linux 内核开发，这件事我们其实还做得不多，不过这一点肯定会到来。
AI 如同当年的编译器，别觉得 AI 会突然彻底改变编程Dirk Hohndel：我很喜欢你刚才说的一个观点：真正的突破点在“审查”和“解释”上。
不过我注意到，每次合并窗口回顾时，贡献者数量和新贡献者数量都非常高。
我在想，LLM 这种 AI 工具，能在多大程度上帮助新人入门？
毕竟内核有 4000 万行代码，流程复杂、工具繁多，想真正开始参与内核开发之前，要学的东西实在太多了。
那在流程的另一端、也就是最开始的阶段，你觉得这些工具能不能降低门槛，让更多人更容易参与进来？
Linus Torvalds:：我觉得是可以的。
不过先说一句，内核里已经有很多开发者了，而且说实话，内核并不一定是你入门编程的最佳起点。
内核是个很特殊的领域。
当然，我也认为内核是编程世界里最有意思的地方之一，所以我很推荐大家去了解、去尝试。
但如果你刚开始学编程，也许可以先从规模更小、复杂度没那么高的项目入手。
总体来说，我把 AI 看作是任何人都可以使用的工具。
它确实新鲜、也很有吸引力，但同时它又并不陌生。
它和当年编译器的出现，本质上是一样的。
你得意识到，我刚入行的时候，编译器其实很糟糕，而今天编译器能做的事情简直像魔法。
现在的编译器，让程序员不用了解那么多底层细节就能完成工作，这本身就是一次巨大的飞跃。
有人总爱说 AI 能带来“10 倍效率提升”，但编译器带来的是上千倍的提升。
所以 AI 并没有那么“特别”。
别觉得 AI 会突然彻底改变编程，这件事我们早就经历过了——几十年前写编译器的那些人已经完成过一次革命。
如果 AI 在此基础上再带来 10 倍、甚至 100 倍的提升，那当然很好，它会让我们能做出更多、更好、更有意思的项目。
但归根结底，它依然只是个工具。
这就是我的看法。
当然，如果 10 年后机器人统治世界、把我们都干掉了，那我就承认我说错了。
Dirk Hohndel：AI 工具和编译器之间的区别是：AI 工具在犯错时要有礼貌得多。
当它弄错时，例如 Claude 会说：“哦，是的，你说的对，我弄错了，很抱歉”。
从来没有编译器对我这么说过。
Linus Torvalds：我听说有人专门用内核相关的数据训练了一个 AI，不只是代码，还包括内核邮件列表的内容。
结果他们后来发现，得教这个 AI 少说脏话，因为它学到的表达方式并不总是那么有礼貌。
这听起来也许只是个玩笑。
但我真正喜欢 AI 的地方在于，你不需要向它解释所有底层细节。
相比之下，当你试图向编译器说明你的意图时，往往必须在非常底层的层面把事情说清楚，这个过程既繁琐又费力。
AI 的优势在于，它提供了一个额外的抽象层。
你可以用更高层次的语言去表达你的想法，而不只是告诉系统每一步该怎么做。
这一点让人类完成事情变得更容易，也更高效。
所以我对 AI 抱有很大的期待。
Linux 铁律：拒绝出现回归Dirk Hohndel：我这里还有 12 个关于 AI 方面的问题，但为了能“活着”离开这间屋子，我还是换个话题吧。
你刚才提到了，我们有这样一条规则：在内核中，不允许回归（no regressions），也不能破坏向后兼容性。
有意思的是，真正能长期坚持这项原则的项目并不多。
在来这里的路上我们还聊到，Python 3.14 的一次更新，导致你正在使用的一个业余项目工具失效了。
那么，为什么做到“不破坏现有功能”这么难？
Linus Torvalds：从技术角度看，这件事确实很难。
并不是所有的内核开发者都喜欢我这条“不许产生回归”的规则，要长期坚持这一规则确实很辛苦。
问题在于，所谓的“回归”，往往不是马上就能发现的。
比如某个行为在两年前改变了，但当时大家都在运行旧的 LTS 内核，并没有察觉异常。
等到两年后，他们升级到新内核，才发现某个细节和以前不一样了，而这个差异恰好破坏了他们的特定应用。
更麻烦的是，两年的时间已经过去，其他应用程序可能已经开始依赖这种“新的行为”。
这时我们就会陷入一个非常棘手的局面：如果去修复当初的回归，就会影响那些已经适配了新行为的程序，等于制造新的回归。
所以这件事远没有听起来那么简单。
嘴上说一句「不许产生回归」很容易，真正坚持下去却极其困难。
为了守住这个原则，我们不得不做出一些非常极端的选择。
比如，在内核中，对不同的程序表现出不同的行为——因为我们很清楚，某些程序期待的是旧的行为，而另一些程序已经建立在新的行为之上。
站在软件工程师的角度，你其实并不想这样做，这种方案本身是“丑陋”的。
还有一个现实问题是，很多人，尤其是在开源社区里，之所以投入时间做这些事情，本身就是因为热爱编程。
而对开发者来说，“有趣”的事情，往往是做一些和过去不一样的、带有创新性的改动：你引入了新的行为，从旧的模型中学到了很多，也可能觉得旧的设计本身就是错的，于是想把它修掉。
这种冲动完全可以理解。
但如果你开发的是一个被他人依赖的库，或者是一个被库依赖、进而被无数人依赖的内核，你就不只是在修复你自己的 Bug，你是在破坏所有依赖你项目的程序。
开发者或许会很容易说一句：“我已经把问题修好了，你去重新编译你的应用吧。
”但现实是，很多应用依赖的，可能是一个 30 年前写成、如今早已无人维护的库。
当底层基础设施悄然改变了行为，修复这类问题往往几乎不可能。
这就是为什么内核一直坚持这个原则：我们不做那种“改进”。
如果我们要做新东西，我们会使用新的接口，而让旧接口保持在可工作的状态。
极少有其他开源项目或闭源项目有这种做法。
我希望更多项目能这样做，但我还不是“世界之王”，所以我管不了别人，我只能给内核定规矩。