摘要：Linus Torvalds 最近点明了一个越来越现实的问题：AI 并没有自动提升漏洞治理质量，反而可能把内核安全列表拖进重复、拥堵和低效。Linux 内核新补充的安全文档，本质上不是反 AI，而是在给“自动化发现漏洞”划边界。
最近围绕 Linux 内核 7.1-rc4 的讨论里，Linus Torvalds 释放了一个很清楚的信号：内核社区已经开始受不了 AI 生成或 AI 辅助生成的漏洞报告洪流。问题不只是报告变多，而是大量报告开始重复、撞车、缺少充分验证，最后把原本用于处理高风险安全问题的私密渠道，变成了低效的分诊中心。
这件事值得关注，不是因为 Linus 又一次“发火”，而是因为它把 AI 时代一个越来越现实的问题挑明了：当发现漏洞的门槛被模型和自动化工具迅速拉低之后，真正稀缺的资源不再是“能不能找到问题”，而是“谁来验证问题、排序问题、修复问题，以及承担误报和错报的成本”。
很多人看到这个消息，第一反应可能是“Linus 反对 AI”。这其实是误读。Linux 内核并没有否定 AI 工具进入开发流程，相反，官方文档甚至已经承认 AI 会参与开发，并要求人类提交者承担审查和签署责任。2 真正被收紧的，是把 AI 找到的疑似问题直接塞进安全私有列表、要求维护者优先处理的这种做法。
安全列表不是普通 bug 入口，而是高风险问题的私密通道
Linux 内核安全列表原本就不是普通 bug 反馈箱。它的存在，是为了在公开披露之前，协调处理那些确实构成安全威胁、而且可能影响大量生产系统的漏洞。也正因如此，这个通道本来就不该承载大量模糊、重复、未经验证的“疑似安全问题”。
而 AI 恰恰在放大这种输入。模型、静态分析器和自动化审计流程确实很擅长大规模扫描代码里的可疑模式，比如边界检查、引用计数、整数溢出和权限边界处理。这些工具不是没用，它们确实能帮助发现真实问题。但只要不同研究者使用相似工具、相似提示词和相似分析框架，他们就很容易在差不多的时间里，把差不多的问题同时提交给同一批维护者。
结果不是“社区更安全了”，而是维护者先被重复劳动淹没。
Linux 内核规模长期增长，维护复杂度本来就在持续上升。AI 如果继续把低质量、重复性的漏洞报告批量推给维护者，冲击的就不只是安全流程，而是整个维护体系的注意力预算。
Linux 这次真正做的，是给“安全漏洞”重新划边界
这轮变化最重要的地方，不在媒体标题，而在 Linux 官方文档新增和澄清的规则。
在 Security bugs 文档里，内核社区重新强调：真正适合走安全列表的，是那些在“正确配置的生产系统”上，能让攻击者获得其本不应拥有的能力，而且容易被利用、会对大量用户构成迫切威胁的问题。1 换句话说，不是所有 bug 都是安全漏洞，更不是所有“看起来有风险”的代码路径都值得进入私密通道。
这其实是在给“安全”两个字去通胀。过去几年，安全行业里逐渐形成了一种习惯：只要能把某个异常路径包装成“潜在漏洞”，它似乎就天然应该获得更高优先级。但在 Linux 内核这种超大规模、长期演进的工程里，如果什么都往安全列表里塞，真正紧急的问题反而更容易被淹没。
最刺眼的一条规则：借助 AI 找到的问题，默认视为公开问题
新文档里最有现实意味的一句是：如果你借助 AI 来识别一个 bug，就必须把它当作公开问题处理。1 内核安全团队给出的理由很直接：这类问题往往会被多个研究者在差不多时间同时发现，而且常常是用同一类工具、同一类方法发现的。既然如此，它就不再适合被当作“只有少数人知道的秘密漏洞”。
这条规则很冷静，也很残酷。它等于直接否定了一个隐含前提：不是你先把 AI 跑出来的结果发进私密邮箱，你就拥有了某种应被秘密保护的独占发现权。对内核社区来说，更现实的判断是，只要某类问题已经能被广泛可得的 AI 工具重复找出，它就已经接近“公共可发现状态”。此时继续走私密安全流程，收益不一定更高，反而会挤占真正需要保密协调的资源。
Linus 真正在防的，是开源社区的治理失衡
把这件事只理解成“老派开发者排斥 AI”，太浅了。Linus 真正担心的，是社区治理机制被输入侧的自动化彻底打穿。
Linux 内核不是论文竞赛，也不是漏洞打榜平台，它首先是一个需要持续发布、持续回归测试、持续维护兼容性的工程系统。维护者每天面对的，不是抽象的“代码质量”，而是具体而有限的注意力分配：哪些补丁先进，哪些问题先修，哪些风险会影响真实用户。
在这样的系统里，最危险的不是有人用 AI 找 bug，而是所有人都被激励去提交更多“看起来像成果”的报告，却没人对后续链条负责。报告越多，责任越稀薄；发现越自动化，处理越人工化。最终社区会陷入一个典型失衡：上游输入暴增，下游维护能力没有增加，维护者只能把时间消耗在筛噪音，而不是修问题。
从这个角度看，Linus 这次踩下的，不是 AI 的刹车，而是流程失控的刹车。
这场争论对技术团队有什么启示
第一，别把 AI 审计结果直接等同于漏洞事实。AI 给出的很多内容只是线索，不是结论。没有版本范围、没有复现条件、没有攻击路径、没有影响边界的报告，最后通常只会制造流程拥堵。
第二，安全流程必须分层。不是所有问题都应该进入最高优先级通道。未来企业如果大量引入 AI 做代码和配置扫描，同样需要把“发现”“验证”“分级”“修复”拆开，而不是把所有告警一起扔给核心团队。
第三，AI 时代真正稀缺的，不再只是发现问题的能力，而是把自动发现纳入可承受治理流程的能力。谁能守住这条线，谁才能在 AI 安全工具越来越普及的时代，继续维持工程效率和判断力。
Linus 这次的表态之所以重要，就在这里。它提醒所有人：AI 可以让漏洞发现变得更便宜，但不会自动让漏洞治理变得更成熟。发现权在下降，判断力反而更值钱了。