示例与 Few-shot

一句话理解：示例是“演示给模型看”的指令，最适合传达难以用文字描述的格式、语气和判断边界；给 3–5 个多样、覆盖边界情况的示例，并明确告诉模型哪些该学、哪些不该照搬。

“语气要专业但有温度”“要简洁但信息完整”——这类要求写一百遍，不同的人和模型也会有不同的理解。而给出两三段真实的好话术，大家立刻就明白了。这就是示例的力量。

但示例也是一把双刃剑。团队经常遇到这样的情况：示例里的申请都是“符合退款政策”，结果模型把大部分案例都判成了符合；示例话术都是 60 字左右，模型就再也写不出更短的回复；示例里出现过的一个商品名，被模型写进了毫不相关的回答里。这一课讲清楚示例什么时候用、怎么给、如何避免被模型“过度模仿”。

什么时候需要示例

示例（Few-shot，也叫 multishot）是在指令中提供若干“输入 → 期望输出”的样例。Anthropic 官方文档把它列为控制输出格式、语气与结构最可靠的方法之一。但并不是每份指令都需要示例：

情况	是否需要示例	原因
语气、风格、话术	强烈建议	文字难以精确描述，示例一看就懂
分类的边界情况	强烈建议	“商品质量问题”和“七天无理由退货”的边界，用对比示例最清楚
特定的写作结构	建议	例如“结论 → 证据 → 建议”三段式处理说明
严格的 JSON 结构	通常不需要	用 结构化输出 强制约束更可靠
简单明确的任务	不需要	例如“提取邮件中的日期”，示例只增加 Token 成本
需要创造性和多样性	慎用	示例会让输出向示例收敛

一个实用判断：如果你发现自己在指令里用形容词反复描述“应该是什么样”，就该换成示例了。

怎么给：五个原则

1. 数量：3–5 个起步。 Anthropic 官方建议提供 3–5 个示例以获得最佳效果。太少容易让模型只学到某个示例的特点；太多会占用上下文，且收益递减。

2. 多样：覆盖真实分布和边界。 示例之间要有足够的差异，避免模型学到你并不想要的规律。以客服话术为例，至少覆盖：正常受理的退款、需要安抚的投诉、数据不足无法确认的情况。

3. 相关：贴近真实输入。 示例的输入要像真实工单一样“脏”：有错别字、信息不全、情绪化表达。用过于干净的示例，模型在真实数据上表现会打折扣。

4. 隔离：用标签把示例和指令分开。 官方建议把示例放在 <example> 标签中，多个示例放在 <examples> 中，让模型清楚区分“这是示例”和“这是要执行的指令”或“这是真实输入”。

5. 说明：告诉模型示例在演示什么。 在示例前后写清楚“学什么、不学什么”，这是防止过度模仿最简单有效的办法。

五个原则落到一段指令里，结构是这样的：

下面是「客服退款 Agent」中客户话术部分的示例写法：

<customer_message_guide>
customer_message 是客服发给客户的话术。以下示例用于说明语气、结构和信息取舍：
先回应客户关心的事，再说明当前进展，最后给出下一步。
示例中的订单号、商品和金额仅作演示，请始终使用本次工具返回的真实数据；
话术长度根据信息量决定，不需要和示例一致。

<examples>
<example>
<situation>签收后第 3 天申请无理由退款，商品未拆封，符合政策，退款申请已提交审批</situation>
<customer_message>您好，您的退款申请我们已经受理并提交审核，审核通过后会按原支付渠道退回，到账时间以渠道处理为准。</customer_message>
</example>

<example>
<situation>客户第三次催退款，情绪激动；商品属于定制类目，按政策不适用无理由退货</situation>
<customer_message>非常抱歉让您多次询问。这件商品为定制款，按售后政策不支持无理由退货。如果商品本身存在质量问题，麻烦您回复实物照片，我们会重新为您判定。</customer_message>
</example>

<example>
<situation>支付记录暂时无法获取，已退金额无法核对，是否可退无法确认</situation>
<customer_message>您好，我们正在核实这笔订单的支付与退款记录，已提交相关团队加急排查，有结果后会尽快联系您。</customer_message>
</example>
</examples>
</customer_message_guide>

注意第三个示例：它演示的是 “无法确认”时应该怎么说。很多团队只给成功案例，结果模型从来学不会在信息不足时坦诚、不承诺。

过度模仿：常见症状与对策

