论文解读：CC-BOS 为什么文言文会变成大模型安全盲区

摘要

这篇文章是我对论文 Obscure but Effective: Classical Chinese Jailbreak Prompt Optimization via Bio-Inspired Search 的中文解读，不是逐段直译。

为了避免把论文里的攻击研究重新整理成一份可直接照着做的操作手册，下面会保留核心观点、实验结果和我的理解，但会刻意省略能直接帮助复现越狱攻击的具体样例与参数。

先用一句人话说结论：

这篇论文想证明的，不是“文言文很神奇”，而是“大模型的安全护栏往往更熟悉现代中文和英文，对文言文这种更压缩、更含混、更爱用典故和隐喻的表达，识别得没那么稳”。

为了避免版本漂移，先说明本文对应的论文信息：

• 原论文：arXiv:2602.22983
• 题目：Obscure but Effective: Classical Chinese Jailbreak Prompt Optimization via Bio-Inspired Search
• arXiv 页面显示版本：v3
• 论文页面日期：2026-03-24
• 我的阅读时间：2026-04-23

0. 先把几个词说人话

在开始之前，先把文中几个容易绕人的词讲清楚。

• jailbreak
  • 指的是想办法绕过模型原本的安全限制，让它输出本来不该输出的内容
• black-box
  • 指攻击者看不到模型内部参数和梯度，只能像普通用户一样和模型对话
• ASR
  • Attack Success Rate，攻击成功率。数值越高，说明越容易让模型“上钩”

0.1 这里说的“护栏”到底是什么

这篇文章里反复提到的“护栏”，不是特指某一个大模型，而是泛指大模型系统里用来阻止危险输入、危险推理、危险输出和危险操作的一整套安全机制。英文里常叫 guardrails。

它有时会是另一个模型，比如用一个专门的安全模型判断用户请求是否违规；但它也可能不是模型，而是一组规则、分类器、权限系统、工具调用限制、日志审计和人工审核流程。更准确地说，护栏不是单个组件，而是一个系统层概念。

常见的大模型护栏一般会分成几层：

1. 模型自身的安全对齐：通过 SFT、RLHF、RLAIF 或类似方法，让主模型学会拒绝一部分明显危险的请求。
2. 输入侧检测：用户请求进入主模型之前，先经过规则、分类器或安全模型，判断是否涉及违法、暴力、自伤、隐私泄露、越狱提示、prompt injection 等风险。
3. 输入归一化：把繁简、错别字、拼写变体、混合语码、隐晦表达或跨语言输入先整理成更容易审核的形式，再做语义判断。
4. 生成过程约束：通过系统提示、策略提示、解码约束、上下文隔离和工具调用限制，降低模型在生成过程中偏离安全边界的概率。
5. 输出侧审查：主模型生成答案后，再检查输出是否包含违规内容，必要时拦截、改写、拒答或要求重新生成。
6. 工具和权限护栏：对 agent 场景尤其重要。模型要发邮件、删文件、查数据库、执行命令或调用外部 API 时，需要额外的权限校验、参数检查、人工确认和审计日志。

这里的 SFT、RLHF、RLAIF 都是模型对齐阶段常见的方法：

• SFT 是 Supervised Fine-Tuning，也就是监督微调。做法是准备一批“用户问题 + 理想回答”的样本，让模型模仿更符合预期的回答方式。安全场景里，样本里会包含应该拒绝、应该转向安全建议、应该避免泄露细节的例子。
• RLHF 是 Reinforcement Learning from Human Feedback，也就是基于人类反馈的强化学习。简单说，就是让人工标注者比较多个回答哪个更好，再训练一个奖励模型，最后用这个奖励信号继续优化主模型，让它更偏向人类认为有帮助、诚实、安全的回答。
• RLAIF 是 Reinforcement Learning from AI Feedback，也就是基于 AI 反馈的强化学习。它和 RLHF 类似，但反馈来源主要从人类变成了 AI judge 或规则化的 AI 评审，用来降低人工标注成本、扩大反馈规模。

这三者都不是“外层拦截器”，而是让主模型本身更像一个会遵守边界的助手。不过它们只能改变模型的倾向，不能保证所有复杂输入都被稳定处理，所以工程上仍然需要输入检测、输出审查和权限控制这些外层护栏。

所以，当本文说“文言文可能绕过护栏”时，意思不是说文言文本身让大模型突然失去能力，而是说安全系统里的某些层可能更熟悉现代、直接、显式的表达方式，于是在面对更压缩、更隐晦、更依赖典故和省略的表达时，没能稳定识别真实意图。

这也解释了为什么“主模型”和“护栏”之间会出现错位：主模型可能读懂了文言文里的含义，但输入检测、输出审查或安全 judge 不一定以同样稳定的方式把它判成高风险请求。

如果把主模型和护栏都换成完全一样的模型，能不能解决这个问题？只能缓解，不能根治。这样做确实可能减少“主模型懂了、护栏没懂”的能力不对称，但同一个模型也可能共享同一类盲区。真正稳妥的工程做法，通常还是分层、异构、可审计的护栏组合，而不是把所有安全判断都押在同一个模型上。

