Linus 用 Claude Code 改了 Linux 内核：吞吐量涨 23 倍，Bug 还是被人揪出来

以“痛批 AI 泡沫”闻名的 Linux 之父，这回自己动手用 AI 改了内核。成绩很亮眼：在一项基准测试中读取吞吐量最高提升 23 倍。但更有意思的是故事结尾——补丁还没合入主分支，人类维护者就先揪出了一个连 AI 和作者都没发现的并发缺陷。

一分钟速览

• Linus Torvalds 借助 Anthropic 的 Claude Code，处理一个困扰内核开发者两年多的性能瓶颈；
• 他提交了一组补丁系列，在 Ryzen Threadripper 的合成基准中把读取吞吐量提升约 23 倍；
• 该系列从常见缓冲读取路径中移除了 folio 引用计数操作，解决的正是页面缓存里的争用问题；
• 维护者 Kiryl Shutsemau 在审查中发现一个竞争条件：文件大小扩展时，读取路径可能把尚未写入的数据返回给用户程序；
• Torvalds 已将后续开发交给 Shutsemau；他本人也承认，真实工作负载下的提升会小得多；
• 补丁的代码、测试程序乃至初步审查由 Claude Code 在其指导下完成，但最终防线仍是人类审查者。

从“骂 AI”到亲自试

Torvalds 此前对 AI 的态度相当尖锐，他曾说：每当看到有人吹嘘“我们 99% 的代码都是 AI 写的”，自己就很生气，因为那些人从不承认代码 100% 是编译器生成的。但就在最近，外部开发者在他的代码树里发现了一个名为 noref-filemap-read-with-llm 的实验分支——要知道，他的代码树里极少保留主开发分支以外的内容。这组基于 Linux 7.3-rc6 的补丁在提交记录中坦白标注了 Claude Code 参与的具体工作，代码、测试程序甚至连提交前的初步审查都由它在指导下完成，性能测量则由 Torvalds 在自己机器上完成。

23 倍是怎么来的

被解决的问题有年头了：页面缓存里的 folio 引用计数争用，最早在 2024 年由长期参与内核内存管理的工程师提出，是在客户真实负载中暴露出来的。Torvalds 自己的一版修复带着缺陷跑了 18 个月，其他开发者的方案也先后碰壁。新方案从常见缓冲读取路径中移除了引用计数操作，并引入新的标志与延迟回收机制。数据很直观：在他的笔记本上，8 线程吞吐量从每秒约 1000 万次读到最高 3300 万次，每次读取消耗的内核周期从约 2950 降到 725；在 64 线程的 Threadripper 上，吞吐量从每秒 1330 万次跃升到 3.04 亿次，周期从近 2 万骤降至 735。

为什么人类审查仍是最后一道闸

代价同样存在：激进的延迟回收机制会在排队页面超过一定数量时强制触发加速宽限期，向尚未映射的用户页面读取数据时也会多触发一次缺页异常。而真正致命的问题藏在时序里。Shutsemau 指出，在无引用的读取路径中，原逻辑先取当前 folio、再读文件大小；当旧 folio 被替换、文件大小又恰好被扩展时，读取边界会采用新的大小，于是可能把文件中新扩出、实际尚未写入有效数据的空白区域当成有效数据返回。这类竞争条件只有操作恰好按特定顺序撞在一起才会出现，恰恰是 AI 自查最容易漏掉的类型。

信号比结果更重要

这件事的意义不在“AI 能不能写内核代码”，而在于它把当前阶段的分工摊开给人看：AI 可以提出足够有想象力、也确实有效的优化方案，把人类从重复改动中解放出来；但把方案送进需要长期稳定运行的基础设施之前，理解时序、判断边界、承担后果的责任，仍落在人类维护者身上。对于正在把 Agent 引入生产系统的团队，这大概是最有参考价值的一个样本。