何时使用
需要把一段会反复执行的提示交付固化为稳定可复用的模板(含角色、约束、示例、输出格式),并以可对比方式迭代优化时使用。
该用:同一任务要跑多次/多输入、要求输出结构一致、需要团队或多 Agent 复用、想用 few-shot 稳定行为、需要可回归地改进效果。
不该用:一次性临时提问(直接写就好,别建模板);任务本身没想清楚(先用 first-principles-thinking 拆解目标再来);问题应靠检索/工具/代码而非提示解决(如取实时数据、精确计算);只是改 1~2 个词的微调。
步骤 / 指令
1. 定义契约
- 任务目标(一句话)、输入变量集 {var1, var2...}、输出 schema(字段+类型+约束)
- 成功判据:3~5 条可判定的验收点(用于后续评测)
2. 搭骨架(按固定段顺序,缺省段省略而非留空)
[ROLE] 角色+能力边界,越窄越好
[CONTEXT] 背景与已知事实,注入处用 {var} 占位
[TASK] 明确动作指令,一次只让它做一件事
[RULES] 约束清单:必须做 / 禁止做 / 边界情形如何处理
[FORMAT] 输出格式:JSON schema / 模板串 / 字段顺序,给出"仅输出X,不要解释"
[EXAMPLES] few-shot:2~4 个覆盖正常+边界+易错的输入→输出对
[INPUT] {待处理输入} 放最后
3. 占位与防注入
- 所有可变内容用显式占位符 {name},并用分隔符(如 <input>...</input>)包裹用户数据
- 指令与数据分离:用户输入不得改写 RULES/FORMAT
4. 选 few-shot 示例
- 覆盖:典型例 + 至少 1 个边界例 + 1 个易错/反例(标注期望处理)
- 示例输出严格符合 [FORMAT];示例数从少到多,够稳即止
5. 评测与迭代(每次只改一个变量)
- 准备 5~10 条评测输入(含已知难例)
- 跑模板 → 对照成功判据打分 → 定位失败模式
- 按优先级修补:先收紧 RULES,再补/换 EXAMPLES,最后调 ROLE/FORMAT
- 每次改动记 version 与差异,保留可回滚版本
6. 冻结
- 通过判据后固化为 vN,记录:变量清单、输出 schema、已知失败模式与规避
修补对照(失败模式 → 动作):
- 格式跑偏 → 强化 [FORMAT],加"仅输出 JSON,无前后缀",补一个格式示例
- 漏边界/答错难例 → 加对应 few-shot 反例并标注期望
- 越权发挥/废话 → 收窄 [ROLE],在 [RULES] 加"未知则输出 null,不臆测"
- 受输入劫持 → 强化指令/数据分离与分隔符
- 不稳定/随机 → 降随机性、增确定性示例、把隐含规则显式化
示例
最小可用模板(情感分类,输出 JSON):
[ROLE] 你是中文短文本情感分类器,只做分类,不解释、不续写。
[TASK] 判断 <input> 的情感倾向。
[RULES]
- 取值仅限:positive | negative | neutral
- 含讽刺时按真实意图判定
- 信息不足或非情感文本 → neutral
- 仅输出 JSON,无任何额外文字
[FORMAT] {"label": "<positive|negative|neutral>", "confidence": <0~1 两位小数>}
[EXAMPLES]
输入:这服务太"贴心"了,等了俩小时 → {"label":"negative","confidence":0.88}
输入:包装完好,按时送达 → {"label":"positive","confidence":0.80}
输入:明天会下雨 → {"label":"neutral","confidence":0.90}
[INPUT]
<input>{user_text}</input>
调用时仅替换 {user_text};评测时换不同 <input> 跑 5~10 条,按"取值合法/难例正确/仅输出 JSON"打分后迭代。
注意事项
- 单一职责:一个模板只解决一类任务;多任务请拆成多个模板串联,别堆叠。
- 指令与数据必须分离:用户内容一律放占位符并用分隔符包裹,RULES/FORMAT 不可被输入改写,防提示注入。
- 示例即契约:few-shot 输出必须与 [FORMAT] 完全一致,错示例会直接污染产出。
- 一次只改一个变量:否则无法归因效果变化;每版留 version 可回滚。
- 不要无脑堆示例/堆约束:token 有成本,够稳即止;冗余规则会相互冲突。
- 跨模型不保证可移植:换模型需重跑评测,输出格式遵从程度差异大。
- 留逃生口:为"信息不足/无法判定"显式定义输出(如 null / neutral),避免模型臆造。
互见
- requires:
first-principles-thinking—— 建模板前先用它把任务目标、输入输出契约与成功判据拆清楚,否则模板会固化错误的问题定义。