Linux 开始给 AI 立规矩了

这几天刷 X，Linux 圈子里最热闹的，不是又有哪个模型在 Ubuntu 上跑起来了。

而是 Linux 内核社区，开始认真讨论一件有点尴尬的事，AI 写出来的代码，到底能不能进内核。

AI 补丁规则

事情是这样的。

8 月 4 日前后，Linux 社区关于 staging 区域拒绝 LLM 生成补丁的讨论，被一群开发者搬到了 X 上。这里的 staging，不是 Linux 内核最核心、最稳定的区域，它更像一个试验场，新驱动、新代码、还在学习中的贡献者，都会先在这里磨一遍。

结果现在连这个试验场，也开始对 AI 生成的补丁说不。

但这个「不」不是全面禁用 AI。

更准确的说法是，如果你不知道补丁在做什么，只是让大模型吐出一段代码，再把它塞进内核，抱歉，这种东西不欢迎。真正的安全修复，则是另一回事。

这一下讨论就炸开了。

有人说，AI 代码也可能是好代码，为什么要一刀切？

也有人说，内核开发不是 LeetCode，能编译、能过几个测试，并不代表你理解了锁、内存、并发和硬件边界。

我觉得两边都没有说错。

但 Linux 这次真正拒绝的，可能从来都不是 AI，而是「没人负责的代码」。

这块需要先讲清楚。

Linux 内核的补丁，从来不是把代码发上去就完事。你要说明它解决了什么问题，为什么这么改，影响哪些路径，测试过什么，谁愿意为它签名。内核维护者看的，不只是代码能不能跑，还要看提交者是不是知道自己在修改什么。

这套流程听着挺老派。

甚至有点慢。

但它保护了 Linux 最重要的一层东西，责任链。

一个补丁出了问题，维护者能找到提交者，提交者也知道自己为什么这么写。AI 可以帮忙搜索、对照、生成草稿，但不能替你站在邮件列表里解释一句「为什么这里要加这个锁」。

如果这句话解释不清楚，那段代码最好不要进来。

这就是 Linux 和很多普通应用项目之间的区别。

你给一个内部工具用 Copilot 生成 300 行 CRUD，出了问题，大不了回滚。你给 Linux 内核塞进一段自己都没读懂的内存管理代码，出了问题，可能是某个数据中心的机器随机崩溃，也可能是一个很久以后才爆出来的安全洞。

不是一个量级。

所以我看到这件事的第一反应不是「Linux 也开始反 AI 了」，而是，Linux 终于把 AI 时代最麻烦的那层东西说出来了。

生成代码很便宜。

解释代码很贵。

顺着这个话题往下看，会发现 Linux 社区对 AI 的态度其实没有那么简单。

今年 7 月，Linus Torvalds 针对内核里的 AI 讨论表达过一个很明确的方向，Linux 不是一个反 AI 项目。内核开发者可以使用 AI，也可以让 AI 做代理式代码审查，但这不等于任何一段 AI 生成的补丁都应该被接受。

这就很像 Linus 的风格。

他不太关心你用不用某个工具，他关心的是你提交的东西是不是靠谱。

你用锤子、扳手还是一只训练有素的机器狗，工具不重要，最后这面墙不能塌。

甚至在更早之前，Linux 内核维护者 Greg Kroah-Hartman 已经在使用本地 AI 工具寻找内核 bug。这个工具在社区里被叫作 Clanker T1000，跑在本地机器上，能扫描、分析和提出修复建议。

但注意，建议不是补丁。

补丁也不是合并。

中间还有一整条人类审核链。

这件事其实挺有意思，Linux 社区并没有把 AI 放在「神」的位置，也没有把它扔进「垃圾」的位置。

它更像一个效率很高、但经常自信过头的实习生。

能帮你找问题，能帮你把重复工作做完，偶尔还能发现人类漏掉的东西。

但它写完的每一行代码，都得有人负责。

这话听着有点保守，可对于内核来说，保守其实是一种生产力。

因为内核的复杂度，很多时候不是写代码的复杂度，而是理解历史的复杂度。一个看起来多余的判断，可能是在修十年前的硬件问题；一个看起来可以删掉的兼容分支，可能还在某个冷门设备上救命。

大模型能读很多代码，但它不一定知道哪一行是历史留下来的伤疤。

这就是 AI 参与 Linux 开发最难的地方。

不是模型不会写 C。

是它还不懂哪些东西不能随便碰。

更麻烦的是，AI 现在已经不只是生成补丁，还在生成 bug 报告和安全报告。

AI 安全报告责任链

