代码语言

知识点思维导图

29 个知识节点

参考资料

Prompt Engineering（05） - Few-shot 示例设计

读完后，你应能完成以下任务：

绘制“Prompt Engineering（05） - Few-shot 示例设计 / 先看一个让人头疼的场景”的关键对象与数据流，解释“它说得没错，但完全不是你要的。”，并用源码位置、日志或 Trace 标注证据。

为“Prompt Engineering（05） - Few-shot 示例设计 / Zero-shot / One-shot / Few-shot：到底差在哪”设计正常与异常输入，验证“很多你用语言说不清的要求（语气、格式、边界怎么判），一个例子就讲明白了。”，输出首个偏差位置与回归测试结果。

实现“Prompt Engineering（05） - Few-shot 示例设计 / Few-shot 的威力：看对比”的最小代码或配置，检验“我们没有用一句「请只输出一个词」的命令，而是用三个例子让模型自己看出了规律：输入是评论，输出是单个情感词，不要解释。”，输出命令、结果与 Diff，并说明不适用边界。

本章目标：理解「示例驱动」的威力，学会用几个精心挑选的例子，让模型精准对齐你想要的输出。

一、先看一个让人头疼的场景

你想让模型把一堆商品评论分类成「正面 / 负面 / 中性」。你直接问：

判断这条评论的情感：物流有点慢，但东西还行。

模型可能回你一大段：

这条评论包含了两种情绪。一方面，用户对物流速度表示不满（"物流有点慢"）；
另一方面，对商品本身基本满意（"东西还行"）。综合来看，情感偏向中性偏正面……

它说得没错，但完全不是你要的。你只想要一个词：中性。结果它给你写了一段小作文，还得你自己再去读一遍判断。

问题出在哪？你没告诉它「输出长什么样」。光靠文字描述「请只输出一个词」有时也不稳定。这时候，最有效的办法不是描述，而是直接给它看几个例子。这就是少样本提示。

二、Zero-shot / One-shot / Few-shot：到底差在哪

这三个词听着唬人，其实就是「给不给例子、给几个例子」的区别：

叫法	给几个示例	通俗理解
Zero-shot（零样本）	0 个	直接下命令，不举例
One-shot（单样本）	1 个	给一个例子打个样
Few-shot（少样本）	2 个以上	多给几个例子，让它摸清规律

打个比方：你带一个新人做数据标注。

Zero-shot：你只说「把这些评论分成正面、负面、中性」，然后让他直接上手。他可能理解得跟你不一样。
One-shot：你先做一条给他看：「你看，这条『质量很好』我标成正面」。他立刻明白个大概。
Few-shot：你做三四条不同情况给他看，连「物流慢但东西好」这种纠结的也示范了。他基本就能跟你标得一模一样。

示例的本质，是用「展示」代替「描述」。 很多你用语言说不清的要求（语气、格式、边界怎么判），一个例子就讲明白了。

三、Few-shot 的威力：看对比

还是上面那个情感分类任务，我们改成 few-shot 写法：

判断每条评论的情感，只回复一个词：正面、负面 或 中性。

评论：质量超出预期，五星好评！
情感：正面

评论：用了一周就坏了，垃圾。
情感：负面

评论：和描述基本一致，没什么特别的。
情感：中性

评论：物流有点慢，但东西还行。
情感：

这次模型几乎一定只回你一个词：

中性

发生了什么？我们没有用一句「请只输出一个词」的命令，而是用三个例子让模型自己看出了规律：输入是评论，输出是单个情感词，不要解释。模型是「模式补全」的高手，你给它一个清晰的模式，它就会照着填。

一句话记住：与其费劲描述你要什么，不如给它看你要什么。

四、怎么挑出「好示例」

示例不是随便抓几个就行，挑得好不好直接决定效果。记住四条：

4.1 覆盖典型情况

每一类、每一种常见输出都应该至少出现一次。做三分类，就别只给「正面」和「负面」的例子——模型没见过「中性」的样子，遇到中性就会乱猜。

4.2 一定要含边界/难例

最容易出错的，往往是那些「模棱两可」的情况。把它们做成示例，效果最好。比如上面「物流慢但东西好」这种夹杂两种情绪的，正是该放进示例里的——它直接教会模型：这种情况算「中性」。

