Linux之父:Linus Torvalds 谈 AI 与 Linux 内核开发

3D 打印
吉他英雄
AI 工具的影响
安全研究人员喜欢受到关注
编译器
对文中 AI 观点的分析

原文：Dirk and Linus discuss AI and kernel development
作者：Joe Brockmeier
发布日期：2026 年 5 月 25 日

Linus Torvalds 不喜欢发表演讲，但偶尔也会同意在 Linux 基金会的活动上与 Dirk Hohndel 进行台上对谈。5 月 20 日，在 2026 年北美开源峰会（Open Source Summit North America）的一场主题演讲中，两人举行了第 30 次这种没有壁炉的“炉边谈话”。讨论的话题包括 3D 打印、吉他效果器、刚刚发布的 Linux 7.1-rc4，以及 Torvalds 与 AI 工具之间复杂的关系。

3D 打印

Hohndel 首先提到，Torvalds 是一位“狂热的 3D 打印爱好者”，而且两人拥有同一型号的 3D 打印机。他说，这一领域有趣的一点是，“基本上一切都是开源的”。他们还有一个共同点：都不喜欢使用可视化工具创建 3D 模型，而更偏爱 OpenSCAD——它允许用户通过编程语言创建模型。Hohndel 想知道 Torvalds 是否研究过 OpenSCAD 的代码，还是仅仅把它当作工具使用。

Torvalds 表示，他只是这款软件的用户。他喜欢用文本描述物体，并把 3D 打印视为一种编程方式。他还喜欢它能生成实体物品，这是内核开发工作无法带给他的体验。不过在编程时，他更喜欢“真正贴近硬件，在另一个层级上工作”。他无意参与 OpenSCAD 项目的开发，因为它与自己习惯编写的代码差异太大。

Hohndel 说，有时他想修复某个应用程序中的错误，“然后看了代码才意识到，我完全不知道该怎么修”。发现还有那么多自己一无所知、却依然乐于使用的东西，是一种很棒的学习体验。

他还表示，多年来，开源工具一直被认为“可能有点笨拙”，而专有工具则好用得多；然而，用于 3D 打印的开源应用程序却“非常酷”，质量也很高。Torvalds 回应道：“我们其实已经走过了人们认为开源软件只适合工程师的阶段。”

吉他英雄

Linux 基金会首席执行官 Jim Zemlin 在介绍 Torvalds 时，称他创造了两项塑造行业的工具：Linux 内核和 Git 版本控制系统。不过 Hohndel 表示，他其实应该因三项重大创新而受到认可，因为 Torvalds 还创建了潜水日志应用程序 Subsurface。现在，这个数字甚至可能需要上调到四项，因为还有“一款由独一无二的 Linus Torvalds 编写的吉他效果器”。

该项目托管在 GitHub 上，其中包含全部软件和必要的电路图，并以 GPLv2 许可证发布，用户可以据此制作一台可正常工作的效果器。Torvalds 提醒感兴趣的用户，必须先把设备制造出来才能使用。虽然可以手工放置元器件，但他建议把设计文件交给印刷电路板（PCB）制造商。他一开始尝试自己手工制作，后来觉得操作过于精细繁琐，最好还是交给专业人士。“如果你喜欢吉他效果器或音乐，并且想要一款非常糟糕的吉他效果器，现在可以自己做一个。”

Hohndel 说，他是这款吉他效果器的早期测试者，并评价道：“它并不差，当然还配有一个 3D 打印的外壳。一切都很有趣。”Torvalds 则一本正经地表示，他也将“改变音乐世界”。

AI 工具的影响

Hohndel 把话题转回 Torvalds 的第一个业余项目，并提到 Linux 7.1-rc4 最近刚刚发布。“还是我通常会问的问题：‘发生了什么？进展如何？’”

Torvalds 回答说，自从切换到 Git 以来，内核项目已经沿用同一套流程大约 20 年了。“我过去总说一切运转良好、进展顺利，一直在稳步前进。但大约半年前，情况发生了变化。”他说，在过去六个月中，内核提交数量大幅增加，最近两个内核版本的提交数量比多年来的常态高出约 20%。

