---
title: "3.3.2 Few-shot Prompting：用示例教会 AI"
---


![03-technique_3.3-advanced-techniques_3.3.2-few-shot.png](/images/Basic/03-technique_3.3-advanced-techniques_3.3.2-few-shot.png)
# 3.3.2 Few-shot Prompting：用示例教会 AI

## 经过本节学习，你将掌握

- Few-shot 的定义和工作原理
- 为什么示例比长篇解释更有效
- 如何选择高质量的示例
- 示例数量的最佳实践
- Few-shot 的适用场景和局限性

## 什么是 Few-shot Prompting

Few-shot（少样本）的意思是：**给 AI 几个示例，让它学习模式后处理新任务**。

```
任务：将用户需求转换为技术任务

示例1：
需求："用户可以添加待办事项"
任务：
- 创建输入框组件
- 实现添加按钮点击事件
- 更新任务列表状态

示例2：
需求："用户可以删除待办事项"
任务：
- 为每个任务添加删除按钮
- 实现删除确认逻辑
- 从列表中移除对应任务

现在请处理：
需求："用户可以标记任务为已完成"
```

AI 看到两个示例后，就「学会」了转换规则，能按相同格式处理新需求。

## 核心洞见：为什么示例比解释更有效

> "展示一次，胜过解释一百遍。"

这不是夸张。人类学习新技能时，看示范比听讲解更有效。AI 也一样。

| 方式 | 效果 | 原因 |
|-----|------|------|
| 长篇解释规则 | 容易遗漏细节，格式不稳定 | AI 需要「理解」你的意图 |
| 提供示例 | 格式一致，细节完整 | AI 直接「模仿」模式 |

**实际测试表明**：对于格式化输出任务，Few-shot 的准确率比 Zero-shot 高出 20-40%。

## 示例数量：多少个最合适？

| 数量 | 适用场景 | 权衡 |
|-----|---------|------|
| **1 个**（One-shot） | 格式明确，规则简单 | 最省 token，但模式可能不够清晰 |
| **2-3 个** | 大多数场景 | 平衡效果和成本，推荐默认选择 |
| **4-5 个** | 复杂模式、边界情况多 | 效果更好，但 token 消耗增加 |
| **更多** | 很少需要 | 收益递减，考虑是否需要微调 |

**经验法则**：从 2 个示例开始，如果输出不稳定，再增加到 3 个。

## 如何选择高质量示例

### 原则一：代表性

示例要覆盖**典型情况**，不要全是特例。

```
❌ 差示例选择（全是边界情况）：
- 空字符串处理
- 超长文本处理
- 特殊字符处理

✅ 好示例选择（先典型，后边界）：
- 普通长度的文本（典型）
- 包含中英文混合的文本（常见变体）
- 空字符串处理（边界情况）
```

### 原则二：多样性

示例要覆盖**不同类型**，避免 AI 过度拟合单一模式。

```
任务：分类用户反馈

❌ 差示例（全是负面）：
- "太难用了" → 负面
- "垃圾软件" → 负面

✅ 好示例（覆盖各类）：
- "太难用了" → 负面
- "还不错，但希望能加个夜间模式" → 中性
- "用了三个月，效率提升很多" → 正面
```

### 原则三：格式一致

所有示例的**输入输出格式必须统一**。

```
❌ 格式不一致：
示例1：输入 "..." → 输出：任务列表
示例2：输入："..." 输出 - 任务1 - 任务2

✅ 格式一致：
示例1：
输入："..."
输出：
- 任务1
- 任务2

示例2：
输入："..."
输出：
- 任务1
- 任务2
```

## 差提示词 vs 好提示词

### ❌ 差提示词

```
帮我把用户故事转成开发任务，格式要清晰，包含前端和后端的工作。

用户故事：作为用户，我希望能够搜索任务
```

**问题**：没有示例，AI 不知道你期望的「清晰格式」是什么样。

### ✅ 好提示词

```
任务：将用户故事转换为开发任务清单

示例：
用户故事：作为用户，我希望能够按日期筛选任务
开发任务：
【前端】
- 添加日期选择器组件
- 实现筛选状态管理
- 更新任务列表渲染逻辑
【后端】
- 添加日期筛选 API 参数
- 实现数据库查询条件

现在请处理：
用户故事：作为用户，我希望能够搜索任务
```

