03｜用几个例子教会AI做任何事

场景引入：带新人的智慧

假设你的团队来了一位新同事，你让他帮忙整理客户反馈。你会怎么交代？

如果你只说”把客户反馈整理一下”，他大概率会问你：整理成什么样？按什么分类？要不要标优先级？

但如果你先拿出三条已经整理好的样本：

原始反馈：订单详情页打开后一直白屏 分类：Bug 优先级：P0 摘要：订单详情页白屏，影响用户查看订单

原始反馈：能不能加个按月筛选的功能 分类：功能需求 优先级：P2 摘要：用户希望增加按月份筛选订单的功能

原始反馈：你们的客服响应很快，体验不错 分类：正面反馈 优先级：P3 摘要：用户对客服响应速度表示满意

新同事看完这三个例子，立刻就明白了你要的格式、分类标准和摘要风格，接下来的一百条反馈他都能按照同样的模式处理。

这种”通过示例来教学”的方法，在 Prompt Engineering 中叫做 Few-shot Prompting（少样本提示）。它是目前最实用、适用面最广的提示词技巧之一。

---

三种提示策略：从零到多

根据提示词中包含示例的数量，可以分为三种策略。

零样本提示（Zero-shot）

不给任何示例，直接提出要求。

将以下句子翻译成英文：
今天天气真好，适合出去走走。

零样本依赖模型本身的能力。对于模型擅长的通用任务（翻译、摘要、简单问答），零样本通常就够了。

单样本提示（One-shot）

给一个示例，让模型理解你的期望。

请按照示例的格式，将技术术语翻译并添加注释。

示例：
输入：Load Balancer
输出：负载均衡器（Load Balancer）—— 将网络流量分配到多台服务器的组件

请处理：
输入：Message Queue

AI 回复：

消息队列（Message Queue）—— 用于在系统组件之间异步传递消息的中间件

一个示例往往就能让模型抓住输出的格式和风格。

少样本提示（Few-shot）

给 3-5 个示例，是最常用也最稳定的方式。示例越多，模型对你期望的”模式”理解越准确。

根据以下示例，对新的客服对话进行意图分类。

示例 1：
客户：我的订单三天了还没发货
分类：物流查询

示例 2：
客户：能帮我把收货地址改成北京市海淀区中关村大街 1 号吗
分类：信息修改

示例 3：
客户：这个东西质量太差了我要退货
分类：退货退款

示例 4：
客户：你们有没有 512GB 的版本
分类：商品咨询

请分类：
客户：我上周买的耳机左边没声音了怎么办

AI 回复：

分类：售后维修

模型从四个示例中学到了分类的粒度和类别体系，即使”售后维修”这个类别没有在示例中出现过，它也能合理推断。

---

为什么 Few-shot 有效

Few-shot 的原理并不是让模型”学习”新知识，而是通过示例来激活模型已有的能力并约束输出模式。

你可以把它类比为给导航系统设置途经点。模型本身知道很多条路（它训练时见过海量的文本模式），但不知道你想走哪条。零样本是只告诉目的地，模型自己选路；Few-shot 是沿途设置几个途经点，让模型沿着你期望的路线行驶。

具体来说，Few-shot 在三个层面发挥作用：

1. 格式锚定：示例定义了输入和输出的结构，模型会严格模仿
2. 标准校准：通过示例的具体内容，模型理解你的判断标准（比如什么算 P0，什么算 P2）
3. 边界划定：示例隐含了任务的范围和粒度

---

示例选择的四个原则

Few-shot 的效果很大程度上取决于你选择的示例。随意挑几个例子塞进去，效果可能还不如零样本。

原则一：代表性

示例应当覆盖任务中最常见的类型。

反面教材：做情感分类，三个示例全是”正面”情感。 正确做法：正面、负面、中性各一个。

原则二：多样性

示例之间应当有足够的差异，避免模型学到过于狭窄的模式。

反面教材：三个示例的输入都是短句。 正确做法：短句、长句、含特殊字符的句子各选一个。

原则三：边界覆盖

有意识地包含容易混淆或判断困难的”边界案例”。

比如在情感分类任务中，“这个产品还行吧，没什么特别的”是一个典型的边界案例——它既不是明确的正面，也不是明确的负面。把这类案例放入示例中，能显著提升模型在模糊地带的判断准确性。

原则四：格式一致

所有示例必须使用完全相同的格式。格式不一致是 Few-shot 失效的最常见原因。

# 错误：格式不一致
示例 1：输入是"xxx"，它属于A类
示例 2：xxx → B 类
示例 3：【xxx】分类结果：C类

# 正确：格式统一
示例 1：
输入：xxx
分类：A类

示例 2：
输入：xxx
分类：B类

示例 3：
输入：xxx
分类：C类

---

格式技巧：让示例结构清晰

当示例较多或内容较长时，使用分隔符和标签来组织结构，避免模型把示例内容和指令混淆。

技巧一：使用统一分隔符

请按照以下示例，将非结构化的地址文本解析为结构化格式。

