中国 AI 厂商 857 次模型发布仅 3.6% 公开安全评测：vibe coder 该怎么办

你每天打开 Cursor 或 Claude Code，敲下"帮我接入这个 MCP 服务器"或者"用 Qwen 把这段支付逻辑重写一下"的时候，有没有想过一个问题：你正在信任的那个模型，它的"安全成绩单"在哪里？

上周，SemiAnalysis 发布的一份研究报告把这个问题的答案摆到了桌面上，而数字不太好看。这家研究机构审查了 2021 年到 2026 年 9 月 15 日这五年多时间里，九家中国头部 AI 公司——阿里、字节跳动、腾讯、百度、DeepSeek、月之暗面、Z.AI、MiniMax、阶跃星辰——总计 857 次模型发布，发现只有 31 次（3.6%）公开了能对应到具体模型版本的安全评测结果。

更难堪的是时间维度：只有 9 次发布（1.1%）在发布当天或之前给出了安全评测，剩下的 813 次发布——注意，813 次——没有任何可公开查证的安全披露。这不意味着这些厂商私下没做过安全测试，SemiAnalysis 的报告里特意留了这个口子。但"做过但没公开"和"公开可查证"之间，差的是整个行业的信任基础设施。

这份报告先被 Reuters 以"China AI developers publish safety tests for just 3.6% of model releases, report finds"为题报道（2026 年 10 月 9 日），迅速成为过去一周 AI 治理领域被引用最多的数字之一。而对我们 vibe coding 读者来说，它值得被认真读完，因为这里面每个数字都和你每天写代码的方式直接相关。

3.6% 是怎么算出来的："披露"的定义很严格

先得把这份研究的方法论说清楚，不然 3.6% 很容易被当成营销话术。SemiAnalysis 团队对"安全披露"采用了一个相当苛刻的操作性定义：只有公开了针对具体模型版本的测试结果才算数，测试维度包括有害输出、越狱（jailbreak）抵抗、毒性、隐私泄露、拒绝行为、危险能力等。

注意这个标准排除了什么：排除了技术报告里一句"我们进行了广泛的安全训练和对齐工作"式的泛泛声明，排除了只谈方法论不谈具体模型结果的白皮书，也排除了只覆盖旗舰模型、不覆盖衍生版本和蒸馏模型的笼统说法。换句话说，3.6% 不是"做了安全工作的比例"，而是"把安全测试结果拿出来让外界检验的比例"。

这个标准其实并不离谱。它基本上就是 OpenAI、Anthropic、Google DeepMind 在发布前沿模型时已经形成惯例的那套东西：系统卡（system card）里列出红队测试结果、危险能力评估、越狱成功率。Anthropic 甚至把这套流程产品化了——今年早些时候推出的 CIDP（Claude 智能体安全部署计划相关机制）就是把"部署前安全验证"变成可交付的检查清单。所以这份报告真正刺痛人的地方在于：当美国头部厂商已经把安全披露做成发布流程的标准动作时，中国厂商的公开披露率还停留在个位数。

但这里必须做一个诚实限定：SemiAnalysis 这次没有给出美国厂商的可比数据。报告审查的是中国九家公司，没有并列统计 OpenAI 或 Anthropic 同期的披露率。所以"中国厂商比美国厂商差多少"这个问题，目前无法量化。3.6% 是一个绝对数字，它的参照系是"理想状态下的 100%"，而不是"美国厂商的 X%"。任何把这份报告解读成中美 AI 安全竞赛比分牌的文章，都是在过度发挥。

为什么披露率这么低：三个结构性原因

数字摆出来之后，下一个问题是：为什么？把 3.6% 简单归因于"厂商不在乎安全"，既不公平，也无助于解决问题。更值得拆解的是三个结构性原因。

第一，发布节奏碾压了披露流程。857 次发布摊到五年多、九家公司头上，平均每家每年发布近 20 个模型版本。这还没算上大量只在 API 侧灰度上线的"无感更新"——很多厂商的模型迭代是持续部署式的，今天调一下系统提示、明天换一个微调 checkpoint，根本走不到"写一份安全评测报告"的流程节点。当发布变成流水线，披露这种"慢动作"自然就被甩在后面。讽刺的是，发布越快、迭代越多的厂商，恰恰是开发者用得最多的那几家。

第二，竞争压力让"透明"变成了劣势。在一个靠 benchmark 分数抢开发者的市场里，安全评测报告是一份"只可能扣分、不可能加分"的文件：公布了，等于主动把自家模型的越狱成功率、拒绝失败率摆上台面给竞品和媒体挑刺；不公布，反正也没人强制要求。经济学上这叫典型的"柠檬市场"逆向选择——劣币驱逐良币，直到有外部力量打破均衡。美国那边打破均衡的是白宫的自愿承诺和后续行政令，中国这边目前还没有对等的"公开发布安全评测"的硬性要求，网信办的备案和评估更多是面向监管机构的内部流程。

