一段需求发给模型，第一次答得像样，第二次就偏了。有人把这种波动归因于运气，或者怀疑模型状态不稳。多数时候，问题出在提示里那些没被写下来的东西。
提示词设计常被理解成“找一句管用的话”。实际工作里，它接近写一份交接文档：对方不熟悉你的上下文，只能依据你给出的文字行动。写交接文档时，含糊的地方会立刻暴露；写提示词时，含糊的地方会被模型的流畅表达盖住，直到结果不对才被发现。
说得多，不等于说得准
形容词堆得越多，约束反而越松。“专业一点”“详细一些”“语气自然”，这些词每个人理解都不同。模型只能猜，猜法每次可能不一样。有效的约束通常很具体：输出分几段、每段回答什么、哪些内容不要出现、遇到信息不足时是停下还是标注。
这里有个不太直觉的点：限制输出范围，往往能让结果变得可用。重点不在于让模型少说话，而在于让它把力气放在确定的地方。
四个容易被漏掉的约束
- 任务边界：要完成什么，明确不做什么。比如“只解释机制，不给出建议”。
- 材料来源：依据哪些输入，材料里没有的怎么处理。是允许推断，还是必须标注缺口。
- 输出形态：结构、长度、称呼、是否需要小标题。形态约束清楚，后期整理省力。
- 判断口径：什么算完成，什么算偏离。写给自己看的那条标准，最好也写进提示里。
这四项可以当作一组检查点，不必固定顺序。不同任务会增减，但漏掉其中任何一项，输出就容易在某个维度上漂移。
给失败留一个出口
很多提示只描述成功路径：给出答案、列出步骤、完成改写。可真实任务里，信息不足、材料矛盾、要求本身含糊才是常态。加一句“如果不确定，说明缺少什么信息”，并不会让模型变笨，反而减少它用看似合理的句子填空。
失败处理也是提示词设计的一部分。它是一开始就承认任务有边界，并非事后打的补丁。把边界写出来，输出才有可核对的基础。
措辞解决不了的那部分
也要承认另一面：有些问题不是提示词能修的。模型没有接触过的信息、输入材料自相矛盾、任务目标在团队内部还没对齐，这些换多少种说法都不会消失。把这类问题归因于提示词设计，容易陷入反复改字却不见效果的循环。
一个可操作的判断是：如果换个人来读这段提示，仍然不知道该怎么完成，那问题在任务定义；如果人读完能执行，模型却频繁跑偏，才轮到措辞和约束继续调整。
提示词设计最终处理的不是“怎么说漂亮”，而是把隐性标准摆到桌面上。写的过程也在逼着写的人确认：自己到底想要什么。这件事听起来简单，做起来常常卡住，原因大概不在模型那边。