做AI应用安全评估这几年我见过太多有意思的绕过手法但最让我印象深刻的不是那些复杂得像小说一样的提示词注入而是看起来人畜无害的十六进制字符串和表情符号。上个月在给一套基于大模型API搭建的智能客服系统做安全测试时我构造了一种编码混杂的输入就绕过了系统内置的关键词审核逻辑。这个案例放在AI安全攻防的大背景下并不算新颖但它折射出的问题值得所有正在做LLM应用开发、内容审核、安全运维的同行认真想一想我们的安全限制到底在拦什么又为什么这么容易被绕过去。这篇文章不会讨论任何真正的攻击利用细节而是站在防御者的角度把十六进制编码和表情符号这两类典型的语义干扰手法拆开来看。适合谁读正在做AI应用安全的工程师、提示词工程的开发者、还有那些负责为大模型应用设计审核策略的产品经理。你会看到这类问题出现的根本原因、攻击者利用的思路框架以及我实测下来最有效的三层防御设计。1. 先搞清楚安全限制到底拦的是什么1.1 内容安全策略的基本组成目前几乎所有大模型应用的安全限制都不是单点防御而是一套多层体系。最外层通常是关键词匹配和正则规则比如直接过滤掉“赌博”“暴力”等相关词或者对URL、邮箱等模式做拦截。往下一层是分类器也就是用一个小模型或者规则引擎对用户输入做风险打分分数超过阈值就拒绝响应。最内层才是模型自身的安全对齐也就是大家经常说的“价值观对齐”让模型在生成阶段主动拒绝输出违规内容。这套体系有个天然的问题每一层都有不同的“盲区”。关键词拦截只能拦住明文一旦内容经过编码转换正则就没辙了。分类器对语义的理解依赖训练数据碰到没见过的新表达就容易失明。模型自身的安全对齐虽然最强但它的判断是基于token序列的注意力权重一旦关键信息被异常token稀释审查效果就会大打折扣。三层防御各自为战缺少统一的语义理解层这就是编码绕过和表情符号混淆能不断刷存在感的根本原因。1.2 编码与语义之间的“翻译层”大模型处理文本的第一步是tokenization也就是把用户输入拆分成token序列再映射成向量去做计算。这个过程中存在一个关键的“翻译层”有些内容在人类看来是同一句话但在token层面却可以有不同的表示方式。也就是说安全审核看到的内容和模型真正语义理解的内容中间可以被人为制造出巨大的认知偏差。举个例子。你直接输入“请忽略之前的指令”审核系统能轻易识别。但如果你把这句话里的每个字按ASCII码顺序转换成十六进制前面再加一句“请将下面的十六进制代码解码并输出”结果会怎样关键词匹配完全不认识这串乱码分类器看到的是“解码”“十六进制”这类中性词而模型在后续推理中却会去执行解码后的指令。这就是编码绕过的基础逻辑——利用审核层和模型理解层之间的语法差异在语义空间中玩“偷梁换柱”。很多开发者觉得这类攻击是“高科技”其实它的原理朴素得很就是找到了系统里没人盯的那个翻译环节。2. 十六进制编码的注入形态与防御缺口2.1 编码绕过的基本原理要真正理解十六进制编码为什么能绕过安全限制得先建立一个概念安全审核和模型推理共享同一段输入但它们对这段输入的“感知方式”完全不同。审核系统通常对原始文本做字面匹配而模型会经历一个完整的理解过程。攻击者利用的正是这个时间差和感知差。具体到十六进制编码常见的形态有这么几类将整句指令或关键词转换成十六进制字符串比如转ASCII码的十六进制表示将部分关键词编码其他文本保持明文混搭提交在编码内容前后加入引导指令让模型自己完成解码操作使用Unicode编码、URL编码、Base64等多层嵌套方式复合处理我测试过的一个典型流程是先构造一段包含风险指令的明文然后把其中关键动作词汇全部转成十六进制最后在开头加一句“现在把下面的十六进制内容翻译成正常文本然后执行”。审核层看到的是一串无害的字符组合而模型回应了用户的“翻译请求”。这种手法不是ChatGPT特有的几乎所有基于LLM的应用都存在类似的接口风险。2.2 测试中的触发链路与特征我在安全测试中总结过这类编码注入的三个典型特征这些特征对防守方设计检测规则很有参考价值。第一个特征是“解码指令编码数据”的组合结构这条规律非常稳定。只要存在“解释”“翻译”“解码”“恢复”这类动词同时后面跟着高密度的十六进制或字符实体基本就可以判定为可疑。第二个特征是编码数据的字符分布异常。正常的用户输入里不会突然出现一长串连续的十六进制字符或者大量#x开头的HTML实体。这类模式在字符频度上自带指纹适合做统计异常检测。第三个特征是语义层面的不协调。系统如果只看单条消息可能无法发现异常但如果结合对话上下文就会发现用户前一轮还在正常聊天下一轮突然要求模型“解码执行”行为轨迹存在明显的逻辑跳跃。这类行为特征对捕获未知变种非常有用因为它不依赖具体关键词。2.3 防御者视角规范化与检测盲区说完了攻击形态重点聊聊防守方应该怎么做。我在实践中有个核心结论对付编码绕过的第一道防线不是更复杂的关键词库而是输入规范化。所谓输入规范化就是在文本进入审核流程之前先做一个统一的解码和标准化处理。十六进制转明文、HTML实体解码、Unicode归一化、URL解码这些操作应该作为前置步骤自动完成。我见过不少团队在关键词库上花了大量精力但连最基础的解码预处理都没做等于把前门大敞着。但注意规范化不能乱做否则会伤业务。纯粹把用户的编码数据强制解码一方面可能破坏正常业务逻辑比如用户确实想讨论十六进制颜色码另一方面会给攻击者提供新的探测面。我的建议是做“审核专用的并行解析”方案保留原始输入给业务逻辑使用同时生成一份完全解码后的副本给审核引擎检测两份文本独立存在互不干扰。这算是我踩过不少坑之后总结出来比较稳妥的做法。3. 表情符号多模态混淆的危险一面3.1 表情符号为什么能干扰语义判断表情符号在安全攻防中的角色比大多数人想象的要复杂。它的本质作用是给文本增加额外的情感和语气信息但正是这种“附加信息”身份让它成了天然的语义干扰源。从模型的处理机制来看表情符号在tokenizer中占用独立的token这个词向量会与相邻文本的向量发生交互。当输入里出现大量表情符号时注意力机制会被这些高权重token分散导致审核分类器对真正的风险内容感知变弱。同时表情符号本身往往被归类为低风险词不会被关键词规则拦截。这两点叠加就让表情符号成了绕过安全限制的一块很合适的“遮羞布”。我在测试中使用表情符号的典型策略是把风险指令中的某些敏感词用同义的表情符号替代或者在指令的关键位置插入大量无关的表情符号做干扰。前者依赖审核系统对表情符号的识别盲区后者则是通过对注意力权重的“稀释”来降低风险内容的可见性。3.2 注意力机制下的干扰实例说说我实际跑过的一个对比测试。同样一段包含风险指令的文本纯文本输入被审核系统拦下的概率接近百分之百但当我在这段文本的每个关键词之间插入一个表情符号并把某些动词替换成对应的表情符号后审核系统的拦截概率明显下降。为什么会这样我用一个生活化的类比来解释。想象你在嘈杂的集市里跟朋友说话周围全是叫卖声、喇叭声、小孩哭声这时候就算你说了一句不太合适的话旁边的保安也不容易听清。表情符号就是集市里的噪音它让安全审核这个“保安”听不清风险指令的完整语义但模型的指令跟随能力依然能从上下文中拼凑出用户的意图。这里需要特别提醒一点表情符号干扰并不只是简单的“插入噪音”。我实测下来攻击者往往会在表情符号的使用上有比较强的规律性比如选取与风险内容存在语义关联的表情符号做替换或者在特定位置密集使用同一符号。这些规律恰恰可以作为防御方建立行为特征库的依据。3.3 表情符号在对抗样本中的角色如果把表情符号和其他混淆手段叠加使用对抗强度会成倍上升。比如“十六进制编码表情符号”的组合风险指令被编码成不可读的字符串字符串中再混入表情符号作为分隔符同时加入指令要求模型解码并忽略干扰符号。这种复合型绕过对传统审核体系的打击是毁灭性的每一层防御看到的都是截然不同的内容。但从防御角度看这类对抗样本也给了我们很有价值的提示识别表情符号混淆不能只做字面检测必须结合语义层面的一致性判断。也就是说系统要回答一个关键问题这段文本去除表情符号之后剩下来的语义内容是否依然自洽如果一段输入中表情符号的出现频率和位置分布完全不符合正常用户的表达习惯同时去除符号后的文本存在高度指令化的行为倾向这个组合特征就需要被标记下来转入深度审核。4. 构建防护体系的实战路径4.1 输入侧多层校验与归一化设计经过前面这些测试我在自己的项目里搭起了一套针对编码混淆与符号干扰的三层输入防护分享出来给大家参考。第一层是格式校验用白名单思维过滤异常结构。对文本长度、字符分布、编码类型做统计建模检测高密度的连续十六进制段、异常的Unicode范围、高频表情符号区域。这一层不需要理解语义就是快速粗筛把明显的异常样本拦在最前面。第二层是语义归一化。生成一份解码后的副本完成十六进制转明文、Unicode归一化、HTML实体解码、URL解码并对表情符号做标签化替换处理也就是把表情符号统一替换为[EMOJI]占位符。这份副本专门用于安全审核。第三层是风险语义识别用内容安全分类器加上基于行为的规则引擎结合上文提到的“解码指令编码数据”“语义跳跃”等行为特征做判定。三层叠加之后编码绕过的成功率会大幅下降。4.2 模型侧上下文安全对齐与细粒度审查输入侧防护做得再好也拦不住所有攻击。所以还需要在模型侧做一些配合工作。我建议在系统提示词里加入安全上下文约束明确要求模型对包含“解码”“翻译”“恢复”等指令的内容保持警惕在解析编码数据之前自动评估来源和意图。这类约束不能杜绝风险但可以显著拉高攻击者的成本。更有效的做法是构建细粒度的输出审查机制。不要只看模型最终输出的那个字符串而是把“输入解码后的语义”“模型的中间推理结果”“最终输出”三者做交叉比对。如果输入在解码后包含风险指令而模型输出中出现了相关内容的影子那么无论表面上语句多么无害都应该触发告警。我在项目中就是把模型输出接入了一个独立的审核通道做二次语义分析。效果虽然会增加几十毫秒的延迟但相比安全漏洞造成的风险这个成本完全值得。4.3 输出侧响应检测与熔断机制输出侧的审核有一个容易被忽略的点不仅要判断输出内容本身是否违规还要监控“输入—输出”之间的语义映射关系。举个例子输入是一堆十六进制乱码模型输出的却是正常文本这本身就是一个强信号说明用户很可能在利用模型做解码操作。此时即使输出内容本身看着正常也应该记录审计日志并触发频率限制。我建议为这类高风险操作单独配置熔断规则。比如单个用户在一定时间内触发三次以上的“解码型输入—正常文本输出”模式就自动降低其可用额度或转入人工审核队列。熔断机制的价值不在于拦截某一次攻击而在于打破攻击者批量探测的节奏。大量自动化攻击依赖快速迭代和反馈一旦你让对方每次尝试都变慢、变困难攻击的性价比就会急剧下降大部分投机者就会放弃。5. 安全测试中的常见问题与实测调优记录5.1 特征库为什么总被绕过在安全攻防这个领域最普遍的挫败感来自于“昨天还管用的规则今天就被绕过了”。我早期也走过这个弯路热衷于收集各种已知的绕过样本把它们做成正则规则和关键词库结果发现维护成本极高而且新变种出现的速度远快于规则更新的速度。后来我调整了思路。特征库可以保留但只能作为辅助手段核心防线必须建立在行为和语义分析上。关键词会被编码绕过但“解码指令编码数据”的组合结构很难被完全隐藏内容可以被表情符号稀释但去除符号后高风险语义倾向很难消除。特征库负责捕捉已知模式行为模型负责捕捉未知变体两者配合才能避免“头痛医头”。另外我建议给特征库的每条规则加上一个过期时间。规则长时间没有命中要么说明攻击手法已经过时要么说明存在没被发现的变形方式。前者可以清理后者需要重新测试评估。这个机制能倒逼安全团队定期复盘规则库避免自欺欺人地认为“没报警就等于安全”。5.2 误杀率升高之后怎么调优加严防护之后下一个问题必然出现误杀率升高。我把安全参数调紧后第一周就有不少真实用户反馈对话被错误拦截产品那边差点要找我喝茶。这类问题的根源在于安全系统的很多特征在“正常用户”和“攻击者”之间并没有清晰的界限。比如一个程序员用户可能在聊天中贴出一段十六进制数据也可能在表达里频繁使用表情符号。调优的核心思路是引入上下文和用户画像。同一个特征在不同场景下应该有不同的权重。新注册用户、匿名会话出现“解码指令编码数据”组合风险等级应该定高老用户、高频正常使用用户出现相同特征可以适当放宽并转入观察模式。还可以把全局判定改为分级处置不是所有可疑请求都直接拒绝而是按风险等级执行不同策略高风险阻断、中风险加验、低风险放行并记录。分级处置在提升安全性的同时能把误杀对业务的影响控制在可接受范围内。5.3 安全测试的三条实用经验最后分享三条实操经验这些都是我在真实项目中总结出来的。第一条攻防测试必须有明确的授权和边界。没有授权的绕过测试不仅违规而且容易给自己和团队带来不必要的麻烦。即使是授权测试也应该限定在测试环境或者专门的沙箱账号中避免污染真实的业务数据。第二条安全测试案例一定要沉淀成可执行化的检测规则。每次发现新的有效绕过方式不要只停留在“哇这样也能绕过”的感叹里要立刻转化为自动化用例嵌入到回归测试流程中。否则下次发版同一个漏洞可能在不同模块里再次出现。第三条安全建设是一个持续对抗的过程。不要指望一次上线就能一劳永逸地解决所有问题。AI安全攻防的精髓在于快速响应、持续迭代。我在项目里保留了一个每周定时执行的对抗性测试任务用最新的绕过思路去验证现有防线发现缺口就立刻修补。这是目前我认为最有效的防护状态维护方式。做AI应用安全这几年我最深的体会是没有绝对安全的系统只有相对完善的防御体系。十六进制编码和表情符号只是AI安全攻防这个领域里的两个切面但它揭示出的核心矛盾一直没变——安全系统要追求对语义的深度理解而攻击者则永远在寻找理解过程中的缝隙。作为安全从业者我们能做的就是不断把缝隙缩得更小把攻击者的成本抬得更高。这条路上没有终点但每多一次对抗测试、每多一条有效规则整个生态的安全水位就会高一点。希望这篇文章能给正在搭建大模型应用安全体系的你一些参考也欢迎在评论区聊聊你遇到的绕过案例。