他最初猜测，是因为 7.0 是一个 .0 版本，各家公司都在努力把自己的代码赶进这个版本，类似的情况在 6.0 发布时也曾发生。“后来事实证明我错了。”真正的变化是，AI 工具对很多人而言已经足够好，“我们看到几乎所有领域的开发活动都明显增加了”。这些工具降低了编写 Linux 内核补丁的入门门槛，并确实产生了影响。不过，他说，这种影响并不完全是正面的。

Hohndel 回应说，7.1-rc4 公告的一部分涉及内核安全策略的调整。Torvalds 在公告中表示，大量涌入的 AI 报告已经使安全邮件列表“几乎完全无法管理”。因此，Willy Tarreau 更新了安全漏洞文档，明确了内核安全相关错误报告的定义和处理方式。

Torvalds 暂停了一下，询问现场有多少人使用 AI 编程；环视会场后，他说：“是的，几乎所有人。”他表示，自己对 AI 怀有一种爱恨交织的感情：“我喜欢这些工具。我觉得它非常有用，也很有意思。但它确实正在制造一些痛点。”

他说，Linux 开发中的主要痛点往往出现在人们被迫改变工作方式的时候。人们找到了一种舒适的工作方式，随后某种事物出现并打破了这种状态：

2000 年前后，我不得不改变自己的工作方式，因为随着 Linux 项目不断发展，我原来的方式已经无法继续扩展。我至今仍记得，那是内核开发过程中最痛苦的阶段之一。而那确实已经是 25 年前的事情了。我认为，如今 AI 正在带来一些相同的影响，迫使人们走出自己的舒适区。

他说，AI 生成的错误报告正在给维护者带来同样的痛苦。人的处理能力无法无限扩展，而大家仍需要时间弄清楚如何使用 AI 工具——“或许‘负责任’并不是最准确的词——但要以一种真正能与社区及其他开发者协同工作的方式使用它”。内核社区确实已经感受到了其中的痛苦：

这个邮件列表上的人数很少，因为一切都被认为需要高度保密，而我们却把全部时间花在将报告转发给更熟悉相关领域的开发者上。我们修改了政策：如果你通过 AI 发现了安全漏洞或任何其他错误，基本上都应该把它视为公开信息。因为既然你能用 AI 找到它，其他一百个人也同样能用 AI 找到。

尽管这些错误应该被视为公开信息，Torvalds 仍表示，报告者不应公开漏洞利用方法。他强调，自己说的不只是 Linux 内核，而是任何软件中的漏洞。“只需要让人们知道问题是什么，不必准确告诉他们怎样在周五下午让某个人的生活变得极其悲惨。”

安全研究人员喜欢受到关注

他再次强调，自己非常喜欢 AI 工具，也不认为这项技术本身不好；不过，目前仍有一些尚未解决的社会层面问题，而这些问题才是关键。他说，安全漏洞报告者长期以来一直热衷于吸引关注，甚至会特意为安全漏洞打造品牌。他们创建网站、设计徽标，“希望凭借这个漏洞获得所有名声，然后在与受影响者——也就是之后需要修复漏洞的维护者——沟通之前就将其公开”。

Hohndel 提到，最近内核中发现了四个本地权限提升漏洞，其中两个在没有联系维护者的情况下就被公开了。“我的反应总是：‘这是一家我永远不想合作的公司，因为如果你们这样对待 Linux 内核，也会这样对待任何人。’”这四个漏洞体现了 Torvalds 所说的挑战，因为维护者根本没有机会在全世界得知这些漏洞之前完成修复。不过 Hohndel 问道，如果所有 AI 发现的错误都被视为公开信息，“这是否会让维护者始终处于被动状态？”

“遗憾的是，我认为我们无法绕开这个问题。”Torvalds 说。内核包含大量代码，也就必然存在错误，这不应该让任何人感到意外。过去，内核维护者可以通知 Linux 发行版确实需要升级，却不必准确说明安全漏洞的具体内容。由于内核是开源的，修复本身是公开的，“但通常这些安全问题非常隐蔽，很难被识别。在 AI 时代，你只需把识别过程自动化即可”。

