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

如果只看技术履历，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 编译：

“我对技术不是特别怀旧” 

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 是一个非常庞大的代码库，它永远不会变得“容易维护”，但至少我们不应该让它比必要程度更难维护。

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

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，但说明不清楚，我经常会直接看代码。然后有时我会觉得：哦，原来如此，这说得通。有时则完全说不通，那我就会反对。

所以，是的，我也许已经不再是严格意义上的程序员，但我仍然有足够强的技术背景。看到代码时，我仍然能够做判断。

不要以为 Rust 能修掉所有 bug

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 那种原始、简单但强大的力量，而且我不认为这一点会改变。

不过回到 Git。对我来说，Git 的目标之一从来不是 C 本身。C 不是问题，C 只是一个实现选择，因为那是我一直使用的语言。

我真正希望 Git 拥有的是少数几个非常高层次的概念，这些概念可以解释整个架构。你其实可以从很早期的 Git 历史里看到这一点。我们不只有 C 版本，也有 Java 版本。很多公司后台其实都在运行 Java 版本，因为在服务器环境里，一个 Java 版本的 Git 通常非常方便。

所以，Git 现在支持 Rust，我认为这并不像 Rust 进入内核那样是一个巨大的变化。因为 Git 早就已经有多种不同语言并存的情况。

Dirk Hohndel：你这么说很有意思。Rust 现在已经被推向很多领域。我们已经看到一些人用 LLM 把现有工具重写成 Rust，也已经看到一些相当糟糕的 bug，比如 Ubuntu 25.10 的自动更新问题。这件事你怎么看？

Linus Torvalds： 公平地说，Rust 的确可以避免一些你在 C 里面容易犯的简单错误，但它不会修复逻辑错误，对吧？它不会替你思考。

如果你写的是错误代码，那么语言本身并不重要，最后结果仍然会是错的。所以我完全不反对 Rust，但我也想降低大家的预期：不要以为 Rust 能修掉所有 bug。

Rust 确实能修掉几类 bug，让这些 bug 更难出现。但你仍然可以犯很多逻辑错误。事实上，最近内核里一些比较大、比较受关注的 bug，就是逻辑错误。它们不是内存安全问题，也不是某种微妙的语言问题，就是糟糕的编程。而遗憾的是，即使在维护非常谨慎的子系统里，这种事情也会发生。即使是那些很重要、理论上应该非常安全的内核代码里，也会发生。

所以，不要期待一门语言能神奇地替你修掉所有 bug。

Dirk Hohndel：这里还有一个问题。在内核、Git 这类工具的过渡阶段，C 代码和 Rust 代码会互相交互。Rust 给你的那些保证，只适用于代码库里纯 Rust 的部分。一旦你和 C 代码交互，这些保证就不再完全成立了。

Linus Torvalds： 公平地说，大多数和 C 代码交互的 Rust 代码，交互的是内核里的核心 C 代码。而这些核心代码的质量通常比外围的一些 C 代码要高得多。

我这么说不是因为写这些代码的人更聪明，或者是更好的程序员，而是因为这些代码已经在各种环境下被测试过。它们太核心了。无论你做什么，都会和内存管理、核心内核代码之类的东西打交道。所以这些代码已经在 Linux 支持的每一个平台上被测试过。

但另一方面，很多单独的驱动程序，只有当你拥有特定硬件时才会被测试。所以在内核里，代码的可靠程度确实是不一样的。我认为，Rust 侧现在接触到的很多 C 代码，恰恰是更稳定、更成熟的核心代码。

Dirk Hohndel：内核本身也有这样的结构：有些代码经过了大量测试，有些实验性代码可能没有测试得那么充分。还有我们前面提到的，一些更老的代码因为硬件已经不常见，甚至已经不存在了，所以也不太常被使用。

比如有多少人在自己的 S390 上跑 Linux，我不知道。但我不认为那是大型机上运行的主要操作系统。所以我觉得，测试最多、审查最多、最值得信任的代码，往往是所有人都依赖的核心代码。是这样吗？

Linus Torvalds： 是的。而且这类代码通常也是被最多人看到的代码。即使你是一个驱动开发者，通常也需要了解一点核心代码。你需要知道内核里的内存分配是怎么工作的，所以你至少会看过那些接口。

但反过来就不一定成立。如果你维护的是核心 VFS 层之类的东西，你可能永远不会去看某一个具体的驱动。

所以我确实会鼓励那些想进入内核开发的人从驱动开始。因为那里有很多……我不想说“问题”，但那里确实有很多边缘情况。

Dirk Hohndel：我们可以称之为学习机会。

AI 可以带来 10 倍提效？

Linus Torvalds： 对，学习机会。但与此同时，我也想提醒大家，内核真的很大。它不是最容易上手的项目。所以我也想稍微降低大家的预期。我们对新开发者有相当严格的规则，也有固定的做事方式。

Dirk Hohndel：我想先郑重指出一下：我们已经聊了很多内容了，但居然还没有谈到 AI 和 LLM。不过我觉得，这可能是本次会议里唯一一场能坚持这么久才谈 AI 的对话。当然，我们还是应该谈谈这个话题。一个月前，我们在明尼阿波利斯也做过一场类似形式的对谈。那次有很多人注意到，你在台上说，你认为 LLM 只是一个工具。这个观点我完全同意。

