为什么最好的通用AI模型在安全领域总是输给专用模型

Anthropic并非偶然让Claude Opus 5在网络安全方面得分不高。它有意限制了该模型的进攻性安全能力，这是一种为了限制滥用风险而做出的刻意权衡。结果是，像Sakana AI的Fugu-Cyber和Google的Gemini 3.5 Flash Cyber这样的专用系统现在在渗透测试方面表现优于Opus 5，不是因为它们整体更聪明，而是因为它们专为一项任务而构建，并且在没有安全天花板的情况下被允许做好这项工作。

在一个多年来一直以广度作为卖点的行业中，这是一种不寻常的动态。前沿实验室的宣传通常是：一个模型，擅长一切，所以你不需要工具箱。安全正成为这种宣传首先失效的领域，因为使模型擅长发现漏洞的东西, , 对系统弱点进行激进、详尽的探测, , 正是安全团队在面向数百万用户的通用产品中理应限制的行为。Anthropic的选择不是工程上的失败。这是一个清晰的权衡：广义安全与窄域能力，而Opus 5在这个轴上选择了前者。

同一枚硬币的另一面

阿里巴巴对相关问题的回应具有启发意义，恰恰因为它根本不涉及模型能力。它的会话内代码审查在AI生成的代码进入仓库之前捕获其中的漏洞，而不是依赖编码模型本身来避免编写不安全的代码。这是针对同一根本问题的架构性答案：不要指望通用模型同时成为可靠的安全门。相反，将专用审查工具接入管道。开发者是否真的让该审查器在每个提交上运行，而不是在截止日期压力下禁用它，这是阿里巴巴推出该工具必须回答的真正悬而未决的问题。

与此同时，这一图景的威胁方面也并未停滞不前。一种新记录的零查询攻击让对手仅利用时序和内存侧信道数据，就能从云API中提取专有模型，而无需发送任何提供者可记录或标记的查询。这与主导AI安全报道的提示注入和越狱担忧相比，是一个有意义的、不同的威胁模型。它针对的是基础设施，而非模型的判断力，并且模型本身无论进行多少能力限制都无法阻止它。

这一切意味着什么

将这三个发展放在一起，一幅图景浮现出来：AI安全正分裂为专业化层级，而非整合为一个可信的通用模型。进攻性安全测试正转向不受消费产品限制的专用系统。防御性代码审查正转向接入开发管道的专用工具，而非依赖编码模型自身的判断力。而基础设施层面的威胁（如模型窃取）需要另一种防御方式，这与模型本身的能力或安全性无关。

对于任何基于“领先的通用模型自动就是领先的安全工具”这一假设而续签AI安全合同的企业来说，这一假设已不再成立。实际的应对方式是测试针对具体任务（渗透测试、代码审查、威胁检测）的窄域专用替代方案，而不是假设房间中最聪明的模型也最擅长保护它。