一段指令看起来写得很完整，模型却答偏了。常见反应是继续加形容词：严谨、简洁、贴合业务。问题往往不在形容词，而在任务没有落到可执行的动作和可验收的产物上。提示词设计要先处理这件事：让模型知道它要交付什么，以及什么算完成。
先把任务写成动作和产物
很多提示词开头先设定角色、背景和语气，却把“做什么”放在后面。模型会抓住显眼信息，背景过长时，核心任务被稀释。可以把任务改成动词加产物：归纳争议点、列出待确认项、把会议记录整理成行动清单。角色可以保留，但它不能替代任务说明。若需要固定格式，就给出字段、顺序和空值处理方式；若允许自由发挥，也要说明哪些部分不能改。
约束要能被检查
“专业”“自然”“有洞察”这类要求，人和模型理解不一致，输出后也难以判断。可检查的约束通常写成具体条件：每段先给结论；引用原文时标明位置；不确定的信息单独列出；不引入输入中没有的事实。约束过多会互相冲突，比如既要求简短又要求覆盖所有细节。把必须遵守的规则和可调整的偏好分开，写在同一段里会让模型难以取舍。
- 必须项：输出语言、字段、禁止项、事实来源边界。
- 偏好项：语气、篇幅、举例数量、展开程度。
- 异常项：信息不足时如何提问，无法判断时如何标注。
示例用来划边界
示例常被当作装饰，其实它承担边界说明。只给一个正面样例，模型可能复制表面措辞；再给一个反例，说明哪些输出不接受，边界才有着落。示例宜短，覆盖关键差异，避免塞入无关信息。多轮对话中，还要说明哪些历史信息继续有效，哪些只作背景。提示词设计在这里接近接口契约：输入是什么，输出是什么，异常怎么处理，都要有交代。
把维护成本算进去
一段提示词起初能跑通，后续不断加需求，很容易变成层层补丁。保留版本和变更原因，把稳定规则与临时要求分开，每次只改一个变量，观察输出是否按预期变化。不要用一段超长提示词包打所有任务；按场景拆分，定位问题会省力。提示词设计不是一次性写作，而是持续校准。它不神秘，也不万能，价值在于把模糊意图变成可讨论、可修改的说明。