他说，就在上周，“我们修复了一个错误；三小时之内，就有人发表了一篇博客文章，解释该修复所涉及的安全影响，因为安全研究人员喜欢受到关注。别误会，我们所有人都喜欢。”安全公司有充分的动机运行 AI 工具来寻找漏洞、发布引人注目的公告，并争取成为第一个报告漏洞的人。“我认为今后事情就是会这样发展，而且你确实无能为力。”解决办法不是停止开发开源软件，因为 AI 同样可以通过逆向工程在闭源软件中发现漏洞。然而，在那种情况下，人们却无法利用 AI 帮助修复漏洞。

Hohndel 表示，他注意到这些公司“很乐意花费大量资金和 token 来指出一个错误，但奇怪的是，这些报告一个补丁都没有”，尽管内核是开源的。媒体的所有注意力都集中在发现错误上，而公司似乎没有意识到，提供错误修复可能会获得更多关注，这多少令人遗憾。

“公平地说，有时发现错误确实比修复错误容易。”Torvalds 说。这听起来可能很消极，但他认为总体而言这仍是一件好事。AI 发现错误意味着短期的痛苦，但长期收益是错误最终得到了发现和修复，结果会因此变得更好。“冲突并不在于 AI 很糟糕，而在于这种新工具带来了一些社会协作上的关卡和痛点。”内核已有 35 年历史，AI 有时会发现内核开发者一直没有找到的问题；解决这些新问题需要一些时间。“实际上，我对整件事非常乐观。”

考虑到错误报告正大量涌入，Hohndel 问他是否使用了一些优秀工具来帮助代码审查、理解补丁或改进其他工作流程。Torvalds 回答说，内核维护者拥有大量工具，并指出“Linux 内核实际上发展得很好；每个版本都有超过一千人参与，还有一支稳定的维护者团队”。大多数时候，这些维护者也因参与项目而获得不错的报酬。

Torvalds 说，他一直在讨论 Linux 开发和 AI 带来的问题，是因为这正是自己的工作。“但想想其他成千上万个由人们维护的普通项目，它们并不是 Linux 内核。”当这些项目的维护者遭遇 AI 驱动的安全报告或错误报告洪流时，很容易精疲力竭。“而当你要求提供更多信息时，报告者只是路过式地扔下一份报告，之后甚至不再回答你的问题。”说到这里，Torvalds 承认自己已经忘记了最初的问题是什么。

Hohndel 提醒他，最初的问题是他使用了哪些工具。“哦，对。我们的确会使用 AI 工具。”例如 Sashiko，它会对发送到内核邮件列表的补丁进行审查。他说，许多公司都在开发内部私有工具，很多核心内核开发者也在使用本地 AI。他建议其他人也研究一下本地 AI 工具：“你不会希望完全受制于那些大公司，因为它们终有一天会决定：哦，我们也需要赚钱。”

不过，他的大部分工作都是与人协作。作为顶层内核维护者，他已经不再编写太多代码；他的工作是与人打交道，而他不会使用 AI 来与人打交道。“我也建议你们不要那样做。”

编译器

由于 Torvalds 提到与人协作，Hohndel 询问他会给刚刚开始职业生涯的人哪些建议，以及他们应该把注意力放在哪里。Torvalds 回答说，AI 是一款优秀的工具，但终究只是一款工具。每当看到有人声称自己 99% 的代码都是由 AI 编写时，他就会生气：“我几乎可以保证，他们 100% 的代码都是由编译器编写的，但他们从来不会这样说。”

他从小就开始编写机器码：“而且我说的机器码不是汇编语言，我说的是数字。”他说，以这种方式直接与硬件打交道“会留下深刻烙印”。他花了一段时间才开始采用更高级的工具。“我后来意识到编译器很好用，而现在我也逐渐认识到 AI 工具同样很好用。”代码仍然是他写的，只是不再采用过去的方式。他确信 AI 正在改变编程，但并没有改变编程的根本。

这就像你们都会使用编译器来生成代码一样。你们所有人——好吧，也许不是所有人，但很多人——都会使用 AI 生成源代码，再由编译器处理这些源代码，然后由汇编器生成机器码。这是一场革命，但其意义与我们以前见过的那些革命相同。AI 会把你的生产率提高十倍。

而我认为编译器让你的生产率提高了一千倍。所以 AI 很棒，但 AI 并没有改变编程。它或许正在改变其他领域，别误会，但我是个程序员，所以我不关心那些。

