---
title: "少样本提示：给 2-3 个例子让 Claude 精准理解"
description: "当文字描述说不清格式或风格时，用两三个输入输出样例把要求固定下来；附可直接套用的模板、选例标准与常见坑。"
updated: 2026-11-13
canonical: https://docai.cc/learn/few-shot-prompting-guide/
markdown_mirror: https://docai.cc/learn/few-shot-prompting-guide.md
---
## 什么时候该给例子

同一句「写得自然些」，你和 Claude 的理解可能完全不同。换成「照这三条的语感写」，歧义立刻少一半。当任务的难点在风格、格式或判断边界上，描述常常不如样例。

三类任务收益最明显：模仿固定文风、把杂乱内容整理成统一字段、给文本打标签。反过来，开放式创意和需要大量推理的任务，例子太多会绑住手脚。

少样本的完整定义见[少样本提示](/concepts/few-shot/)。

## 一个能直接套用的最小结构

示例要成对出现：一条输入，一条你认可的输入结果。中间用同样的符号分隔，模型才知道边界在哪。

把下面的客户反馈分成三类：功能建议、故障报修、价格咨询。

示例 1
输入：希望 App 支持夜间模式。
输出：功能建议

示例 2
输入：更新后打开就闪退。
输出：故障报修

示例 3
输入：团队版按年买有折扣吗？
输出：价格咨询

现在分类：导出的报表日期全是乱码。

这段模板有三个细节：类别名前后一字不差；每条示例只演示一种判断；待处理的输入单独放在最后。只写一句「请准确分类」，模型得自己猜什么叫准确。

## 用边界样例定住灰区

标准样例只告诉模型「常见情况长什么样」，真正容易翻车的是灰区。把最容易争议的两三条写进去，并附一句判断理由。

判断一条评论算不算投诉：先给一条明确投诉、一条明确夸奖，再补两条。说「比上一代差远了」算投诉，因为矛头指向当前产品；说「这个价位，表现还行」不算，因为没有指出具体缺陷。灰区样例的作用，是提前把「算」与「不算」的界线画出来。

## 选例标准与常见坑

数量克制。两到四个通常够用，每个例子都占上下文，堆多了会稀释重点。上下文怎么计量，见[上下文窗口](/concepts/context-window/)。

格式统一。字段顺序、标点、换行保持一致。模型会认真模仿格式，示例互相打架时，它只能猜哪个是标准。

难度递进。先简单后复杂，规律更容易被抓住；一上来给最绕的样例，学到的可能只是噪音。

还要检查示例和指令是否一致。正文说「只输出标签」，示例却带了一段分析，模型多半会跟着输出分析。

### 两种高频任务的写法

复刻文风时，样例最好是你自己写的，或者确认可以使用的素材。贴三段喜欢的文案，再补一句「只学句式和节奏，不要复用其中的具体说法」，能减少原句被搬进新稿。批量生成前，先用一条新主题试写，看它有没有学会停顿和收尾的方式，而不是只换了名词。

做字段抽取时，样例要展示异常输入怎么处理。比如金额缺失、日期写成「下周三」、职位名称后面带括号说明。每条样例后补一句「缺失写 null」，模型遇到类似情况才不会自行编一个值。

### 三个常见坑

样例彼此太像，等于只给了一个样例。有信息量的是差异：长度、语气、边界。

范文太长也有副作用。整段五百字的文章放进去，模型可能连原文的措辞一起搬走。你要的是特征，不是复制。

批量处理前先试跑一条新输入。结果稳了再放量；不稳就改示例，别在指令里不断打补丁。

## 负例：把「不要什么」摆出来

正例告诉模型往哪走，负例告诉它哪里是坑。做创意类任务时，光给好样例不够，模型很容易滑回最常见的套话。

> 写一句关于「坚持学习」的短句。
> 反例（不要这样写）：
> - 「只要努力，就一定能成功」——太满，没有信息。
> - 「新的一天，新的开始」——谁都能说，等于没说。
> - 「成功的人都爱学习」——因果倒置，读者不会信。
> 正例：
> - 「学得快的人，不是记性好，是敢把学到的东西马上用一次。」
> 按正例的写法再来三句。

给负例时一定附上理由。只写「这句不好」，模型不知道不好在哪，可能换一句同样空洞的话。理由要指向具体毛病：太满、太泛、因果倒了、没有画面。反例和正例最好成对出现，模型才能看出分界线画在哪里。

## 一个完整的结构化抽取例子

字段抽取是少样本最稳的用武之地，因为对错一眼可查。下面这份模板可以直接改字段名使用。

```text
从招聘信息里提取字段，输出 JSON，不要解释。

示例 1
原文：杭州某电商公司招前端工程师，3 年经验，熟悉 React，薪资 20-30k。
输出：{"公司":"杭州某电商公司","职位":"前端工程师","经验":"3 年","城市":"杭州","薪资":"20-30k"}

示例 2
原文：成都游戏工作室招聘数值策划，经验不限，薪资面议。
输出：{"公司":"成都游戏工作室","职位":"数值策划","经验":"不限","城市":"成都","薪资":null}

示例 3
原文：深圳急招数据分析师，精通 SQL，2 年以上，15-25k，五险一金。
输出：{"公司":null,"职位":"数据分析师","经验":"2 年以上","城市":"深圳","薪资":"15-25k"}

现在处理：
原文：〔待处理的招聘信息〕
输出：
```

三条示例各管一件事：第一条演示完整格式，第二条演示缺失值写 null，第三条演示公司名没出现时不猜。字段名、引号、冒号必须完全一致，模型会逐字模仿。字段一多，建议在指令里列出固定顺序，否则每次输出的键序可能不同；需要严格机器可读时，可以配合[结构化输出](/concepts/structured-output/)的方式约束格式。

处理完先抽查三条，再跑全量。错得最多的地方通常不是格式，而是模型替你补了原文没有的信息。

## 自测

1. 你的示例覆盖了至少一种边界情况吗？
2. 三条示例的格式是否一致？
3. 换一条没见过的输入，输出还稳定吗？

例子决定输出的形状，指令决定输出的目的，两者要一起给。下一节从反面看：[好提示词与坏提示词的真实差距](/learn/good-vs-bad-prompts/)。