晚上十一点，把「请简洁回答」改成「用三句话回答」，输出确实从一段散文变成了三条要点，但原来那句「不要给建议」被挤掉了，回答末尾又冒出一段热心的延伸。改一个词，整体漂移——用过对话式模型的人大概都经历过这种时刻。它说明提示词设计不是在找一句咒语，而是在一个概率系统里做约束。
它更像写需求文档
写需求文档时，难的从来不是写「要什么」，而是写清楚「不要什么」，以及「什么情况算做对了」。提示词也是同一件事。模型不会读心，它只会根据你给的文字去猜一个分布；你没说的部分，它按训练数据里常见的样子补齐。这种补齐通常「看起来合理」，而不等于「符合你的场景」。
所以一条提示词是否站得住，可以问三个问题：约束条件是否可验证，输出形态是否可检查，出错时是否知道往哪儿改。三个都答不上来，那基本是在碰运气。
示例的另一面
给例子通常能让输出贴近预期，但例子的作用常被误解。它不只交代格式，还在暗示内容的粒度、语气和留白程度。副作用是，例子里的偶然特征容易被当成规则复制：你给了一个带表格的示例，模型可能认为所有回答都该是表格；示例里恰好三条，它就倾向于凑三条。
应对办法比较笨但管用——例子覆盖差异，而不是堆数量。一条正例加一条明确标注「这样不行」的反例，往往比五条同构正例承载更多信息。另外把「必须」和「建议」分开写，别让示例替你表达优先级。
格式约束是最容易握住的那部分确定性
如果输出要进入下游程序，格式就不再是风格问题。把结构写死——字段名、层级、空值怎么表示、超出范围怎么处理——能省掉大量返工。这里有个常见疏漏：只说「输出 JSON」，不说字段缺失时填什么。于是模型自由发挥，有时给 null，有时给空字符串，有时干脆省略那个键，解析端只好再加一层兜底。
- 先定字段，再定内容口径；
- 空值、异常、拒答都要有明确写法；
- 要求模型在拿不准时说明原因，而不是硬编一个答案。
上下文不是越长越管用
输出不对时，很多人的第一反应是往提示词里加内容。加到一定程度，早先写下的关键约束会被稀释，模型反而抓不住重点。提示词设计的另一半功夫其实在取舍：哪些信息必须常驻，哪些可以按需检索，哪些干脆交给外部规则判断，不必塞进文字里。
一个实用的自查是：把提示词从头读一遍，能否指出哪几句是「必须遵守」，哪几句只是背景说明。如果自己都分不清，模型大概率也分不清。
有些问题不在提示词里
多轮对话中的指令漂移、对隐含常识的误判、对没见过的格式的笨拙模仿，这些确实能靠改措辞缓解一部分，但缓解不等于解决。模型能力上限、信息本身缺失、任务定义本身模糊，都不是字句能补的。承认这条边界，能省下很多无谓的反复调参。
我自己的习惯是：一条提示词改到第三版还不对，就先停下，回头看任务是不是根本没定义清楚，或者要不要换一种拆解方式，而不是继续打磨句子。
提示词设计的价值，也许不在于写出多精巧的文字，而在于它逼着人把「我到底想要什么」讲清楚。这个过程本身就有回报——无论后面接的是模型，还是同事。