2026年10月13日，Linus Torvalds 向 Linux 内核邮件列表提交了一组 10 个补丁。这组补丁在他的指导下用 Claude Code 编写，解决了一个自 2024 年以来一直悬而未决的页缓存（page cache）扩展性瓶颈。大约四个小时后，开发者 Kiryl Shutsemau 回复指出代码中存在一个竞态条件（race condition）。一方说，AI 用几周解决了人类两年半没解决的问题；另一方提醒，这个补丁还没准备好。两边都有道理，而对用智能编程助手写代码的人来说，真正重要的是发现这个 bug 的流程。
Torvalds 用 Claude Code 在 Linux 内核里做了什么？
他重写了页缓存的读取路径，让最常见的 read() 路径不再修改页面的引用计数。公告见 2026年10月13日的邮件 "Improve page refcount scalability"，代码在他公开仓库的 rcu-free-v3 分支。
- 问题本身：大量线程读取同一个文件时，每次读取都会写同一个计数器，这条缓存行在 CPU 核心之间来回跳动。Matthew Wilcox 在 2024 年根据真实客户负载报告了这个问题。
- 之前的尝试：Torvalds 自己的一个草稿，他在自己机器上"带着问题"用了一年半；Shutsemau 一年前的版本，"同样有问题"；以及 Ilya Gladyshev 已到第 6 版的系列，"仍有已知的根本性问题"（均为 Torvalds 邮件原话）。
- Claude Code 的角色：据 Hardware Busters 对第一版说明信的总结，智能体编写了实现代码、测试程序、生成待解决问题清单的审查，以及说明信本身的初稿。基准测试在 Torvalds 自己的机器上运行。
- 分支名称：第一版以
noref-filemap-read-with-llm发布，使用 AI 这件事就写在名字里。
支持这组补丁的理由是什么？
它能用、体量小，而且是在两年半的失败尝试之后出现的。Torvalds 回应 Wilcox 的异议时这样写道："I have a patch series. It's clean. It's ten patches, each of them cleanly separated, half of them *tiny*, and none of them more than 150 lines of code. It works."
以下数据由他本人在自己的硬件上测得：
| 机器 | 之前 | 之后 |
|---|---|---|
| Ryzen Threadripper，64 线程 | 每秒 1330 万次读取，每次约 19900 个周期 | 每秒 3.04 亿次读取，每次 735 个周期 |
| Core i7-8565U 笔记本，8 线程（第一版） | 每秒约 1000 万次读取，2950 个周期 | 每秒最多 3300 万次读取，725 个周期 |
Torvalds 在邮件里自己加了说明：这是"a very artificial case"，所有 CPU 循环读取同一页面的一小块，"any real life impact will be much much less"。这个数字说明瓶颈消失了，而不是说你的服务器会快 23 倍。
审查者发现了什么？
一个真实的竞态条件、设计上的异议，以及这项改动是否值得冒险的根本疑问。全部发生在公开邮件列表上，不到 24 小时。
- 竞态条件：Shutsemau 指出，如果页面在缓存中被替换，而文件在读取过程中变大，读取方可能从旧页面复制"data that never got written there"。他提出的修复只有两行：读取文件大小之后，用
xas_reload()再确认一次页面没有变。 - 设计：Wilcox 表示不喜欢新的
PG_rcu_free标志，并提出了另一条路线。Harry Yoo 要求对等待释放的内存设上限。 - 成本与收益：Pedro Falcato 写道，在出现性能真正改变的实际场景之前（"not a microbenchmark"），这些补丁"look to be more trouble than they're worth"。
- 已知的性能回退：在第一版中，向尚未映射的用户页面读取 16 字节，耗时从约 4150 个周期升至 6550 个周期（Hardware Busters）。目前尚不清楚 v3 是否仍有此问题。
Torvalds 接受了竞态修复，并把这组补丁交给 Shutsemau 继续推进：他即将休假，还要负责合并窗口。目前这些改动都还没有合入内核。
双方在哪些地方一致，哪些地方分歧？
| 要点 | Torvalds | 审查者 |
|---|---|---|
| 瓶颈是否存在 | 存在，自 2024 年起 | 存在，无人质疑 |
| 代码正确性 | "It works" | 数小时内发现并修复竞态 |
PG_rcu_free 标志 | 必需，必须在取消映射之前存在 | Wilcox 倾向另一种机制；Shutsemau 和 Hildenbrand 建议仅限 64 位 |
| 实际收益 | 承认远小于 23 倍 | Falcato 要求真实负载，而不是微基准测试 |
| AI 的角色 | 在他的指导下编写代码、测试和审查 | 争论的是设计，不是工具 |
最后一行最重要。没有任何审查者因为补丁是用 AI 写的而拒绝它。这些异议和人写的补丁会收到的异议完全一样，而这个 bug 恰恰是 Torvalds 自己手写的草稿也犯过的那一类。
如何在自己的项目里复用 Torvalds 的方法？
把智能体的工作隔离出来，让它列出问题清单，自己做测量，运行竞态检测工具，并在合并前让另一个人审查。对应的命令如下：
1. 用一个能说明用途的分支。
git switch -c filemap-read-with-llm2. 让智能体列出可能出错的地方，而不只是写代码。Torvalds 就是这么做的。可以粘贴到会话里的示例提示词：
列出这项改动中尚未解决的问题：可能的竞态条件、
线程之间的读写顺序、资源在仍被读取时就被释放的情况。
对每一项，说明是否有测试覆盖。3. 运行竞态检测工具。靠肉眼审查，不论是人还是智能体，都会漏掉竞态。工具可以在运行时抓到其中一部分：
# Go
go test -race ./...
# C 和 C++，使用 ThreadSanitizer
clang -fsanitize=thread -g -O1 app.c -o app && ./app
# Linux 内核（KCSAN），写入 .config
CONFIG_KCSAN=y4. 在自己的机器上测量，并说明数字证明不了什么。Torvalds 发布基准数据时附上了"any real life impact will be much much less"。照做即可。
5. 在提交信息中声明使用了 AI。内核在 Documentation/process/coding-assistants.rst 中对此有明文规定：智能体绝不能添加 Signed-off-by，只有人可以；贡献需带上格式为 Assisted-by: LLM [TOOL1] [TOOL2] 的一行。在 Verboo Code 中，/commit 追加在提交信息末尾的文本可以配置：
/commit-message set "Assisted-by: LLM"
/commit-message status如果想在请人审查之前先让智能体审一遍 PR，/review 命令会运行 gh pr diff 并返回分析结果。把它当作第一轮：在内核这个案例里，补丁经过了智能体的审查，到达邮件列表时仍然带着竞态。
Verboo Code 的立场是什么？
这件事是迄今为止支持在严肃代码中使用智能编程助手的最好论据，但理由和标题暗示的不同。重要的数字不是 23 倍，而是这个竞态在大约四个小时内就被发现，因为代码交给了懂这个子系统的人公开审查。代码经过了智能体和 Torvalds 两道关，到达邮件列表时依然带着这个问题。
我们从中得出的规则是：只有你和智能体读过的代码，不要合并。智能体加快了编写、测试和列出风险的速度；专家审查仍然是区分"在我的基准测试里能跑"和"能用"的关键。
这笔账里便宜的部分，是让智能体再多跑一轮：问题清单、缺失的测试、对 diff 的第二遍审查。Verboo Code 提供无限 token，第三次审查和第一次花费相同，也给发现 bug 的人工审查留出更多时间。
