这五种提示词写法看着专业，其实在降低输出质量

提示词圈有一批流传极广的”技巧”。它们的共同点是：写起来很有专业感，实际效果存疑或者干脆是负的。

下面五种是我认为最值得警惕的。

一、堆砌角色设定

你是一位拥有 20 年经验的资深专家，
毕业于世界顶尖学府，曾获得多项国际大奖，
你的分析总是深刻而全面……

问题：这些形容词不携带任何可执行的信息。”20 年经验”不会让模型多知道任何事实，”多项国际大奖”更不会。它们只是占据了上下文，稀释了真正的指令。

改成：说清楚你要什么视角、什么标准。

从代码可维护性的角度审查这段代码。
重点关注：命名是否表意、函数职责是否单一、
边界情况是否处理。不评价性能。

二、”请深呼吸，一步一步思考”

问题：让模型分步推理这个方向没错，但这句话本身太空泛。”一步一步”是哪些步？模型只能自己编一套步骤，而它编的步骤未必是你要的。

改成：把步骤直接写出来。

三、威胁与利诱

这件事对我非常重要，做不好我会失去工作。
如果你做得好，我会给你 200 美元小费。

问题：先不谈效果，这类写法有一个确定的坏处——它占用了上下文，却没有传递任何关于任务的信息。同样的字数用来描述你的实际需求，收益是确定的。

另外，把它写进团队共用的提示词模板里，交接时会很尴尬。

四、把所有约束堆在最后

很多人的提示词长这样：先是一大段任务描述，然后是二十条注意事项。

问题：约束太多、太靠后时，被忽略的概率显著上升。而且这些约束往往互相冲突——”要详细”和”要简洁”同时出现，”要有创意”和”严格按模板”同时出现。

五、用大量示例，但示例本身不一致

给示例（few-shot）是有效的技巧，前提是示例之间必须自洽。

常见错误：三个示例的格式略有不同——一个用了句号，一个没用；一个带了单位，一个没带；一个三句话，一个七句话。模型会从这种不一致里推断出”格式可以自由发挥”，于是输出五花八门。

六、一个共同的判断标准

上面五种的共同问题可以概括成一句话：它们占用了上下文，却没有传递任务信息。

所以判断一句提示词该不该留，问自己：删掉这句，模型会少知道一件关于这个任务的事吗？

• 会 → 留着
• 不会 → 删掉，把位置让给真正有信息量的内容

按这个标准过一遍，多数人的提示词能砍掉三分之一，而效果通常还会变好。