Few-shot 示例怎么写，才不会把模型教偏

我从一次翻车说起

去年给一个电商客户做意图分类，我把 Prompt 写好，跑了 50 条测试集——准确率 92%，挺满意。上线第三天，客诉群炸了：一大批「还没发货但想改地址」的请求被模型归到了「催发货」。

排查下来不是指令写得有问题，是示例出了问题。我给的五条示例里，四条是「催发货」和「退款」，没有一条覆盖「改地址」。模型从示例里学到的潜台词是——只要提到订单状态，大概率是催发货。

这件事让我意识到一个被低估的事实：Few-shot 示例不是装饰，它是你喂给模型的「参考答案」。你给什么答案，模型就学什么标准。选得准，输出稳定；选得偏，模型被你亲手教歪。

理论：示例为什么能改变模型行为

Few-shot prompting 的核心概念来自 Brown et al.（2020）的 GPT-3 论文。他们发现，当模型规模足够大时，只要在 Prompt 里给出几条输入-输出示范，模型就能在不做梯度更新的情况下学会一个新任务。这种能力叫「上下文学习」（in-context learning）。

关键不在于模型「理解」了你的任务说明——它其实是在做模式匹配。模型会根据你给的示例，推断「这类输入应该对应这类输出」，然后把同样的映射应用到新输入上。

这里有一个容易被忽略的细节：Min et al.（2022）在研究中发现，示例的标签分布会直接影响模型判断。如果你的示例里 80% 都是正面情感，模型会倾向于把模糊输入也判为正面——即使输入本身更偏中性。换句话说，示例不仅在教模型「怎么回答」，还在教模型「什么答案更常见」。

这对业务 Prompt 意味着两件事：

1. 示例要覆盖真实的类别分布，而不是只挑最典型的样本。
2. 示例要覆盖容易混淆的边界情况，否则模型遇到模糊输入会凭示例分布瞎猜。

Anthropic 在其 Prompt 工程指南中明确建议：给 Claude 提供 2–3 条有代表性的输入-输出对，放在指令之后、实际请求之前。OpenAI 的官方指南则进一步建议用 XML 标签或 Markdown 结构把每条示例框起来，防止模型把示例和指令混在一起理解。

案例一：客服意图分类

先看我最开始翻车的那个场景。客服意图分类，候选标签有：退款、换货、催发货、改地址、投诉、咨询、无法判断。

最开始的 Prompt 是这样的：

你是客服意图分类助手。根据用户描述，判断意图类别。
候选类别：退款、换货、催发货、改地址、投诉、咨询、无法判断。
 
示例：
用户：我的快递三天了还没到，能不能催一下
意图：催发货
 
用户：衣服收到有破洞，怎么退货
意图：退款
 
用户：买大了想换小一号
意图：换货
 
用户：这个还有货吗
意图：咨询
 
用户：你们客服态度太差了
意图：投诉
 
现在请分类：
用户：我刚下单但地址填错了，能改一下吗

模型输出：催发货。

问题很明显——五条示例里没有一条「改地址」，但有两条涉及订单物流（催发货、退款），模型就把「订单相关」的模糊请求都归到了最高频的示例类别。

修改后的 Prompt 做了三件事：

1. 每个候选标签至少给一条示例
2. 加入边界示例（同时提到退款和换货的情况）
3. 把示例顺序按常见到罕见排列

你是客服意图分类助手。根据用户描述，判断意图类别。
候选类别：退款、换货、催发货、改地址、投诉、咨询、无法判断。
 
示例：
用户：我的快递三天了还没到，能不能催一下
意图：催发货
 
用户：衣服收到有破洞，怎么退货
意图：退款
 
用户：买大了想换小一号
意图：换货
 
用户：我刚下单但地址填错了，能改吗
意图：改地址
 
用户：你们客服态度太差了，要举报
意图：投诉
 
用户：这个产品支持分期付款吗
意图：咨询
 
用户：我想退款但东西还没收到，而且换货也行
意图：无法判断
 
现在请分类：
用户：我刚下单但地址填错了，能改一下吗

模型输出：改地址。

改动的核心逻辑：不是给更多示例，而是让示例覆盖所有你需要模型区分的类别。Cleanlab 的研究也指出，构建 Few-shot 示例集时，最可靠的做法是先确保每个目标类别至少有一条示例被纳入，再去补充边界和混淆样本。

案例二：产品评论情感分析

情感分析看起来简单——正面、负面、中性，三条示例搞定。实际做下来，最容易出问题的是中性。

