企业官网建设流程全解析

1. 一个反直觉的现象：为什么“之乎者也”能绕过安全防线

第一次听说“用文言文就能让大模型说出不该说的话”，我的反应和大多数人一样——这怕不是段子吧？毕竟在我们这些做模型应用的人眼里，安全对齐（Alignment）是花了大价钱、喂了海量数据才调出来的东西，怎么可能被几句“之乎者也”给绕过去？

但实测下来，事情没那么简单。这个现象背后其实藏着一个非常朴素的技术逻辑：大模型的安全训练数据，绝大多数是现代汉语白话文。无论是红队测试的对抗样本，还是安全微调的偏好数据，几乎都是用当代口语、网络用语、标准书面语构造的。文言文作为一种语料占比极低、语法结构迥异的表达形式，天然落在了安全训练的“分布外”（Out-of-Distribution）区域。

打个比方，这就像小区保安天天盯着穿黑衣、戴墨镜的可疑人员，结果有人穿着戏服、踩着高跷大摇大摆走进去，保安脑子里根本没有对应的“可疑模板”，反应自然就慢了半拍。模型的安全分类器也是同理——它见过太多“教我做一个危险物品”这种直白表达，也见过各种拼音、谐音、拆字的变体，但“敢问阁下，何以制此物”这种句式，在它的安全特征空间里几乎是一片空白。

这篇文章我想聊的不是怎么去“攻破”什么，而是从防御和工程视角，把这个现象拆开揉碎讲清楚：它为什么成立、涉及哪些技术环节、对做AI应用的人意味着什么、以及在产品落地时该怎么补这个窟窿。适合做LLM应用开发、安全评测、提示词工程、以及任何把大模型接入生产环境的同学参考。哪怕你只是用API做个客服机器人，这篇文章里的排查思路和加固手段都用得上。

2. 现象背后的技术拆解：安全对齐到底在哪一层失守

2.1 大模型安全防线的三层结构

要理解文言文为什么能“钻空子”，得先搞清楚一个大模型产品里，安全防护到底铺在哪几个层面。根据我这几年做落地项目的经验，主流方案基本是三层叠加：

文言文攻击主要打在模型层和输出层的结合部。输入层的关键词库基本拦不住——你很难把“之乎者也”的句式加进黑名单，那会误伤大量正常古文内容。模型层的安全对齐因为训练数据偏差，对文言表达的“危险意图”识别率明显下降。输出层的审核分类器如果也是基于现代汉语语料训练的，面对文言输出同样会“看不懂”。

2.2 为什么安全训练数据存在语言分布偏差

这里要讲一个做数据的人都知道、但外行容易忽略的事实：安全对齐数据的构造成本极高。每一条红队样本都需要人工设计、人工标注、人工复核，一条高质量对抗样本的成本可能是普通训练样本的几十倍。在这种成本约束下，数据构造者会优先覆盖“高频攻击面”——也就是大多数人会用的现代汉语表达。

文言文在预训练语料里占比本来就低（主流中文语料里古文比例通常不到百分之几），在安全微调阶段更是几乎被忽略。这就导致一个结果：模型在预训练阶段“学过”文言文，能读懂、能生成，但在安全对齐阶段“没被教过”文言文场景下的危险边界在哪里。能力在，约束不在，这就是漏洞的根源。

我用一个更直白的类比：这就像一个翻译官，中文和英文都精通，但你只培训过他“英文场景下哪些话不能说”，没培训过“文言文场景下哪些话不能说”。当有人用文言文跟他交流时，他的语言能力完全在线，但安全判断模块处于半休眠状态。

2.3 从Tokenization到注意力：文言文绕过的技术链路

再往底层挖一层，文言文绕过还和模型的分词机制、注意力分配有关。

现代汉语的敏感词检测和语义理解，很大程度上依赖分词后的token序列。比如“制作危险物品”这七个字，分词后是几个明确的token，模型在注意力层能快速捕捉到“制作”和“危险物品”的强关联。但文言文“制此危物”四个字，分词结果完全不同，“危物”甚至可能不是一个常见token组合，注意力权重被分散到各个单字上，危险信号的聚合度大幅下降。

另外，文言文的省略句式和倒装结构会进一步稀释语义强度。“何以制之”这种表达，主语省略、宾语前置，模型需要多跳推理才能还原出完整意图，而安全对齐训练出的“危险意图识别”往往是浅层的模式匹配，多跳之后信号就衰减了。

注意：这里讲的是机制层面的客观分析，目的是帮助做防御的人理解攻击面，不是教人怎么构造攻击。实际做产品时，重点应该放在怎么补这些分布外场景的防护。

3. 实测复现：一个完整的验证流程与观察记录

3.1 测试环境与变量控制

