越狱与护栏

模型的拒答行为来自偏好训练。人类或 AI 的反馈教会它拒绝某些请求。

这意味着拒答是学来的倾向，而不是规则。 背后没有规则引擎，也没有一张违禁话题的查表。模型只是有一个训练出来的倾向，而这个倾向泛化得并不完美——这正是它能被绕过、也正是它有时会拒绝本该答应的请求的原因。

理解这一点会决定你建什么：模型层面的安全是一个概率层，而任何你必须确保执行的东西，都该放进你自己的代码里。

为什么绕过能成立

安全训练只覆盖它训练过的数据分布。远离这个分布的请求，泛化结果无法预测。

下面按有助于你防御、而非有助于你实施的粒度，列出几大类手法：把请求包装成虚构或假设情境、套上一个人设、拆成逐个看起来无害的步骤、用编码或另一种语言混淆，以及利用那种「答比不答好」的指令跟随偏差。

这些手法没有一个是在利用 bug。它们利用的是「训练出的倾向」与「规则」之间的落差——更好的训练能把这个落差收窄，但不会让它消失。

新手法会不断冒出来，因为攻击面就是「所有表述请求的方式」这个全集。把服务商的安全措施当成抬高门槛的手段，而不是一道边界。

真正靠得住的那一层

你自己实现的护栏是强制措施，模型自带的护栏是倾向。凡是重要的东西，都要建前者。

调用模型之前做输入检查。 长度上下限、格式校验、按用户限流。这些都很便宜，而且能堵住资源耗尽和滥用这类漏洞——无论模型行为怎么调都堵不住它们。

之后做输出检查。schema 校验、敏感数据的模式匹配、必填字段缺失就拦截。通不过校验的输出，到不了用户手里。

一个独立的分类器。 用一个小而快的模型检查输入、输出或两者——放在主调用之外，这样它就不会被同一段 prompt 说服而放弃职责。这是结构上的优势：独立检查不会受到那些已经骗过主模型的操纵影响。

在你的代码里做权限校验。 不管模型产出什么，动作都以已认证用户的权限执行。这才是真正靠得住的防线，比上面所有措施加起来都值钱。

后果重大的操作要人工审核。 见人在回路的设计。

护栏是有代价的

每一层都会增加延迟、成本和误报——而真正伤产品的是误报。

过度拦截是一种真实的失效模式，而不是一个保险的默认值。一个拒绝讨论症状的医疗应用，或者一个拒绝解释某类漏洞的安全工具，就是坏的。拒绝合法使用是有代价的，只是这个代价容易被忽略，因为它看起来不像一起安全事件。

两个方向都要量。跟踪误报率要像跟踪漏报率一样认真，把正常流量上的高拒答率当成一个待修的缺陷。

把问题范围缩小

最有效的安全措施通常是把范围收窄。

一个只回答产品文档问题的系统，用检索增强生成（RAG），并指示它只根据检索到的内容作答，攻击面就很小。它没有工具、没有外部动作，也没有理由聊别的。离题的请求检索不到相关内容，也就产不出有用的东西。

一个能力广泛的通用助手，从构造上就有很大的攻击面。如果你不需要通用能力，那不去建它就是最强的护栏——而且不花一分钱。

实际形态

对大多数应用来说：限制输入的规模和速率、按 schema 校验输出、在代码里做用户权限校验、对不可逆操作设卡、保持范围狭窄、记录一切。

等你量出了它确实能解决的具体问题，再加分类器层。不要一上来就做这个——更便宜的结构性措施覆盖面更广。

上线前还要做对抗测试。见对 AI 系统做红队测试。

要点回顾

• 拒答是学来的倾向，不是规则——所以它在两个方向上都泛化得不完美。
• 绕过利用的是倾向与规则之间的落差；服务商的安全措施抬高的是门槛，不是边界。
• 你的护栏是强制措施：输入限制、输出校验、独立分类器，以及代码里的权限检查。
• 对已认证用户做权限校验，才是真正靠得住的防线。
• 过度拦截是真实的缺陷——量误报要像量漏报一样认真。
• 收窄范围是现有护栏里最便宜也最强的一个。

下一篇： 处理 PII 与敏感数据