夜雨聆风5 月 17 日，Linus Torvalds 在 Linux 内核邮件列表（LKML）上发布了 7.1-rc4。每周发一个 RC 是他的惯例，过去三十多年从未间断。但这一次，公告的后半段不是代码变更统计，而是一段措辞罕见的警告：
“AI 报告的持续涌入，已经让安全邮件列表几乎完全不可管理了。”
他说的是 security@kernel.org —— Linux 内核的私有安全披露渠道。这个邮件列表存在的意义是让安全研究者在补丁准备好之前私下报告漏洞，避免被恶意利用。三十多年来，这套机制运转良好，确保 Linux 内核代码安全运行在全球数十亿台设备上，从 Android 手机到 AWS 服务器，从新能源汽车到国际空间站。
但如今 AI 正在瓦解这套机制的基本运转逻辑。
重复的 AI 报告“攻击”
“不同的人用同样的工具发现了同样的问题，产生了巨大的重复。”Linus 写道。维护者们把时间花在转发报告、回复“这个问题一个月前就修了”、指向公开讨论上。他把这称为“完全没有意义的空转”。
问题出在一个简单的逻辑上：当一个漏洞可以被 AI 工具轻易发现，它就不再是秘密。“如果你用 AI 工具发现了一个Bug，别人大概率也发现了。”Linus写道，“AI 发现的漏洞从定义上就不算秘密，放在私有列表上处理只会让情况更糟 —— 因为报告者看不到彼此的报告。”
这不是他第一次因为 AI 的事上 LKML 头条。两个月前的 4 月 12 日，内核社区经过长达数月的争论，正式发布了 AI 辅助代码的提交规范。当时争论的焦点是：AI 生成的代码能不能提交到内核？
Linus 坚持了一贯的实用主义终结了争论，最终出台的规范允许 AI 辅助编码，但要求标注“Assisted-by”标签，AI 代理不得使用具有法律效力的“Signed-off-by”签名。核心原则只有一条：每一行 AI 生成的代码，出了问题由点击“提交”的人全权负责。
一份文档，五条规矩
和 4 月的代码规范一样，这次 Linus 也不是只在邮件里抱怨。随 7.1-rc4 一同合并的，还有一份由长期内核开发者 Willy Tarreau 撰写的新文档，标题是“什么才算安全 Bug”。
文档先澄清了一个事实：送到安全团队的大部分报告，根本不是安全 Bug，它们只是被错误归类为安全问题的普通 Bug，原因是对 Linux 内核威胁模型缺乏了解。
紧接着是针对 AI 辅助发现 Bug 的五条规矩：
第一，报告要短。AI 生成的报告往往冗长无比，分段堆砌。文档要求把关键信息放在最前面，不要让审查者在多页文本里大海捞针。
第二，纯文本。AI 报告经常带着 Markdown 格式标签，但邮件列表的转发和回复过程会破坏这些格式。要求一律转成纯文本。
第三，只说事实。AI 报告经常罗列一堆“可能的影响”和理论推导，文档要求只提供可验证的事实。
第四，确认复现。如果 AI 工具提供了一个复现步骤，先自己跑一遍。如果复现不了，这份报告的可靠性就要打一个大大的问号。
第五，带上补丁。既然 AI 工具能发现 Bug，就让它顺便写一个修复补丁。测试过再提交，并且必须包含“Fixes:”标签指向引入 Bug 的那个 commit。
最关键的一条规则写在前面：“如果你借助 AI 发现了 Bug，你必须将其视为公开信息。不要公开发布复现步骤，也不要再走私有安全披露渠道。因为当你的 AI 能发现这个问题的时候，别人的 AI 大概率也已经发现了。”
Greg KH 和他自己搭的 t1000
几乎在同一时间，内核社区的“二把手”Greg Kroah-Hartman 正在做一件看起来和 Linus 的抱怨完全相反的事。
Greg 是 Linux 稳定版分支的主要维护者，负责把修复补丁回移到各个 LTS 内核版本。从今年 4 月初开始，他开始在自己的桌面上跑一台 AI 模糊测试机器，名字叫 gkh_clanker_t1000。
硬件是一台 Framework Desktop，搭载 AMD Ryzen AI Max + Strix Halo 处理器。这台机器完全本地运行，不连任何云服务。后来他又加了一台，叫 gkh_clanker_2000。
4 月 7 日以来，这套系统已经贡献了近二十个被合并到主线内核的补丁。覆盖的子系统包括 ALSA（音频）、HID（人机接口设备）、SMB（文件共享）、Nouveau（NVIDIA开源显卡驱动）和 IO_uring（异步I/O）。
Greg KH没有公开这套工具的软件栈细节 —— 用了什么模型、什么模糊测试框架、怎么把 LLM 和内核测试运行器串起来。Phoronix 在 4 月首次报道了这套系统，此后 Greg 只是在 Mastodon 上零星发了几张机器的照片。
但结果摆在那里：从 4 月到现在，一个又一个真实的内核 Bug 被其发现、被修复、被合并。不是重复报告，也不是理论推导，而是实实在在的、有价值的代码补丁。
AI 对内核社区的真实影响
Linus 的抱怨和 Greg 的实践看起来矛盾，但放在时间线上看，它们指向的是同一个转折点。
3月26日，Greg 在接受媒体采访时说了一段话：“几个月前，我们收到的是我们称之为‘AI 垃圾’的东西，AI 生成的安全报告要么是错的要么质量很低，当时觉得还挺搞笑的，并不太担心。”
“但一个月前，发生了一些事情，世界突然变了。现在所有开源项目都有用 AI 生成的真实报告，而且质量很好，是真正的 Bug。”
他说不清楚原因。“没人知道为什么，要么是很多工具突然变好了，要么是很多人开始认真对待这件事了。似乎是不同的团队、不同的公司同时在做。”
在这次采访中，他提到了自己的一次实验：“我写了一个特别简单的提示词，说‘给我找出这些’，它吐出了 60 个问题，还附带了修复方案。大约三分之一是错的，但仍然产生了三分之二正确的、有价值的补丁。”
他的结论是：“AI 工具已经很好了，我们没法无视这件事，它在变得更好。”
但 Greg 也特别提到，Linux 内核能应对这个量级的 AI 报告，因为其团队够大，维护者分布也广。他真正担心的是小型开源项目，可能维护者没有足够的精力去处理这些指数级增长的 AI 报告。
对于 AI 工具近来对内核社区造成的真实影响，虽然 Linus 在吐槽，Greg 在猛夸，但实际上两位内核社区大佬的表述并不矛盾：Linux 内核社区作为一个整体也许扛得住 AI 带来的变化，但安全邮件列表这个特定的工作流确实已接近崩溃。
AI 只是工具，关键在于怎么用
看到 Linus 的抱怨后，有人提了一个自然的反问：既然 AI 在制造问题，为什么不用 AI 来筛选和过滤那些垃圾报告？
答案是，这等于在套娃。
AI 生成的假报告之所以烦人，恰恰是因为它们看起来像真的 —— 格式正确、堆栈信息齐全、问题描述有条理。传统垃圾邮件过滤器能工作，是因为垃圾邮件有统计特征（批量发送、相似文本）。但 AI 生成的每条 Bug 报告都不一样，这正是 AI 最难过滤的那类内容。更重要的是，AI 筛选器的误杀代价远比漏杀高 —— 一条垃圾报告被放过，最多浪费几秒；但一条真实的内核 Bug 报告被误杀，可能会导致永远没人去修。
Linus 的核心立场从来没有变过：人要为代码负责。每个补丁都有 Signed-off-by 签名，每个子系统都有明确的维护者。这条责任链条的核心是可追溯的人类行为。引入AI做初筛，等于在最前端加了一个黑箱——它为什么放过了这条、丢掉了那条，没有人能给出有意义的解释。
但这不意味着 Linus 反对 AI，他吐槽归吐槽，并没有对 AI 采取一刀切的行动，只是提出新的规范，促使有 AI 参与的工作流程与时俱进地优化。Greg 的 gkh_clanker 恰恰证明了他的逻辑：AI 是一个工具，关键在于谁在用它、怎么用。
Linus 抱怨的那些报告，是随手用 AI 扫了一遍、把结果粘贴到邮件里就发出去的人。他们不理解代码，不验证结果，不提供补丁，不承担任何责任。而 Greg 是自己跑 AI、自己验证结果、自己写补丁、自己 Signed-off-by、自己维护子系统。工具是一样的工具，使用者是截然不同的人。
5 月 17 日，Linus 在 7.1-rc4 的公告末尾写了一句总结：
“AI 工具很棒，但前提是它们真的有帮助，而不是造成不必要的麻烦和毫无意义的假装工作。随便用，但用在能提高效率的地方。”
然后他补了一句对那些只发报告不干活的人说的话：
“如果你真的想贡献价值，读文档，写个补丁，在 AI 做的事情之上加一些真正的价值。别做那种随便发个报告、实际上什么都不理解的路过党，好吗？”
参考来源：
Linus Torvalds, Linux 7.1-rc4 Release Announcement, LKML-https://lkml.org/lkml/2026/5/17/896
The Register-https://www.theregister.com/security/2026/05/18/linus-torvalds-says-ai-powered-bug-hunters-have-made-linux-security-mailing-list-almost-entirely-unmanageable/5241633
Phoronix-https://www.phoronix.com/news/Clanker-T1000-AMD-Ryzen-AI-Max
老牌开源项目该不该接受 AI 代码？-https://my.oschina.net/u/4487475/blog/19585524