### 输出对比

好提示词的输出会严格遵循示例格式：
```
开发任务：
【前端】
- 添加搜索输入框组件
- 实现搜索关键词状态管理
- 实现防抖搜索逻辑
- 更新任务列表渲染，高亮匹配文字
【后端】
- 添加搜索关键词 API 参数
- 实现模糊匹配数据库查询
```

## 实战示例：待办清单项目

小李需要 AI 帮他生成多个组件的 TypeScript 类型定义。他希望格式统一。

### Few-shot 提示词

```
任务：为 React 组件生成 TypeScript Props 类型定义

示例1：
组件描述：一个显示任务标题的组件，标题必填，可选显示完成状态
输出：
interface TaskTitleProps {
  title: string;           // 任务标题，必填
  isCompleted?: boolean;   // 完成状态，可选
}

示例2：
组件描述：一个按钮组件，显示文字必填，点击事件必填，可选禁用状态
输出：
interface ButtonProps {
  label: string;           // 按钮文字，必填
  onClick: () => void;     // 点击事件，必填
  disabled?: boolean;      // 禁用状态，可选
}

现在请处理：
组件描述：一个任务卡片组件，包含标题必填、描述可选、截止日期可选、优先级必填（高/中/低）
```

### AI 输出

```typescript
interface TaskCardProps {
  title: string;                        // 任务标题，必填
  description?: string;                 // 任务描述，可选
  dueDate?: Date;                       // 截止日期，可选
  priority: 'high' | 'medium' | 'low';  // 优先级，必填
}
```

注意 AI 自动学会了：
- 注释风格（`// 说明，必填/可选`）
- 可选属性用 `?`
- 枚举类型用联合类型

## 适用场景

| 场景 | 示例 | 为什么需要 Few-shot |
|-----|------|-------------------|
| 格式化输出 | 生成 API 文档 | 确保格式一致 |
| 分类任务 | 情感分析、标签分类 | 明确分类标准 |
| 转换任务 | 需求 → 任务、代码 → 文档 | 学习转换规则 |
| 风格模仿 | 按特定风格写文案 | 学习语言风格 |

## Few-shot 的局限性

| 局限 | 表现 | 解决方案 |
|-----|------|---------|
| Token 消耗高 | 示例占用大量上下文 | 精简示例，只保留关键信息 |
| 示例选择难 | 选错示例导致效果差 | 遵循代表性、多样性、一致性原则 |
| 过度模仿 | AI 照搬示例细节 | 用不同的示例内容，只保留格式相同 |

## 可复制模板

### 通用 Few-shot 模板

```markdown
任务：[任务描述]

示例1：
输入：[示例输入1]
输出：
[示例输出1]

示例2：
输入：[示例输入2]
输出：
[示例输出2]

现在请处理：
输入：[实际输入]
```

### 分类任务模板

```markdown
任务：将用户反馈分类为 [类别列表]

示例：
反馈："[示例反馈1]"
分类：[类别]

反馈："[示例反馈2]"
分类：[类别]

反馈："[示例反馈3]"
分类：[类别]

请分类：
反馈："[待分类内容]"
```

### 转换任务模板

```markdown
任务：将 [源格式] 转换为 [目标格式]

转换规则示例：

源：[示例源内容]
目标：
[示例目标内容]

源：[示例源内容]
目标：
[示例目标内容]

请转换：
源：[实际内容]
```

## 进阶预告：动态 Few-shot

在进阶版中，你会学到「动态 Few-shot」——根据用户输入**自动选择最相关的示例**，进一步提升效果并节省 token。

## 本节要点

✓ **Few-shot 的本质**：用示例教会 AI 模式，而非用文字解释规则

✓ **示例数量**：2-3 个是最佳平衡点

✓ **示例选择三原则**：代表性、多样性、格式一致性

✓ **适用场景**：格式化输出、分类、转换、风格模仿

✓ **与 Zero-shot 的选择**：如果 Zero-shot 格式不稳定，换用 Few-shot

下一节，我们学习如何让 AI「想一想再回答」——Chain of Thought。