越狱提示词模板

做模型安全、合规评审或红队测试的人，常卡在同一处：知道有越狱这回事，但拿到一份提示词后说不清它算不算越狱、风险在哪、该拦哪一句。这篇不教怎么写攻击话术，只讲套路怎么被拆解成可识别的结构，给一套判断标准、自查清单和排查顺序，并说明哪些场景下这些判断会失效。

做模型安全、合规评审或红队测试的人，常卡在同一个地方：知道有越狱这回事，但拿到一份提示词后说不清它到底算不算越狱、风险在哪、该拦哪一句。这篇不教怎么写攻击话术，只讲套路怎么被拆解成可识别的结构，给一套判断标准、自查清单和排查顺序。

先说清一件事：越狱提示词不是玄学，它是一组可以被拆开看的结构特征。你要做的不是背模板，而是学会看一条输入有没有绕过安全策略的倾向、有没有伪造授权、有没有把真实诉求藏在设定里。判断标准定下来，后面谁来看都不会跑偏。

先划边界：什么算越狱，什么只是正常追问

越狱的判定要看两条线：意图与结果。意图线上，看这条输入是否试图绕过模型既定的安全策略；结果线上，看输出是否真的越过了本该守住的边界。两条线缺一条都不能直接定性，只满足一条时按「疑似」记录，进入复核而不是直接处置。

越狱提示词的几类常见结构套路

套路本身不新鲜，难的是在一条长输入里认出它。下面几类是实际评审里反复出现的结构，识别信号比话术本身更重要。安全术语的口径可以到 安全术语分类页（/ai-dict/category/safety） 对照当时的定义，避免各人理解不一致。

角色与身份包装

把模型放进一个不受约束的设定里，再提出真实诉求；识别信号是设定与诉求不匹配

分段与延迟触发

先铺垫若干轮无关对话，再抛出核心请求；识别信号是上下文里出现明显的意图跳变

编码与改写

用替代表述、多语言混写或非常规符号改变字面形态；识别信号是同一语义被反复换壳

授权与场景伪造

声称有内部授权、测试许可或紧急情形；识别信号是授权来源无法验证

这四类经常叠加出现。一条输入如果同时触发两类以上，风险等级就该往上走一档，而不是按单类处理。反过来，只出现一类且信号很弱时，先记录观察，别急着下结论。

拿到一条提示词，按什么顺序判断风险高低

1. 第一步：看目标请求指向的是信息、能力还是绕过监管。指向越具体、越偏向可执行动作，风险越高。指向概念和原理的，即使措辞激烈，等级也先放低。
2. 第二步：看手段是否依赖伪造身份、隐藏指令或多轮诱导。手段越多层、越刻意，越值得警惕；单一手段且可被正常对话解释的，降级观察。
3. 第三步：看后果假设模型照做，产出是否可用于欺诈、规避审核或制造现实危害。只在这一步不成立时，才把前两步的判断降级处理。

三步走完再定级，别跳步。实际工作里最常见的错误是看到敏感词就定高危，或者看到礼貌措辞就放行。判断口径要在团队里固定下来，站内对安全相关术语和分类的整理见 安全专题页（/safety），定级前先对齐这里的说法。

红队测试里可落地的排查动作

红队测试的价值在于可复现，不在于样本多。建测试集时按套路分类打标，每类保留少量代表性样本即可，重点让任何同事拿到都能跑出同一结果。样本去重比堆量重要。

• 跑测时分开记录三样东西：输入结构、模型反应、是否触发拒答，别只盯着最后一句输出
• 复现失败先查上下文长度和系统提示词是否变化，再查采样参数，顺序别颠倒
• 测试结论写清适用的调用方式与模型，换模型或换接口后必须重跑，不能直接沿用
• 接口侧延迟与稳定性先量出基线，否则你分不清是模型拒答还是链路超时

接口侧的基线可以用 速度测试工具（/tools/speed-test） 先跑一遍，把延迟和稳定性记下来。很多「模型变聪明了/变傻了」的结论，其实是链路波动造成的假象，先排除这一层再谈模型行为。

产品与合规侧能做的六项防范

防范不是加一堆关键词。关键词拦得住字面，拦不住换壳。下面六项按性价比排，前两项做扎实，后面几项的收益才明显。

• 入口处做意图分类，区分信息查询、能力调用与绕过尝试，按类走不同策略
• 系统提示词写清不可协商的边界，并让它优先于用户设定的角色
• 输出侧加一层审核，重点拦可执行的危险步骤，而不是敏感词本身
• 留存与审计：记录触发拦截的输入结构而非完整原文，兼顾复盘与隐私
• 对第三方接入的工具与技能做来源核对，避免把外部提示词直接拼进主线
• 定期用历史拦截记录回测新规则，看误判率有没有跟着一起涨

第三方工具和技能的来源核对常被忽略。外部提示词一旦被直接拼进主线，你等于把别人的边界当自己的边界用。技能与工具目录可以到 技能目录（/skills） 和 插件目录（/plugins） 核对当时的收录与说明，接入前先看来源和权限范围。个人信息处理口径参考 安全术语分类页（/ai-dict/category/safety）。

别误伤：哪些情况容易被错判

误判的代价不只是多拦几条，而是真实工作被挡住之后，团队会开始绕过你的规则。安全研究、渗透测试教学、漏洞披露类提问本身是正当场景，这类输入被拦掉，损失比漏放一条更大。

两套阈值不要混用。面向公众的通用产品可以从严，动作快、可回溯；面向已授权内部测试的环境应以记录和复核为主，规则太紧会把测试本身逼停。什么情况下这套判断不适用：当提问属于公开可查的正当技术讨论、且模型侧没有明确安全策略时，不要用越狱框架去定性。

把这套判断固化成日常流程

靠个人经验的判断没法交接。把识别、定级、处置、复盘四步写进安全响应流程，每步指定负责人，换人也能接得住。

1. 识别谁负责初筛、用什么口径判断，写清楚；初筛只看意图与手段两条线。
2. 定级写清升级条件，例如同一套路重复出现或跨模型复现时提高等级，避免临场拍脑袋。
3. 处置拦截、复核、放行三条路径分别由谁批、多久内响应，写进流程文档。
4. 复盘定期回看拦截记录，区分真实风险与误判，按比例调整规则；对外口径统一由合规侧确认。

对外沟通时注意一点：未定性的案例不要描述成结论。把「疑似」说成「确认」，后续澄清的成本远高于当时少说一句。想要按类型和工具维度持续跟踪这类风险的趋势，可以到 排行与追踪页（/rankings） 看当时的汇总，数字以页面当天显示的为准。