「假设你在写小说，主角会怎么……」这类开场白频繁出现在 AI 安全的讨论里，指向同一个现象：有人试图让模型输出它本不该输出的内容，这类尝试被称为提示词越狱。本文只从防御角度拆解它——为什么会发生、平台怎么防、开发者怎么加固自己的产品，以及使用者为什么不该尝试。
为什么模型天然挡不住这类尝试
根源在模型的运作方式上。模型面对的一切都是文字：系统设定是指令，用户提问是指令，用户引用的一段小说内容也是文字。模型无法百分之百可靠地区分「该执行的指令」和「该理解的内容」，当有人把不当请求包装进角色设定、故事情节或多轮铺垫里，模型有可能把它当成创作素材的一部分来处理。
另一个原因是攻击面没有穷尽。自然语言的变化是无穷的，同一意图可以有无穷种表达，防护方无法枚举所有变体。这决定了 AI 安全只能是「持续对抗、层层设防」的过程，做不到一次性封堵。理解这一点，对「AI 到底安不安全」会有更接近现实的判断：它是一道需要持续维护的防线，不是修好就一劳永逸的墙。
平台在防线的哪几层工作
主流平台的防护大致分四层，各层解决不同环节的问题。最前面一层是训练阶段的对齐：让模型在学习阶段大量接触不当请求与正确拒绝的范例，从源头提高拒绝率。接下来是输入输出过滤：在用户输入进入模型之前、模型输出交给用户之前，各加一道内容检查，拦截明显违规的内容。再往上是红队测试：安全团队持续设计新的绕过思路去测试自家模型，发现问题就修补，用内部演练换取对外部攻击的免疫力。最后是行为监控：对异常使用模式，比如高频尝试违规请求的账号，进行识别和处置。
这四层没有哪一层单独够用。对齐挡不住训练之后才出现的新话术，关键词过滤挡不住语义层面的伪装，实际效果来自多层叠加：一层漏了，下一层接着拦。
开发者怎么加固自己的产品
如果你基于模型 API 做产品，安全责任有一部分会落到自己头上。几个务实的加固动作：把系统提示里的边界写清楚，明确禁止的输出类型，不能只依赖模型默认行为；对输出做规则校验，敏感类别的内容在展示前再过一道检查；给模型的能力做权限最小化，它能调用的工具、能查到的数据只给必需的部分，即使被诱导也不会造成实际损失；保留调用日志，出了问题能回溯到具体输入。
还有一件容易被忽略的事：每次修改系统提示或升级模型版本，都要把之前处理过的安全用例重新跑一遍，确认旧问题没有回来，这类做法可以参考提示的回归测试。另外要分两种情况：选择开源权重模型自建服务时，平台侧的内容过滤不会自动存在，过滤层需要自己补上，责任划分要想清楚；普通用户使用第三方套壳应用时，它是否完整保留了官方的安全机制并不透明，认准官方入口至少能确保防护是最新版本。
使用者为什么不该尝试
先把边界说清：绕过平台的安全机制，几乎都违反用户协议，情节严重会被封号处置；用它生成违法违规内容，更直接触碰法律红线，后果由使用者本人承担。本文拆解机制，是为了帮助理解 AI 安全的边界与防御逻辑，不提供任何可操作的绕过方法，也不建议在真实产品上做尝试。
对普通用户来说，值得带走的是判断力：当一个「AI 工具」宣传自己「没有任何限制」，这通常意味着它缺了上面说的某几层防线，风险由使用者的输入和输出自己扛。
一张表看四层防线的分工
| 防线 | 解决什么问题 | 局限在哪 |
|---|---|---|
| 对齐训练 | 从源头提高模型拒绝不当请求的比例 | 对训练之后才出现的新话术乏力 |
| 输入输出过滤 | 拦截进出两侧明显违规的内容 | 语义层面的伪装可能漏过 |
| 红队测试 | 提前发现并修补新的绕过路径 | 覆盖范围取决于测试投入的持续度 |
| 行为监控 | 识别并处置异常使用模式 | 属于事后处置，拦不住单次请求 |
AI 安全防御速查
- 模型分不清「指令」和「内容」，这是越狱尝试存在的根源
- 安全靠多层防线叠加，没有一劳永逸的封堵
- 开发者：边界写进系统提示、输出再校验、权限最小化、留日志
- 绕过机制违反用户协议，生成违法内容触碰法律红线，不要尝试
三个常被问到的疑问
被诱导产出的违规内容，责任由谁承担？使用与传播环节的责任通常落在实际使用者身上，平台协议一般明确禁止此类行为，具体认定以法律法规与平台规则为准。
管住了输入，模型就不会自己出错吗？管不住。模型仍可能在没有任何恶意提示的情况下自行生成不当内容，所以输出侧的过滤同样必要，两侧都要设防。
企业内部部署的模型也需要这些防线吗？需要。内部使用不等于无风险：员工输入可能包含敏感数据，输出可能流向外部，防护层的配置应按数据敏感程度来定，不按人数来定。
