Linus 的首个 AI 补丁系列，Review 先挑出错

一个管了内核二十多年的人，在一组补丁的说明里写清了一件事：代码、测试、复核，都是模型在他指导下做的。这句话比补丁本身更难消化。

一、发生了什么

10 月 14 日，LWN 编辑 corbet 发了一则短讯：Linus Torvalds 在刚结束的内核维护者峰会（Maintainers Summit）上提到，自己一直在用大模型做一组补丁，解决一个拖了很久的问题；现在这组补丁已经发到邮件列表，等人审。

这批补丁共十个，分支名很直白：noref-filemap-read-with-llm。据转述，补丁说明里交代了分工——代码、测试程序、上面那些数字背后的复核工作，以及这段说明的初稿，都是在他的指导下由 LLM 编程助手 Claude Code 完成的；数据跑在他自己的机器上。

改的东西不算玄：多个线程同时读同一份页缓存里的小片段时，内核每次都要对 folio 的引用计数做原子加减，几个核会在同一条缓存行上打架。补丁给"热"的 folio 打个标记，把释放推迟到一个 RCU 周期之后。这样不仅指针查找在 RCU 保护下，连 folio 数据的读取本身也能留在临界区里，快路径上不用再动引用计数。前提是往用户缓冲区拷贝时不触发缺页，一缺页就退回原来的路径。

LWN 给的结论是：在一个读操作密集的基准里，性能提升一个数量级。代价也写在同一篇报道里——Review 已经找出一处竞态条件，还得接着改。补丁没有合并。

把这两段放在一起看，会发现它是一份很少见的公开样本：从想法到实现到被挑错，全过程都留了痕。以往这类工作只会出现在某个人的本地分支里，外人只能看到最后的合并结果。

二、跟你有什么关系

只用电脑的人：这件事对你今天没有任何影响。没合并的补丁不进你的系统，内核不会因为这条新闻变快。

做后端或内核的人：这是一份现成的模板。它示范的不是"让模型写代码"，而是"人定方向、人定验收标准，模型填实现"。分支名、补丁说明、测量数据全公开，等于把 AI 参与的痕迹留在了版本史里，后来的人能查。

在团队里推 AI 编程的人：最难开口的那句话，被别人先说了。以前争论"AI 写的代码能不能进主干"，现在的问题变成"怎么记录它、怎么验它"。

还有一个更现实的差别：这组补丁解决的是一个存在很久的小问题，不是重写一个子系统。范围窄、边界清楚、有稳定基准，正好是模型能发挥的地方。换成一个需求都说不清的功能，同样的流程未必成立。

三、怎么判断一段 AI 参与的底层代码能不能收

1. 先看它有没有坦白。补丁说明里写清哪部分由模型产出、哪部分由人复核，这不是形式主义。出了问题时，这份记录决定你能不能定位到"当时谁认为它是对的"。

1. 再看有没有能重跑的测量。Torvalds 这组补丁带了基准，而且是在自己机器上跑的，别人可以照着重测。没有数字的"性能优化"，一律当猜想处理。

1. 把并发、内存生命周期、错误路径单独拎出来，用人工审。LWN 报道里那处竞态就是这么被抓到的。这类问题不是"读一遍代码"能看出来的，得有人专门想着"两个线程同时到这里会发生什么"。

四、三个别信的说法

"Linus 都用了，说明 AI 写内核没问题。" 他用的方式和你想象的相反：方向他定，基准他跑，数字他认，署名他担。这是"我负责"，不是"它可靠"。把这句话简化成背书，等于把最关键的环节删掉了。

"提升一个数量级，下个版本就能用上。" 报道里写得很清楚，Review 已经发现竞态，还要继续改。性能数字和可合并之间隔着一整轮正确性审查，这段路经常比写代码更长。

"人只要在最后签个字。" 这组补丁里，人做的恰恰是最费脑子的部分：判断哪条路值得走、设计怎么验、看结果对不对。签字只是最后一步，前面三步都省掉的话，签字没有意义。

五、一句话结论

真正的信号不是"AI 会写内核代码了"，而是"连最挑剔的人也开始公开说明自己哪部分没写"。

信息来源

• LWN.net，Linus Torvalds's first LLM-assisted patch series，2026 年 10 月 14 日：https://lwn.net/Articles/1100449/

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。