系统 / 开发者 / 用户提示词分层

System, Developer, and User Prompt Layering

PE-F-02内容已写满G00地基：模型是概率采样器第 1 层

01为什么需要它

提示词不是一段越写越长的文本，而是按特权与生命周期分层的一组指令。

• 分层之所以必要，是因为不同内容的变更频率与权威性不同：产品级约束几乎不变，任务级指令每次调用都变，用户输入则完全不可信。
• 混在一层会导致每次改一处就要重测全部内容，也无法在安全侧表达「谁说了算」。

02机制说明

系统层承载产品身份、长期约束与安全策略，其特点是稳定、由开发者掌控、可被缓存；开发者层承载任务级指令与输出契约，随调用点变化；用户层承载本次输入，内容不可信。

• 三者之外通常还有工具返回、检索资料与记忆条目，它们与用户输入同属不可信内容，需要显式标注而非与指令混排。
• 分层的两个直接收益是
• 1. 把稳定前缀与易变后缀分开，使提示缓存可以命中
  2. 为指令层级提供工程落点，使「低特权来源不得覆盖高特权来源」这条规则有地方可写。

03何时该用 / 何时不该用

04实验台

1. shellbash

   查看代码

   # 同一段长前缀，分别用「系统层内容完全不变」与「系统层改一个字」的两种方式调用
   # 记录每档的时间与计费字段（缓存命中通常在响应里以 cached_tokens 之类的字段体现）
   for variant in stable mutated; do
     echo "== variant=$variant =="
     for i in 1 2 3; do
       curl -s "$API_ENDPOINT" -H 'content-type: application/json' \
         -d @"payload-$variant.json" | grep -o '"[a-z_]*cached[a-z_]*":[0-9]*'
     done
   done

   预期观察：stable 档从第二次起出现缓存命中字段、延迟明显下降；mutated 档每次都当作全新前缀，命中归零。这一步让读者亲眼看到「系统层的稳定性 = 可缓存性 = 成本」。

2. filemarkdown

   查看代码

   分层记录表：把现有提示逐段剪开，每段填四列
     段内容 | 放在哪一层（系统 / 开发者 / 用户） | 变更频率（几乎不变 / 每次调用 / 完全不可信） | 若放错层的代价
   判据：凡是「几乎不变」的内容都应落在系统层且位于前缀；凡是「每次调用都变」的内容都不得进系统层。
   不得用「反正模型看得懂」替代分层判断——分层要管的是缓存与权限，不是模型理解力。

   预期观察：读者能把自己的提示切成三层，并说出每一段为什么在那层，而不是凭感觉排列顺序。

05证据

06术语

07失效模式

• 把系统层当垃圾桶每次调用都变的内容写进系统层会破坏前缀稳定性，缓存全失效，延迟与成本同时上升。
• 只用大写与强调表达优先级特权关系没有工程落点，安全侧无法表达「谁说了算」，模型只看到更响的语气。
• 把分层当成安全机制层级只是工程落点，防注入仍须权限收窄与输出校验，分层本身不拦任何东西。
• 三层之外的可信度混同工具返回、检索资料与记忆条目与用户输入同属不可信内容，不加标注就与指令混排等于放弃边界。

08在本站知识结构中的位置

所属分组

G00地基：模型是概率采样器

依赖深度

第 1 层（同层节点彼此无先后约束）

在 交互全景图 中定位本节点。