模型会学习示例中 所有 可见的规律，包括你并不想让它学的。常见症状：

症状	例子	对策
照抄具体内容	示例中的“定制款”出现在普通商品的话术里	明确声明示例内容仅作演示；使用明显与真实业务区分的示例数据
长度趋同	示例都在 60 字左右，所有输出都是 60 字	示例长度要有差异；在说明中写“长度根据信息量决定”
标签分布偏斜	5 个分类示例里有 3 个“符合退款政策”，模型偏向这个类别	各类别均衡覆盖，或只为容易混淆的边界给示例
句式固化	每条话术都以“您好，您的订单”开头	示例的开头和句式要有变化
规则与示例打架	规则说“不承诺到账时间”，示例里写了“预计明天到账”	所有示例都要按最新规则审查，规则变更时同步修改示例

最后一项尤其隐蔽：示例是非常强的信号，实践中经常能看到模型在规则与示例冲突时跟着示例走，而且这种问题很难通过阅读指令发现。 示例和规则一样需要版本管理和回归测试。

进阶用法

用对比示例讲清边界。 分类任务中最有价值的示例，是两个看起来很像、但类别不同的输入：

<example>
<input>客户留言：收到的面霜外包装被压坏了，瓶子还没拆封，想退掉。</input>
<refund_decision>符合退款政策</refund_decision>
<why>商品未拆封且存在外观破损，属于质量问题，不受签收 7 天的限制。</why>
</example>

<example>
<input>客户留言：面霜已经打开用过一次，味道不喜欢，想退掉。</input>
<refund_decision>不符合</refund_decision>
<why>已拆封的个护类目不适用无理由退货，客户也未主张商品存在质量问题。</why>
</example>

每个示例附上 why，模型学到的是判断依据，而不只是表面的关键词。Anthropic 文档还提到，Few-shot 示例可以与思考能力配合：在示例中展示推理过程，模型会把这种推理方式泛化到自己的思考中。

示例放在哪里。 通用的语气和格式示例，放在 Agent 层指令里；只在某类任务中用到的示例，放进对应的 Skill，按需加载。这样既节省上下文，也避免不相关的示例干扰其他任务。

动态示例。 当边界情况很多时，可以建一个示例库，每次根据当前输入检索出最相似的几个示例放入上下文。这本质上是把 RAG 用在示例上，适合分类细、案例多的客服与工单场景。

示例的来源。 最好的示例来自真实的线上案例，尤其是曾经出错、后来被人工修正的案例。它们正是模型最需要学习的边界。这也把示例和 评测集 连在了一起：同一批案例，一部分用作示例，另一部分留作测试，两者不能重叠，否则测试结果会虚高。

示例库、评测集与动态检索之间的关系如下：

常见误区

• “示例越多越好。” 超过一定数量后收益递减，而 Token 成本和过度模仿的风险持续上升。
• “只放最好的成功案例。” 失败、数据不足、需要转人工的情况同样需要示例，否则模型只会“报喜”。
• “示例写一次就不用管了。” 规则、话术规范、产品功能变化后，过时的示例会悄悄把模型带回旧行为。

产品经理检查清单

• 哪些要求是用文字说不清、需要用示例演示的？
• 示例是否覆盖了典型情况、边界情况和“无法完成”的情况？
• 示例在长度、句式、类别分布上是否足够多样？
• 是否说明了示例的用途，以及哪些内容不能照搬？
• 每个示例是否都符合当前版本的规则？规则变更时由谁同步修改？
• 用作示例的案例是否已经从评测集中排除？

练习

做一次“示例效果对比”（约 45 分钟）：

1. 选取「客服退款 Agent」的退款原因分类任务，定义 5 个类别。
2. 准备 20 个测试输入，其中至少 6 个是容易混淆的边界情况。
3. 分三轮测试：无示例；5 个示例但全部是典型情况；5 个示例，其中 2 组为对比边界示例并附 why。
4. 统计三轮的分类正确率，并检查第二轮是否出现类别偏斜或照抄内容的情况，写下你的结论。

延伸阅读

• Prompting best practices：见“Use examples effectively”与“Structure prompts with XML tags”小节。
• OpenAI Prompt engineering：见 Few-shot learning 相关小节。

下一步

示例解决的是“怎么表达”。下一课「把业务规则翻译成指令」解决“规则放在哪里”：哪些规则写进 Prompt，哪些必须交给程序强制执行。