前几天，有开发者刷新 Linus Torvalds 的内核仓库时，发现了一个让人愣住的新分支：noref-filemap-read-with-llm。末尾那个"llm"明晃晃地写着——这事有 AI 参与。知乎
对，就是那个 Linus。2024年底还公开嘲讽 AI 行业"90%是营销"的人，这次亲自把 Claude Code 带进了 Linux 内核。36氪
他动了什么地方？
10月10日，Linus 提交了一组8个实验性补丁，瞄准一个被内核开发者 Matthew Wilcox 在2024年就点名的老问题：多个线程同时读同一个小文件时，每次都要反复修改同一个内存对象的引用计数，原子操作让 CPU 核心之间疯狂争抢同一条缓存行。在 Linus 的测试机上，99.92% 的跨核开销全堆在这一条线上。ZDNet知乎36氪
新方案思路挺妙：借助 RCU 机制，把从页缓存移除的内存延迟归还，读线程在受保护区间里直接把数据拷走，不用再抢那个计数器。
效果是能测出来的：一台4核8线程的笔记本上，8个线程每次读16字节，吞吐量从每秒约1000万次干到约3300万次；每次读取的内核 CPU 周期从2950个降到725个。36氪
先泼盆冷水：这是实验分支，还没合入主线。"3倍"只对多线程小块读取这个特定场景成立，单线程只快了一成左右。而且有代价——内存延迟归还会加大回收压力，Linus 自己承认这是整组补丁解决得最烂的地方。所以，"AI能写操作系统了"的幻觉可以先收一收。知乎36氪
第二天，更有意思的事来了
仓库里又冒出一个 assoc-array-fixes 分支。这套数据结构2013年就进了内核，代码晦涩到有开发者提交 Bug 报告时，Linus 都跟不动逻辑。他让大模型把庞大函数拆开、放进用户态测试框架里跑，结果不仅坐实了报告的 Bug，还顺藤摸瓜挖出3个新的——全部能追溯到2013年第一次合入的那次提交。一份 Bug 报告，牵出四处藏了十几年的坑。知乎微博
真正值得盯住的，是五个字
Linus 在补丁说明里大大方方写着：代码、测试程序、审查材料，连说明文字的初稿，都是"在我的指导下"借助 Claude Code 完成的。这五个字才是重点。AI 干的是活：写实现、写测试、拆老代码、起草文档；人干的是判断：目标他定、方案他审、结果他测、责任他扛。代码能过地球上最毒舌的代码审查者这一关，说明 AI 的产出确实到了顶级工程能用的地步——但前提是，后面站着一个能把问题定义清楚、能把结果验证明白、敢签字负责的人。36氪ZDNet
他的态度轨迹也挺值得品：2024年底嘲讽"90%是营销"；今年1月在业余项目里试水 vibe coding，给一个 Python 音频可视化小工具写代码；最近在欧洲开源峰会上，他对着老友 Dirk Hohndel 说：“我以前觉得 AI 不怎么样，但现在，我真的很喜欢用它”。顺带补了一句提醒：面对真正重要的软件，用 AI 必须格外谨慎。36氪ZDNet
Linus 有句名言：Talk is cheap, show me the code。如今连 code 都可以让 AI show 了，真正值钱的东西就换成了另外三样——知道该写什么，能验证对不对，敢为结果署名。
