有人把提示词设计说成「会说话就行」。真到项目里，这句话通常撑不过第二轮。模型输出偏了，团队第一反应是换个更聪明的模型，或者把指令写长一点。可很多时候，问题出在需求本身没有被拆清楚——提示词只是把模糊暴露了出来。
难题一：你想要的，和你写下的，不是一回事
一个常见的场景是让模型整理会议纪要。写下的指令是「总结要点，简洁明了」。跑出来的结果看着像样，但没人能用：该保留的决定被压成一句话，责任人和时间点消失了。
问题不在于「简洁明了」这个词不够精确，而在于它描述的是风格，不是内容边界。提示词设计在这里要做的，是把「要点」翻译成可判断的条件：哪些信息必须出现，哪些可以删，长度限制针对的是句子还是条目。
这一步往往比写指令本身花时间。因为它逼着人先回答：这份纪要到底是给谁看的，看完要做什么。答不上来，提示词怎么写都会漂。
难题二：约束越多，模型越容易顾此失彼
另一个反复出现的情况是约束堆叠。要求输出用 JSON、不超过三百字、语气正式、覆盖五个方面、不能出现某个词。单看每条都合理，合在一起就互相挤压。模型可能为了守住格式而牺牲内容，也可能为了覆盖全面而把每条都写得很薄。
有经验的做法不是继续加规则，而是分出层次：哪些是硬约束，违反了就不可用；哪些是偏好，可以让步。提示词设计里，这个分层比措辞技巧重要得多。把硬约束放在前面、写清楚，把偏好用「尽量」「优先」这类词标出来，模型才能知道冲突时该保什么。
这也解释了一个现象：同一段提示词，在不同任务上表现差别很大。不是提示词本身变差了，而是约束之间的紧张程度变了。
难题三：验收标准如果说不清，提示词永远调不完
调提示词最耗人的阶段，是「感觉还差一点」。输出不差，但说不上哪里不对，于是反复改措辞，改完再看，还是差一点。
这种情况通常不是语言问题，而是缺少验收标准。如果团队事先没定义「合格输出长什么样」，那么每一次调整都只能凭印象判断，提示词设计就变成了猜谜。反过来，只要能把几条可检查的标准写下来——比如必须包含哪几类信息、禁止出现哪类表述、结构上分几段——调整就有了方向，也能判断什么时候该停。
值得注意的是，验收标准不必很复杂。它更像一张检查清单，而不是评分表。清单越具体，提示词越容易收敛。
哪些部分无法靠模板解决
市面上流传着大量提示词模板，结构工整，套上去也像那么回事。但模板能提供的，主要是格式和常见套路。真正决定效果的，仍然是对任务的理解：知道输出会被谁使用、在什么环节被检查、出错代价有多大。
换句话说，提示词设计不是一次写完的文档，而是随着对任务理解加深不断修订的过程。第一版通常只是把想法写下来，第二版才开始补边界，第三版可能要做减法。
还有一个容易被忽略的边界：有些任务不适合靠提示词解决。需要精确计算、需要访问实时数据、需要稳定复现的场合，把压力全放在指令上，往往事倍功半。承认这一点，比继续打磨措辞更实际。
回到最初那个说法。会说话确实有帮助，但提示词设计更像写一份给陌生人的工作说明：对方不知道你的背景，不会追问，只会照字面执行。写的人越清楚自己要什么，这份说明就越短，也越管用。