给例子比讲道理管用

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

为什么例子这么有效

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

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

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

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

给几个、给什么样的

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

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

挑什么样的例子，比给几个更重要。三条原则：

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

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

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

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

三个陷阱

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

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

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

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

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

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

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

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

什么时候不该给

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

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

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

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

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