少样本提示（few-shot）怎么写？给几个例子最好
few-shot 提示词，就是在给模型下指令时，顺手附上几个”输入→输出”的示范例子，让模型照着例子的格式和风格来做你真正的任务。 它和直接下命令（zero-shot）最大的区别，就是多了”演示”这一步——你不光告诉模型要什么，还当场示范一遍。
这篇讲清楚：为什么给例子能让输出变稳，例子给几个合适、怎么挑，以及哪类任务最该用 few-shot、哪类其实不用。读完你就能把那种”每次结果都不一样”的提示词，调成稳定可交付的。
为什么需要 few-shot
很多人写提示词只写一句指令，比如”帮我把这些客户反馈分类”。模型确实会做，但常出两类毛病：
- 格式飘：这次输出 JSON，下次输出大白话，下游程序没法解析。
- 理解偏：你心里的”分类标准”和模型猜的不一样，分得驴唇不对马嘴。
光靠文字描述标准，往往说不清楚——有些规则你自己都讲不全，但一举例就明白了。few-shot 的价值就在这：用例子替代啰嗦的规则说明，让模型从样例里”反推”出你要的模式。这在 提示词的六大策略（规划中）里属于最立竿见影的一招。
few-shot 是怎么工作的
可以把它理解成”带着标准答案进考场”。模型没有真的”学习”你的例子（参数不变），而是在这一次对话里，把你给的样例当成临场参照，模仿它的模式来处理新输入。
典型的 few-shot 提示词长这样：
任务：判断下面这句话的情绪（正面/负面/中性）
示例1：
输入：这家店服务太差了，再也不来
输出：负面
示例2：
输入：东西还行，价格一般般
输出：中性
示例3：
输入：物流超快，包装也很用心，好评！
输出：正面
现在请判断：
输入：客服回复慢，但问题最后解决了
输出：
模型看到前三个示范，就明白了：输出只能是三个词之一，不要解释、不要多话。这正是单靠文字指令很难一次说清的。
给几个例子最好？怎么挑？
这是 few-shot 最实操的问题。给判断口诀：
| 例子数量 | 适用情况 |
|---|---|
| 1 个（one-shot） | 任务简单，主要是为了固定输出格式 |
| 2–5 个 | 大多数场景的甜区，覆盖主要类别即可 |
| 6 个以上 | 类别多、边界模糊的任务，但收益递减、还费 token |
挑例子比堆数量更重要，三条原则：
- 覆盖典型类别：每个你关心的输出类别，至少给一个例子。只给正面例子，模型对负面就抓瞎。
- 包含边界样例：把那种”容易判错的、模棱两可的”也举一个，告诉模型你在这种情况下到底想怎么处理。
- 例子本身必须正确：模型会忠实模仿。例子里有一个错的，输出大概率跟着错——这是最常见的翻车点。
还有个细节：例子的格式要和你期望的输出严格一致。例子里输出是纯 JSON，正式任务就别混排版；例子里带了多余的”输出：“前缀，模型也会跟着带。想把格式钉死，再配合 结构化提示词（规划中）的写法效果更好。
哪类任务适合 few-shot
few-shot 最适合”格式固定、有明确模式可模仿”的任务：
- 分类打标：情绪/意图/工单类型，类别就那么几个。
- 格式抽取：从一段文字里抽出固定字段，套成你要的表格或 JSON。
- 风格仿写：让文案对齐某种语气、某个模板，给两篇范文模型就上道了。
- 数据清洗/改写：把杂乱输入规整成统一格式。
反过来，这几类不太需要 few-shot：
- 开放生成（写一篇文章、出创意）：例子反而会把模型框死，不如把要求讲清楚。
- 复杂推理：与其堆例子，不如让模型”分步想”（chain-of-thought），效果通常更好。
- 任务极简单：一句话能讲明白的，直接 zero-shot，别浪费 token。
判断口诀：要的是”照模子来”就用 few-shot，要的是”放开想”就别用。
两个容易被忽略的坑：顺序和 token 成本
例子选对了，还有两个变量能让效果差一截，很多人调了半天提示词都没意识到问题出在这。
第一个坑：例子的顺序会影响输出。 模型对”最后一个例子”和”离当前输入最近的例子”更敏感，这叫近因效应。如果你把最典型、最标准的例子放在最前面，把边界样例放在最后面紧挨着真实输入，模型反而更容易在边界情况上”抄”这个边界例子的判断逻辑。反过来，如果顺序随意排，比如把三个正面例子挨在一起、最后才出现一个负面例子，模型有概率被”带偏”，倾向于把接下来的输入也判成正面——这在分类任务里尤其明显。实操建议：例子顺序按”从典型到边界”排列，同类别的例子别扎堆放在一起，交替着放（正面、负面、中性、正面、负面），减少模型顺着”惯性”往同一个类别猜的倾向。如果你发现模型总把某类判错，先别急着改例子内容，试试只调换顺序，往往立竿见影。
第二个坑：例子越多，token 成本越高，而且是每次调用都要付费重复付。 few-shot 不像微调，例子不会被模型”记住”，你每发一次请求，这几个例子就要连着输入一起发一遍。假设你的 5 个分类例子加起来 300 字，按 GPT-4 级别模型输入价格算，一天调用 1 万次，仅这部分例子就要多传 300 万字符的重复内容——这笔账在做客服工单分类、批量内容审核这类高频调用场景里，一个月下来可能是几千到上万元的额外支出。两个省钱思路：一是把例子精简到刚好覆盖类别边界，别为了”保险”堆到 8 个、10 个；二是如果调用量真的很大（日调用量上万次），认真评估要不要转向微调（fine-tuning）——把这几个例子对应的几百到几千条标注数据喂给模型做一次训练，之后每次调用就不用再带例子了，长期反而更省。
few-shot 和微调，到底怎么选
这是很多人卡住的地方：例子效果不稳定，第一反应是”要不要干脆微调一个模型”。给你一个简单的判断框架：
| 维度 | few-shot | 微调 |
|---|---|---|
| 启动成本 | 几分钟写好例子就能用 | 要准备至少几百条标注数据，训练+验证有周期 |
| 调用成本 | 每次调用都要带例子，量大了累积贵 | 训练完之后调用不带例子，单次更便宜 |
| 迭代速度 | 改个例子立刻生效 | 改规则要重新训练，周期以天计 |
| 适合阶段 | 任务刚起步、规则还在探索 | 任务规则已经稳定、调用量足够大 |
| 数据要求 | 3-8 个例子够用 | 通常要几百条以上高质量标注 |
经验判断：如果你的任务规则还在变、调用量一天几百次、团队里没人专职维护模型训练流程，老老实实用 few-shot，别折腾微调。如果任务规则半年没变过、日调用量上万、团队有资源做数据标注和模型迭代，那微调能省下真金白银的 token 成本，也能让输出更稳（不受例子顺序、例子选择这些”玄学”因素干扰）。大部分团队其实卡在中间：先用 few-shot 把规则和例子跑顺、跑稳定个把月，等规则真正定型、调用量真正起来了，再考虑微调——这也是从”能用”到”好用”最稳妥的路径，别一上来就想着微调，容易在规则没摸清楚之前就把钱和时间砸进去。
怎么落地：从单点到团队规范
个人用 few-shot 很简单，难的是让一个团队都按统一标准用 AI。当客服、运营、市场各写各的提示词，例子东拼西凑，输出质量就没法管控。
成熟做法是把高频任务的提示词（含挑好的例子）沉淀成团队模板库，谁用都从模板起步，而不是从零写。这其实是管理者要操心的事——不是教大家用某个工具，而是把”好提示词怎么写”变成组织能力。这块系统的方法，可以看 管理者如何用 AI 和 AI 时代的组织变革。
常见问题
问：few-shot 和 zero-shot 到底差在哪，什么时候该升级到 few-shot？ zero-shot 是只给指令不给例子，few-shot 是额外给几个示范。当你发现 zero-shot 输出格式不稳、或理解偏差大，就该加例子升级到 few-shot——这是最省力的提效手段。
问：例子是越多越好吗？ 不是。2–5 个通常就够，再多收益递减还多花 token。关键看例子选得好不好——覆盖典型类别、带上边界样例，比单纯堆数量有用得多。
问：为什么我加了例子，输出反而更乱了？ 大概率是例子本身有问题：格式不统一、含有错误示范、或类别覆盖不全。模型会忠实模仿你给的样例，例子里的瑕疵会被放大。先检查例子，再加数量。
问：few-shot 会让模型真的”学会”我的任务吗？ 不会。它只在当次对话里参照例子，不改变模型本身。换一段对话，这些例子就”忘了”。要长期复用，得把提示词和例子存成模板，每次带上。
👉 看看 AI 时代的组织与管理 专栏，或了解 AI 时代管理者认知课。需要定制落地与陪跑，欢迎聊 企业服务。