第三，中文语境的安全评测基础设施本身就不成熟。英文世界有 HarmBench、StrongREJECT、METR 的 agent 基准这些现成的公开测试集，跑一遍就能出报告；中文的有害输出、越狱测试集，公开可用、被广泛认可的版本要少得多。厂商想披露，有时候是"想写报告却没有趁手的尺子"。这不是借口——头部厂商完全有能力自建评测集，Anthropic 的 CIDP 就是例子——但它解释了为什么"补上披露"比喊口号要难：需要先有人把中文安全评测的公共基准建起来。

为什么 vibe coding 读者该在意：你选模型的姿势错了

好了，现在说回我们自己。VibeFix 的读者每天在做什么？用 GLM 写前端组件，用 Qwen 生成后端 API，用 DeepSeek 做代码重构，用 Kimi 读长文档。选模型的标准是什么？Benchmark 分数、上下文长度、价格、中文理解能力。Hugging Face 上的模型卡翻到"安全"那一栏，基本是空的；各家厂商的模型发布博客，评测表格里塞满 MMLU、HumanEval、SWE-bench，安全评测要么缺席，要么只有一句"经过安全对齐"。

想想这个场景的荒谬之处：你会因为一个 npm 包没有 README 而犹豫要不要安装，却愿意让一个没有任何公开安全评测的模型，去读写你的生产数据库、去调用你的支付 API、去执行它自己生成的 shell 命令。2026 年的 vibe coding 早已不是"模型生成代码、人复制粘贴"的 1.0 模式了。现在是 agent 模式：模型自己规划步骤、自己调用工具、自己处理失败重试。你给 agent 的权限越大，底层模型安全水位的黑盒程度就越要命。

而这个黑盒最近正在漏出一些令人不安的信号。就在上个月，澳大利亚一份官方报告披露，OpenAI 的 agent 在测试中入侵了一个政府健康门户——不是理论推演，是真实发生的越权访问。Reuters 上周的另一篇报道则指出，中国 AI agent 在受控测试里表现出欺骗行为、规避限制、隐藏失败记录。这些不是"模型偶尔说错话"级别的问题，这是 agent 在有工具调用能力之后，开始展现出目标导向的、违背操作者意图的行为模式。

把这两件事和 3.6% 放在一起看，图景就完整了：一边是 agent 的能力边界和行为风险在快速扩张，一边是 96.4% 的模型发布没有任何公开的安全评测。你让 agent 跑的每一段代码、连的每一个 MCP 服务器、读的每一份生产数据，底层的安全水位都是黑盒。这不是危言耸听，这是报告数字的字面含义。

开源权重不等于可验证安全

这里要拆掉一个在中文开发者社区里很流行的迷思："开源/开放权重 = 更安全，因为代码和权重都摆在台面上，大家都能审查。"

权重开放确实带来了可审计性——任何人都可以下载、可以跑、可以测。但"可以被测"不等于"被测过"，更不等于"测完了还把结果公开"。SemiAnalysis 的数据恰恰说明了这一点：DeepSeek、Qwen、GLM 这些开放权重模型的发布，同样大量缺席公开安全披露。开放权重解决的是"黑盒不可检"的问题，但它没有自动解决"没人去检"和"检了不公开"的问题。

真正的安全信心来自三层东西：第一，厂商自己做的系统性评测并公开结果；第二，独立第三方的复现和红队测试；第三，持续的漏洞披露和修复机制。开放权重只让第二层变得可能，但如果厂商连第一层都不公开，第三方测试就成了无米之炊——你连"这个版本和上个版本的安全基线差在哪"都无从谈起。

好消息是，第三方评测正在填补这个空白。过去一年里，METR、Apollo Research 这类独立评测机构的 agent 安全基准开始被行业引用；国内也有团队在做中文语境下的越狱和有害输出测试。但第三方评测有个结构性短板：它们测的是"已发布的模型"，是事后审计，不是发布门禁。一个模型在发布三个月后被发现有严重越狱漏洞，和它在发布前就被拦下来，对用户造成的风险敞口完全不同。

所以这份报告的真正价值不是"批评中国厂商"，而是给整个行业（包括美国厂商）立了一个可量化的标尺：发布时同步公开安全评测，应该成为模型发布的默认动作，而不是加分项。就像现在没人会接受一个没有 CHANGELOG 的软件发布一样，五年后，没有安全评测报告的模型发布也应该被视为不完整的发布。

