AI疯狂扫了4000万行Linux内核，一个版本CVE冲破2000个，维护者快被活活逼疯了：真正该被删的不是Bug，是没人用的老代码

Updated 09/02/2026 1 min read

AI飞行客

有一件事挺反直觉的。

你在2026年所有的AI安全创业公司路演PPT里看到的叙事，全都是同一个剧本：”用AI守卫你的代码库，把隐蔽的高危漏洞一个不落地揪出来。” 投资人听完拍桌子，CTO听完下单，工程师听完欢呼。

但这个叙事里永远藏着半句没说完的话——AI揪出来的”漏洞”里，有多少是真该修的，有多少只是噪声？

Linux内核刚刚用血淋淋的现实给了整个行业一记响亮的耳光。

根据Phoronix最新报告，Linux 6.x时代每个版本的修复量稳定在500个上下，进入7.0系列后迅速破千。而按当前趋势，即将发布的 Linux 7.3 版本，CVE修复量将直接冲击 2000个大关。换句话说，3个大版本周期，漏洞数量翻了近4倍。

但这个数字暴涨的背后，藏着两个让人哭笑不得的事实：

1. 内核本身的代码质量没有变差。维护者Jakub Kicinski直接给出了一个令人窒息的数据——7.3开发周期的648个安全补丁中，三分之一到一半来自AI工具； 2. 这些AI补丁中”大量的低优先级和幻觉来源的错误”需要耗时十倍的人力去甄别真假。

你召来AI当了100倍效率的”铁人保安”，结果它每分钟冲你办公室里喊一句”有炸弹”。然后你会发现，真正烧时间的不是排雷，是把那90%的”假炸弹”挨个扒开皮给老板看。

—

“发现漏洞”和”制造工作量”是一体两面

AI在代码审计上的优势毋庸置疑。一个7×24小时不眨眼、能遍历4000万行代码的系统，肯定能挖出人类眼里读不进去的边角料——那些写于上世纪90年代的SGI驱动、ISA总线协议栈、IBM古董文件系统模块里藏着的一千个内存越界。

但问题在于：这些漏洞到底该不该修？

维护者Andrew Lunn直接提议：删掉约 28000行ISA和PCMCIA时代的网络驱动代码。这些硬件的实物已经比你公司Ping域名还难找到，社会上的存量使用者几乎为零。它们的全部存在意义，就是为AI扫漏工具持续贡献漏洞通告，然后浪费掉维护团队每年上百个工时去翻旧档案写补丁。

这种荒诞的投入产出比，迫使Linux社区做出一个更激进的决策：

如果一段代码剩余的唯一价值就是缓解AI扫漏工具的精神焦虑，那它的维护成本已经远远超过了它的兼容价值。

SGI、IBM的远古驱动与文件系统模块被拉上了处决名单。

更深层的问题在于：目前的AI代码安全工具本质上是一个”抓Bug机器”，而不是”修Bug工程师”。

它能在几秒内告诉你某一行存在潜在的内存越界。但你不能把那一行的断点日志发给内核维护者，然后说”去修吧”。

真正让人崩溃的是接下来的工程链路： – 确认这条告警到底是不是真漏洞； – 评估它的真实影响面——这台机器有没有人装着那款2005年的网卡？ – 设计补丁方案——改一行代码可能会牵动几十个关联子系统的对齐； – 测试、回归、合并。

这条链路的成本，随AI产出量的上升呈超线性增长。因为从AI告警到确认漏洞的门槛是O(1)，但从确认到落地的成本是O(n)——n是关联模块数和代码库深度。

当一个迭代周期收到了300到400个AI补丁，而其中只有几十个是真正有价值的高危漏洞，剩下的全是”大象踩蚂蚁”式的误报和幻觉补丁，维护者的注意力已经被彻底降维打击成了”垃圾邮件过滤器管理员”。

这件事给所有把AI投入生产环境的人（不止是安全）画了一条清晰的边界线：

AI的产出应以”该做什么”收尾，而不是以”好像哪里不对”交差。

只告诉你”这行代码可能有问题”的系统，价值远远低于一个能自动完成以下闭环的系统：”第472行存在无需竞态条件即可提权的逻辑漏洞，Patch已生成并通过回归测试，请Review确认后签入。”

否则，所谓的AI安全管理，只是在把人类从”写代码的人”退化成了”给AI报错分类的人”——这跟用AI画图后你花更长时间去”抽卡+修手”的荒诞闭环毫无区别。

至于那些2005年生产、如今陈列在eBay上当摆件的ISA网卡——有时候，真正的解决方案不是给它的驱动打补丁，而是删了它，然后告诉这个世界：这一段历史已经翻篇了。