10 月 12 日晚，一篇让中文程序员圈炸锅的报道出现了：Linus Torvalds 正利用 Claude Code 进行一项重大的 Linux 内核改进，原始报道来自 Linux 硬件媒体 Phoronix。 不到 24 小时，B 站、微博、知乎、小红书全在转，知乎问题标题甚至直接写成了"如何看待 Linus 使用 Claude Code 进行 Linux 内核 vibe coding"。哔哩哔哩知乎
先别急着站队。这波传播里，标题、标签和事实混在一起，值得把时间线捋直，再看这次改动本身——因为对一个深度用 AI 编程工具的人来说，这件事真正的信息量不在"祖师爷也用了"，而在他是怎么用的。
从"要么 Fork 要么走人"到亲自下场：四步时间线
把公开信源串起来，会发现这不是一个突发新闻，而是一场持续了四个月的立场演变：
6 月下旬：谷歌工程师做的内核 AI 审查工具 Sashiko 开始在中文社区流传，有人写出了本地部署指南。按其介绍，这款工具的核心是模拟完整内核维护者审查流程，分层逐项校验，覆盖内核开发所有高频问题。知乎
7 月：LKML（内核邮件列表）爆发 AI 审查大论战。据 B 站内核区科普视频梳理，支持者说它能发现 53% 人类遗漏的漏洞，反对者抱怨它充斥着 20% 的误报和"幻觉"，一位维护者甚至说加班 13 小时写的补丁被一秒打回。 Linus 亲自下场裁决，随后成形的知乎话题标题就是那句著名的定调：Linus 称 Linux 不搞"反 AI"，并要求"要么 fork，要么走人"。 该话题下的头部回答一路刷到 37 万浏览。哔哩哔哩知乎
9 月：一位自称做 Linux 内核的工程师在热答里承认——此前一年他一直觉得内核领域是最难被 AI 攻破的，直到 Sashiko 开始介入 review。知乎
10 月 12 日：轮到 Linus 自己用了。
这次改动，实际发生的是什么
综合微博科技媒体转述、小红书科技博主对原始仓库的核对和 Phoronix 报道，细节其实很清楚。
最值得注意的信号藏在分支命名里：Linus 的主仓库几十年来几乎只挂一条 master 主干，而这个周末多了一条新分支 `noref-filemap-read-with-llm`，llm 三个字母直接缀在结尾，连名字都不藏着。 它瞄准的是内存管理里最要命的部位之一：当成千上万个线程同时读同一个文件的小块数据时，内核要对每块内存做引用计数，大家挤在同一处排队，速度被拖死；新方案是读页缓存时彻底绕开 folio 引用计数。而补丁说明里，Linus 亲笔写明代码、测试程序和这份说明的初稿都是在他的指挥下由 LLM 助手完成，性能测试就跑在他自己的机器上——此前一轮文件读取优化已经用过同样的路子。小红书
第二条线是那个被讨论最多的"关联数组"修复：继此前借助 Claude Code 优化文件读取性能之后，这次他用大模型分析了一段长期以来逻辑晦涩的关联数组代码。 起点是开发者尼尔斯提交的一份缺陷报告，由于原始实现过于晦涩难以直接理解，托瓦兹选择让 LLM 把庞大的函数拆分成更清晰的结构，以便于人工审查其逻辑正确性，再放进用户空间测试框架运行——结果不仅证实了原始报告的缺陷真实存在，还顺带挖出另外三个潜伏达十余年的问题。目前修复以 `assoc-array-fixes` 标签挂在他自己的仓库里，尚未合并主线，预计将在 Linux 7.4 合并窗口期间进一步推进。新浪微博小红书
B 站新闻视频下 499 赞的第一条评论说"在人工智能出现之前，Linus 就已经在使用邮件列表指挥能工智人进行 vibe coding 了"，是玩梗；另一条更值得划重点：“这只是利用大模型做改进，不是说人家会直接合并 slop。”
为什么"审查 AI"被打回，"辅助开发 AI"却被祖师爷用上了
这是整件事最有认知增量的一点。7 月 LKML 吵翻的 Sashiko，核心矛盾从来不是 AI 行不行，而是责任和噪音的错配：它往邮件列表批量发审查意见，误报要人类维护者逐条消化，指出 0.01% 的问题也够各模块负责人喝一壶。评论区说得直白：AI 只能写对应的那一部分，写出来的可能和其他部分不兼容。
而 Linus 这次的模式恰好反过来：实践也显示，AI 并非凭借自身超越人类的程序理解能力直接定位缺陷，而是通过改善代码可读性，配合实际执行和可重复的测试框架，最终由人工审查确认问题。 同样是用大模型，一个是把 AI 塞进别人的工作流，一个是把 AI 关进自己的工作流。这解释了为什么前者四个月吵不完，后者一个人用出了三个陈年漏洞。新浪微博
顺带一提，开源世界对 AI 的分界线不止画在一处：Zig 的作者走完全禁用 AI 生成代码的路线；而唯一从零自研引擎的浏览器项目 Ladybird，今年 6 月直接关闭公开 PR 通道，不再接受外部代码贡献。 按原文作者的梳理，创始人 Andreas Kling 的理由是 AI 工具改变了贡献的经济学，一份大补丁不再必然代表大投入，旧尺子没法再量新东西。接受、禁用、拒收，三条路都有人在走。知乎
一个内核维护者的用法，能搬进你项目的三件事
如果你已经在用 Claude Code、Codex 或 Cursor 干重活，这次事件给了三个比"祖师爷站队"更有用的参照：
先让 AI"翻译"，再让它动手。 面对读不懂的旧代码，别问"这里有什么 bug"，让它把巨型函数拆成人能审的结构。AI 这次的价值不是"程序理解超过人类"，而是改善可读性——让缺陷在人眼里变得可见。
测试框架永远比模型先到场。 Linus 敢用 LLM 拆出来的代码，前提是用户空间测试可重复执行。你的项目里没有可跑的测试，AI 的重构就只是另一堆需要人肉验证的 AI 代码。
AI 的产出先落地成可回退的工件。 独立分支、独立标签、不合主线——出问题随时整体丢掉。对照此前"谁来收拾这堆 AI 代码"的争论，这条就是答案的一半：收拾的边界，从你给 AI 划的分支开始。
接下来看什么
别把这次当成"内核正式接纳 AI"的定论——补丁还没合并。真正值得盯的是三个信号：Linux 7.4 合并窗口里这批修复能否进去、合并说明里会不会继续大方标注 LLM 参与（`noref-filemap-read-with-llm` 这个分支名已经说明他不打算藏）、以及内核文档层面会不会给 AI 辅助开发立下新规则。距 Linus 1991 年在新闻组里宣布 Linux，整整 35 年过去了。 这个最挑剔的代码库怎么给 AI 划边界，后面大概率就是整个行业抄的模板。哔哩哔哩
至于"vibe coding"这个标签？看完全文你会发现，祖师爷干的始终是他那句老话——Talk is cheap, show me the code。区别只是这一次，写第一稿的换了机器，看 code、跑 code、对结果负责的，还是他。