4.3 格式必须统一

所有示例的格式要一模一样：同样的字段名、同样的标点、同样的换行方式。模型对格式极其敏感，你这条用「情感：」，下一条用「结果 -」，它就会困惑该学哪个。

4.4 内容要准确无误

示例就是「标准答案」。你示例里标错一个，模型就会跟着错。 给示例前务必自己核对一遍，错误的示例比没有示例更糟。

五、给几个示例？格式怎么定

数量：

简单任务（情感分类这种）：2-5 个通常就够。
类别多、规则复杂：可以多给，但很少需要超过 10 个。
给太多的坏处：占用上下文、变慢、还可能因为示例分布不均，把模型「带偏」。
经验法则：从 3 个开始，不够再加，每加一个都看看是否真的变好了。

格式建议：

用清晰、固定的分隔。常见的有 输入：/ 输出：、Q: / A:，或者直接用 Markdown 结构。
让「示例区」和「真正要处理的那条」长得一样，只把最后一条的答案留空，引导模型来补。
如果输出是结构化的（JSON、表格），示例里就要给出完整的结构化样例（这点和第 07 章紧密相关）。

六、什么时候用 / 什么时候别用

适合用 Few-shot：

输出格式有特定要求，文字描述说不清的。
分类、抽取、改写这类「有固定模式」的任务。
模型 zero-shot 时总是理解偏差、答非所问的。
需要统一风格/语气（比如固定的客服话术口吻）。

不必用（或别用）：

任务本身很简单，zero-shot 已经答得很好——加示例纯属浪费。
开放性创作（写一篇独特的小说），示例反而会限制模型发挥、让它模仿示例的腔调。
上下文非常紧张时，示例会挤占宝贵的空间。
你手头没有高质量示例——宁可不给，也别给错的。

七、一个完整的 Few-shot 实战示例（信息抽取）

光分类还不够，再看一个更实用的：从一句话里抽取结构化信息。比如从用户的报修描述中，抽出「设备、故障类型、紧急程度」。

从用户的报修描述中，抽取以下三个字段，按示例格式输出。

描述：打印机卡纸了，急着打合同，麻烦快点。
设备：打印机
故障：卡纸
紧急程度：高

描述：会议室的投影偶尔花屏，不影响用，有空再看看。
设备：投影仪
故障：花屏
紧急程度：低

描述：三楼空调不制冷，整层都热得受不了。
设备：空调
故障：不制冷
紧急程度：高

描述：我的电脑开机有点慢，平时还能用。
设备：

模型会稳定地补全：

设备：电脑
故障：开机慢
紧急程度：低

注意这几个示例做了什么：覆盖了不同设备（打印机/投影/空调）、不同紧急程度（高/低都有），「紧急程度」这种需要从语气里推断的字段也通过例子讲清了判断标准（「急着」「整层受不了」=高，「有空再看」「平时能用」=低）。这正是前面挑示例四原则的落地。

八、常见错误

示例本身就标错了：模型照单全收，越学越歪。给之前一定自己核对。
类别没覆盖全：三分类只给两类的例子，第三类必翻车。
格式不统一：示例之间字段名、标点、换行不一致，模型不知道学哪个。
只给「简单题」：全是一眼能判断的例子，遇到边界情况照样懵。要把难例放进去。
示例和实际输入对不上：示例是短句，实际要处理的是长段落——风格差太远，效果会打折。
示例堆太多：以为越多越好，结果又慢又占地方，收益却几乎为零。

九、最佳实践

先 zero-shot 试一把：能用就别加示例，加示例是为了解决具体问题，不是默认动作。
从 3 个示例起步：覆盖典型 + 至少 1 个边界案例，不够再逐个加。
格式严格对齐：所有示例和最终输入用同一套模板，最后一条留空答案。
示例当标准答案对待：宁缺毋滥，错的示例不如不给。
示例选有代表性的真实数据：别自己编太理想化的例子，要贴近你真实会遇到的输入。
和格式控制配合：要结构化输出时，示例里就给出完整结构（见第 07 章）。

十、本章小结

