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。