很多团队在构建情感分析示例时，会选非常清晰的正面和负面评论。这样做的好处是模型对极端情感判断很准，坏处是遇到「还行吧」「一般般」「能用但不好用」这类模糊评论时，模型会倾向于选正面或负面，因为它从示例里学到的判断尺度是两极化的。

我在一个实际项目里试过两种策略，差异很明显：

策略 B 在极端情感上掉了 2 个百分点，但模糊测试集涨了 23 个百分点。对业务来说，模糊评论恰恰是最需要准确判断的那部分——极端负面评论本来就会被人工复查，真正漏检的是那些「不太好也不太差」的评论。

OpenAI 的 Prompt 工程指南建议用 XML 标签把每条示例框起来。这对结构化输出特别有用：

你是一个产品评论情感分析器。
只输出「正面」「负面」或「中性」，不要输出其他内容。
 
<review id="example-1">
这个耳机太棒了，音质完美，续航也长
</review>
<sentiment id="example-1">正面</sentiment>
 
<review id="example-2">
质量差到离谱，一天就坏了
</review>
<sentiment id="example-2">负面</sentiment>
 
<review id="example-3">
一般般，没什么特别的，能用
</review>
<sentiment id="example-3">中性</sentiment>
 
<review id="example-4">
音质还行但佩戴不太舒服，戴久了耳朵疼
</review>
<sentiment id="example-4">负面</sentiment>
 
现在请分析：
<review>
包装挺好的，耳机一般，不值这个价
</review>

这里有个细节：第四条示例把「音质还行但佩戴不舒服」归为负面。这是一个主观判断——有些团队会归为中性。关键是你要在示例里明确表态，让模型知道你团队的判断标准是什么。示例不仅是教模型「怎么分类」，还是在教模型「遇到矛盾信息时偏向哪边」。

案例三：合同条款摘要生成

Few-shot 示例不只用于分类任务。在生成类任务里，示例的作用更微妙——它同时约束格式、长度和抽取重点。

一个法务团队需要把合同条款摘要为一句话，要求包含：主体、义务、违约后果。最初的 Prompt 只写了文字说明，模型输出的摘要长短不一，有时漏掉违约后果。

加上示例之后：

你是法务助理。将以下合同条款摘要为一句话，必须包含：
主体、义务、违约后果。
 
<clause id="example-1">
乙方应于本合同签署后 30 日内向甲方交付全部货物，
逾期未交付的，每逾期一日按合同总金额的 0.5% 支付违约金。
</clause>
<summary id="example-1">
乙方须在签约后 30 日内交付全部货物，逾期每日按合同总额 0.5% 支付违约金。
</summary>
 
<clause id="example-2">
甲方应在收到货物后 7 个工作日内完成验收，
验收不合格的应书面通知乙方，逾期未提出异议视为验收合格。
</clause>
<summary id="example-2">
甲方须在收货后 7 个工作日内验收，不合格需书面通知乙方，逾期视为合格。
</summary>
 
现在请摘要：
<clause>
丙方承诺自协议生效之日起 12 个月内为甲方提供技术维护服务，
未能按时响应的，甲方有权解除合同并要求退还已支付的服务费用。
</clause>

输出：丙方须在协议生效后 12 个月内提供技术维护服务，未按时响应则甲方有权解约并要求退费。

对比没有示例时的输出：丙方要为甲方提供技术维护。（漏掉了时限和违约后果）

示例在这里起了三重作用：

一张流程图：Few-shot 示例设计过程

把上面三个案例的经验抽象一下，Few-shot 示例设计可以走这个流程：

这套流程的核心思想是：先铺覆盖、再调分布、最后做版本化。不要一上来就堆示例数量，先确保每个你需要模型区分的类别都有代表。

示例数量和顺序怎么选

这是被问得最多的问题。答案是：没有一个万能数字，但有可操作的原则。

OpenAI 和 Anthropic 的建议基本一致：从 3–5 条高质量示例开始，然后根据评测结果按需补充。Google 在 2025 年的 Prompt 工程白皮书中甚至明确建议「始终包含 Few-shot 示例」，不推荐 Zero-shot 用于生产环境。

顺序方面，几个经验：

• 常见到罕见：把最常见的业务场景放前面，帮助模型先建立主要模式。
• 简单到复杂：先给清晰的典型样本，再给模糊的边界样本。
• 不要按字母或随机排列：有研究表明，列表前部的示例对模型影响力更大（首因效应），把最重要的放前面。