如果你只先记住一句话，后面就够用了：

这篇论文不是在讨论“文言文翻译得好不好”，而是在讨论“文言文会不会成为安全检测的盲区”。

1. 先给一个压缩版中文摘要

下面这段不是原文逐句直译，而是我根据论文摘要做的压缩转述版中文翻译：

随着大语言模型越来越普及，安全风险也越来越值得重视。已有研究表明，不同语言环境下，模型遭受 jailbreak 的脆弱程度并不一样。本文把目光放到文言文上。作者认为，文言文因为表达简练、语义隐晦，可能部分绕过当前安全机制。基于这个观察，论文提出了一个名为 CC-BOS 的黑盒攻击框架，用来自动生成文言文对抗提示。它把提示策略拆成多个维度，再用一种受果蝇觅食启发的搜索算法去不断优化组合。为了让评测更稳定，作者还加入了一个把文言文相关输出归一化到英文的翻译模块。论文报告称，这套方法在多种模型上的效果优于已有基线方法。

如果把上面这段再压成一句话，那就是：

作者认为，文言文不是“古老的翻译材料”，而是一种可能让安全护栏看漏意图的特殊输入分布。

2. 为什么作者会盯上文言文

这部分是整篇论文最关键的直觉来源。

作者的判断大致是这样的：

1. 很多现成护栏主要针对现代中文、英文和常见表达方式优化
2. 文言文天生更短、更压缩，也更容易一词多义
3. 文言文很常用借代、典故、隐喻、倒装、省略
4. 结果就是：模型也许能理解你的意思，但护栏未必能稳定识别你真正的危险意图

这件事可以类比成：

• 模型主体像一个“读古文还不错的人”
• 护栏像一个“主要受现代文本训练的审稿人”

于是就会出现一种错位：

• 主体模型理解了隐含意思
• 外层安全检查却没有及时把这个意思拦下来

论文第 1 节和第 3.1 节基本都在为这个判断服务。作者强调的不是“文言文训练数据少”，而是“这里存在一个安全盲区”。也就是说，问题未必只是数据量不足，更可能是现有安全对齐的覆盖面和语言假设太现代了。

但我建议读者在这里保留一点谨慎：

• 这还是论文提出的解释框架，不是已经被行业完全验证的共识
• “文言文有效”背后可能混着多种因素，比如语言分布偏移、过滤规则偏现代、评测方式偏模板化等

3. CC-BOS 的方法本质是什么

如果把整篇方法部分翻成人话，我觉得它其实只做了三件事。

3.1 先把“怎么伪装请求”拆成若干维

论文没有把 jailbreak 当成一句神秘咒语，而是把它当成“多个策略开关的组合”。

你可以把它粗略理解成：

• 说话的人设怎么包装
• 任务场景怎么包装
• 用什么风格和语气说
• 要不要借隐喻、典故或转述把真实意图藏起来

作者把这些因素整理成一个多维策略空间。这样一来，问题就从“手工写一句攻击提示词”变成了“在很多可能组合里找更有效的那组”。

3.2 再用一个启发式搜索去找更好的组合

CC-BOS 里的 BOS 可以理解成一种受果蝇觅食启发的优化搜索。

论文的高层想法并不复杂：

• 先随机生成一批候选方案
• 在它们附近做一些小范围试探
• 逐步向当前最有效的方案靠近
• 如果长时间没进展，就做一次更大的跳变，避免卡在局部最优

如果你熟悉工程优化，会发现这本质上不是魔法，而是一个很典型的启发式搜索框架：

• 局部探索
• 朝当前最好结果收敛
• 偶尔大步跳出死胡同

作者的重点不是发明了一种全新的数学，而是把这种搜索思路和“文言文多维策略空间”绑在了一起。

3.3 最后用翻译归一化来做评测

论文还有一个很有意思的设计：

它没有直接拿模型在文言文上下文里的原始回复去做最终判断，而是先把回复做一次跨语言归一化，再进入后续评测。

作者的理由是：

• 文言文表达太压缩
• 隐喻太多
• 如果直接按表面词汇去判，很容易把“已经危险了”的输出低估掉

所以你可以把这个模块理解成：

不是攻击本身的一部分，而是为了让“评测到底算不算成功”这件事更稳定。

这也解释了为什么它在消融实验里会单独影响成功率统计。

4. 实验结果怎么读

这篇论文最抓眼球的地方，显然是结果数字。

我把论文给出的主要结果整理成一张更容易读的表：