尽管如此，他补充说，自己仍然希望理解一切是如何运作的。他已经不再使用机器码编程，但依然会检查生成的代码。当他使用编译器，甚至在吉他效果器这样的“个人项目”中使用 AI 时，他都会查看最终生成的汇编语言，因为那是伴随他成长的东西。即便使用 AI 编程，如果项目需要长期维护，“你不仅需要理解自己的提示词，还需要理解最终结果，因为这是你能够长期维护它的唯一方式”。

此时，这场对谈的时间已经用完。Hohndel 表示，他还有许多问题想问，但只能等到明年两人再次进行同样的对谈时再提了。

对文中 AI 观点的分析

需要先说明：这次谈话包含三种性质不同的表述——可以查证的事实、基于经验的判断，以及为了强调观点而使用的比喻。后两类通常不能简单判定为“正确”或“错误”。以下分析以截至 2026 年 9 月能够查到的研究和后续材料为依据。

基本正确或有证据支持的观点

1. AI 编程工具确实可以提高生产率，但效果取决于任务

这个大方向是正确的。受控实验显示，AI 对边界清晰、上下文较少的任务帮助明显：

一项 GitHub Copilot 实验中，参与者完成指定 JavaScript HTTP 服务器任务的速度提高了 55.8%。
Google 针对 96 名工程师进行的企业级受控实验估计，AI 让任务完成时间缩短约 21%，但置信区间较大。
汇总 Microsoft、Accenture 和 Cisco 三项现场实验的研究发现，获得 Copilot 使用权限的开发者完成的拉取请求数量有所增加。

因此，“AI 是一种有用的编程工具”有实证支持。不过，这些结果不能直接推广到所有开发者、所有代码库和所有类型的任务。

2. 复杂、成熟代码库中的收益可能很低，甚至为负

Torvalds 强调开发者必须理解代码和系统上下文，这一点非常重要。METR 在 2025 年进行了一项随机对照实验：16 名熟悉各自项目的资深开源开发者完成 246 个真实任务。允许使用当时的 AI 工具后，完成任务的时间不是缩短，而是平均增加了 19%。开发者却主观认为自己快了 20%。

该研究规模不大，使用的也是 2025 年初的模型，不能证明 AI 总会降低效率；但它证明了“生成代码更快”不等于“完成工程任务更快”。阅读上下文、验证行为、纠正错误和响应代码审查同样属于开发成本。Linux 内核正是这类上下文复杂、质量要求高且需要长期维护的代码库。

3. 未经验证的 AI 错误报告会消耗维护者资源

这不是抽象担忧，而是 Linux 内核项目已经遇到的实际问题。Linux 7.1 的安全报告文档明确指出，大量 AI 辅助报告存在准确性差、内容过长、夸大影响、缺少可用复现程序等问题，已经造成维护者过载。文档要求报告者验证问题、提供经过测试的复现方法、说明可验证的影响，并尽可能提交经过测试的修复。

这也解释了 Torvalds 为什么反对“路过式”报告：生成一份看起来可信的报告成本很低，证明它是误报的成本却由维护者承担。这是一种明显的成本转移。

4. AI 可以发现人类长期遗漏的错误

这个判断合理，也得到了内核项目实践的支持。AI 辅助静态分析和代码审查可以批量检查很少有人关注的旧代码路径，发现空指针、释放后使用、边界检查缺失等模式。Linux 内核文档本身也承认，AI 可以有效地在“很少被探索的区域”寻找错误。

但“发现可疑代码”“证明错误可以触发”和“判断它是否构成安全漏洞”是三个不同层次。AI 在第一层通常最有价值，后两层仍需要复现、威胁模型和人工判断。

5. 长期维护的软件要求人对结果负责

这是文章中最可靠的工程结论。无论代码由人手写、代码生成器产生，还是由 LLM 生成，维护者最终都必须能够解释其行为、测试其边界并处理后续故障。Linux 内核后来制定的 AI 辅助开发规则也遵循这一原则：AI 不能签署开发者来源证书（DCO），必须由人审查并对提交承担全部责任。

不准确、缺少证据或需要限定的观点

1. “AI 会把生产率提高十倍”没有事实依据

