少样本示例设计（考点 4.2）· CCAF 备考

本页目录5

这个考点是什么

少样本示例设计（few-shot / multishot prompting）指的是在 prompt 里放入若干「输入→输出」范例，用具体示范替代抽象的文字规则，让 Claude 通过模式匹配而不是重新解读指令来产出目标格式。

这是 Prompt Engineering 里效果最可靠的手段之一：当失败模式是「格式不统一、边界案例判断不一致」而不是「模型缺乏领域知识」时，示例往往比反复加重指令措辞更管用——文字规则仍需模型自行还原排版细节、自行判断边界，示例则直接把目标形状摆在眼前，少了这一层解读空间。

官方给出的标准是三个词：Relevant（示例贴近真实业务场景，不是泛泛的 demo）、Diverse（覆盖不同情形和 edge case，变化幅度要足够大，避免模型只学到一种狭窄、甚至无关的规律）、Clear（用 <example> 标签包裹单个示例，多个示例外层再套一层 <examples>，让 Claude 能把「这是示范」和「这是指令」区分开）。

数量上官方建议 3-5 个：太少（比如只给 1 个「完美」示例）信息量不足以体现任务的范围和边界。

值得注意的是，示例数量本身不是越多越可靠——真正决定效果的是 diverse 有没有做到位，只堆数量而彼此雷同的示例并不会让效果变好；但官方也指出，配合 prompt caching 使用时，可以把规模扩大到 20+ 个 diverse、高质量的示例进一步提升效果，因为缓存摊销了这部分上下文的重复成本。

考点还延伸到两个容易被忽略的用法：示例可以和 thinking 配合，在示例里嵌入 <thinking> 标签演示推理过程，模型会把这种推理模式泛化到自己的推理里；以及「negative examples」这个术语专指「不应该长成什么样」的反面示范，不是负数、差评来源或语气负面的示例。

为什么考

这个考点常见三种出题角度。一是直接记忆题：考 Relevant/Diverse/Clear 三个标准的准确措辞与 <example>/<examples> 标签用法、以及示例数量的一般建议（3-5 个），干扰项通常是「1 个完美示例就够」「示例只能放在 system prompt」等对官方表述的曲解。

二是术语字面陷阱题，比如把「negative examples」误读成负数示例、差评示例或语气负面的示例。

三是场景应用题：给出真实工程场景（PR 审查格式不统一、合同条款边界案例误判、财报 prose 抽取准确率偏低），要求判断该用 few-shot 示例还是更强硬的指令措辞、后处理渲染、多次模型调用来解决——考察的是「识别到 few-shot 适用之后，还要能判断它是否对症」这一层。

核心辨析

1
数量与质量的关系
官方建议 3-5 个高质量、多样化示例作为基本盘，少于这个数量信息量不足以体现任务边界；但示例数量本身不是可靠性的来源——真正起作用的是 diverse 有没有做到，只堆数量而彼此雷同不会让效果变好。

官方另外指出，配合 prompt caching 使用时可以扩展到 20+ 个 diverse、高质量示例进一步提升效果，这是特定场景下的进阶用法，不是「examples 越多越好」的一般规则。
2
Relevant / Diverse / Clear 三要素缺一不可
只做到「贴近真实场景」而不「多样」，模型仍会在边界案例上学偏；示例内容即使正确，不用 <example>/<examples> 标签与指令文本区分开（Clear），也可能被模型当成普通说明文字而非示范来对待。
3
何时选 few-shot 而非加强文字指令
当问题是「输出格式/风格不统一」而非「模型缺乏领域知识」时，few-shot 比重复强调、加重措辞的指令更有效，因为文字规则仍需模型自行解读排版细节，示例直接给出目标形状，减少了这一层解释空间。
4
few-shot 与 thinking 的配合是「演示推理模式」而不是「要求想得更久」
在示例里嵌入 <thinking> 标签展示推理过程，模型会把这种推理模式泛化到自己的 thinking block 中；这与调大思考量、要求「仔细思考」是两件不同的事。
5
negative examples 的准确定义是「展示输出不应该长成什么样」的反面示范（错误格式、错误推理、禁止内容），常见误读是把它当成含负数的示例、来自差评反馈的示例、或语气负面的示例——字面联想是最大的失分点。
6
面对边界模糊的分类任务（如同时含终止条款与不可抗力语言的合同条款），只增加更多标准案例的示例无助于提升准确率；必须专门构造边界案例示例，并展示「为什么归为 A 而非 B」的判断依据，这属于 Diverse 要素里「覆盖 edge case」的具体落地。

反模式对照

常见做法

只给 1 个措辞完美的示例，指望模型举一反三

正确做法

提供 3-5 个覆盖不同情形和边界案例的多样化示例

单个示例信息量不足以体现任务的范围和边界，模型容易把这一个特例当成唯一模板。

常见做法

把「扩到 20+ 个示例」理解成「数量堆上去就一定更好」，于是复制粘贴大量高度相似的示例

正确做法

先满足 3-5 个 Relevant、Diverse 的基本盘；确实需要扩大规模时，保证每个新增示例仍然 diverse，并配合 prompt caching 摊销上下文成本

官方确实提到配合 prompt caching 可以用 20+ 个 diverse、高质量示例进一步提升效果，但前提是 diverse 没有妥协——彼此雷同的示例无论堆多少，仍会让模型学到一种狭窄甚至无关的模式。

常见做法

把示例直接写进 prompt 正文，不做任何标记

正确做法

用 <example> 包裹单个示例，多个示例外层再套 <examples>

缺少标签时模型难以区分「这是要模仿的示范」还是「这是另一条指令」，容易把示例内容当成额外规则来执行。

常见做法

发现输出格式/风格不统一后，反复加强指令措辞去「命令」模型统一格式

正确做法

直接给出覆盖不同场景的目标格式 few-shot 示例

格式漂移通常源于模型对文字描述的排版细节自行解读，示例比复述规则更精确，能直接消除这层解读空间。

练这个考点

练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。

专练考点 4.2

该考点的公开题（免登录，含完整解析）：

← 返回考点目录