你当时还说了一句很有意思的话：你说它可能带来 10 倍的增量效率。然后很多人就说，“哦，Linus 认为 LLM 能让一切都变好 10 倍。”

所以我很好奇，你当时说的那个 10 倍，到底是什么意思？

Linus Torvalds： 那不是科学数字，显然，那就是我随口拍出来的数。

Dirk Hohndel：本来这是后面两个问题之后才要问的。所以换句话说，那是你凭直觉给出的一个数字。那么 LLM 到底提供了多少真实的增量价值？

我们刚才说，核心代码会得到更多人的关注。但 LLM 可以把同样的审查力度、同样的算法、同样的逻辑测试能力应用到所有代码上。你觉得 LLM 现在能在多大程度上为 Linux 内核社区带来生产力提升？我说的不是对你个人，而是对整个内核社区。

Linus Torvalds： 现在我们大概处在这样一个阶段：希望它创造的生产力已经超过它消耗掉的生产力。

直到今年年初左右，我们看到的 LLM 生成内容里，垃圾内容肯定比有用代码多。即使到现在，它仍然会占用开发者很多资源。

因为你会收到一些 bug 报告。我不知道在座有多少人在自己的工作中见过这种模式。我敢打赌，或者说我知道这种情况不只发生在内核里：你会收到一个看起来完全合理的 bug 报告，但你可能要花相当多精力，最后才发现它其实只是幻觉。

当人类需要花很多时间去判断一个机器生成的报告是不是真的时，这会非常消耗资源。

但与此同时，过去几个月里确实发生了一个变化：我们开始收到很多非常好的 bug 报告。不过，大多数好的报告并不只是 LLM 自己生成的。它们需要一个人去检查 AI 生成的报告，确认它是有效的，并且在修复问题的开发者之间扮演中间人的角色。

我们也不得不反复提醒一些人：如果你用 LLM 找到了一个 bug，并不意味着你只要让 LLM 写一份 bug 报告，然后把它扔给我们就够了。

我们希望看到一个建议性的补丁。我们也希望运行 LLM 的那个人能够参与往返沟通。我们需要有人可以讨论问题。

有些时候，补丁只是一个非常简单、显而易见的一行修改。但很多时候，问题会变成：我们过去没有考虑到这个问题，要真正修好它，需要重新组织一些代码，需要投入一些精力。

这时候，你就非常希望最初提交报告的那个人能参与进来。开发者可能会回来问：“这是我们建议的修复方案，你的 LLM 怎么看？”

对复杂系统要有敬畏之心 

Dirk Hohndel：你刚才描述的其实指出了一个很多人容易忽略的区别。LLM 现在非常擅长找 bug。作为一种攻击工具，或者说作为一种发现问题的工具，它们已经强了很多。尤其是过去六个月，我们确实看到了一些明显进步。

但另一方面，如果是让它们生成 Linux 内核这个级别所要求的可靠代码，我仍然没有完全被说服。我一直觉得，LLM 很擅长“从零到 demo”。你可以很快做出一个演示。但“从零到生产级代码”，我不确定它一定会做得更快。

Linus Torvalds： 是的。我个人会在自己的玩具项目里使用 LLM，而且我确实很喜欢这一点。我把它们当作原型工具。

比如我会说：我想试试这个东西，但这只是我的玩具项目，如果完全自己写，成本太高，而且我还不确定它能不能行。于是我就让 LLM 帮我做。很多时候，生成出来的代码并不能直接使用，但它是一种很好的试验方式。我希望大多数人今天也是这样使用 LLM 的。

我同意，当我们看到 AI 生成的 bug 报告时，有时也会收到 AI 生成的补丁。在简单情况下，这些补丁完全没问题。

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

这类修复往往需要那些长期维护代码、真正理解代码的维护者和开发者来处理。以我的经验，LLM 还没有达到这个层次。

当然，这未来可能会改变。也许有一天你可以告诉它：“请看大局，请真正把这个问题修好，请表现出一点好的工程品味。”但至少现在，大多数时候还缺少这种品味。

我认为，对 LLM 进行反复提示，确实常常能帮助它生成更好的质量。但至少在今天，它们还不能替代那种来自经验的架构级知识。

Dirk Hohndel： 是的，你确实需要一个理解大局的架构师。出于个人好奇，在座大概有一半人看起来像软件工程师。你们当中有多少人每天都在使用 LLM？

Linus Torvalds： 显然，AI 有很多很好的用例。我们刚刚谈到了它在 bug 方面带来的变化。有些被发现的问题不只是在当前代码里，有些甚至可以说非常惊人。当然，是以一种痛苦的方式惊人。

别误会，bug 从来都不好玩。如果是安全相关的 bug，而且两天后就出现在科技媒体上，那就更不好玩了。

但与此同时，我绝不是那种“射杀信使”的人。我认为，LLM 能找到 bug，对我们来说整体上是一件好事。即使这些 bug 让人尴尬，即使它们是我们可能 20 年前就应该发现的长期存在的严重 bug，最终它们被发现仍然是好事。

当下可能会有点痛苦，但最终我们会因此变得更强。只是过去几个月确实有点痛苦，因为 LLM 指出了几个相关的 bug。这并不奇怪：一个人发现一个 bug 后，另一个人就会去问 LLM：“那这个相似区域呢？”

所以我们才会在几周内看到三四个关系非常紧密的 bug 变成大新闻。

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

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：冬梅，36氪经授权发布。