Few-shot-Prompt
4676 字约 16 分钟
domain/aiai/prompt
2026-07-24
Few-shot Prompt 的核心不是"多给几个例子"，而是用少量示例帮助模型推断任务边界、输出格式、判断标准和隐含偏好。
通过示例，让模型在当前上下文中临时学习一种任务模式。
1. Few-shot 是什么
Few-shot Prompt 指在正式任务前，给模型提供若干个"输入 → 输出"的示例，让模型模仿这些示例完成新任务。
基本结构
你是一个 xxx。
请按照下面示例的风格完成任务。
示例 1：
输入：
...
输出：
...
示例 2：
输入：
...
输出：
...
现在处理：
输入：
...
输出：适合场景
| 场景 | 原因 |
|---|---|
| 输出格式要求严格 | 示例比规则更直观 |
| 任务标准难以用语言完全描述 | 示例可以传递隐含判断 |
| 需要稳定风格 | 示例能锚定语气、长度、结构 |
| 分类、抽取、改写、评分 | 示例能告诉模型"什么算对" |
| 复杂边界判断 | 示例能展示例外情况 |
2. Few-shot vs Zero-shot vs In-context Learning
2.1 Zero-shot
Zero-shot 是不给示例，只用任务说明。
请把下面用户反馈分类为：Bug、需求、咨询、投诉。
用户反馈：
App 打开后一直转圈，进不去首页。优点：简单、成本低、上下文占用少。
缺点：模型按默认理解执行，格式不稳定、分类边界不一致。
适合/不适合
| 场景 | 是否适合 Zero-shot |
|---|---|
| 简单总结 | 适合 |
| 常规翻译 | 适合 |
| 普通问答 | 适合 |
| 严格结构化抽取 | 不太适合 |
| 复杂分类边界 | 不太适合 |
| 风格模仿 | 不太适合 |
2.2 Few-shot
Few-shot 是给少量示例，让模型按照示例推断模式。
任务：将用户反馈分类为 Bug、需求、咨询、投诉。
示例 1：
输入：点击发布后闪退。
输出：Bug
示例 2：
输入：希望可以支持夜间模式。
输出：需求
示例 3：
输入：会员怎么取消自动续费？
输出：咨询
现在分类：
输入：App 打开后一直转圈，进不去首页。
输出：适合需要稳定模式的任务。
2.3 In-context Learning
In-context Learning 是更广义的概念，指模型在当前上下文里"临时学习"任务规则。Few-shot 是 In-context Learning 的一种常见形式。
| 概念 | 重点 | 示例 |
|---|---|---|
| Zero-shot | 只靠指令 | "请总结这篇文章" |
| Few-shot | 靠几个示例学习模式 | "参考下面 3 个总结示例" |
| In-context Learning | 在上下文中临时学习规则、格式、偏好、知识 | 示例、规则、反例、术语表、评分标准都算 |
Few-shot ⊂ In-context LearningFew-shot 是通过"示例"实现上下文学习；而 In-context Learning 还可以通过规则、文档片段、知识表、评分 Rubric、反例等方式实现。
三者关系
3. Shot 数量对效果的影响
Shot 数量不是越多越好。示例数量会影响模型的稳定性、泛化能力、成本和注意力分配。
3.1 0-shot
适合简单任务。
请把下面内容总结成 3 点。| 优点 | 缺点 |
|---|---|
| 快，Prompt 简短 | 格式不稳定，模型可能自由发挥 |
| 省 Token，成本低 | 标准不清晰，分类边界容易漂移 |
| 灵活，不容易被示例限制 | 风格不可控，输出长度、语气容易变化 |
3.2 1-shot
适合给模型一个"格式锚点"，主要解决格式问题，但对复杂边界帮助有限。
3.3 2-3 shot
最常见的数量区间。
| 任务 | 推荐 Shot |
|---|---|
| 分类 | 2-5 |
| 信息抽取 | 2-4 |
| 改写 | 2-3 |
| 总结 | 1-3 |
| 风格模仿 | 2-5 |
| 代码生成规范 | 2-4 |
2-3 个示例通常可以覆盖：标准情况 → 另一种常见情况 → 一个边界情况。
3.4 5-shot 以上
适合复杂任务，尤其是边界多、类型多、标准不容易描述的任务。
| 场景 | 为什么需要更多示例 |
|---|---|
| 多类别分类 | 每类至少 1 个示例 |
| 复杂审核规则 | 需要覆盖边界案例 |
| 法务/医疗/金融类文本判断 | 判断标准更细 |
| 多风格内容生成 | 需要展示不同风格 |
| 高精度结构化抽取 | 需要减少字段误解 |
示例太多的副作用
| 问题 | 说明 |
|---|---|
| Token 成本增加 | 上下文变长 |
| 注意力稀释 | 模型可能忽略关键指令 |
| 示例冲突 | 不一致示例会误导模型 |
| 过拟合示例 | 新任务稍微变化就输出僵硬 |
4. 示例选择策略
Few-shot 的效果主要取决于示例质量，而不是示例数量。
三个核心维度：相似性、多样性、难度递增。
策略选择决策流程
4.1 相似性策略
选择和当前任务最接近的示例。适合追求准确率，但泛化能力可能不足。
适合：格式化输出、业务场景分类、客服回复、代码生成、文档生成。
4.2 多样性策略
示例覆盖不同类型、不同边界、不同输入形态。
适合：多类别分类、内容审核、信息抽取、需求分析、Agent 任务分派。
示例结构
示例 1：明确 Bug
示例 2：明确需求
示例 3：咨询
示例 4：投诉多样性可以提升覆盖面，但过度多样会降低局部准确率。
4.3 难度递增策略
示例从简单到复杂排列，让模型逐步理解任务规则。适合复杂推理、复杂抽取、多步骤生成。
推荐结构
示例 1：简单情况
示例 2：中等复杂情况
示例 3：边界情况
示例 4：复杂综合情况
现在处理：真实任务5. 示例排序策略
Few-shot 中示例的顺序也会影响结果。
排序流程
推荐顺序
普通示例 → 典型示例 → 边界示例 → 反例 → 当前任务更具体：
1. 最基础的正确示例
2. 最常见的业务示例
3. 容易误判的边界示例
4. 明确不该怎么做的反例
5. 当前输入不推荐的顺序：复杂边界示例 → 简单示例 → 无关示例 → 当前任务（模型可能一开始就被复杂示例带偏）。
6. 正例、反例与边界例
高质量 Few-shot 不应该只有正例。
四类示例协同作用
| 类型 | 作用 |
|---|---|
| 正例 | 告诉模型应该怎么做 |
| 反例 | 告诉模型不要怎么做 |
| 边界例 | 告诉模型模糊情况如何判断 |
| 异常例/信息不足例 | 告诉模型缺失信息时如何处理 |
6.1 正例
输入：希望可以增加深色模式。
输出：需求6.2 反例
反例：
输入：这个功能真垃圾。
错误输出：Bug
正确输出：投诉
原因：用户表达的是负面情绪和体验不满，但没有描述具体功能异常。6.3 边界例
输入：每次打开 App 都很慢，希望优化一下。
输出：Bug / 性能问题
原因：虽然用户使用了"希望"，但核心是现有功能体验异常，不是新增需求。6.4 信息不足例
输入：不能用了。
输出：
{
"type": "信息不足",
"reason": "缺少具体功能、操作路径和异常表现"
}这类示例非常重要，可以防止模型强行猜测。
7. Few-shot Prompt 通用模板
7.1 标准母模板
你是一个{角色}。
任务：
{任务说明}
判断标准：
1. {标准1}
2. {标准2}
3. {标准3}
输出格式：
{格式说明}
示例 1：
输入：{示例输入1}
输出：{示例输出1}
示例 2：
输入：{示例输入2}
输出：{示例输出2}
示例 3：
输入：{示例输入3}
输出：{示例输出3}
现在处理：
输入：{真实输入}
输出：7.2 分类任务模板
你是一个用户反馈分类助手。
任务：
将用户反馈分类为以下类型之一：
- Bug：已有功能异常、报错、崩溃、卡死、结果错误
- 需求：希望新增能力、优化体验、增加配置
- 咨询：询问功能、规则、价格、使用方式
- 投诉：表达强烈不满、服务体验差、负面情绪
- 信息不足：无法判断具体类型
输出 JSON：
{
"type": "",
"reason": ""
}
示例 1：
输入：点击发布后 App 闪退。
输出：{ "type": "Bug", "reason": "用户描述了明确的功能异常和崩溃现象" }
示例 2：
输入：希望支持微信登录。
输出：{ "type": "需求", "reason": "用户提出了新增登录方式的诉求" }
示例 3：
输入：会员到期后数据还会保留吗？
输出：{ "type": "咨询", "reason": "用户在询问产品规则" }
示例 4：
输入：客服半天不回复，太差劲了。
输出：{ "type": "投诉", "reason": "用户主要表达服务不满和负面情绪" }
示例 5：
输入：不能用了。
输出：{ "type": "信息不足", "reason": "缺少具体功能、操作路径和异常表现" }
现在处理：
输入：{用户反馈}
输出：7.3 信息抽取模板
你是一个结构化信息抽取助手。
任务：
从文本中抽取以下字段：
- name：姓名，没有则为 null
- phone：手机号，没有则为 null
- date：日期，没有则为 null
- intent：用户意图
- missing_fields：缺失字段列表
要求：
1. 不要编造文本中不存在的信息
2. 字段缺失时填 null
3. 输出严格 JSON
示例 1：
输入：我是张三，明天下午想预约宠物洗澡。
输出：{ "name": "张三", "phone": null, "date": "明天下午", "intent": "预约宠物洗澡", "missing_fields": ["phone"] }
示例 2：
输入：李女士，手机号 13800000000，周五上午带猫体检。
输出：{ "name": "李女士", "phone": "13800000000", "date": "周五上午", "intent": "预约猫体检", "missing_fields": [] }
现在处理：
输入：{文本}
输出：7.4 文案改写模板
你是一个产品文案优化助手。
任务：将原始文案改写得更清晰、自然、有行动引导，但不要夸张营销。
风格要求：
1. 简洁
2. 口语化
3. 不使用过度营销词
4. 保留原意
示例 1：
输入：本功能可以帮助用户进行快速的数据同步。
输出：开启后，数据会自动同步，使用时不用手动刷新。
示例 2：
输入：您可以通过该入口进行会员权益查看。
输出：在这里可以查看你的会员权益。
示例 3：
输入：系统检测到您的网络环境存在异常。
输出：当前网络不稳定，请稍后再试。
现在处理：
输入：{原始文案}
输出：7.5 总结任务模板
你是一个阅读总结助手。
任务：
将文章总结为：
1. 一句话核心观点
2. 三个关键要点
3. 一个值得继续思考的问题
要求：
- 不要照抄原文
- 不要加入原文没有的信息
- 语言简洁
示例：...7.6 代码生成模板
你是一个 iOS Swift 开发助手。
任务：根据需求生成 Swift 代码。
代码要求：
1. 使用 Swift
2. 命名清晰
3. 保持函数职责单一
4. 对异常情况做保护
5. 不要引入不必要的第三方库
示例 1：
需求：判断字符串是否为空或只包含空格。
输出：
extension String {
var isBlank: Bool {
trimmingCharacters(in: .whitespacesAndNewlines).isEmpty
}
}
示例 2：
需求：安全获取数组指定下标元素。
输出：
extension Array {
subscript(safe index: Int) -> Element? {
guard indices.contains(index) else { return nil }
return self[index]
}
}
现在处理：
需求：{开发需求}
输出：7.7 Agent 任务分派模板
你是一个多 Agent 调度器。
任务：根据用户需求判断应该交给哪个 Agent 处理。
可选 Agent：
- ProductAgent：需求分析、PRD、用户故事
- DesignAgent：交互设计、页面结构、用户流程
- IOSAgent：iOS 实现方案、Swift、UIKit、SwiftUI
- BackendAgent：接口设计、数据库、服务端逻辑
- TestAgent：测试用例、边界条件、验收标准
- DocAgent：文档整理、知识库沉淀
输出 JSON：{ "agent": "", "reason": "", "next_action": "" }
示例 1：
输入：帮我把这个需求拆成开发任务。
输出：{ "agent": "ProductAgent", "reason": "用户需要进行需求拆解，属于产品分析任务", "next_action": "先提取核心目标、用户角色、功能范围和验收标准" }
示例 2：
输入：这个接口应该怎么设计表结构？
输出：{ "agent": "BackendAgent", "reason": "用户关注接口和数据结构，属于服务端设计任务", "next_action": "先确认实体关系、字段、索引和接口入参出参" }
示例 3：
输入：帮我补充 iOS 端实现方案。
输出：{ "agent": "IOSAgent", "reason": "用户明确要求 iOS 实现方案", "next_action": "分析页面结构、数据流、状态管理和关键类设计" }
现在处理：
输入：{用户需求}
输出：8. 示例质量检查清单
设计 Few-shot Prompt 时的自检表：
- 示例是否和当前任务相关？
- 示例输入是否真实、自然？
- 示例输出是否符合最终期望格式？
- 示例之间是否存在冲突？
- 是否覆盖了常见情况？
- 是否覆盖了边界情况？
- 是否包含信息不足时的处理方式？
- 示例数量是否过多？
- 示例顺序是否从简单到复杂？
- 当前任务和示例之间是否有明显断层？
9. 示例选择的实用公式
三示例公式（适合大多数任务）
示例 1：最典型情况
示例 2：另一种常见情况
示例 3：边界情况五示例公式（适合复杂业务任务）
示例 1：简单正例
示例 2：另一类正例
示例 3：复杂正例
示例 4：边界例
示例 5：信息不足例正反例公式（适合模型经常误判的任务）
正确示例：
输入：...
正确输出：...
错误示例：
输入：...
错误输出：...
为什么错：...
修正输出：...10. Few-shot 常见错误
| 错误 | 表现 | 正确做法 |
|---|---|---|
| 示例多但质量低 | 20 个格式不一致的示例 | 3-5 个高质量、格式统一、覆盖边界的示例 |
| 示例与任务不相似 | 客服投诉分类用了商品标题改写示例 | 选择与当前任务领域一致的示例 |
| 只有简单例无边界例 | 遇到"每次打开都很慢，希望优化"误判为需求 | 补充边界例（如"希望但本质是 Bug"的场景） |
| 示例输出与要求不一致 | 要求 JSON 但示例输出纯文本 | 示例必须严格遵循要求的输出格式 |
| 没有信息不足处理 | "不行"被强行分类 | 增加信息不足示例，防止模型强行猜测 |
11. Few-shot 设计决策表
Shot 数量选择决策树
| 任务情况 | 推荐方式 |
|---|---|
| 简单、常规、无固定格式 | Zero-shot |
| 需要固定格式 | 1-shot |
| 需要稳定分类 | 3-shot |
| 多类别、多边界 | 5-shot |
| 高风险、高精度 | Few-shot + 反例 + Rubric |
| 长文档理解 | RAG / 文档上下文 + Few-shot |
| Agent 调度 | Few-shot + 任务类型表 |
| 风格模仿 | 2-5 个风格示例 |
12. Shot 数量收益变化
示例从 0 到 8 个时，任务稳定性通常先快速提升，之后边际收益下降。
| Shots | 效果（相对质量） |
|---|---|
| 0-shot | 55 |
| 1-shot | 68 |
| 2-shot | 76 |
| 3-shot | 83 |
| 5-shot | 88 |
| 8-shot | 90 |
3-shot 是性价比最高的节点，5-shot 之后边际收益显著下降。
13. 核心结论
Few-shot 的重点不是数量，而是示例的代表性。
少而精 > 多而杂
相似性保证准确
多样性保证覆盖
难度递增保证理解
边界例保证稳定
反例减少误判推荐组合（3-5 个示例）
1 个典型正例
1 个常见变体
1 个边界例
1 个反例
1 个信息不足例