Linus 让 Claude 写内核，为什么还列了十条未解问题？

Linus 都让 Claude 写 Linux 内核了，还需要程序员懂代码吗？看完他的提交说明，我的答案是更需要。AI 已经能参与很难的工作，但这次让我服气的，是提速数字后面那份没写完的账。

这不是只让 AI 补几行代码。Linus 在自己的内核仓库开了一个实验分支，说明里明确写到，代码、测试程序、用于列出问题的审查，以及说明初稿，都由 Claude Code 在他指导下参与完成；测量跑在他自己的机器上。

他特意留下的三个英文词是 “under my direction”，在我的指导下。知道这句以后，再看“AI 写了内核”，就不会把它理解成 Linus 给出一个愿望，然后等电脑报喜。

三倍是真的，受益的是一种具体读法

问题出在很多线程同时读同一个文件时。Linux 会把常用文件内容放进内存缓存，省得反复去硬盘找；可旧流程每读一次，都要去同一个计数器上记两笔。人多了，这本登记簿自己成了排队的地方。

Linus 这组补丁想省掉读取时的重复登记，同时把那块内存真正交给别人使用的时间稍微推后。只要读者还可能用到它，就先别让新住户搬进来。这样既能少争抢计数器，又得重新算清楚内存何时可以回收。

在他的四核八线程笔记本上，八个线程反复读取同一个文件的 16 字节，吞吐量从每秒约 990 万至 1040 万次，变成 3000 万至 3300 万次。这个“约三倍”有明确条件，适合拿来说明共享缓存的竞争确实被缓解了。

但如果只有一个线程，表里的变化就小得多。这也符合前面的原因：本来就没人跟你抢登记簿，撤掉它不会凭空快出三倍。拿这个结果去许诺 Linux 整机提速，或者游戏帧数翻三倍，已经换了题。

原文还提醒，这台笔记本会因温度降频，因此他更看重每次读取花掉多少处理器周期，而不是只盯每秒次数。测试还关闭了部分安全防护开关。数字足够说明这个想法值得继续研究，却没法直接替读者的电脑报出收益。

他没有只留下跑得快的那一页

我更在意的是接下来的反例。同一份说明写到，当读取目标的内存页尚未准备好、需要走异常处理时，一项 16 字节读取测试反而更慢。少做重复登记有好处，新增判断和退回原流程也会花时间；这些都由同一份补丁带来。

延后回收内存还有另一笔代价：已经不用的页在等候期间仍占地方。Linus 记录过，早期六个补丁在一项小内存虚拟机测试里，会导致系统杀掉占内存的大进程；补上后两个补丁后，这个复现能跑完。但内存分配器仍看不见等待中的页，问题清单没有因此被划掉。

为了确认测试真能抓到错误，他还做了一个反向试验：故意把应该延后释放的内存立即释放。同一套检查果然读到了不属于原文件的数据。这比“所有测试通过”多说了一件事：测试在保护机制坏掉时，确实会报警。

十条问题不是十个已经确认的漏洞。它们混合了已知退步、尚未测量的成本、未覆盖的机器和需要同行一起判断的设计。其中包括内存压力、某些平台上的行为，以及这次延后释放会给其他任务增加多少负担。Linus 把自己知道什么、还缺什么，都摆在了补丁旁边。

懂代码的人，接下来的工作更具体了

Reddit 的 r/theprimeagen 里，用户 littlefiredragon 留了一句：“Anyone who has used AI knows there’s a world of difference between a novice vibe coding and an expert doing it.” 他的意思是，新手和专家使用同一种 AI，做出来的事仍会很不一样。

我赞同这句话，但不想把它讲成“只有专家才配用”。这个例子里，经验起作用的地方很清楚：知道该优化哪一条路径，知道三倍收益只覆盖什么，知道该故意弄坏哪一处来检验测试。刚开始用 AI 的人也能练这些判断，不能用一张成功截图替代它们。

截至这次核对，公开的是实验分支和补丁说明，说明没有给出合入正式内核的版本目标；It’s FOSS 的报道也把它当作这组实验工作介绍。我们现在看到的成果，是一个有测量、有反例、值得同行继续审的方案。

所以 Linus 让 Claude 写内核，并没有让程序员的判断变得多余。恰恰因为 AI 能把方案推进得这么远，人终于有一份足够具体的东西可以追问：快在哪里，慢在哪里，哪种错误还能发生？那十条未解问题，正是这次工作接下来要做的部分。