把一段需求丢给模型，常见的结果不是拒绝，而是一份看起来顺滑、用起来卡壳的回答：摘要漏掉限制条件，方案有结构却缺执行入口，改写保留了语气却丢了原意。问题未必在模型，而在提示词设计没有把任务边界摆出来。它像写一份可执行的工作说明，而不是寻找一句“神奇咒语”。
先把任务说成可验收的动作
“帮我看看”这类说法留给模型的解释空间太大。把动作换成可验收的表述：从材料中抽取待确认事项、按给定字段整理访谈记录、把长段落改成面向客户的说明。动作一旦具体，输出就有了落点。再补一句交付形态——用短段落、列表还是字段表；哪些信息必须出现，哪些可以省略。提示词设计在这里做的是减法：减少猜的空间，也减少事后返工。
约束不是堆条件，而是做取舍
很多人会把“简洁、完整、专业、口语化、稳妥、有创意”一起写进请求，结果模型只能自行调和冲突。约束需要分层：哪些是硬边界，例如不能编造来源、不能改变原意；哪些是风格偏好，可以随场景调整。与其堆一长串形容词，不如说明“如果信息不足，就标注待确认，不要补写”。这类取舍比华丽措辞有用。
示例说明边界，不要锁死答案
给例子通常能提升稳定性，但例子也可能变成模板。只放一个完整示范，模型容易复制表面句式；给出输入、期望输出和不可接受的方向，反而能说明边界。示例之后再加一句“不要照抄示例中的措辞，只保留结构与信息关系”，能减少机械模仿。对于需要多轮调整的任务，可以要求模型先复述理解，再给初稿；复述偏差时，先纠正理解，再进入改写，往往省力。
上下文要贴近任务
贴一段长材料并不等于提供上下文。与任务无关的背景会稀释重点，关键约束反而被淹没。一种做法是先说明当前场景、输出给谁看、这份内容将用于哪里，再给必要材料；材料很长时，要求模型先列出它识别到的约束，再进入写作。这样做不是让请求变复杂，而是让模型知道该忽略什么。
留一个检查口
把检查项写进请求，是提示词设计里容易被忽略的一步：输出前确认是否覆盖所有约束、是否出现未标注的推测、是否按约定字段组织。它能减少明显疏漏，却不能替代事实核验、权限判断和业务责任。模型可以帮忙整理思路，但“这句话能不能发出去”仍要由人决定。