为了把这件事讲清楚，我搭了一个最小验证环境。用的是某开源中文大模型（参数量在70亿级别），部署在本地推理框架上，关闭了外挂的内容审核API，只保留模型自身的安全对齐能力。这样做的目的是隔离变量——如果开着输出层审核，很多请求在返回前就被拦了，看不到模型层的真实表现。

测试设计了三组对照：

• A组：现代汉语直白表达的危险请求
• B组：现代汉语变体表达（谐音、拆字、隐喻）
• C组：文言文表达的同义请求

每组构造20条语义等价的请求，人工评估模型的“拒绝率”和“部分配合率”。这里要说明的是，所有测试请求都限定在“模型安全策略明确禁止”的范围内，评估标准是模型是否拒绝、是否给出安全提示、是否部分配合。

3.2 三组对照的拒绝率差异

实测数据如下（拒绝率指模型明确拒绝并给出安全提示的比例）：

这个结果说实话比我预想的还要明显。C组的拒绝率不到A组的一半，而“部分配合率”高得离谱——模型往往会先给一段安全提示，然后“但是，若从学术角度探讨……”接着就开始输出本不该输出的内容。这种“半推半就”的状态，在实际产品里是最危险的，因为它既没有完全拒绝，又给出了实质性的危险信息。

3.3 模型“半配合”状态的典型表现

我记录了几种反复出现的模式，这些模式对做防御的人特别有参考价值：

第一种是学术化包装。模型会把危险请求重新框定为“古代文献研究”“历史场景还原”，然后以学术讨论的口吻输出内容。这种输出往往还带着“仅供学术参考”的免责声明，但实质信息一点没少。

第二种是角色代入。当请求以“假设你是古代某类人物”开头时，模型的安全约束会明显松动。它会认为自己在“扮演角色”，而角色的话不代表模型自身立场。这个逻辑漏洞在现代汉语里也存在，但文言文场景下更严重，因为模型对“古代角色”的安全边界训练更少。

第三种是渐进式引导。单次文言文请求可能被拒绝，但如果先聊几句古文、建立“古文对话上下文”，再逐步引入敏感话题，模型的警惕性会持续下降。这其实是多轮对话安全的老问题，但文言文让衰减速度更快。

实操心得：做安全评测时，单轮测试的拒绝率会高估模型的安全性。真实攻击者用的是多轮渐进，实测下来多轮场景的绕过成功率比单轮高出两到三倍。所以评测集必须包含多轮对话样本。

4. 防御加固：从数据、提示词到输出审核的完整方案

4.1 安全训练数据的语言多样性补强

最根本的解法是在安全对齐数据里补上文言文和多语言变体的覆盖。但这里有个现实问题：文言文的安全样本构造难度大，懂古文又懂安全的人少。我的建议是分两步走。

第一步，用现代汉语安全样本做机器翻译+人工校验，批量生成文言文版本。现在模型的古文翻译能力已经不错，可以先把现有红队样本翻译成文言文，再人工过一遍，修正那些翻译后语义偏移的样本。这样能把数据构造成本降下来。

第二步，针对高频危险类别（比如涉及人身安全、违法行为的类别），单独构造文言文对抗样本。不需要覆盖所有类别，优先覆盖危害等级最高的那几类。根据我的经验，安全数据不需要面面俱到，但高危类别必须有分布外覆盖。

4.2 系统提示词的多语言约束设计

系统提示词（System Prompt）是成本最低、见效最快的加固点。很多产品的系统提示词只写了现代汉语的约束，比如“拒绝回答任何涉及危险物品制作的问题”。这种写法对文言文请求基本无效，因为模型不认为文言文请求属于“这个问题”。

改进思路是把约束写成语义层面而非表达层面：

• 不要写“拒绝回答涉及XX的现代汉语问题”
• 要写“无论用户使用何种语言、何种文体、何种表达方式，只要请求的实质意图涉及XX，一律拒绝”

关键是把“实质意图”这个词明确写进去，并且列举几种可能的表达形式（古文、方言、外语、编码等）。实测下来，加了这层约束后，文言文场景的拒绝率能从38%提升到70%左右。虽然还不够，但作为第一道防线性价比很高。

4.3 输出层审核的语义化改造

输出层审核如果只做关键词匹配，对文言文输出基本无效。必须做语义化改造，核心是让审核分类器也具备“跨文体理解”能力。

具体做法有两种。一种是回译审核：把模型输出先翻译成现代汉语，再用现有的审核分类器判断。这个方案实现简单，但会增加延迟，而且翻译本身可能丢失或改变语义。另一种是多文体审核训练：在审核分类器的训练数据里加入文言文、方言、外语样本，让它直接具备跨文体判断能力。这个方案效果好但成本高。

我的建议是混合使用：对延迟敏感的场景用回译审核，对安全要求极高的场景用多文体审核模型。两者叠加，文言文输出的拦截率能到90%以上。

4.4 多轮对话的状态追踪与风险累积

