Marico's space
最近盯着 Linux 内核邮件列表的八卦看了一阵子，发现 Linus Torvalds 终于发飙了。这事说大不大，说小不小，但确实把一个老问题摆到了台面上：AI 工具降低了找 Bug 的门槛，但没降低理解 Bug 的成本。当第二步被大规模跳过去的时候，维护者就成了噪音的承受者。这就是刚刚把 Linux 内核安全邮件列表搞崩的那件事。
快速总结： AI 工具降低了发现潜在 Bug 的成本，但没有降低理解它们的成本。当第二步被大规模跳过时，维护者承受了所有噪音。这就是刚刚把 Linux 内核安全邮件列表搞崩的原因。
2026 年 5 月 17 日，Linus Torvalds 在发布 Linux 7.1 第四个候选版本时，做了一件他很少做的事：停止聊代码，开始聊人。
而且聊得不太友好。
他的消息很直接：Linux 内核的私有安全邮件列表已经变得"几乎无法管理"。原因是：一波持续不断、越来越快的 AI 生成 Bug 报告——重复、低质量，而且最要命的是，提交者根本不知道自己看的是什么。
这不是小抱怨。这是一个结构性问题的信号，它在地球上最关键的几个开源项目之一内部已经到达临界点。
Torvalds 在 Linux 7.1-rc4 发布时同步发布了"内核状态"说明。除了关于驱动更新、GPU 补丁和文件系统工作的常规说明外，他还标记了一个文档更新——然后解释了为什么现在需要这个文档。
故事很简单：AI 驱动的静态分析工具变得便宜且容易获取。研究人员和开发者开始用它们扫描 Linux 内核源代码树。工具找到了东西，这些人就把东西报上去——直接发到私有安全邮件列表——没有任何额外调查。
结果？多个人用同样的工具独立扫描同一代码库，找到同样的问题，然后各自发送单独报告。维护者整段时间做的事情就是：
Torvalds 说得很直白：
"完全是毫无意义的消耗……对每个参与者都是浪费时间。"
— Linus Torvalds，Linux 7.1-rc4 发布公告
内核项目用一个文档更新作为回应，现在正式处理这个问题。规则很简单：
如果你用 AI 工具发现了潜在的 Bug，走公开渠道上报——不要通过私有安全列表。
这不是惩罚，是架构设计。私有安全列表的存在是为了协调披露真实的、未公开的、可利用的漏洞。它要求维护者把每个进来的报告当作潜在敏感信息来处理，安静地调查，协调补丁，管理披露时间。那个流程有真实成本。
用未经人工分类的 AI 扫描器输出淹没它，会摧毁让这个渠道有价值的信噪比。把 AI 辅助发现的结果路由到公开渠道，内核团队就可以应用社区分类、公开过滤重复项，避免耗尽管理私有安全协调的那几个人。
这是大多数报道都略过的部分。
这些报告中有很大一部分不只是重复——它们被错误分类了。普通 Bug 被当成安全漏洞报上来，因为提交者不理解 Linux 内核的威胁模型。
Linux 内核有一个有完整文档的威胁模型。并非所有在孤立状态下看起来危险的东西在真实攻击场景中都是可利用的。AI 扫描器看起来像漏洞的内存模式可能是：
当有人不做威胁模型阅读、不查 Bug 跟踪系统、不对照最近提交验证，直接倾倒 AI 报告时，他们产生的是伪装成信号的噪音。而且他们迫使有经验的维护者把时间花在他们没有的时间来拆解这些噪音。
Torvalds 说得很明确：他不需要路过式贡献者——发一个随机报告然后消失。如果你找到了什么，他希望你：
这要不是真正的 Linux 故事，就不会有关于分歧的部分。
2026 年 3 月，内核维护者Greg Kroah-Hartman 告诉 The Register 一些不同的事：AI Bug 报告已经从低质量噪音转变为真正有用的贡献。他的经验是质量已经有了实质性改善。
另外，Nvidia 内核工程师Sasha Levin 提出了一个完全不同的架构响应——一个 Linux 内核紧急开关机制，允许管理员在等待补丁落地时临时禁用有漏洞的内核函数。这是一种防御姿态而不是门槛设置。
所以即使在内核社区内部，人们也在得出不同的解决方案。Torvalds 关注噪音问题。Levin 考虑真实 Bug 存在时的运营响应。Kroah-Hartman 看到杯子里有半杯水。
三种视角都是合理的。情况确实复杂。
退后一步看，这个模式在任何大规模开源与 AI 工具交叉的地方都能认出。
AI 降低了找到东西的成本。它没有降低理解它的成本。这两个东西之间的差距就是问题所在。
当你在一个 3000 万行代码库上运行静态分析器，它返回 400 个潜在问题时，分析师的工作——那个昂贵的、有技能的、不可替代的部分——是搞清楚这 400 个里面哪 5 个真正重要。AI 加速了第一步。它没有自动化第二步。
Linux 安全列表现在发生的是，人们完全跳过第二步直接去报告。他们把工具的输出误认为是分析的输出。
这是伪装成 AI 问题的流程问题。
同样的事情在漏洞研究领域广泛发生。自动扫描器找到候选项。人类研究员验证它们。如果你去掉验证步骤，直接把候选项发出去，就产生了噪音。扫描器不知道它找到了什么。只有研究员在调查之后才知道——研究员。
这里还有一个更不舒服的潜台词值得说出来。
这种行为的一部分是追求名声。如果 AI 工具浮出了一个潜在内核 Bug，你提交了一份报告，你就做了一件事——你发现了一个 Linux 内核漏洞。这听起来很厉害。它不重要的是它是否已经被修复、已经被知道、或者根本不是漏洞。行动本身就产生了一个你可以讲的故事。
这是贡献的游戏化。在大规模开源项目上这是腐蚀性的，因为它把维护者的收件箱变成了每个人的成就农场。
作为一个维护开源 CLI 工具和 VS Code 扩展的人——这些项目规模远不及 Linux 内核——我可以告诉你，一份低质量的自动化问题报告，处理的能量比生成它花的时间还多。你打开它希望它是某个在生产环境中遇到真实边缘案例的人。结果它是一份扫描器输出，没有复现步骤，没有上下文，没有任何迹象表明报告者曾经运行过代码。这种摩擦会杀死真正路线图上的动力。
对 Linux 内核——以及对任何严肃的开源项目——的真正贡献需要做那些无聊的、缺乏魅力的工作：
这不是抱怨。这是入场费。内核社区对此一向严格要求，因为赌注很高。你在发布运行在数据中心、医疗设备、航天器和数十亿部手机上的代码。"我用一个 AI 扫描器找到的"不是足够的门槛。
如果你想做有意义的 AI 辅助 Linux 内核安全研究，以下是真正需要的过程：
扫描之前：
扫描器返回结果时：
git log --all --oneline -- <file>
如果你认为它是真实的且未修复的：
黄金标准：
这种情况是 AI 工具商品化、贡献摩擦趋近于零时会发生什么的早期案例研究。
更低的摩擦不总是更好。在质量重要的系统里——Linux 内核的安全流程绝对符合条件——摩擦在做有用的工作。它过滤掉没有做足够思考的人的报告。在不替换成其他东西的情况下移除摩擦，你会得到规模化的垃圾邮件。
内核团队的回应——把 AI 辅助报告路由到公开渠道、要求更多文档、明确说明他们想要什么和不想要什么——本质上是有选择地重建那个摩擦。不是为了把人挡在外面，而是为了确保通过的东西值得处理成本。
这是对不合理情况的合理回应。
更有趣的是——Sasha Levin 的紧急开关提案暗示了这一点——内核社区最终能否在维护者端建立用 AI 对传入报告进行分类的基础设施。用 AI 对抗 AI 垃圾。几个 Slashdot 评论者做了同样的观点：一个大语言模型（LLM）如果能访问 Bug 跟踪系统和 git 历史，可能可以用很少的训练在高准确性下分类"可能是重复/已经修复/不是安全问题"。
这是架构上的玩法。不是拒绝 AI。不是接受噪音。是在接收端建一个更好的过滤器。
Linus Torvalds 没有说 AI 工具是坏的。他说的是：用它们却不理解它们告诉你什么，不做后续分析，不关心报告对任何人有没有用——这是浪费每个人的时间。
他是对的。
AI 降低了找到候选项的成本。它没有取代知道实际上找到了什么所需的判断力。当那种判断力在规模化时被跳过，承受冲击的维护者付出了代价。
新文档规则是一条合理的线。更难的问题是——当 AI 工具变得普遍时，开源项目如何管理贡献质量——是整个生态需要回答的问题。
Linux 内核只是最先碰到了。
原文链接：https://dev.to/...