那个曾说"AI是90%营销、10%现实"的Linus Torvalds，真香了。知乎
10月10日，他在Linux内核仓库提交了一组补丁，commit里写得明明白白：代码、测试程序、评审清单，甚至commit文本初稿，都是Claude Code"在我的指导下"完成的。分支名更直白——noref-filemap-read-with-llm，后缀"with-llm"生怕别人看不见；这个新分支是一位开发者刷新Linus官方内核仓库时发现的。10月13日补丁发上邮件列表，LWN次日报道：这是Linus的第一个LLM辅助补丁系列。知乎知乎知乎
改的是什么？一个卡了两年的老瓶颈
Linux的page cache像一间公共仓库：多个线程同时读同一个文件的小块数据时，每次都要给同一块内存页（folio）加减引用计数。线程一多，这行计数就成了独木桥，CPU核心之间疯狂争抢缓存行。内核开发者Matthew Wilcox早在2024年就指出过这个问题；在Linus的测试机上，8线程并发小读时，这项开销占到"Load HITM"的99.92%，几乎吃满总线带宽。知乎知乎
新方案的思路是绕开争抢：页从缓存移除后，借助RCU机制延迟一个周期再释放，读线程在保护区内直接把数据拷给用户，不再碰那个共享计数。效果立竿见影——在Linus自己那台i7-8565U笔记本上，8线程反复读同一个一页大的文件，吞吐量从约1000万次/秒冲到3000万次/秒，约3倍。单线程只提升约一成。有人搬出另一组多核合成基准喊出"23倍"，但Linus本人提醒：真实工作负载下，提升会小得多。知乎知乎
AI写的代码，最后栽在人手里——是好事
补丁还没合入主线。审查中，维护者Kiryl Shutsemau揪出了一个竞态条件：当folio被替换、文件大小又紧接着扩展时，读取路径可能把"还没写入的新扩区域"当成有效数据返回。AI和Linus都没发现，人工review发现了。截至10月中旬，补丁仍在修改。所以别急着写"Linux已经跑在AI代码上"——实验分支就是实验分支，能不能进主线，闸门始终是人拉的。知乎知乎
更值钱的彩蛋：13年的老Bug被顺手挖了三个
带llm的分支出现第二天，Linus仓库里又冒出一个assoc-array-fixes。这是一套2013年合入内核的老数据结构，开发者Nils Ollrogge提交了Bug报告，但代码晦涩到Linus自己都难跟清逻辑。他让大模型把庞大函数拆开、理清边界，再放进用户态测试框架跑：不仅确认了Nils报告的问题，还额外挖出3个Bug——4个Bug全部能追溯到2013年的首次提交。其中一个很具体：根节点拆分时索引位段错位，存进去的对象找不回来，18个键就能复现。知乎微博知乎
比起"提速3倍"，这才是对普通团队更有现实感的一幕：祖传代码没人敢动、文档缺失、原作者失联，AI最擅长的恰恰是"把烂代码读明白、把历史包袱排雷"，而不是替你做决定。
Linus有句老话：Talk is cheap, show me the code。这次他补上了下半句的注脚——代码可以让AI写，但方向得你定，结果得你测，责任得你扛。AI干活，人拉闸，这套分工连Linux之父都认了，你还在纠结什么？
