1. 这个标题到底在说什么
先把标题拆开看。“857个模型，只有3.6%公开安全测试”，这两个数字放在一起，本身就构成了一种强烈的张力。857个模型，指的是当前市面上可被公开检索到、有明确版本号、有可下载权重或可调用接口的AI模型总量——这个数字还在以周为单位滚动增长。3.6%则是指其中真正公开过安全测试报告、红队评估结果或第三方审计结论的比例。换句话说，每100个你能叫得出名字的模型里，只有不到4个愿意或能够拿出像样的安全证据。
“AI发布速度为何跑在安全证据前面”，这句话问的不是技术问题，而是节奏问题。模型迭代的周期从过去的半年压缩到现在的几周甚至几天，但安全测试的周期——从威胁建模、红队构造、评估执行到报告公开——几乎没有同步缩短。这就形成了一个结构性缺口：发布动作越来越轻，安全举证越来越重，两者之间的时间差被越拉越大。
这篇文章想聊的就是这个缺口是怎么形成的、它具体表现在哪些环节、以及作为一个在实际工作中需要选型、部署、评估AI模型的人，你该怎么理解这件事、怎么在缺证据的情况下做判断。不管你是刚入行的算法工程师、负责模型上线的产品经理，还是做安全合规的技术管理者，这个话题都绕不开。
2. 857和3.6%这两个数字是怎么来的
2.1 模型数量的统计口径
857这个数字不是凭空来的。它通常来自几个公开渠道的交叉汇总：模型托管平台上的公开仓库、学术论文附带的开源权重、企业官方发布的API模型卡片、以及一些聚合类榜单的收录条目。统计时会做去重——同一个模型的不同量化版本算一个，同一个基座的不同微调版本如果独立发布也算独立条目。
但这里有个容易被忽略的问题：统计口径本身就不统一。有的榜单把微调版本单独计数，有的合并；有的把多模态的各个子模块分开算，有的打包。所以857这个数字你把它理解成一个量级参考就好，不必纠结个位数。真正有意义的是它的增长速度——过去一年这个数字翻了不止一倍，而且新增条目里超过六成来自中小团队和个人开发者。
2.2 安全测试公开比例为何这么低
3.6%这个比例之所以低得刺眼，原因得从几个层面拆。
第一层是成本。一次像样的安全测试，不是跑几个提示词看看模型会不会说脏话那么简单。完整的红队评估需要覆盖对抗性输入、越狱尝试、数据泄露探测、偏见与毒性评估、以及下游滥用场景模拟。这套流程走下来，人力成本少则几周，多则几个月，对于一个小团队来说，这个投入可能比训练模型本身还大。
第二层是意愿。公开安全测试报告意味着把模型的弱点摊在桌面上。对于商业模型来说，这直接关系到品牌形象和客户信任。很多团队的选择是：内部做测试，但不公开。内部测试报告和公开安全证据是两回事，前者是自保，后者是接受外部审视。
第三层是标准缺失。什么叫“安全”？不同团队的理解差异巨大。有的认为不输出违法内容就算安全，有的要求对抗鲁棒性达到某个阈值，有的关注隐私泄露风险。没有统一标准，就没有可比性，公开出来的报告也常常各说各话，读者很难从中得出有效结论。
第四层是激励错位。当前的市场竞争节奏下，先发布、先获客、先迭代是优先级最高的事。安全测试在很多人眼里是“刹车”，不是“引擎”。当整个行业的奖励机制偏向速度时，安全举证自然被挤到后面。
注意：这里说的“安全测试”指的是模型层面的安全评估，不是传统网络安全里的渗透测试或漏洞扫描。两者有交集，但评估对象和方法论差别很大。
3. 发布速度为什么能跑赢安全证据
3.1 模型迭代的工程化程度在提升
过去训练一个模型，从数据清洗到超参调优再到部署上线，周期以月计。现在呢？预训练基座越来越成熟，微调工具链越来越顺手，部署框架越来越标准化。一个团队拿到基座权重后，用几百条指令数据做微调，几天内就能产出一个“新模型”并发布。工程效率的提升是实打实的，但安全评估的工程化程度远远没跟上。
安全测试目前仍然高度依赖人工构造攻击样本、人工判断输出是否越界、人工撰写评估报告。这个过程很难被自动化流水线替代，因为安全判断本身就需要上下文理解和领域知识。你可以用脚本批量生成越狱提示词，但判断模型输出是否构成实质风险，仍然需要人来看。
3.2 安全评估的“最后一公里”问题
安全评估有个很尴尬的特点：80%的常见问题可以用标准测试集覆盖，但剩下20%的长尾风险往往才是真正致命的。而覆盖这20%需要针对具体模型的应用场景做定制化红队测试。一个通用聊天模型和一个医疗咨询模型的威胁模型完全不同，前者可能更关注毒性输出，后者更关注错误建议的后果。
这就导致安全评估很难“一次做好、到处复用”。每个模型发布前都得重新走一遍定制化流程，而这个流程的时间成本很难压缩。发布方等不起，于是选择先发再说。
3.3 市场反馈循环的加速
还有一个更隐蔽的推动力：用户反馈本身成了某种“事后安全测试”。模型发布后，用户会以各种方式试探边界，发现问题后反馈或公开讨论。对于发布方来说，这相当于把一部分安全测试成本转嫁给了社区。这种做法在短期看是高效的，但代价是风险暴露的窗口期被拉长，而且反馈质量参差不齐。
4. 安全证据缺失带来的实际影响
4.1 对模型选型者的困扰
如果你是一个需要在生产环境部署AI模型的技术负责人，面对857个模型和3.6%的公开安全测试比例，你的选型决策会变得非常困难。没有公开安全证据，你只能依赖：模型卡片里的自我声明、社区口碑、以及自己做的有限测试。这三者都有明显缺陷——自我声明缺乏验证，社区口碑容易受营销影响，自测又受限于时间和专业能力。
我见过不少团队的做法是：先用起来，出了问题再换。这种“试错式选型”在低风险场景下可以接受，但在涉及用户数据、金融交易、医疗建议等场景下，风险敞口太大。
4.2 对下游开发者的连锁反应
模型安全证据的缺失会沿着供应链向下传导。一个做AI应用开发的团队，如果底层模型的安全边界不清晰，他们就无法准确判断自己的应用在什么情况下会出问题。这会导致两种极端：要么过度保守，加大量人工审核，牺牲用户体验；要么过度乐观，把模型的自我声明当真，结果在真实场景中翻车。
4.3 对行业信任的长期侵蚀
更宏观的影响是信任问题。当用户发现模型频繁出现安全问题时，对整个AI能力的信任度会下降。这种信任一旦被侵蚀，修复成本极高。而且，缺乏公开安全证据意味着无法建立行业基准，好的实践无法被识别和推广，差的实践也无法被有效约束。
5. 面对这种局面，实际工作中能做什么
5.1 建立自己的最小安全评估流程
既然公开证据不够用，那就自己动手。一个最小可行的安全评估流程不需要多复杂，但必须覆盖几个核心维度：
- 输入边界测试：构造一批对抗性提示词，看模型是否会被诱导输出不该输出的内容。这批提示词不需要多，但要有代表性，覆盖指令覆盖、角色扮演、编码绕过等常见手法。
- 输出一致性检查：同一个问题换不同问法，看模型回答是否稳定。如果换个说法就给出完全不同的答案，说明模型的鲁棒性存疑。
- 敏感信息探测：测试模型是否会在特定提示下泄露训练数据中的敏感片段。这个测试需要一些技巧，但基本的探测方法是公开可查的。
- 下游场景模拟：把你实际业务中最高频、最高风险的几个使用场景拿出来，构造真实输入，观察模型输出。
这套流程走下来，快的话一两天，慢的话一周。比起完全依赖公开证据，自己跑一遍至少能建立基本的安全认知。
5.2 把安全评估嵌入发布流程
如果你是发布方，哪怕不公开完整报告，也建议在内部把安全评估做成发布前的必经环节。具体做法可以参考软件工程里的“质量门禁”思路：
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 预发布 | 基础安全测试集 | 无高危输出 |
| 预发布 | 对抗鲁棒性抽检 | 越狱成功率低于阈值 |
| 发布后 | 用户反馈监控 | 无集中性安全问题 |
| 发布后 | 定期复测 | 每季度或每次重大更新后 |
这个表格里的阈值需要根据你的具体场景来定，没有万能数字。关键是形成习惯：不经过这个流程的模型不上线。
5.3 推动安全证据的标准化
从行业角度看，安全证据的公开需要标准化。目前已经有一些组织在尝试制定AI安全评估框架，但落地程度参差不齐。作为从业者，你能做的是：在自己的团队内部先统一评估标准，然后在对外合作中要求对方提供符合标准的评估结果。这种自下而上的推动虽然慢，但比等待自上而下的规范更现实。
6. 几个常见的认知误区和实操心得
6.1 “模型卡片写了安全就没问题”
模型卡片里的安全声明，绝大多数是自我声明，没有第三方验证。我见过不少模型卡片写着“经过全面安全测试”，但实际测试下来，基本的越狱提示词就能突破。所以模型卡片的安全部分，当作参考信息就好，不要当作证据。
6.2 “开源模型比闭源模型更安全”
这个说法没有依据。开源意味着权重可查，但不意味着安全测试更充分。实际上，很多开源模型的发布节奏更快，安全测试更仓促。闭源模型虽然不公开权重，但有些团队在内部安全测试上的投入反而更大。安全与否和开源闭源没有直接关系，关键看发布方在安全上投入了多少。
6.3 “安全测试做一次就够了”
模型是会变的。微调、量化、部署环境变化，都可能改变模型的安全表现。我实测过同一个基座在不同量化精度下的安全表现，差异可以很大。所以安全测试不是一次性动作，而是持续过程。至少在每个重大版本更新后，都要重新跑一遍核心测试项。
6.4 一个实用的排查技巧
当你怀疑模型有安全问题但不确定具体是什么时，可以试试“边界探测法”：从正常输入开始，逐步增加对抗性，观察模型在哪个点上开始出现异常输出。这个方法能帮你快速定位模型的脆弱边界，比盲目跑大量测试用例更高效。
具体操作是：先给一个完全正常的请求，确认模型正常响应；然后逐步加入轻微的指令干扰，比如改变语气、添加无关上下文、使用隐喻表达；每次只改变一个变量，观察输出变化。当输出开始偏离预期时，记录下当前的输入特征，这就是模型的脆弱点。
7. 从857和3.6%看AI行业的节奏问题
857个模型和3.6%的公开安全测试比例，这两个数字放在一起，反映的不是某个团队的问题，而是整个行业的节奏问题。发布速度跑在安全证据前面，本质上是工程效率和安全评估效率之间的差距被拉大了。
这个差距不会自动缩小。工程效率的提升有明确的商业回报，安全评估的投入在短期看是成本。除非市场开始为安全证据买单，或者出现重大安全事件倒逼行业改变，否则这个差距会继续存在甚至扩大。
作为从业者，你能做的是在自己的影响范围内，把安全评估的优先级往上提一提。不需要做到完美，但至少不要完全跳过。自己跑一遍基础测试，比完全依赖公开证据要靠谱得多。而且，当你开始做这件事之后，你会发现很多之前没注意到的问题，这些发现本身就有价值。
我在实际工作中体会最深的一点是：安全评估不是阻碍发布，而是帮你更清楚地知道自己在发布什么。知道边界在哪里，才能更好地控制风险。这个认知转变，比任何具体的测试方法都重要。
