少样本示例
例子是传达格式和判断标准最快的方式。但它会连同你的笔误、不一致和偏差一起学走，所以给之前先挑干净。
在提示词里，例子是传达格式和判断标准带宽最高的一种方式——但代价是它会连同你的笔误、不一致和偏差一起学走。所以给例子之前要先挑，而不是随手凑两条。这套做法官方提示文档也把它列为最有效的手段之一openai-prompt，两家厂商在这一条上口径一致。anthropic-prompt
读完你能回答：
- 为什么一条例子能顶三段形容词，给几条才合适？
- 该挑什么样的，哪些是必须覆盖的？
- 什么样的例子会让输出变差，怎么自查？
一条例子能带出的，形容词说不出口
因为形容词是被压缩过的信息，而且每个人解压的方式都不同。
「语气自然」到底指什么？行业缩写能不能用？句子该长该短？称呼对方还是不称呼？先给结论还是先问缘由？——说出这四个字的时候，你脑海里有一个很具体的画面，可那个画面并没有跟着传出去。它只能按语料里「自然」周边最常见的写法来办，取了个平均值。
换成一条例子，情况就不同了。一条输入对应一条输出，长度、有没有称呼、先讲结论还是先照顾情绪、拒绝时用什么措辞、要不要给一个时间承诺——这些没写出来的要求，一次全部交代清楚。
还有一层机制上的原因。它做的事是延续已有的文本：先看到两条输入和它们各自的输出，再看到第三条输入，最自然的接续就是产出一条风格对齐的结果。你并不是在教它什么，而是给它一个可以照着往下填的模式。 那篇论文把这件事讲得很直白：权重一个都不动，只在上下文里放几条示例，它就能接住一个从没见过的任务。gpt3-paper
顺带说清一个常见疑问：它并不是「记住」了这几个例子。例子只是这一次输入的一部分，跑完就没了，下一轮不带就不会起作用——这是例子和微调最根本的区别。
既然如此，给几条合适？两条到五条是多数场景的甜点。只给一条，它分不清哪些特征是「必须照做」、哪些只是这条碰巧长这样；两三条之后，共同点才凸显出来。再往上加，收益迅速递减——每个例子每轮都要重发一遍，成本是实打实的。
挑哪几条，比给几条更要紧
数量只是下限，选材决定成败。三条原则：
一、覆盖不同情况，别都是同一类。假如挑进来的例子清一色是简单场景，一旦碰上复杂输入它就没了头绪。合理的搭配是：一个典型情形、一个稍难一点的情形、再加一个边界情况。
二、必须包含它怎么处理「不知道」。这一条回报格外高。放一条「材料里查不到 → 输出：材料中无此记录」进去，效果强过在限制条件里反复强调十遍「不要编造」，这是防编造最实在的一招。
三、例子必须是对的。这话听着像废话，可不少团队的示例是随手写出来的：格式前后不统一，有的甚至本身就是错的。它会一字不差地把这个错学走。
格式上用结构把例子和指令分开，输入输出用固定标记标清，别让它分不清哪句是例子、哪句是要求。
这几种活，给例子不如不给
反过来说，有三种情况可以不加例子，加了只是白花钱。
一、任务本身极其标准。把合同里的金额抽出来、把日期统一成一种写法，这类活它见过的样本比你给的多得多，例子帮不上忙。
二、你要的就是多样性。给新功能起名字、想一批宣传语这类活，例子反而会把它框住——它会不自觉地朝你给的那几条靠拢。这时候应该少给甚至不给，把随机性放高一些。
三、格式已经能被硬约束住。只是想让输出严格按给定字段排列，用格式约束强制比塞例子更可靠也更省。例子该传达风格和判断标准，不是凑格式。
例子里的偏差会被原样放大
这是给例子最容易踩的坑，而且踩了之后很难归因——因为你看着例子觉得没问题。
陷阱一：例子的偏差会被放大。你递过去的四条例子，每条都只写了一句话，它就再也不写两句，哪怕这次输入明显需要展开；四条都是拒绝类的口气，碰上一次本来可以批准的，它也可能按拒绝的口吻写。哪些特征是你有意设计的，哪些只是巧合，它区分不了。所以例子要有意识地保持多样性，尤其在长度、语气、结论方向上。
陷阱二：分类任务里的顺序和比例效应。做意图识别时，八条例子里六条标成「退款」，它就会习惯性往退款上判；排列顺序也有影响，尤其是最后一个。做法：各类别数量尽量均衡，顺序打散，别把同类排在一起。
陷阱三：例子格式不统一。这一条最隐蔽。三条例子里两条用「客户说：／我们回：」开头、一条直接写，它就会把这种不一致当成某种规律去模仿，输出的结构开始随机漂移。给例子之前先把格式对齐，一条一条对齐。
交出去之前，自己先看一眼
上面三条陷阱有个共同点：身在其中的时候看不出来。所以别靠感觉，用一个很土的办法过一遍。
把例子单独抄出来，盖住要求、限制和其他所有文字，只看这几条例子本身——一个新人照着它们做，会做出什么东西？
他做出来的东西和你要的一致，例子才算干净。他要是也拿不准，模型同样拿不准；他要是做出来的是另一回事，说明你写的要求和例子在互相打架，先改哪一边得先想清楚。这一步花不了几分钟，但它能在你上线之前把上面三类问题提前暴露出来。
好例子和好测试用例，本来就是同一批东西
最后一条，也是全篇回报最大的一条：例子应当取自真实数据，而不是临时编造。
从真实用户输入里挑几条出来，每条配上你认可的答案。这样做有三层理由：
真实。你自己编出来的例子，往往比你以为的更「顺」——而真实用户输入是残缺的、带错别字的、信息不全的。用编的例子调出来的提示词，一上线碰到真实输入就顶不住了。
有边界。真实数据里天然带着那些难处理的输入。挑的时候刻意留一条信息不全的、一条特别长的、一条格式古怪的，它们覆盖的正是线上最容易出事的地方。
顺带就是测试集。从真实数据里挑出来的这批样本，配上你认可的标准答案，本身就是一组测试用例——挑几条进提示词当例子，剩下的留着跑分。但同一条不能既当例子又当测试，那样等于提前泄题。这批样例还能干一件更要紧的事——判断提示词改动的好坏——怎么用，那篇展开讲。
维护上还有一笔账要提前记：例子写多了，改动会变得很黏手。比如业务上把单笔退款上限从 200 元提到 500 元，你会发现三条例子里都写着 200，得一条条改，还得回头确认有没有漏掉哪条。这属于提示词资产管理的问题，所以现在就给每条例子附一句注释：它当初是为了防哪个问题加进来的。
格式定住之后，还有一件事值得单独处理：输出要被程序读的时候，靠例子凑格式是下策，要机器读的结果就别让它自由发挥 讲的是怎么从根上把格式卡住。