Few-shot = 在提示词里给模型几个「输入→输出」的例子，用展示代替描述。
它的威力在于：很多语言说不清的要求（格式、语气、边界判断），一个例子就教明白了。
挑示例四原则：覆盖典型、含边界难例、格式统一、内容准确。
数量从 3 个起步，按需增加；简单任务和开放创作通常不需要。
核心心法：与其描述你想要什么，不如给它看你想要什么。

下一章我们讲思维链（CoT）——当任务需要「推理」而不只是「模仿」时，怎么让模型把思考过程一步步写出来，从而答得更准。

十一、配套 Demo

见 提示词工程-demo/05-demo/：一个可直接复制使用的「评论情感分类」few-shot 提示词模板，含 4 个精选示例。README 里还附了「去掉示例 vs 保留示例」的对照，你可以亲手跑一遍，感受示例带来的差别。

十二、动手实践：demo：少样本提示模板（评论情感分类）

这个 Demo 不用写代码、不用装东西。目的：让你亲手感受「给几个示例」对结果的影响。

12.1 怎么用

打开任意一个 AI 对话工具（ChatGPT、Claude、文心、通义、Kimi…都行）。
先复制下面的「❌ 无示例版」，跑一遍，看输出。
再复制「✅ Few-shot 版」，跑一遍，对比。
重点观察：有示例时，输出是不是更短、更规范、更符合预期。

12.2 ❌ 无示例版（Zero-shot）

判断下面这条评论的情感：
物流有点慢，但东西还行。

👉 可能的问题：模型可能给你一大段分析，或者输出「正面偏中性」这种你没法直接用的词，每次格式还不一样。

12.3 ✅ Few-shot 版（带 4 个精选示例）

判断每条评论的情感，只回复一个词：正面、负面 或 中性。

评论：质量超出预期，五星好评！
情感：正面

评论：用了一周就坏了，垃圾。
情感：负面

评论：和描述基本一致，没什么特别的。
情感：中性

评论：物流有点慢，但东西还行。
情感：中性

评论：客服态度差，再也不来了。
情感：

👉 模型会稳定只回一个词（这里应是 负面）。

12.4 这 4 个示例为什么这么挑

示例	它负责教模型什么
「质量超出预期」→ 正面	典型正面长啥样
「用了一周就坏了」→ 负面	典型负面长啥样
「和描述基本一致」→ 中性	典型中性长啥样（三类都要覆盖！）
「物流慢但东西还行」→ 中性	边界难例：夹杂两种情绪时怎么判

这正是第 05 章「挑示例四原则」的落地：覆盖典型 + 含边界难例 + 格式统一 + 内容准确。

12.5 进阶玩法：换成抽取任务

把分类换成「抽取结构化信息」，威力一样。复制下面这个跑跑看：

从用户的报修描述中，抽取三个字段，按示例格式输出。

描述：打印机卡纸了，急着打合同，麻烦快点。
设备：打印机
故障：卡纸
紧急程度：高

描述：会议室的投影偶尔花屏，不影响用，有空再看看。
设备：投影仪
故障：花屏
紧急程度：低

描述：我的电脑开机有点慢，平时还能用。
设备：

👉 模型会照格式补出 设备：电脑 / 故障：开机慢 / 紧急程度：低。

12.6 你应该观察到的差别

无示例：输出长短不一、格式飘忽，有时还夹带解释。
有示例：输出干净、统一、可直接用——你没多说一句「请简洁」，是示例把规矩立住了。

这就是少样本提示的核心价值：用展示代替描述。

十三、总结

先看一个让人头疼的场景：它说得没错，但完全不是你要的。
Zero-shot / One-shot / Few-shot：到底差在哪：很多你用语言说不清的要求（语气、格式、边界怎么判），一个例子就讲明白了。
Few-shot 的威力：看对比：我们没有用一句「请只输出一个词」的命令，而是用三个例子让模型自己看出了规律：输入是评论，输出是单个情感词，不要解释。
怎么挑出「好示例」：每一类、每一种常见输出都应该至少出现一次。
给几个示例？格式怎么定：给太多的坏处：占用上下文、变慢、还可能因为示例分布不均，把模型「带偏」。
什么时候用 / 什么时候别用：输出格式有特定要求，文字描述说不清的。