AI 安全能力，不是平滑领先，而是参差不齐

今天 HN 上最值得认真看的文章之一，是一篇讨论 Mythos 之后 AI 网络安全能力边界的文章。它真正有价值的地方，不是继续追问"是不是某个前沿模型已经在安全上遥遥领先"，而是提出了一个更符合现实的判断：AI 的安全能力并不是一条平滑上升的曲线，而是一种很不规则、很参差的前沿。

作者的核心观点可以概括成一句话：在一些安全任务上，小模型、便宜模型，甚至开源模型，也能复现 Mythos 公布案例中的相当一部分分析；而在另一些任务上，排名又会突然彻底洗牌。也就是说，安全能力并不会随着模型更大、更贵、更"前沿"而稳定单调提升。它更像是一片锯齿状地形，不同任务、不同推理模式、不同上下文组织方式，会把模型能力切成完全不同的样子。

嗯，这个判断很重要。因为过去大家太容易把 AI 能力理解成一个统一标尺，好像只要 leaderboard 更高、模型更大、价格更贵，它在所有复杂任务上都会更强。但安全从来不是一个单一任务。真正的安全流水线，至少包括大范围扫描、脆弱点识别、误报过滤、验证与分级、补丁生成，甚至还可能包括利用构造。这里面有的是检索问题，有的是程序理解问题，有的是约束下的工程设计问题，有的是高噪声下的判断问题。它们对模型的要求并不一样。

这也是为什么文中最值得记住的，不是"某个小模型也找到了某个漏洞"，而是"能力排序会在不同安全任务之间剧烈重排"。有的模型能看出复杂漏洞链，却在简单的误报辨别上翻车；有的模型能在基础检测上表现很好，但在需要更深数学推理或 exploit 设计时明显变弱。这说明真正该比较的，不是抽象的"安全能力总分"，而是整个系统在不同环节上的任务匹配。

我觉得这篇文章最重要的现实启发，是它把护城河的位置重新画了一遍。以前很多人会自然地把 moat 放在模型本身：谁有最强模型，谁就更接近自动化安全能力的制高点。文章的判断则更接近工程现实：真正的 moat 更可能在系统上，而不是模型上。也就是你如何做目标选择、如何缩小代码范围、如何构建验证循环、如何做 triage、如何减少误报、如何把结果写成 maintainer 愿意接受的报告，以及如何把专家经验嵌到整个流程里。

这其实和很多 AI coding 话题正在走向的结论很像。决定结果上限的，越来越不只是模型"会不会答"，而是系统"把什么问题、以什么形式、在什么阶段交给它"。在安全场景里尤其如此。因为安全问题最怕两种事：一种是漏报，另一种是误报过多导致没人再信你。一个便宜模型如果能在大规模扫描阶段承担足够好的初筛，再把高价值样本送进更重的验证与利用分析流程，它的系统价值可能远比"单次回答不如最强模型漂亮"来得大。

换句话说，如果安全能力是 jagged 的，那最合理的部署方式通常不是赌一个最贵模型通吃全部任务，而是做分层流水线。便宜、快、覆盖广的模型负责大面积搜索和粗筛；更强的模型负责复杂验证、 exploit 思路和补丁讨论；再往上，还要有人类安全工程师做最后判断、复核和对外沟通。这样的系统虽然没那么神话化，但更接近可持续生产。

这对普通开发团队也有很现实的启发。第一，不要被"某个模型能独立发现零日"的宣传直接带着跑。你真正该问的是，这个结果来自模型本身，还是来自背后的 scaffold、工具链、验证器和专家流程。第二，如果你想在团队里引入 AI 安全能力，别一上来就追最贵模型，先把任务拆开，看哪些环节需要高智力，哪些环节更需要低成本高覆盖。第三，评估 AI 安全工具时，不能只看它"找到了什么"，还要看它"稳定性如何、误报如何、维护者是否愿意接收结果"。

从更大的角度看，我认为这篇文章是在给 AI 安全产业降温，但不是泼冷水，而是去神话。它承认这条路是真的，承认 AI 确实已经能在安全上做出非常有价值的工作；但同时也提醒大家，不要把成果误读成"某个模型已经构成不可逾越的代差"。至少在现阶段，更强的解释仍然是：能力分布很不均匀，而真正难复制的是把这些不均匀能力组织成一条可信、可扩展、可被维护者接受的安全生产线。

所以，今天更值得记住的结论不是"前沿模型又赢了"，而是另一句更朴素的话：在安全这件事上，模型当然重要，但系统比模型更像护城河。