示例格式对比：哪种结构更好

不同模型对示例格式的偏好略有不同，但有几种通用写法。下面是同一个情感分类任务的四种格式对比：

格式 A：纯文本

评论：这个耳机音质很好
情感：正面
 
评论：质量太差了
情感：负面
 
评论：一般般
情感：?

格式 B：XML 标签

<review>这个耳机音质很好</review>
<sentiment>正面</sentiment>
 
<review>质量太差了</review>
<sentiment>负面</sentiment>
 
<review>一般般</review>
<sentiment>?</sentiment>

格式 C：JSON

[
  {"review": "这个耳机音质很好", "sentiment": "正面"},
  {"review": "质量太差了", "sentiment": "负面"},
  {"review": "一般般", "sentiment": "?"}
]

格式 D：Markdown 表格

| 评论 | 情感 |
|------|------|
| 这个耳机音质很好 | 正面 |
| 质量太差了 | 负面 |
| 一般般 | ? |

我的经验是：如果最终输出需要是结构化格式（JSON、表格），示例也用同样的结构化格式，让模型看到一致的输入-输出模式。如果输出是自然语言，XML 标签或纯文本都可以。OpenAI 官方明确推荐在 developer 消息里用 XML 标签组织示例。

常见坑和避坑指南

在实际项目里，我踩过也见过这些坑：

1. 示例只放成功案例 很多团队在构建示例集时，下意识只选「模型能答对的」。结果模型在正常场景表现很好，一遇到异常输入就崩。示例必须覆盖失败场景——模型需要学会说「我不知道」。

2. 示例来自不同来源，风格不统一 A 同学写了两条，B 同学补了三条，每个人的表述风格不同。模型会把风格差异当成「答案可以有多种写法」，输出开始飘。示例应该统一风格，最好由同一个人定调。

3. 更新示例后不回归测试 加了一条新示例，结果某个之前分对的类别开始分错。这种「按下葫芦浮起瓢」的情况非常常见。每次改示例，都要跑一遍完整测试集。

4. 示例里夹带私货 有些示例的输入过于具体，包含了不应该作为判断依据的信息。比如示例里写「我是老顾客了，东西有问题要退款」，模型可能学会把「我是老顾客」和「退款」关联起来。示例输入应该只包含与判断直接相关的信息。

5. 忽略上下文窗口限制 示例太多会吃掉上下文空间，导致后面的实际请求和系统指令被截断。特别是在用长上下文模型时，不要觉得「窗口够大就随便塞」。示例数量和上下文消耗要精打细算。

交付前检查清单

每次上线或修改 Few-shot 示例前，我会过一遍这个清单：

• 每个候选类别都至少有一条示例覆盖
• 包含至少一条「无法判断」或拒答示例
• 示例分布接近真实业务场景的频率分布
• 边界和混淆场景有专门示例覆盖
• 所有示例的格式、风格、长度保持一致
• 示例中不含敏感信息（已脱敏）
• 示例按从常见到罕见的顺序排列
• 使用 XML 标签或明确分隔符框定每条示例
• 在完整测试集上跑过评测，无退化类别
• 示例数量和上下文消耗在预算范围内
• 示例已纳入版本管理，有变更记录
• 新增或修改示例后回归测试全部通过

如果 12 条里有一条没过，就不要上线。改示例的成本很低，但修线上 bug 的成本很高。

小结

Few-shot 示例的本质是你给模型的一份「评分标准」。你展示什么算好答案、什么算边界、什么该拒答，模型就按什么标准来。

不要把示例当装饰。把它当产品设计来做——有覆盖策略、有优先级、有版本管理、有回归测试。

参考资料

• Few-Shot Prompting - Prompt Engineering Guide
• Few-Shot Prompting: Techniques, Examples, and Best Practices - DigitalOcean
• Prompt Engineering Guide - OpenAI API
• Prompt Engineering Best Practices 2026 - Thomas Wiegold
• Ensuring Reliable Few-Shot Prompt Selection for LLMs - Cleanlab
• Zero-Shot, One-Shot, and Few-Shot Prompting - Learn Prompting
• Effective Context Engineering for AI Agents - Anthropic
• Best Practices for Prompt Engineering - OpenAI Help Center
• The Few Shot Prompting Guide - PromptHub
• Brown, T., et al. (2020). Language Models are Few-Shot Learners. NeurIPS.
• Min, S., et al. (2022). Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? EMNLP.