前阵子帮同事看一个提示词。他把需求写成了一屏半：先定角色，再列七条禁止事项，中间夹三个示例，末尾补一句“务必准确”。跑出来的结果，比他随手敲的两行还偏。他把原因归到模型身上，我倾向另一种解释：那七条禁止事项里，至少有两条在互相打架。
这是提示词设计里最常见、也最难自察的一种失败——麻烦不在于写得不够多，而在于写进去的约束彼此冲突，模型只能自己挑一条来服从。
长度不是问题，冲突才是
冲突长什么样，其实很容易辨认。要求“回答简洁”，又要求“覆盖所有情况”；要求“严格按固定格式输出”，又要求“根据内容灵活调整结构”；要求“不要遗漏细节”，同时限定“控制在三句话内”。人看到这种要求会当场追问一句“到底要哪个”，模型不会追问，它会折中，而折中的结果通常两头都不满意。
还有一种更隐蔽的冲突，来自没写出来的前提。写提示的人脑子里有一幅完整画面：读者是谁、这段话用在哪、上一轮聊到哪儿了。这些留在脑子里的部分，模型只能拿默认值去填。默认值不一定错，只是不由你控制。等到输出不对劲，人会以为是自己“没写清楚”，于是继续加句子，把原本就拥挤的约束挤得更满。
它更像是在划边界，而不是在提要求
我越来越觉得，提示词设计真正在做的事，是把一件模糊的事切成若干可判定的决定，然后指明哪些决定归自己，哪些交给模型。写的时候可以先问三个问题：
- 哪些必须固定——输出格式、长度、语气、能不能举例，哪些允许它自己判断；
- 什么算做完——给一个能检验的判据，而不是“写得再好一点”“专业一些”这类没法验收的说法；
- 卡住时怎么办——允不允许它说信息不足、需要补充，还是宁可它硬编一个答案。
第三个问题经常被跳过，但它决定了输出里会有多少看似笃定、实则凭空捏造的内容。如果提示里没有任何“可以说不”的出口，模型往往倾向于给出一个完整但不可靠的结果。
顺着这个思路看，那些流行的模板结构——角色、任务、约束、示例——本身没什么神秘，它们的作用是把上述决定摆到明面上，免得遗漏。真正费工夫的是删：删掉重复的约束，删掉互相矛盾的措辞，删掉自己也没想清楚却先写进去的要求。加一句很容易，删一句要难得多。
有些问题，提示词设计救不了
也要承认边界。当任务本身没有可判定的完成标准，比如“写得有洞察力”，再精巧的措辞也只是把模糊往后推了一层；当需要的信息根本不在上下文里，提示写得再细，模型也只能猜；当任务需要访问外部数据或执行操作，问题就不在措辞，而在工具和流程。这些情况下继续打磨提示，投入和产出会迅速脱节。
回到开头那位同事。我们最后做的事很简单：把七条禁止合并成两条，删掉一个自相矛盾的示例，在结尾加一句“信息不足时直接说明缺什么”。提示短了将近一半，输出稳定了不少。提示词设计做到最后，往往不是把话说得更漂亮，而是把没想清楚的地方想清楚——这件事，模型替不了你。