这是文中最明确的不准确表述。现有研究报告的是特定条件下约 20%～56% 的提速，或者在成熟项目中出现 19% 的减速，没有可靠证据支持普遍的十倍提升。

更重要的是，Torvalds 在文章发表后的 2026 年印度开源峰会上亲自澄清，这个 “10 倍”数字“并不科学”，只是随口给出的数字。因此它应该被理解为一种强调 AI 潜力的修辞，而不是测量结果或预测模型。

同样，“编译器让生产率提高一千倍”也没有给出定义、基线或测量依据。两组数字都不适合被当成统计事实引用。

2. 把 AI 类比为编译器有启发性，但技术上并不等价

这个比喻正确地表达了“开发者会使用更高层工具生成更低层代码”，但容易掩盖关键差异：

编译器依据语言规范进行相对确定性的转换，同一输入通常产生可重复、可验证的结果。
LLM 根据概率生成内容，可能误解需求、虚构 API，或产生表面合理但语义错误的代码。
编译错误通常能由类型检查和测试较早暴露；AI 生成代码的问题可能恰好通过测试，却违反未写明的系统约束。

所以，AI 可以成为编程工具链的一层，但目前不能因此获得与编译器相同的信任程度。恰恰因为两者不同，AI 输出通常需要更强的审查，而不是更弱的审查。

3. “提交量增加约 20% 的真正原因是 AI”尚未得到证明

提交量增加本身可以通过版本历史核对，但把增长主要归因于 AI 属于观察性推断。要证明因果关系，至少需要识别哪些提交使用了 AI、排除版本周期、公司投入、维护策略和项目规模变化等因素。

而且，提交数量也不是生产率或软件质量的直接指标。更多提交可能代表更多有效改进，也可能包含补丁拆分、返工或低价值修改。因此更准确的说法是：Torvalds 观察到提交量与 AI 工具普及同时上升，并认为两者有关；这不是已经得到严格验证的因果结论。

4. “AI 找到的漏洞都应视为公开”是项目策略，不是普遍事实

Linux 内核采用这一规则，是因为多名研究者可能使用相同工具重复发现同一问题，继续放进私有安全列表会阻碍去重并压垮少数维护者。这在内核当前的工作流中有现实依据。

但它不能推广为所有项目的安全披露原则。AI 发现的漏洞仍可能是新颖、可利用且尚未被其他人发现的漏洞；如果贸然公开复现代码或利用细节，仍可能给用户带来风险。即使按照内核的新规则，也只是公开报告问题，并不意味着应该立即公开漏洞利用程序。披露方式仍应根据项目政策、影响范围和修复准备情况决定。

5. “AI 同样容易逆向闭源软件”说得过于绝对

AI 确实可以帮助分析二进制文件、识别漏洞模式和理解反编译代码，所以闭源并不能阻止自动化安全研究。但“同样容易”并不准确。闭源分析通常缺少源代码、符号、类型、构建配置和设计上下文，还可能受到混淆与反调试技术影响，其难度通常高于直接分析完整源代码。

Torvalds 更可靠的核心观点是：闭源不能从根本上阻止漏洞发现，而且闭源会限制外部研究者直接检查和修复问题。至于两种分析是否“同样容易”，则取决于具体目标，不能一概而论。

综合评价

Torvalds 对 AI 的判断最有价值之处，不是“10 倍”这样的数字，而是他把注意力从“生成了多少代码”转向了“是否为整个协作系统创造了净价值”。这与现有证据相符：AI 可以显著加速某些任务，也可能在复杂项目中因为审查、返工和沟通成本而拖慢开发。

因此，更准确的结论不是“AI 编程一定更快”或“AI 只会制造垃圾”，而是：

AI 的收益高度依赖任务、模型、开发者经验和代码库复杂度。
生成速度不能代替端到端生产率、代码质量和维护成本。
AI 发现或生成的结果必须由能够验证、解释并负责的人提交。
对开源项目而言，AI 是否有价值，最终取决于它减少了维护者的工作，还是把验证成本转嫁给了维护者。

参考资料

本文译自 LWN.net。原文采用 Creative Commons Attribution-ShareAlike 4.0 International（CC BY-SA 4.0）许可证发布。本译文遵循相同许可证。