维度	论文报告的结果	我会怎么理解
主评测 AdvBench	在 Gemini-2.5-flash、Claude-3.7、GPT-4o、DeepSeek-Reasoner、Qwen3、Grok-3 上都报告了 100% ASR	说明在论文自己的设定里，这个方法非常强
额外数据集	CLAS 上大多是 99%-100%，StrongREJECT-small 上大多是 98.3%-100%	说明作者试图证明这不是只对一个基准有效
查询成本	平均查询数大约 1.12 到 2.38，低于多种基线	说明它不只成功率高，而且搜索成本也低
防御场景	加上输入和输出双重防御后，论文报告仍有 22%-40% 的 ASR	说明单层护栏不够稳，组合防御也未必万无一失
跨模型迁移	交叉迁移成功率大约 76%-96%	说明这类提示不一定只对单个模型有效
消融实验	只用文言文上下文是 18%，加上策略空间到 60%，再加优化到 100%	说明作者认为“语言上下文 + 结构化策略 + 搜索优化”三者缺一不可

这里面最值得注意的不是“100%”这三个字本身，而是它对应的结构：

• 不是单纯换成文言文就满分
• 不是单纯上一个搜索算法就满分
• 而是把特殊语言上下文和系统化策略组合叠在一起以后，效果才被作者报告为接近极致

不过我建议一定要给这些数字加上脚注式理解：

1. 这些结果是论文在自己的评测集、裁剪规则、judge 流程和模型版本下得到的
2. 这不等于真实生产环境里“任何线上系统都会被 100% 打穿”
3. 论文还引入了翻译归一化和判分流程，这会影响最后统计出来的成功率

换句话说：

这篇论文足以说明“这里确实有值得重视的漏洞方向”，但还不能被读成“所有现实系统已经毫无抵抗能力”。

5. 这篇论文真正提醒我们的是什么

如果把攻击细节都拿掉，我觉得这篇论文真正重要的启发有四个。

5.1 不要把安全理解成“关键词过滤”

如果护栏主要依赖显式词汇、显式模板或常见拒答模式，那么一旦用户换了语言风格、句法结构或修辞方式，系统就可能漏判。

这篇论文本质上就在提醒：

安全检测应该对“意图”更敏感，而不是只对“表面字词”更敏感。

5.2 多语言安全不只是“多翻几种现代语言”

很多团队说自己做了 multilingual safety，实际往往还是停留在：

• 英文
• 现代中文
• 少数主流欧洲语言

但真实世界里，语言分布远比这复杂。历史语言、书面变体、方言化表达、混合语码、拼写变体，都会制造护栏盲区。

文言文在这篇论文里，更像一个特别突出的案例。

5.3 输入归一化和语义归一化很重要

论文把翻译模块放进评测流程这件事，虽然会让人讨论它是否“放大了成功率”，但它也反过来提醒防御者：

很多时候，安全系统要先把输入和输出归一化，再做更高层的意图识别。

否则你看到的只是表层文本，不是底层意思。

5.4 单一护栏很难扛住复杂输入分布

论文里的结果即使在防御场景下下降了，也仍然保留一定成功率。

这说明更稳妥的做法应该是：

• 输入侧检查
• 生成时约束
• 输出侧审查
• 跨语言意图识别
• 更丰富的对抗数据持续回灌

也就是分层防御，而不是把希望押在一道门上。

6. 我觉得还要保留哪些怀疑

我挺喜欢这篇论文的问题意识，但如果你要把它当成行业事实来引用，我建议同时带上下面几条保留意见。

6.1 “文言文有效”不一定全是文言文本身的功劳

这里面可能同时混着：

• 语言分布偏移
• 模板检测脆弱
• 模型主体和安全层能力不对称
• 评测 judge 对翻译后文本更敏感

所以别把它简单概括成“古文天然克制大模型”。

6.2 论文结果非常强，因此更需要看复现实验

当一篇安全论文报告出接近满格的成功率时，最应该继续问的不是“太厉害了”，而是：

• 模型版本换掉会怎样
• API 提供商更新护栏后会怎样
• 换到真实业务流量和更长上下文时会怎样
• 不同评测 judge 是否会给出一样的结论

也就是说，高结果值得重视，但越高越要复核。

6.3 这类论文最大的价值，不是“教人攻击”，而是“逼人补洞”

如果只把它看成又多了一招越狱技巧，那读法其实有点窄。

更有价值的读法是：

• 它暴露了现代语言中心主义的安全假设
• 它提醒我们别把语言安全当成静态规则库
• 它迫使防御系统面向更广的表达变体去建模

总结

最后再把整篇文章压成三句话。

第一，这篇论文的核心主张是：文言文可能成为大模型安全机制的一个盲区，因为模型能理解，但护栏未必稳稳识别。

第二，CC-BOS 的方法本质是：把提示词伪装策略拆成结构化维度，再用启发式搜索去自动找到更有效的组合。

第三，这篇论文最值得工程团队记住的，不是某个具体攻击技巧，而是下面这句提醒：

如果你的安全系统只熟悉现代、直接、显式的表达方式，那么它迟早会被更隐晦、更绕、更不按常规分布来的语言输入撞出漏洞。

如果你是做模型安全、内容审核或 agent guardrail 的，这篇论文值得读；如果你是普通读者，那你至少可以从里面记住一个很重要的事实：

安全问题很多时候不是“模型懂不懂”，而是“系统在什么表达分布下会看漏”。