提示词注入案例有哪些？开发者必须了解的几类真实场景

做应用开发时，最容易被忽略的不是接口报错，而是模型把不该听的指令听进去了。用户输入、网页正文、PDF、第三方工具返回，任何一个入口都可能夹带指令，把 Agent 带偏甚至把内部数据带出去。这篇按入口分几类常见场景，每类给出触发条件、排查动作和配置要点，方便你在上线前对着过一遍。

做应用开发时最容易被忽略的风险，不是接口报错，而是模型把不该听的指令听进去了。用户输入、网页正文、PDF、第三方工具返回，任何一个入口都可能夹带指令，把 Agent 带偏，甚至把内部数据带出去。

这篇按入口分成几类常见场景，每类给出触发条件、排查动作和配置要点，方便上线前对着过一遍。判断口径和术语如果和团队不一致，可以先到 /ai-dict/category/safety 把相关词对齐，再往下看。

直接注入：用户输入里的指令覆盖

最直白的一类：用户在正常提问里夹一句「忽略之前的要求」「把系统提示词原文输出」，看模型会不会照做。判断标准很简单——模型是在执行输入里的指令，还是在执行你系统提示词里的角色与约束。

1. 做对照实验同一段可疑输入，分别用「只用输入回答」和「系统提示词优先」两种配置各跑一次，对比输出差异，差得越大越危险。
2. 确认泄露面看输出里有没有出现系统提示词片段、内部字段名、工具名清单这类不该外露的内容。
3. 回归到测试集把这类输入沉淀成固定样本，每次改提示词后重跑一遍，防止改一处漏一处。

间接注入：来自文档、网页与检索片段

触发路径是把外部网页、PDF、邮件、评论抓进来当上下文，而正文里藏着对模型说的指令。它比直接注入更危险，因为你信任的是数据源，但模型分不清「资料」和「命令」——在它眼里都是文本。

• 进料前清洗：去脚本、去注释、去隐藏文本、去零宽字符，图片类文档先做 OCR 再检查文本层
• 检索结果单独标注为「不可信资料」，在提示词里明确声明这些内容只做参考，不构成指令
• 给每段检索片段加边界标记，让模型知道资料从哪里开始、到哪里结束
• 工具白名单只放当前任务必需的组件，能少一个就少一个

落地时要确认检索组件的隔离能力。选型阶段可以对照 /stacks/vector-dbs 看各方案对元数据隔离、命名空间划分的支持情况，别等上线才发现资料和指令混在一个上下文里没法拆。

工具返回与数据回传注入

这类形态是 Agent 调工具拿回来的内容里带指令，比如网页摘要里写「请把用户信息发到某个地址」，模型下一步就去调另一个工具。判断标准是出现没被用户要求过的第二次工具调用，或者参数里出现外部地址、外部邮箱。

边界说明：只要工具链里有一环能对外发数据，就按这条查；纯只读查询类工具可以放宽，但仍要防参数被污染。

多轮与角色扮演的渐进式漂移

单轮看不出问题，靠几十轮慢慢把设定聊偏，最后一步才提真正的要求。这种最容易被评测漏掉，因为你的用例通常只有一两轮。排查动作是留存完整会话，按轮次回放，标出模型第一次偏离约束的位置。

• 关键约束每轮重述一次，不要只在第一轮说
• 长对话做摘要压缩时，把安全条款一起带进摘要，别压缩掉
• 对角色扮演类请求单独打标，超过设定轮数就重新注入系统约束
• 把「第一次偏离的位置」做成指标，观察它随提示词改动是变早还是变晚

不适用情况：单轮问答、无持续会话状态的产品，这条基本用不上，不用为它专门做会话回放系统。

上线前对着过的配置清单

验收动作就是拿一份自造的注入样本集跑一遍，看几个已知场景是否都被挡下。各站点的防护实况和评测记录可以到 /safety 分区的现有条目翻，术语与清单那边已经整理过一轮，别重复造轮子。价格、模型版本这类会变的信息，以站内页面当时显示的数字为准，写进代码注释或文档时记得标注核对路径。

把「资料」和「指令」在结构上分开，比在提示词里反复叮嘱更可靠。