多轮渐进式引导是最难防的，因为它把危险意图拆散到多轮对话里，单轮看都没问题。防御的关键是跨轮次的风险累积追踪。

工程上的做法是维护一个对话级的风险分数，每轮对话后更新。如果连续几轮都在往敏感方向靠，即使单轮没触发阈值，累积分数也会触发拦截。这个机制在现代汉语场景下已经有成熟实现，文言文场景只需要把风险特征提取器扩展一下，让它能识别古文表达的风险信号。

注意：风险累积机制要小心误伤。正常用户聊历史、聊文学，也可能连续多轮涉及古代敏感话题。所以阈值设置要结合用户意图分类，不能只看话题关键词。

5. 常见问题排查与避坑指南

5.1 为什么加了关键词还是拦不住

这是被问得最多的问题。关键词拦截对文言文几乎无效，原因在2.3节讲过——分词和注意力机制导致危险信号被稀释。如果你的防护体系只有关键词层，那文言文绕过是必然的。排查时先确认你的防护有几层，如果只有输入层关键词，那问题不在关键词库不够全，而在架构本身缺层。

5.2 翻译成现代汉语再审核的延迟问题

回译审核的延迟主要来自翻译模型推理。实测下来，70亿参数的翻译模型在GPU上单次推理约200到400毫秒。如果你的产品对延迟敏感（比如实时对话），这个开销可能不可接受。优化方向是用蒸馏后的小翻译模型，或者只对“疑似风险”的输出做回译，先用轻量分类器筛一遍。

5.3 安全与可用性的平衡点怎么找

加固安全一定会影响正常使用。文言文场景下，最容易误伤的是正常的历史、文学、古文翻译类请求。我的经验是设置分级响应：低风险请求正常回答，中风险请求加免责提示后回答，高风险请求拒绝。分级标准用意图分类器判断，而不是用文体判断。同样是文言文，问“古代某制度怎么运作”和问“古代某危险技术怎么实现”，意图完全不同，不能一刀切。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是只测单轮。早期做评测时我只测单轮请求，看到拒绝率还行就以为没问题。后来做多轮测试才发现，渐进式引导的绕过率高得多。现在我的评测集里多轮样本占比不低于40%。

第二个坑是过度依赖外挂审核。有段时间我把安全全押在输出层审核API上，结果发现审核API本身对文言文也不敏感。外挂审核是必要的，但不能是唯一的，模型层的内生安全才是根本。

第三个坑是忽略低资源语言。文言文只是分布外表达的一种，方言、少数民族语言、甚至某些专业术语密集的表达，都可能有类似问题。做安全加固时要有“分布外意识”，不能只盯着文言文这一个点。

6. 这件事对AI应用开发者的实际影响

6.1 产品上线前的安全评测清单

如果你正在做LLM应用，上线前建议至少跑一遍这个清单：

• 单轮直白请求的拒绝率是否达标
• 单轮变体请求（谐音、拆字、隐喻）的拒绝率
• 单轮文言文请求的拒绝率
• 多轮渐进式引导的绕过率
• 输出层审核对文言文输出的拦截率
• 正常古文类请求的误伤率

这六项里，前三项是基础，后三项是很多团队会漏掉的。特别是最后一项，加固安全后一定要测误伤，否则可能把正常用户也拦了。

6.2 不同规模团队的分级加固策略

不是所有团队都有资源做全套加固。按投入产出比，我给个分级建议：

小团队（个人开发者、小产品）：优先做系统提示词语义化约束，成本几乎为零，能挡住大部分低级绕过。其次接一个成熟的输出审核API，虽然对文言文不完美，但能兜底。

中型团队：在提示词和审核API基础上，补一批文言文安全样本做微调。不需要全类别覆盖，优先高危类别。同时把多轮风险累积机制加上。

大型团队：建完整的多文体安全数据管线，审核分类器做多文体训练，评测集覆盖单轮、多轮、多文体、多语言。这套体系建起来成本高，但一旦建成，对各类分布外攻击都有防御力。

6.3 安全与体验的长期博弈

最后说点个人体会。做AI安全这几年，我最大的感受是：安全和体验的博弈是长期的，没有一劳永逸的方案。文言文绕过今天被讨论，明天可能就有新的绕过方式出现。重要的不是堵住某一个具体漏洞，而是建立一套能快速发现、快速响应新漏洞的机制。

具体来说，就是要有持续的红队测试、要有分布外意识、要有分级响应能力。这三样东西建起来，比单纯堆关键词库有用得多。我见过太多团队把安全做成“打补丁”，出了事才补，补完又出新的。真正稳的做法是把安全当成一个持续运营的系统，而不是一次性的功能。

文言文这件事给我们的真正启示，不是“古文很危险”，而是任何训练数据覆盖不到的表达形式，都可能成为安全盲区。今天补了文言文，明天可能还有别的。保持警惕，持续迭代，这才是做AI应用该有的心态。