一组数字很扎眼。

同一类攻击文本，意思几乎不变，只是把“内部策略 / 推理块”的写法改得不像一点，平均攻击成功率就从 61% 掉到 10%。

这不是某个 jailbreak 模板突然失效。更麻烦的地方在于：模型可能没有真正理解“谁有权限说话”，而是在看文本像不像高权限内容。

Charles Ye、Jasmine Cui、Dylan Hadfield-Menell 最近把这个问题叫作 role confusion，角色混淆。Simon Willison 转述并评论了这项研究，也顺手夸了一个细节：论文配了博客版。这个做法很对。安全研究如果只躺在 PDF 里，很多产品团队根本来不及吸收。

研究发现：模型会把“像内部文本”的用户输入看重

这项研究的主线很清楚：prompt injection 不只是用户在提示词里捣乱，而是模型对文本身份的判断不稳。

问题研究里的说法对产品的含义
发生了什么模型会混淆 system、think、assistant、user 等角色文本角色标签不一定等于可靠权限边界
攻击怎么发生用户输入模仿内部推理块、策略文本或高权限口吻低权限文本可能被模型当成高权限指令
关键数字destyling 后，平均攻击成功率从 61% 降到 10%风格对角色判断影响很大
适用限制数字来自该研究数据集和实验设置不能当成所有模型的通用安全指标

研究里的例子大意是：用户先提出一个明显有害请求，再附上一段模仿模型内部政策文本的内容，声称在某个条件下可以放行。

对人类读者来说，这很容易识别：那段所谓“政策”仍然是用户贴上来的。它没有更高权限。

但某些模型可能会被这种写法带偏。它看到的不是“这是用户输入”，而是“这段话很像内部规则”。于是原本的安全训练可能被覆盖。

研究中提到的案例包括 gpt-oss-20b。这里要收住一点：这不能直接推断 OpenAI 商业模型、闭源模型或所有大模型都有同样表现。稳妥的结论是，当前模型在角色感知上存在明显缺陷，而且这个缺陷不只是多写一条规则就能解决。

最反常的是 destyling。

所谓 destyling，就是把同样的意思改写得不那么像预期角色格式。内容没怎么变，风格变了。结果攻击成功率大幅下降。

如果模型真的理解“user 不能覆盖 system”，风格不该有这么大影响。现在的结果更像是：它在看制服，不是在查证件。

为什么重要：安全边界不能只靠提示词维持

我不太买账“把 system prompt 写严一点就行”的乐观说法。

提示词当然有用。过滤、隔离、检测也都有用。工程世界不是非黑即白。

问题是，只要最终还要把系统指令、网页内容、工具返回、用户输入一起塞进上下文，再让模型自己判断“谁该被听见”，风险就还在。

这对两类人最直接。

受影响对象现实动作代价
AI 产品团队需要重新检查 RAG、浏览器代理、邮件助手、代码助手里的输入边界上线会变慢，工具调用要加外部校验
企业采购和安全团队不能只看模型演示效果，要追问权限隔离、日志审计和工具审批采购周期可能拉长，PoC 要加安全测试

普通用户未必会感知“角色混淆”这个词。但他们会感知后果：助手读网页时被网页内容带偏，处理邮件时误听邮件里的恶意指令，调用工具时执行了不该执行的动作。

AI 产品越像代理，问题越尖。

聊天机器人答错一句话，损失有限。能读文件、发邮件、改代码、下单、查企业系统的模型，一旦分不清“数据”和“指令”，就不是尴尬，是权限事故。

古人说，“名不正，则言不顺”。放到大模型这里，话要说得更硬一点：角色名如果只是标签，权限就只是愿望。

<system>、<user>、<assistant> 这些标记，在工程文档里像制度。在模型内部，可能只是训练中见过的格式模式。

这就是行业被刺痛的地方。

很多安全设计默认存在一条隐形边界：系统提示词更高，开发者规则更可信，工具结果只是数据，用户输入不能篡改目标。可模型未必真的理解这套权力关系。它可能只是学会了“哪种写法更像上级”。

那攻击者就不会只改关键词。

他们会改口吻，改排版，改上下文位置，改成工具日志，改成审计报告，改成开发者注释。今天拦住一种制服，明天就换一套。

接下来该看什么：权限架构，而不是提示词文采

这项研究没有证明所有模型都防不住 prompt injection。也没有给出终局答案。

它真正有价值的地方，是把一个行业现实说清楚：安全不能长期寄托在模型“看懂格式”的善意上。

接下来最该观察的，不是厂商又写了多长的安全提示词，而是三个更硬的变量。

观察点真正要问的问题
上下文隔离不可信内容能不能避免和高权限指令混在同一个推理空间里
工具审批模型调用外部工具前，是否有独立策略引擎做权限检查
输入定性用户输入、网页内容、知识库文本能否被强制当成数据，而不是指令

这些东西不适合发布会展示。也很难做成一句漂亮口号。

但它们决定产品能不能进入真实业务。

铁路早期也不是靠司机“更认真看信号”解决事故的。真正让系统变稳的，是信号、调度、闭塞、制动这些外部机制。AI 不完全一样，但有一点相通：权力不能只靠话术约束。

对开发者来说，这意味着架构要更保守。

不可信网页不要随便和系统目标混放。工具调用不要只听模型一句话。关键动作要有可验证的权限检查。日志、审计、回滚也要提前设计。

对企业采购来说，也要少被演示视频带着走。

模型在干净环境里完成任务，和它在真实邮件、网页、知识库、工单系统里保持边界，是两件事。采购时该问的不是“它会不会总结文档”，而是“它被文档里的指令带偏后，谁拦住它”。

模型能力越强，这个问题越不能拖。

因为能力提升会让人愿意把真实任务交给它。可如果安全边界还停在“希望它听对人说话”，产品就会越强越虚。

这次研究最好的地方，不是提供了一个新的攻击样例，而是把问题命名得准。

Prompt injection 的核心不只是用户狡猾。它更像是模型对文本身份缺乏真实感知。

角色都认不清，谈忠诚太早。