基本信息
| 为什么弱 | 模型按语义理解，标识符不是内核级边界；内容可以模仿结束符 |
|---|---|
| 定位 | 分隔符负责可读性与工程规范，安全边界交给权限与校验 |
| 替代 | 结构化调用（内容作为参数传递）比字符串拼接更强 |
| 验证 | 用包含伪造结束符的样本实测，看是否被绕过 |
分隔符防护的局限
用分隔符把用户内容包起来是常见做法，但它不是安全边界：内容里可以写出一模一样的结束标记，模型也可能把语义上的连贯当成跨区延续。分隔符真正的价值是工程规范与可读性——让提示结构清晰、让解析有明确边界。安全要靠权限、校验与来源隔离。
典型使用场景
- 模板拼接输入：知道用 <content> 包裹并不等于安全
- 多段资料拼接：用分隔符区分来源，便于引用校验
- 代码生成：把代码块与说明分区分开，便于提取
- 输出解析：用标签或分隔符截取答案区
- 安全评审：检查团队是否把分隔符当成了唯一防线
更稳的组合
更稳的组合
1) 结构化调用：内容作为参数字段传入，不经字符串拼接
2) 数据区与指令区分离，并附带来源标记
3) 高风险动作走审批与参数白名单
4) 输出侧检查：引用校验与外发限制
5) 权限收敛：只给该任务需要的工具与数据范围
# 分隔符仍保留，但只承担可读性与解析便利，
# 不要在文档或评审里把它描述成安全机制隔离手段强度对照
| 手段 | 强度 | 说明 |
|---|---|---|
| 分隔符包裹 | 弱 | 内容可伪造，模型按语义理解 |
| 来源标记 | 中 | 可追溯、可过滤，但不阻止执行 |
| 结构化参数传递 | 较强 | 内容不进指令流，边界在调用层 |
| 权限与白名单 | 强 | 即使注入成功，可造成的损害有限 |
| 审批与确认 | 强 | 高风险动作需要人参与 |
把分隔符当安全机制的最大危害在认知层面：团队会因为加了分隔符就认为风险已解决，从而跳过权限收敛与输出检查这些真正有效的措施。
只加固提示词而不改调用结构，注入面依然存在。判断防护是否有效，看的是调用层是否支持内容与指令分离，而不是提示里写了多少条禁令。