做产品 PMaker
空格的键盘空格的键盘
提示词工程

给例子比讲道理管用

给例子比讲道理管用 | 提示词工程 | 做产品

给例子比讲道理管用

这可能是提示词里性价比最高的一招:**与其用形容词描述你要什么,不如直接给一个「就照这样」的样本。**业内管这叫少样本示例(few-shot)。

你会遇到的现象

  • 你写了「专业、简洁、有亲和力」,它给的东西还是不对味

  • 为了描述清楚想要的风格,提示词越写越长,效果反而更飘

  • 你能一眼看出哪个输出是对的,却说不清标准是什么

为什么例子这么有效

因为形容词是压缩过的信息,而且每个人解压出来的结果都不一样。

「专业」是什么意思?是用行业术语,还是不用?句子该长还是短?要不要称呼对方?出了问题要不要道歉?——你说「专业」的时候,脑子里有一个具体的样子,但那个样子没有传出去。模型只能按语料里「专业」这个词周围最常见的写法来办,也就是取了个平均值。

一个例子就不一样了。看那张图右边:一条示例输入配一条示例输出,里面同时携带了句子长度、有没有称呼、先说结论还是先共情、道歉用什么措辞、要不要给时间承诺——全部隐含要求,一次性传达完毕,而且不会有歧义。

还有一层机制上的原因。模型做的事是延续已有的文本。当它看到「输入 A → 输出 A′」「输入 B → 输出 B′」这样的模式,然后看到「输入 C →」,最自然的延续就是产出一个格式和风格都对齐的 C′。你不是在教它,你是在给它一个模式让它接着往下填。

用形容词描述

「专业、简洁、有亲和力」

满口行业术语 长句、不称呼

口语化短句 先共情再说事

开门见山 不道歉不寒暄

同一个词,三种解压结果 你脑子里那个具体的样子,一个字都没传出去

给一个「就照这样」的样本

输入:用户投诉发货慢 输出:先致歉 → 说明原因 → 给出确切时间

一次性携带的全部隐含要求: · 句子该多长  · 要不要称呼对方 · 先给结论还是先共情 · 道歉用什么措辞 · 要不要承诺时间

2 到 5 个是甜点 一个不够——模型分不清哪些特征必须照做,哪些只是碰巧长这样

务必留一个「材料里没有 → 输出:材料中未提及」的例子,比在限制里写十遍「不要编造」都管用。

你不是在教它,你是在给它一个模式让它接着往下填。也正因如此,例子的偏差会被放大:三个例子都是两句话,它就再也不写三句话的了——多样性要有意识地保持。

给几个、给什么样的

数量:2 到 5 个是多数场景的甜点。

一个例子往往不够——模型分不清哪些特征是「必须照做的」,哪些只是这个例子碰巧长这样。两三个例子之后,共同点就凸显出来了。再往上加,收益迅速递减,而每个例子都在每轮请求里重发一遍,成本是实打实的。

**挑什么样的例子,比给几个更重要。**三条原则:

**一、覆盖不同情况,别都是同一类。**如果你的例子全是简单场景,遇到复杂输入它就懵了。挑一个典型的、一个稍复杂的、一个边界情况。

**二、包含你希望它怎么处理「不知道」的情况。**这一条特别有用。给一个「材料里没有相关信息 → 输出:材料中未提及」的例子,比在限制里写十遍「不要编造」都管用。防幻觉最实在的一招就在这。

**三、例子必须是对的。**听起来是废话,但很多团队的示例是随手编的,格式不统一、甚至本身就有错。模型会忠实地学到那个错。

格式上,把例子和指令用结构分开,每个例子的输入输出用固定标记标清楚。别让模型分不清哪句是例子、哪句是这次真正要处理的输入。

三个陷阱

陷阱一:例子的偏差会被放大。

这是最常踩的。你给的三个例子恰好都是两句话——它就再也不写三句话的了,哪怕这次的输入明显需要更多说明。你给的例子恰好都是负面反馈——遇到正面反馈它可能也按负面的调子回。

模型分不清哪些特征是你有意为之,哪些是巧合。所以例子要有意识地保持多样性,尤其在长度、语气、结论方向上。

陷阱二:分类任务里的顺序和比例效应。

做分类打标时,如果你的例子里有四个是 A 类、一个是 B 类,模型会隐隐倾向于多判 A。同样,例子的排列顺序也会有影响,尤其是最后一个例子。

做法:各类别的例子数量尽量均衡,顺序打散,别把同类的排在一起。

陷阱三:例子成了没人敢动的一坨。

例子一多,提示词就长了。半年后有人想改一条要求,发现改完之后跟某个例子矛盾了,但没人记得那个例子为什么长那样。这属于提示词资产管理的问题,每个例子最好附一句注释:它是为了防哪个具体问题加进来的。

什么时候不该给

例子好用,但不是所有场景都该加。三种情况可以不给。

**一、任务本身极其标准。**翻译、语法纠错这类任务,模型见过的样本比你能给的多得多,例子帮不上忙,只是在烧钱。

**二、你要的是多样性。**做创意发散、头脑风暴时,例子会把它框住——它会不自觉地往你的例子上靠。这种场景反而应该少给例子,把温度调高。

**三、格式已经能被硬约束住。**如果只是想要固定的 JSON 结构,用格式参数强制比塞几个例子更可靠也更省。例子该用来传达风格和判断标准,不是用来凑格式。

最后一条通用建议:**例子该来自真实数据,不该是你现编的。**从你们实际的用户输入里挑几条,配上你认可的标准答案。这既保证了真实性,也顺便成了迭代时的测试样例——这两件事本来就该是同一份东西。

控制输出格式 格式该用硬约束,例子该留给风格和判断标准。

提示词怎么迭代 好例子和好测试样例,本来就该是同一份数据。

参考锚定 同一个道理用在做产品上:给一个具体对照物,胜过十个形容词。