说AI"90%是营销"的那个男人，这次用Claude Code给Linux内核写补丁，还写进了提交记录。微博知乎
骂AI最狠的人，先真香了
10月11日，Phoronix的Michael Larabel发现，Linus的个人代码树里多了个陌生分支：noref-filemap-read-with-llm。8个补丁，基于Linux 7.3-rc6。提交说明里Linus亲自交代了分工：代码、测试程序、问题清单、说明初稿，都是在他的指挥下由Claude Code完成的。这一巴掌，扇得整个AI编程圈集体沉默。知乎微博
AI解的，是人两年没解开的问题
2024年，Oracle工程师Matthew Wilcox发现页缓存的folio引用计数存在争用。Hardware Busters实测，在Linus那台i7-8565U笔记本的8线程测试里，这个争用占了跨核HITM开销的99.92%。Linus自己手工磨了18个月的修复方案，始终有缺陷；他先让AI重构了assoc_array库代码，顺带揪出三个存在十余年的旧漏洞。知乎微博
新方案思路更大胆：加PG_rcu_free标志位，用RCU延迟回收，读拷贝全程不持引用。数字确实夸张——笔记本8线程，每秒读取从1000万次冲到3300万次；换到64线程Threadripper上，从1330万次跃到3.04亿次，单次读取的内核周期从近2万降到735，23倍。知乎
冷水，Linus自己泼的
他明确提醒：这是极端合成基准的成绩，真实工作负载涨幅会小很多。他自己列了10个已知问题。Hardware Busters也测出了代价——待回收队列超过1024页就触发强制快速宽限期，未映射小文件读取要多付一次缺页异常，单线程读16字节从约4150周期涨到6550，反而更慢。微博
兜住Bug的，既不是AI也不是Linus
内核开发者Kiryl Shutsemau在补丁里揪出一处竞态：`filemap_read_rcu_batch()`里folio替换完成后才扩展文件大小，可能暴露从未真正写入的数据。这个洞，Linus和AI都没发现。10月19日，后续开发移交给了Shutsemau，补丁集至今仍是RFC，没合进主线。而11月初谈合并窗口时，Linus说对"AI引发的海量工作"涌入非常"满意"，称这是"一种更健康的方式"。知乎微博
头条报道下的高赞评论则现实得多：“十一刚捅了个大篓子，太相信AI导致过度设计，最后谁都没仔细review，线上直接大事故”。另一条评论泼冷水：“好像人写出来就没bug似的”。两句都对：AI决定速度，人决定对错。今日头条
Linus这套打法可以直接抄作业：方向人定，代码、测试、初审丢给AI；基准自己机器跑，已知问题自己列，合入前必须过另一双人的眼睛。他用AI写内核，但没让AI替内核负责。
