2026年10月13日，Linus Torvalds在自己名下的Git树里建了一个分支，名字叫noref-filemap-read-with-llm。名字直白得不像他：用LLM做的、无引用计数的filemap读取。更不寻常的是附在补丁系列上的那封信——这位对每一行进入Linux主线的代码握有最终否决权的人，第一次公开承认，一段即将接受全球最苛刻审查的内核代码，出自AI之手。
“代码、测试程序、对上述清单的审查，以及这段文字的初稿，都是由一个LLM编码助手（Claude Code）在我的指导下完成的。测量是在我的机器上跑的。”
这句话的分量，远超一个性能补丁本身。
现象层：一个补丁，两个战场
事件要从一根被抢烂的缓存行说起。多个线程高频读取同一个文件时，每读一次都要把页面的引用计数加一再减一，所有线程都挤在同一根缓存行上。在Torvalds的Core i7-8565U笔记本上，8线程测试中folio引用计数争用占了跨核HITMs的99.92%。
这个瓶颈不是Torvalds发现的。2024年，Oracle工程师、长期做内核内存管理的Matthew Wilcox在一个客户工作负载里撞上了它。此后近两年，包括Torvalds自己在内的人都试过各种办法——他甚至还跑过一个“坏掉的”自研修复版本，一跑就是18个月。
这次的路径很干脆：读者不再拿引用，页面离开缓存后等一个RCU宽限期再归还给页分配器。为了不让延迟释放失控，补丁里加了两道安全阀：当一个CPU排队超过1024个页面时，强制触发一个加速宽限期。代价是内存要晚一点才能回收，Torvalds自己承认，这是整个系列“最没解决好的部分”。
数字有冲击力。在笔记本上，原始8补丁分支把8线程读取吞吐从每秒约1000万次冲到最高3300万次，接近3倍；每次读取的内核周期从约2950降到725，降幅约75%。在他64线程的Ryzen Threadripper上，修订后的10补丁系列在高争用场景更夸张：吞吐从1330万飙升到3.04亿，约23倍；周期从近20000降到735。
但Torvalds立刻泼了一盆冷水：基准测试的收益在真实工作负载里会小得多。补丁基于7.3-rc6，截至10月13日尚未合并入主线，仍处于实验阶段。更棘手的是回归——在某些实现版本里，读入未映射用户页会多触发一次缺页异常，把16字节单线程读取从约4150周期推到6550周期；维护者已经开始质疑新的PG_rcu_free标志，Wilcox建议改用page type，并对非活跃链表上的folio在RCU宽限期后回收。
把这两件事放一起看，才显出真正的问题：这不仅仅是一次内存管理优化，而是Linux维护模式的一次压力测试。AI写的代码，能不能过全球最挑剔的那批reviewer？
为什么偏偏是引用计数
引用计数这东西，像图书馆唯一的那本借还登记簿。小文件读取得越快，登记簿前排的队越长。传统思路是在登记簿旁边再开几个窗口，但窗口开多了，账又对不上——页面什么时候能安全释放，成了新的难题。
Torvalds选RCU这条路，等于把“边借边登记”改成“先借后统一核销”。读者只管读，释放的事交给宽限期。性能账好算，工程账难算：延迟回收的内存占着不放，极端情况下可能引发内存压力，那两道1024页的安全阀就是为此加的。可安全阀本身也是妥协——强制加速宽限期会打断RCU的正常节奏，带来新的抖动。
这就是为什么reviewers没有因为数字漂亮就放行。内核补丁从来不是跑分比赛，回归没查清、回收策略被质疑、测量只在个人机器上跑过，任何一条都足以让一个补丁留在实验区。
为什么以前不用AI写
Torvalds对AI的态度，过去三年走了一个完整的弧。2023年12月，他说“我把AI看作能帮助我们把工作做得更好的工具”，但那时他想的还是找Bug，“没人认真考虑用AI写严肃程序”。到2025年底，他称自己是“AI作为工具的坚定相信者”，兴趣从找Bug扩展到维护代码和审查补丁。2026年1月，他开始在一个Python音频可视化器的业余项目里尝试AI辅助编码。
但写内核代码是另一回事。Linux内核有它自己的门槛：不是语法对就行，是要符合几十万人年积累下来的“品味”——命名、错误处理路径、锁的粒度、向后兼容。Torvalds在2026年5月的Linux 7.1-rc4发布帖里抱怨过另一件事：AI生成的安全漏洞报告把内核的私密安全邮件列表变得“几乎完全无法管理”。据内核维护者Willy Tarreau对LWN的说法，这个列表两年前每周只有2-3份报告，到2026年初变成每天5-10份，大量是重复的、低质量的模型写作。
所以这次的分界线画得很细。他不是在让AI自主写补丁，而是在“他的指导下”使用工具，然后自己验证、自己署名。他在信里写得很克制——测量是在“我的机器”上跑的，不是标准化的CI，也不是多架构验证。这种克制本身就是一种表态：AI可以出力，但责任不能外包。
LLM的另一面：它也能挖出旧代码里的Bug
就在同一时期，据相关报道，Torvalds还在另一项维护工作里用LLM拆解了内核关联数组库里一段过于晦涩的大函数。代码被拆到人类能读懂之后，不仅确认了原有问题，测试套件还顺带挖出了3个自2013年就藏在里面的隐蔽Bug。
这件事的象征意义可能比性能补丁更大。过去两年，AI在开源社区的角色一直是“噪音制造者”——每天几十份重复漏洞报告消耗维护者精力。但Torvalds的用法给出了另一种范式：不是让AI直接交作业，而是让AI做人类已经做不动的事——读懂没人敢碰的旧代码，把晦涩拆成可读，然后人类再做最终判断。
这恰好击中了开源维护最痛的点。30年的Linux，最缺的不是写新代码的人，而是敢动旧代码的人。一段2013年留下的代码，原作者可能早已离开项目，文档缺失，测试覆盖薄弱，谁动谁背锅。LLM在这里不是替代维护者，而是给维护者递了一把能撬动历史债务的杠杆。
红线在哪里
Torvalds把两件事分得很开：一边是AI生成的低质量漏洞报告洪水，另一边是他这次的做法——指导工具、用真实硬件的真实测量验证输出、然后把自己的名字放上去。
这条红线的本质是责任归属。AI可以写代码、可以审查、可以跑测试，但最后为结果负责的必须是具体的人。在开源世界，署名不是荣誉，是问责。一个补丁出了问题，社区要找得到那个人，而不是去找一个模型。
这也解释了为什么补丁还没合并。性能数字漂亮，但回归没查清、回收策略被质疑、测量只在个人机器上跑过——这些都不是AI能不能写代码的问题，是工程严谨性能不能过关的问题。Torvalds自己说过，这类修复往往需要“那些长期在场、真正理解代码的维护者和开发者”，而LLM“目前还没到这个水平”。
结论层：这意味着什么
对Linux社区，这件事最可能的走向不是“AI开始大规模写内核”，而是维护工作流的分层：AI负责初稿、测试、旧代码梳理和重复性审查，人类维护者负责架构判断、品味把关和最终署名。
对更广泛的开发者群体，信号更直接：AI辅助开发的价值，不在替代，而在放大。放大你读旧代码的能力，放大你验证假设的速度，放大你处理重复劳动的余裕。但放大不等于自动正确——Torvalds的3倍吞吐，是建立在他亲自跑测量、亲自写披露、亲自扛责任的基础上的。
谁会赢？那些把AI当杠杆、同时把责任边界划得更清楚的人和团队。谁危险？指望AI自动交活、却没人愿意为结果签字的组织。
AI写代码从来不新鲜，新鲜的是有人愿意为AI写的代码署名。在开源世界，署名比代码更难——因为它意味着当AI犯错时，站出来承担责任的是人，不是模型。
快报