Linus 用 Claude Code 写内核补丁：读取吞吐提升 23 倍，Bug 还是人抓出来的

Linux 创始人 Linus Torvalds 用 Anthropic 的 Claude Code 写了一组内核补丁，在合成基准测试中把读取吞吐量提升了 23 倍。但补丁还没合入，人类审查者就凭经验揪出了一个连 AI 和 Linus 都没发现的竞争条件。这件事的价值，不在于“AI 能写内核代码”，而在于它清晰划出了人与 AI 的分工边界。

一分钟速览

• Linus 使用 Claude Code 编写 Linux 页面缓存修复补丁，共 10 个补丁。
• 在 Ryzen Threadripper 的合成基准中，读取吞吐量提升 23 倍。
• 补丁从常见缓冲读取路径中移除了 folio 引用计数操作。
• 审查者发现竞争条件：folio 被替换后文件扩展，可能返回尚未写入的数据。
• Linus 已将后续开发交给发现问题的维护者 Kiryl Shutsemau。

一、一个困扰两年的老问题

页面缓存的引用计数瓶颈，在 Linux 内核里存在了两年多。Linus 自己写过一版修复，跑了 18 个月，最后发现代码有缺陷；其他开发者提出的方案也各有问题。直到这次，他借助 Claude Code 重新梳理了读取路径，提交了一组包含 10 个补丁的系列。

核心改动是从常见的缓冲读取路径中移除 folio 引用计数操作。引用计数是内核里最敏感的东西之一：多一个少一个，轻则性能下降，重则内存被提前释放、系统崩溃。能在这条路径上做减法，说明对锁和生命周期的理解到位了。

二、23 倍是怎么来的，又为什么别当真

在 Ryzen Threadripper 上运行的合成基准测试中，这组补丁把读取吞吐量提升了 23 倍。这个数字很抓眼球，但 Linus 自己提醒：在真实工作负载中，性能提升会小得多。

原因不难理解。合成基准通常把某一类操作放大到极致，比如连续小文件读取，正好命中补丁优化的路径；真实系统里，读取只是整个链路的一环，还要经过调度、文件系统、块设备、网络等层层开销。23 倍是“上限展示”，不是“日常体验”。对内核开发者来说，这个数字的意义是证明方向正确，而不是承诺用户能感知到 23 倍。

三、Bug 是怎么被发现的

在后续审查中，维护者 Kiryl Shutsemau 指出：在 filemap_read_rcu_batch() 中，如果 folio 被替换后文件大小（i_size）又随之扩展，读取路径就可能把文件中尚未写入的数据返回给用户程序。

翻译成日常场景：你读一个文件时，内核用来保存这段数据的内存页刚好被换掉，而文件大小又紧接着扩展。两件事交错发生，读取代码就可能把新扩出来的、实际还没写入内容的部分，当成有效数据交给应用程序。这类问题不会在常规测试里稳定复现，只有在特定时序下才会触发，属于典型的竞争条件。

审查者还对补丁的内存回收机制提出了质疑。最终，Linus 把后续开发工作交给了 Shutsemau——后者此前也研究过这个瓶颈。这个处理方式很“内核社区”：不看出身，只看谁更懂这块代码。

四、人类审查仍是最后防线

这件事最值得记住的，不是“AI 帮 Linus 写了补丁”，而是“AI 写的补丁仍然需要人类审查”。Claude Code 能快速生成结构完整、风格一致的代码，也能在大量上下文中找到优化点；但它对并发时序、内存生命周期的直觉，仍不如在这个子系统里泡了多年的维护者。

这不是贬低 AI。恰恰相反，AI 把“从想法到可审查补丁”的时间大幅压缩了，让 Linus 这样的专家可以把精力放在设计和判断上。但“最后一公里”的责任，仍然落在人身上——尤其是在内核、金融、医疗这类错误代价极高的领域。

五、对 AI 编程工具的三点启示

第一，评估 AI 编程能力，不能只看“能不能写出来”，要看“写出来的东西能不能被审查、被测试、被维护”。第二，AI 最擅长的是有明确边界的重构和模式化修改，最不擅长的是跨模块的时序推理和隐含约束。第三，工具的价值在于放大专家，而不是替代专家——Linus 用 Claude Code，效果远好于一个不熟悉内核的人用同样的工具。

对普通开发者来说，更现实的结论是：把 AI 当成一个速度很快、但需要复核的初级同事。它可以帮你写第一版，可以帮你找优化点，但不能替你对线上系统负责。代码审查、测试覆盖和灰度发布，一样都不能少。