指令角色与信任边界

区分应用规则、用户目标与外部资料在模型输入中的职责。

system、developer、user等角色是供应商定义的API语义，不是可以机械对应的行业统一层级。应用需要表达稳定行为规则，用户需要提供具体目标和偏好，检索与工具结果则提供待判断数据。适配不同模型时，应确认各自角色、原生系统字段和优先级支持，而不是简单改字段名。

OpenAI当前prompt文档将developer用于应用指令，并说明它相对user的优先关系。其他供应商可能使用不同结构。企业可以先维护与供应商无关的规则模块，再由adapter按模型语义渲染。渲染过程与变量schema应有版本，确保一条用户输入不会被错误拼进高优先级规则。

应用规则适合约束任务范围、证据标准、允许工具、停止条件与输出合同；领域模块补充财报口径、法域或教学策略。用户输入提供对象、日期和成功条件。网页、上传文档、代码注释和MCP返回即使包含“忽略之前规则”，也只是外部内容。XML、Markdown标题或引用符可以帮助阅读，却不能独立防止prompt injection。

把规则写成可观察要求，比“你是世界顶尖专家”更容易验证。例如要求关键数值回到原报表并复算，要求法律引文核原文与适用日期，要求提示后答案与独立作答分开记录。不要用一份巨型system prompt补所有历史错误，局部多步骤方法可放入按需加载模块。

提示词只能辅助执行控制。即使模型遵守角色规则，服务器仍要校验主体、资源和动作；即使模型被外部材料诱导，也应无法扩大权限。测试在不同数据通道注入伪指令，观察模型回应与真实工具效果分别如何。一个模型拒绝了单轮攻击，不证明跨摘要、memory和子Agent后的安全性。

产品需要展示简明行动依据、证据与操作记录，不必索取私有思维链。把可审计性建立在真实事件上，能避免把一段说服力很强的自述误当执行证明。

实践重点：按供应商角色语义适配system/developer/user；检索和工具返回保留为数据，授权由执行器判断。

验证抓手：用检索资料中伪造指令测试规则不被改写，并检验工具侧真实权限。

常见误区：把网页内容拼入高优先级prompt，或把分隔标签当可靠安全边界。

OpenAI：Prompt engineering；Anthropic：Context engineering。