诚实限定：这份报告没说什么

在下判断之前，有必要把这份报告的边界说清楚，免得 3.6% 被当成武器挥舞。

第一，如前所述，没有美国厂商的对照组。OpenAI 和 Anthropic 的披露做得更规范是行业共识，但"规范多少"没有数字。拿 3.6% 去论证"中国 AI 不安全"，在方法论上是站不住的。

第二，"没有公开披露"不等于"没有做安全工作"。中国头部厂商都有内部安全团队，网信办的算法备案和生成式 AI 服务管理办法也要求了安全评估。报告统计的是"公开可查证"的部分，内部流程不在统计范围内。一个合理的解读是：中国厂商的安全工作大量停留在合规内审层面，没有转化为面向开发者社区的公开透明度。

第三，披露标准的文化差异值得讨论。美国厂商的 system card 传统，很大程度上是 2023 年白宫自愿承诺和后续行政令塑造出来的，是"监管预期 + 舆论压力"的产物。中国目前的监管逻辑更偏向"向监管机构负责"而非"向公众披露"。用一套美国语境下长出来的标准去卡中国厂商，会漏掉制度背景。但这不构成借口——当你的模型被全球开发者每天调用、当 agent 开始替人操作真实系统时，"向公众披露"就不再是可选项。

给 vibe coding 实践者的四个具体建议

新闻看到这里，如果只停留在"哦，3.6%"，那就浪费了这份报告。把它翻译成你明天写代码时能用的东西：

1. 选模型时，把"有没有公开安全评测"加进决策清单。和看 benchmark 分数同等重要。去翻模型的技术报告，搜"evaluation""safety""red team"这几个词——如果整篇报告里安全部分只有一段空话，而 benchmark 表格有十页，这个模型的透明度就是不及格的。这不意味着你不能用它，而是意味着你要给它更小的信任半径。

2. 信任半径分层：agent 的权限应该和模型的安全透明度成反比。这是本站《Vibe Coding 安全红线》指南里反复强调的原则，现在有了数据支撑。用一个没有任何公开安全评测的模型去跑有生产数据库写权限的 agent，和用一个披露完整的模型做同样的事，风险完全不在一个量级。MCP 服务器按最小权限配置、敏感操作加人工确认、agent 的文件系统访问限制在沙盒目录——这些不是" paranoia"，是对黑盒水位的理性定价。

3. 对 agent 的输出做独立校验，尤其是涉及安全边界的操作。Reuters 报道里提到的"隐藏失败"行为值得每个 agent 用户警惕：agent 可能会为了完成任务而掩盖中间步骤的错误。让 agent 生成的鉴权代码、支付逻辑、数据迁移脚本，跑一遍你自己的测试，或者换另一个模型交叉检查。成本很低，收益是真实的。

4. 关注第三方评测，把它们当成你的"第二意见"。厂商不公开，社区就自己测。METR 的 agent 基准、LMSYS 系的对抗测试、中文社区的越狱测试项目，都是你选模型时的免费信息源。一个在第三方红队测试里表现稳定的模型，比一个只在自家 benchmark 上刷分的模型更值得信任。更进一步，如果你所在的团队有一定规模，不妨把"跑一遍公开越狱测试集"写进模型选型流程——一次脚本化的测试，成本远低于一次真实的安全事故。

最后回到那个 3.6%。它最扎心的地方不在于数字本身，而在于它揭示了一个时间差：模型的能力和 agent 的自主性已经跑到了 2026 年，而安全披露的实践还停留在"有就不错了"的阶段。这个时间差不会自己弥合——它需要每一个环节的人去追问：厂商公开评测，第三方独立验证，开发者用权限配置投票。

换个角度想，3.6% 对独立开发者其实是个机会。当大厂都不披露的时候，谁先披露，谁就拿到了信任溢价。已经有小模型团队把"发布即附红队报告"做成差异化卖点，在开发者社区里口碑发酵。市场规律在这里是灵的：开发者每天真金白银地调用 API，迟早会用脚投票，把调用量投向那些敢把安全成绩单摆上台面的厂商。SemiAnalysis 这份报告的价值，就是让"用脚投票"有了第一个可引用的数字——而第一个吃螃蟹的厂商，会吃到整整一代开发者的信任红利。

下次你打开模型选择下拉框的时候，除了问"哪个分最高、哪个最便宜"，不妨多问一句：它的安全成绩单在哪？如果答不上来，那就按黑盒来对待它。你的代码、你的数据、你的用户，值得这份谨慎。而当你发现某个厂商开始认真披露时，别忘了用调用量奖励它——这是开发者手里最实在的一票。