写给后端工程师的提示词工程清单
把提示词当成接口
后端工程师最熟悉的是接口契约：入参是什么、返回什么、出错怎么办。写提示词时用同样的思路，效果会稳定很多。
检查清单
1. 角色与目标写在最前面
一句话说明模型要做什么、给谁用。例如：“你是一个电商客服质检助手，判断客服回复是否违反下列规则。”
2. 输入用明确的分隔符包起来
<conversation>
{{对话内容}}
</conversation>这样可以避免用户输入里的文字被误当作指令，也是防御提示词注入的第一道防线。
3. 输出格式要能被程序解析
要求输出 JSON，并给出字段说明。能用接口的结构化输出（JSON Schema）就用，比在提示词里反复强调“只输出 JSON”可靠得多。
{"violated": true, "rule_id": "R03", "reason": "承诺了无法兑现的退款时效"}4. 给 2～3 个正反例
示例比描述更有效，但不要给太多，否则模型会过度模仿示例的措辞。
5. 说清楚“不知道”时怎么办
明确允许模型返回 unknown，可以大幅减少编造答案的情况。
6. 温度参数按任务选择
抽取、分类类任务用 0～0.2；写作、头脑风暴用 0.7 左右。
让提示词可测试
我会给每个提示词维护一个小的评测集（几十条真实样本 + 期望输出），每次修改提示词或更换模型都跑一遍，比较准确率。提示词改动和代码改动一样走评审流程。
小结
好的提示词不靠玄学，而是靠清晰的契约和持续的回归测试。