今年春天，Greg Kroah-Hartman 就提到过一个变化，过去收到的很多 AI 安全报告是垃圾，后来突然之间，报告变得真实而且有用。听起来是好消息，对吧？

但好消息一旦规模化，也会变成新的麻烦。

今年 5 月，Linus Torvalds 公开抱怨过，Linux 内核私有安全邮件列表几乎已经被重复的 AI 漏洞报告搞到不可管理。不同研究者调用类似的 AI 工具，扫描同一份代码，最后生成一堆重复报告，全都挤进维护者的收件箱。

这就像全城突然多了十万名侦探。

他们真的找到了犯罪现场。

但每个人都把同一张照片寄了三遍。

你不能说他们完全没用。

但负责整理照片的人，估计已经开始想辞职了。

所以 Linux 内核现在面对的不是「AI 会不会取代开发者」这种很大的问题，而是一些非常具体、非常烦人的问题。

谁来去重？

谁来确认报告是真的？

谁来解释补丁？

谁来承担合并之后的结果？

这几个问题，才是 AI 进入开源基础设施之后真正的门槛。

而且这周还有一个挺有意思的学术信号。

8 月 4 日，一篇关于 Linux 内核注释中陈旧函数引用的研究被公开讨论。研究者用自动化方法扫描 Linux 内核源码，发现大量注释里的函数引用已经过时，并给出自动修复建议。

这类事情特别适合 AI。

它不需要你理解整个 Linux 的哲学，也不需要你凭空设计一个复杂的调度器。它只需要对着庞大的代码库，做一件人类很不想做、但又确实应该做的事情，找出那些已经变质的文档、注释、引用和重复模式。

我一直觉得，AI 在 Linux 里的最佳位置，可能不是替人写核心逻辑，而是替人清理那些积累了十几年的边角料。

代码考古。

很适合机器。

顺着上面的，再聊聊本地 AI 这块。

Linux 与本地 AI 基础设施

这周 X 上还有一条不那么热闹，但我觉得很重要的线索，Linux 正在越来越认真地处理计算加速器，而不是只把所有东西都当成 GPU 的附属功能。

Linux 内核文档里已经有了独立的 compute accelerators 子系统，用统一方式把面向推理的加速设备暴露给用户空间。它和传统 GPU 的边界开始被明确区分，原因也很现实，边缘 AI、NPU、专用推理芯片，都不一定适合套进原来的图形驱动模型。

这件事的画风非常 Linux。

大家还在为 AI 生成的补丁吵架，内核开发者已经在默默给下一代 AI 芯片安排设备节点、内存、队列和用户空间接口了。

嘴上吵得很凶。

代码还是得继续写。

你如果最近在 Linux 上折腾本地模型，应该非常能理解这种割裂感。

模型下载下来不难，真正麻烦的是驱动、内核、显存、共享内存、编译参数、推理后端和硬件加速路径。一个模型能不能跑，不只是看模型文件多大，还要看 Linux 能不能把它正确地送到那块 NPU 或 GPU 上。

这也是为什么 Linux 和 AI 的关系，最后一定会落到基础设施上。

模型会更新。

框架会换。

但设备、驱动、内存和调度这些东西，才是所有 AI 应用最后都要踩到的地面。

所以这一周 Linux AI 领域最值得看的变化，我觉得可以浓缩成一句话。

Linux 没有拒绝 AI。

Linux 正在拒绝不负责任地使用 AI。

允许 AI 找 bug，允许 AI 做审查，允许 AI 清理代码，允许 AI 帮忙理解庞大的内核。

但你提交一个补丁，就得知道它改了什么；你发一份安全报告，就得确认它不是重复噪音；你把 AI 接进开发流程，就得给它设置边界。

这不是 Linux 特有的问题。

以后所有重要的开源项目，都会遇到。

甚至我们自己写一个几百行的服务，也会遇到。

AI 最先改变的，可能不是写代码的速度，而是代码审查和责任分配的方式。以前一个人一天只能看十个补丁，现在机器可以先看一千个，问题是最后那十个真正应该合并的补丁，谁来确认？

这件事没有捷径。

工具可以越来越强，但理解和负责这两件事，暂时还不能外包。

Linux 这个全世界最庞大的协作项目，可能正在给我们做一个很早的示范。

AI 可以进来。

但别想直接坐主驾驶。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ / /

资料与引用

资料截至 2026 年 8 月 10 日。

• -Linux 内核生成内容指南
• -Linux 内核补丁提交指南
• -Linux 内核计算加速器文档
• -Linux 内核注释陈旧引用研究
• -8 月 Linux staging 区域拒绝 LLM 补丁的社区讨论