2026年Appen的一项研究（arXiv:2605.23157）揭示了一个被忽视的安全盲区：大语言模型的安全排名在语言切换后完全失效。同一批模型，换个语言提问，"最脆弱"的模型就会换位。这项覆盖52,272个人工评分的研究显示，没有任何重标定方法能恢复英语测试时的排名顺序。

另一项针对印地语-英语混合语（Hinglish）的红队测试（arXiv:2505.14226）结果更刺眼——通过代码混用的语音扰动攻击，成功率接近99%。

打开网易新闻 查看精彩图片

这意味着什么？你的英语专属红队测试，测量的攻击面与非英语用户实际面临的攻击面，根本就是两个东西。

问题在于，大多数团队的安全门禁（gate）机制建立在英语测试数据上。当攻击者用印地语、斯瓦希里语或Hinglish发起提示注入时，系统可能毫无防备。

平均安全分数在这里是危险的幻觉——它掩盖了你最薄弱的语言环节，而这正是攻击者会找到的突破口。

一个最小可行的解决方案是：为每种语言单独运行对抗测试集，分别评分，并以表现最差的那种语言作为门禁标准，而非取平均。以下是实现这一思路的框架结构（需自备对抗提示词和评判器，本文不包含具体攻击字符串）：

核心结构包含三个硬性规则。第一，每种语言独立成集、独立评分。evaluate()函数从不返回单一数字，而是返回每种语言的攻击成功率（ASR）。

第二，以最差语言为门禁依据，而非平均。gate()函数会故意打印平均值并标注"勿以此为准"——平均值恰恰隐藏了你最脆弱的语言。

第三，使用原生表达，而非翻译。Probe.prompt字段要求用用户实际输入的语体编写（对Hinglish而言，是代码混用的口语化表达，而非印地语的正式译文）。

代码实现上，Probe数据类记录语言代码、原生措辞的对抗提示词，以及安全代理应当拒绝的标记。run_agent()和is_attack_success()两个函数需要接入你的实际代理客户端和评判逻辑——可以是基于评分标准的自动评判，也可以是人工审核，关键是保持确定性且具备语言感知能力。

evaluate()函数按语言分组计算ASR，gate()函数则找出最高攻击成功率的语言，与阈值（默认5%）比较。输出会清晰标注哪门语言是"最差（决定构建门禁）"，并明确区分平均值与最差值。

这个框架的价值不在于代码本身，而在于强制团队面对一个 uncomfortable truth：全球化产品的安全水位，由其最薄弱的语言市场决定。当你的非英语用户量增长时，英语红队的"通过"标签可能正在制造虚假的安全感。

实施建议：从覆盖你实际用户语种的极简集合开始，优先测试代码混合语（如Hinglish、Taglish）和书写系统差异大的语言。对抗提示词应聘请母语者编写，而非依赖机器翻译——语音层面的扰动和口语化陷阱往往无法通过译文复现。

最终门禁决策应写入CI/CD流程：只有当所有语言的ASR均低于阈值时，构建才可通过。这意味着某门小语种的意外漏洞，能够阻止整体部署——这正是设计意图。