3.1 系统提示的结构化设计

3.1 系统提示的结构化设计

本节摘要：系统提示是指令成分的骨架，也是常驻税的第一大户——每轮全额支付、占据窗口最前的黄金位置（2.2 节）。本节给它一套结构模板：角色 / 边界 / 工具 / 输出契约四块，分别回答模型必须知道的四个问题——你是谁、什么不许做、有哪些手段、交什么货。每块配写作规则：角色一句话定位不堆形容词；边界里"禁止项比必须项更防错"；工具块说明何时用哪个（这是模型最常缺的信息）；输出契约要可校验（格式、语言、长度写成机器能检查的断言）。模板之后是管理：系统提示是代码不是文案——唯一真相源、版本号与变更记录、改动必须过评测回归、变量注入显式化，四条纪律缺一不可。最后用常驻税视角算长度账：系统提示不是越长越安全，每多一行都是每轮重复支付的开销。

学习目标

阅读完本节，你应当能够：

1. 用四块模板写出一个完整的结构化系统提示。
2. 说出每块的两三条写作规则及其理由。
3. 为团队的系统提示建立版本化管理（目录、纪律、评测挂钩）。

一、系统提示在四成分中的位置

先归位：系统提示属于指令成分——开发者写、全程常驻、设计期裁剪（1.2 节）。它的三个身份决定了本章的手法：

• 权威性最高：模型对系统提示近似逐字服从，且它位于窗口最前（位置红利，2.2 节）——所以改一个字都值得评审。
• 常驻税第一大户：1,000 token 的系统提示在 40 轮会话里就是 40,000 token 的累计输入——每多写一句话，都是每轮重复付的钱。
• 动态信息的禁地：当前时间、今日库存、会话状态都不许写死在这里（1.2 节的职责错位病）——那是素材与记忆的辖区。

二、结构模板：四块各答一问

模型带着四个空白进入会话：我是谁？什么不能做？我有什么手段？我要交什么货？系统提示的四块恰好各答一问：

一个完整模板（承接 0.1 节的客服任务）：

system_prompt.md —— 退款客服系统提示模板（写法示意，以自家产品为准）

【角色】你是某电商的退款客服助手，服务中文用户；
你能查订单与政策，不能代表公司做出政策外承诺。

【边界】
- 必须：先核对订单，再引用政策条款，最后给结论
- 禁止：承诺 7 天无理由之外的退款；索取密码或验证码；
  讨论与退款无关的话题
- 升级：用户情绪激动或涉及金额超过 5000 元时，调用
  transfer_to_human 转人工

【工具】
- get_order：用户给出订单号或能定位到订单时用；其他
  信息不足时先用 search_user 定位用户
- get_policy：回答政策问题前必查，禁止凭记忆复述政策
- create_refund：仅在结论为"符合条件"且金额核对一致时调用
- transfer_to_human：见升级条件

【输出契约】
- 对用户：中文，两句话以内，先结论后理由
- 内部决策：单行 JSON：
  {"decision":"approve|reject|escalate","reason":"<政策条款编号>"}
​

三、每块的写作规则

角色：一句话定位，写"能做什么的边界"而不是气质形容词——"你能查订单与政策，不能做政策外承诺"比"你是专业的资深专家"信息量高一个量级。

边界：禁止项比必须项更防错。模型的默认倾向是"有求必应"，必须项它大体做得到，翻车几乎都翻在禁止项没写（多承诺一天、多说一句政策外的话）。红线约束写在这里，同时按 2.2 节的推论在最近的用户消息末尾复述。

工具：这是模型最常缺的信息。schema 告诉模型工具"是什么"，用法块告诉它"何时用、先查哪个、什么组合"——两条相近工具的取舍规则（先 search_user 还是先 get_order）只在这里说得清。3.2 节会讲 schema 侧的写法，两处配合。

输出契约：每一条都写成可校验的断言——"单行 JSON，字段 decision 取三个枚举值"是机器能检查的；"输出规范得体"是检查不了的。契约可校验，下游才能自动验收，出问题才能定位是模型没读懂还是没遵守。

💡 可选第五块——少样本示例（few-shot）：对格式类问题（JSON 输出、工具调用搭配）一两个示例常常胜过十行描述；但示例是按 token 计的常驻开销，只在契约难以用规则描述时使用，并控制在两三个以内（示意）。

四、版本化管理：把系统提示当代码

系统提示是系统里被引用最多的"配置"，却没有配置的待遇——散落在代码字符串里、被复制成三份、改了没人知道。四条纪律：

prompts/
└── refund_agent/
    ├── v12.md            ← 当前生效版本：唯一真相源
    └── CHANGELOG.md      ← v11→v12：边界块新增"禁止索要验证码"，动机：安全评审 #47
​

1. 唯一真相源：系统提示只在一个文件里，运行时加载；代码里内嵌的字符串副本一律清剿。
2. 版本号与变更记录：每次修改记一行——改了哪块、为什么、谁批准；生产事故排查时，"当时是 v 几"是第一个要回答的问题。
3. 改动过评测：v12 上线前跑一遍固定评测集（哪怕只有 20 条问句），对比 v11 的通过率——系统提示的改动是高风险变更，不配走"改完即发"。评测集的构建属于评测话题，本书不展开。
4. 变量注入显式化：需要拼接动态信息（如用户等级）时，用显式的模板变量 {{user_tier}} 并在组装层填充——绝不在字符串里悄悄拼接，那会让"哪段是静态指令、哪段是动态数据"永远查不清（这正是 1.2 节三问要能回答的）。

⚠️ 安全红线两条：系统提示里永远不放密钥、token 与内部端点（它可能被诱导泄露）；面向消费者的产品要假设系统提示终将被人读到，不放不愿公开的内容。

五、长度预算：常驻税视角的性价比

系统提示不是越长越安全。设 2.1 节的分配表给指令 4%（128k 窗口即约 5k token）：模板四块约 600~1,500 token（示意），剩余空间装少样本与专项规则。超长的系统提示有两个反作用：每轮多付的 token 是线性放大的成本；条目多到彼此稀释后，模型对单条规则的服从率反而下降（1.1 节的注意力稀释同样发生在指令内部）。纪律：写不进 5k 的规则，就该问它是不是真的属于指令——很多"规则膨胀"其实是素材（该检索）或记忆（该跨会话存）走错了门。

本节要点回顾

1. 四块模板：角色（一句话定位）、边界（禁止项优先）、工具（何时用哪个）、输出契约（可校验断言）——各答模型的一问。
2. 写作规则：少形容词多边界；用法说明是模型最缺的信息；契约必须机器可检查。
3. 版本化四纪律：唯一真相源、变更记录、改动过评测、变量注入显式化。
4. 安全红线：不放密钥；假设会被读到。
5. 长度账：常驻税视角下每行都是每轮的钱；装不下的规则该回 1.2 节查成分错位。

指令成分定型了。常驻层的另一半藏在每次请求的 tools 参数里——那份模型要逐字读的"API 文档"，绝大多数团队从未审计过它的 token 成本与选择代价。下一节审它。