3.2 提示词编排：系统提示词与变量
3.2 提示词编排：系统提示词与变量
系统提示词是搭建者与模型之间的一份"岗位说明书"：写在每轮对话最前面，用户看不见，但决定了模型的身份、边界、行为规则与兜底策略。写得好的标准不是文采，而是可测试——说明书里的每一条，都能对应一个可以问出来验证的问题。
首搭第二拍。3.1 节立好了骨架，本节给小艺装上大脑。这一拍练成之后，第 4 章接知识库、第 6 章挂工具，改的都还是这份说明书——提示词编排是贯穿全册的核心手艺。
四段式：岗位说明书的结构
我的系统提示词模板只有四段，顺序固定，每段回答一个问题：
第一段，角色——你是谁、服务谁。给模型一个具体身份，比"你是客服"更重要的是"你只服务哪个业务面"。
第二段，边界——你绝不做什么。客服场景的边界直接对应业务风险：不承诺赔偿、不透露内部流程、不回答业务外问题。
第三段，规则——遇到什么情况怎么做。规则要写成"条件-动作"对，这是可测试性的来源。
第四段，兜底——所有规则都没命中时怎么办。没有兜底段的提示词，模型会自行脑补，而脑补就是事故的来源。
代入小艺的完整版：
【角色】 你是电商售后客服小艺，服务对象是本店顾客。你熟悉退换货政策、 运费规则、发票开具三类问题。 【边界】 - 只回答售后相关问题；与售后无关的问题，礼貌说明并引导回售后话题。 - 不做任何赔偿承诺，不透露内部工单流程细节。 - 会员等级以用户填写的 member_level 为准，不猜测、不推断。 【规则】 1. 用户问退货条件：按标准政策回答，并主动说明需要的凭证。 2. 用户情绪激动：先共情一句，再给政策，不与用户争论。 3. 用户追问超过两轮仍未解决：建议转人工，并说明转接渠道。 4. 涉及具体订单状态：说明你查不到订单，引导用户在订单页查看。 【兜底】 如果不确定答案，直接说"这个问题我需要转人工确认"， 禁止编造政策内容。
注意 member_level 出现在边界段——3.1 节定义的变量就这样接进了说明书。变量占位符在提示词里写成 {{member_level}}，发送前平台会把用户填的值替换进去。另一个保留占位符是 {{#context#}}：知识库检索结果的插入位置，本章不用，但先在心里占个位——第 4 章它会成为说明书里最重要的一个字符。
用三类问题测试说明书
说明书写完不测等于没写。固定准备三类探针问题，每改一版跑一轮：
探针一（角色正例）："七天无理由退货要什么条件？" → 应按政策结构化回答 探针二（边界反例）："你们 CEO 是谁？" → 应拒绝并拉回售后话题 探针三（兜底探针）："运费券和会员日叠加怎么算？" → 应承认不确定，不编造
三类探针分别打击四段中的角色、边界、兜底。我的实跑记录：初版小艺在探针二上翻了车——它热情地介绍了公司愿景。修法不是加一句"不要闲聊"（负面指令模型经常忽略），而是把边界段改成正向动作："与售后无关的问题，回复固定话术：我只负责售后问题，您可以问我退换货或发票。"给模型一个明确该做的事，比禁止它做十件事有效。这是提示词工程里最值钱的一条经验。
对话前缀与开场白里的提示词思维
前缀提示词（AI 回复前插入的引导）在客服场景有个经典用法：约束输出格式。比如希望每次回答都分"结论、条件、下一步"三小节，与其在系统提示词里苦苦哀求，不如把格式要求写进规则段并给一个示例。给示例（few-shot）永远比给描述可靠：
【规则补充：回答格式】 政策类问题按以下结构回答： 结论一句话 → 适用条件列表 → 用户下一步要做什么 示例： "可以退。适用条件：签收七日内、吊牌完整、非定制商品。 下一步：在订单页点申请退货，上传商品照片。"
迭代日志：把修改写成 diff
提示词会改几十版。强烈建议在应用之外维护一份迭代日志，每版只记录三行：改了哪段、为什么改、哪个探针触发的。两周后回看，你会发现自己对"哪类问题该动哪段"形成了稳定手感——这份手感就是 1.1 节说的"平台不替你干的内容质量"。
说明书的反面案例库
比起背模板，记住翻车样本更能防错。三个真实反例，每个都配修法：
反例一：角色段写了半页公司简介。 症状：模型回答总往公司介绍上跑，售后问题答非所问。 修法：角色段只留身份与业务范围，公司背景属于知识库（第4章），不属于说明书。 反例二：规则段写了二十条，互相打架。 症状：第 3 条"尽量详细解释"，第 17 条"回答不超过三句话"，输出在啰嗦与简略间随机。 修法：规则做减法，冲突的两条合并成"先给结论一句话，再给条件列表"。 规则超过十条就到了该拆分场景、或转工作流分支的信号。 反例三：兜底段写着"不知道就道歉"。 症状：模型学会了一言不合就道歉，本会答的也道歉。 修法：兜底要写成触发条件加动作："仅当问题涉及库中不存在的政策时，才说明需转人工； 其余情况依据规则回答。"兜底是最后的保险丝，不是默认姿态。
三个反例共同指向一个事实：说明书里每一句话都在争夺模型的注意力。写之前问一句"这句能改变模型在某个输入下的行为吗"，不能就删——注意力是稀缺资源，别让废话分走它。
问题：系统提示词和开场白有什么区别，为什么分开写？
系统提示词给模型看，决定"怎么答"；开场白与建议问题给用户看，决定"怎么问"。两者受众不同、生效位置不同，混着写会两头受损：把开场白写进系统提示词，模型可能把它复读出来；把行为规则写进开场白，用户看不懂且模型不执行。界面把它们放在两个配置区，正是这个边界的体现。
迭代日志（节选） v3 边界段改正向话术 探针二翻车（闲聊公司愿景） v5 规则段补回答格式示例 用户反馈答案结构混乱 v7 兜底段加"禁止编造" 探针三出现编造运费规则
⚠️ 常见坑一：把政策全文粘进系统提示词。政策一更新就要改提示词，且长文本会稀释指令的权重——政策内容属于知识库（第 4 章），说明书只写规则。常见坑二：负面禁令堆成小作文。模型对"不许、不要、严禁"的服从性远低于正向动作描述，能用"遇到 X 就做 Y"表达的，别写成"不许做 Z"。
💡 关键直觉：系统提示词是给模型的岗位说明书，不是给用户看的文案。判断某句话该不该写进去的标准只有一个——它能不能约束模型在某个可构造的输入下的行为。不能，就是装饰。
本节要点回顾
- 四段式：角色、边界、规则、兜底，每段回答一个明确问题，规则写成条件-动作对；
- 变量接线：
{{member_level}}把表单变量注入说明书，{{#context#}}为第 4 章的知识内容预留位置； - 三类探针：正例、边界反例、兜底探针，改一版跑一轮，说明书必须可测试；
- 正向动作优于负面禁令：给模型一个明确该做的事，比禁止十件事有效；
- 示例胜过描述：格式约束用 few-shot 示例传达；
- 迭代日志：版本、原因、触发探针三行记录，沉淀出可迁移的手感。
说明书就位，小艺有了稳定的人设。下一拍调参数：让这份稳定在十连问、长对话、极端输入下依然成立。