---
输入：北京海淀区中关村大街1号院3号楼502室
输出：
省份：北京
区县：海淀区
街道：中关村大街
门牌：1号院3号楼502室
---
输入：广东省深圳市南山区科技园南路18号
输出：
省份：广东省
城市：深圳市
区县：南山区
街道：科技园南路
门牌：18号
---
输入：上海市浦东新区张江高科技园区碧波路888号
输出：

技巧二：使用 XML 标签包裹

当示例内容本身可能包含与 prompt 格式冲突的字符时，XML 标签是更安全的选择。

请按照示例，为代码片段生成一行功能注释。

<example>
<code>
def calculate_discount(original, rate):
    return round(original * (1 - rate), 2)
</code>
<comment>根据折扣率计算商品的折后价格，结果保留两位小数</comment>
</example>

<example>
<code>
def merge_intervals(intervals):
    intervals.sort(key=lambda x: x[0])
    merged = [intervals[0]]
    for current in intervals[1:]:
        if current[0] <= merged[-1][1]:
            merged[-1][1] = max(merged[-1][1], current[1])
        else:
            merged.append(current)
    return merged
</code>
<comment>合并有重叠的区间列表，输入区间按起点排序后依次检查是否可合并</comment>
</example>

请为以下代码生成注释：
<code>
def find_peak(nums):
    left, right = 0, len(nums) - 1
    while left < right:
        mid = (left + right) // 2
        if nums[mid] < nums[mid + 1]:
            left = mid + 1
        else:
            right = mid
    return left
</code>

---

实战案例一：情感分类

这是 Few-shot 最经典的应用场景之一。

对以下商品评论进行情感分类。分类标签为：正面、负面、中性。

评论：这款键盘手感非常好，打字很舒服，很满意这次购物。
情感：正面

评论：用了不到一个月就坏了，按键经常没反应，非常失望。
情感：负面

评论：质量还可以，中规中矩，和描述基本一致。
情感：中性

评论：外观设计不错但噪音有点大，总体来说性价比尚可。
情感：中性

评论：包装被压坏了好几个角，不过产品本身没问题，用起来还行。
情感：

AI 回复：

中性

注意第四个示例——“外观不错但噪音大”这种正负混合的评论被标注为”中性”，这教会了模型在遇到类似混合评价时如何判断。如果没有这个边界示例，模型可能会倾向于标注为”正面”或”负面”。

---

实战案例二：数据格式转换

Few-shot 特别适合教模型做格式转换——给几个输入输出对，它就能处理新数据。

将以下非标准日期格式统一转换为 ISO 8601 格式（YYYY-MM-DD）。

输入：2025年3月15日
输出：2025-03-15

输入：Mar 15, 2025
输出：2025-03-15

输入：15/03/2025
输出：2025-03-15

输入：2025.03.15
输出：2025-03-15

请转换以下日期：
输入：08-Nov-2024
输出：

AI 回复：

2024-11-08

再来看一个更复杂的转换——将自然语言描述转换为结构化数据：

将运维事件描述转换为 JSON 格式。

描述：3月10日上午10:15，订单服务的CPU使用率飙升到95%，持续了8分钟，
根因是一个慢查询导致连接池耗尽，通过添加索引修复。
JSON：
{
  "timestamp": "03-10 10:15",
  "service": "订单服务",
  "metric": "CPU使用率",
  "peak_value": "95%",
  "duration": "8分钟",
  "root_cause": "慢查询导致连接池耗尽",
  "resolution": "添加索引"
}

描述：3月12日下午3:40，支付网关响应时间从200ms上升到1500ms，
持续约15分钟，原因是第三方支付接口超时，切换备用通道后恢复。
JSON：
{
  "timestamp": "03-12 15:40",
  "service": "支付网关",
  "metric": "响应时间",
  "peak_value": "1500ms",
  "duration": "15分钟",
  "root_cause": "第三方支付接口超时",
  "resolution": "切换备用通道"
}

描述：3月13日凌晨2:20，用户中心的内存占用达到12GB触发告警，
持续了25分钟，排查发现是缓存未设置过期时间导致内存泄漏，
通过设置TTL为30分钟解决。
JSON：

AI 回复：

{
  "timestamp": "03-13 02:20",
  "service": "用户中心",
  "metric": "内存占用",
  "peak_value": "12GB",
  "duration": "25分钟",
  "root_cause": "缓存未设置过期时间导致内存泄漏",
  "resolution": "设置TTL为30分钟"
}

模型准确地从非结构化描述中提取了所有字段，并且保持了与示例一致的 JSON 结构和字段命名风格。

---

实战案例三：风格模仿

Few-shot 还能教模型模仿特定的写作风格。这在需要保持品牌语调一致性的场景中非常实用。

以下是我们技术博客的写作风格示例。请模仿这种风格写一段新内容。

<example>
主题：为什么需要消息队列
正文：想象一下餐厅里的传菜窗口。厨师做好一道菜，放在窗口上，
服务员有空了就来取。厨师不需要等服务员，服务员也不需要等厨师——
这个窗口就起到了解耦和缓冲的作用。消息队列在软件系统中扮演的
正是这个"传菜窗口"的角色。当服务 A 需要通知服务 B 处理一个任务时，
它不必直接调用 B 的接口然后傻等回应，而是把消息丢进队列，
B 按自己的节奏消费即可。
</example>

