设想一个常见场景：你打开内部问答工具，输入“请总结这份材料，给出建议”，模型很快返回一段结构完整的话，却没有抓住真正要解决的问题。多数时候，不是模型突然变笨，而是提问里缺少任务对象、使用场景和验收标准。这个场景里，提示词设计更像把模糊需求翻译成可执行任务，而不是寻找一句神奇咒语。
先把“帮我看看”改写成任务
“帮我看看”不是任务，只是请求。任务至少要交代：处理什么材料，完成什么动作，结果给谁看，什么情况算完成。比如把“分析一下访谈记录”改成“从访谈记录里找出用户提到的流程堵点，每条附一句原文依据，按流程环节归类”，模型才知道该找什么、怎么组织。这里不必追求华丽措辞，信息密度比修辞重要。
上下文不是背景板，约束也别堆成墙
提供上下文时，要区分事实、假设和指令。把“这是背景”与“这是要求”混在一起，模型容易把叙述当成命令。约束方面，格式、长度、语气和禁止项都可以写，但不必一次写满。约束太密，反而互相打架：既要简短，又要覆盖所有细节，就需要先说明优先级。我的判断是，约束应该围绕验收标准展开，而不是为了显得严谨。
示例有用，但别让示例替你思考
给一两个输入输出样例，能帮助稳定风格和结构；示例过多，模型可能模仿表面格式，忽略新任务里的差异。比较稳妥的顺序是，先写清任务和验收，再补一个最小示例。这里也牵涉提示词设计的边界：它不能弥补需求本身没想清楚，更不能替代对业务规则的理解。
把调试留在流程里
提示词改了以后，不能只看一次回答顺不顺眼。留一组固定问题，覆盖常见输入和边界情况，改完就重跑，记录哪类错误减少、哪类被引入。这样做不复杂，却能避免凭感觉反复改句子。提示词设计更像版本管理：每次改动对应一个明确问题，而不是把措辞调得更“高级”。
我更愿意把提示词设计看成一份可修改的任务说明。它不保证一次答对，但能让错误有迹可循：是输入没给全，还是约束冲突，抑或验收标准含糊。改到这一步，再讨论模型能力，判断会踏实一些。