<example>
主题：什么是数据库索引
正文：如果你去图书馆找一本特定的书，有两种方式：从第一个书架开始
一本本翻过去，或者先查目录卡片找到位置再直接走过去。数据库索引
就是这个"目录卡片"。没有索引的查询是全表扫描——数据库引擎
逐行检查每条记录是否符合条件。当表中有几百万行数据时，
这种暴力搜索的代价就很可观了。建了索引之后，数据库可以通过
B+树结构快速定位目标行，查询时间从秒级降到毫秒级。
</example>

请用同样的风格写：
主题：什么是容器化部署

AI 回复：

想象你要搬家，有两种打包方式：一种是把衣服、书本、厨具散着装上卡车，到了新家再一件件归位；另一种是提前把每类东西装进标准化的收纳箱，箱子上贴好标签，到了新家直接按箱搬入。容器化部署走的就是”收纳箱”路线。每个应用连同它依赖的运行环境——操作系统库、配置文件、语言运行时——一起打包成一个容器镜像。这个镜像在你的笔记本上能跑，在测试服务器上也能跑，在生产集群上同样能跑。再也不会出现”在我机器上是好的”这种经典场面。

AI精准地模仿了示例中的风格特征：先用日常类比引入，再过渡到技术概念，语言简练直接，带有一点口语化的技术幽默。

---

Few-shot 的局限

Few-shot 并非万能。了解它的局限，能帮助你判断什么时候应该换用其他策略。

局限一：单纯的 Few-shot 在复杂推理任务中容易不足

Few-shot 本质上是教模型进行模式匹配——看到类似的输入，产出类似格式的输出。但当任务需要多步推理时，仅给出”输入→答案”的示例往往不够。

# Few-shot 可能失败的场景
示例：小张有 3 个苹果，小李给了他 2 个，他现在有 5 个苹果。
示例：小王有 10 块钱，花了 4 块，他还剩 6 块。

问题：一个水池有两个进水管和一个出水管。进水管 A 每小时注入 3 吨水，
进水管 B 每小时注入 2 吨水，出水管每小时排出 1 吨水。
水池初始有 10 吨水，4 小时后有多少吨水？

对于这类需要链式推理的任务，下一章将介绍的思维链（Chain-of-Thought）技巧比单纯的 Few-shot 更有效。不过值得一提的是，Few-shot 和 CoT 并非互斥——如果你在示例中不仅展示答案，还展示推理步骤（即 Few-shot + CoT），效果往往比单独使用任何一种都要好。

局限二：示例数量受上下文窗口限制

每个示例都占用 token。如果你的示例很长（比如每个示例含一段完整的代码），3-5 个示例可能就消耗了大量的上下文窗口，留给实际任务和模型输出的空间变得紧张。

实用建议：保持每个示例简洁而完整。如果原始数据太长，提取最核心的部分作为示例。

局限三：示例偏差会被放大

如果你的示例存在系统性偏差，模型会忠实地复制这种偏差。比如你给的情感分类示例中正面评价都很短、负面评价都很长，模型可能会学到”短评论 = 正面”这种错误模式。

检查方法：审视你的示例，确保它们在长度、复杂度、风格上没有与标签形成虚假关联。

---

Few-shot 的实用清单

在实际使用 Few-shot 时，可以对照以下清单：

检查项	说明
示例数量是否充足	简单任务 1-2 个，中等任务 3-5 个
类别是否均匀覆盖	每个目标类别至少有一个示例
是否包含边界案例	容易混淆的情况要有代表
格式是否完全统一	分隔符、标签、缩进前后一致
示例是否简洁	保留核心信息，去掉冗余内容
示例顺序是否合理	从简单到复杂排列，或类别交替排列
是否有虚假关联	检查示例特征与标签之间是否存在意外的模式

---

本章回顾

要点	内容
Zero-shot	不给示例，依赖模型自身能力，适合简单任务
One-shot	给一个示例，快速锚定格式和风格
Few-shot	给 3-5 个示例，最常用的提示技巧
示例选择	注重代表性、多样性、边界覆盖、格式一致
格式组织	用统一分隔符或 XML 标签包裹示例
适用场景	分类、格式转换、风格模仿、信息提取
局限	推理任务效果有限，受上下文窗口制约，示例偏差会被放大

思考题

1. 选择你工作中一项重复性的文本处理任务（如日志分类、数据清洗、格式转换），设计一组 Few-shot 示例，测试AI的完成效果。
2. 在情感分类的例子中，如果你把”外观设计不错但噪音有点大”这个边界示例从”中性”改为”负面”，模型对后续类似评论的判断会如何变化？动手试试。
3. 思考一下：对于”根据需求文档生成测试用例”这个任务，你会如何设计 Few-shot 示例？需要几个示例？每个示例应该覆盖什么类型的需求？

下一章，我们将学习另一种强大的提示技巧——角色提示（Role Prompting）。通过给AI设定一个专业身份，你能从根本上改变它回答问题的深度和视角。