当文字指令产出不一致的输出时，例子能修好更多指令修不好的问题。这就是 few-shot prompting 的核心——通过具体的输入/输出对来示范期望的行为。
区别
Zero-shot — 只有指令，没有例子。“把发票编号、金额和日期提取成 JSON。“模型仅凭描述推断格式。
Few-shot — 指令加 2-4 个具体例子。“提取结果应该长这样：[输入文档] → [期望的 JSON 输出]。“模型看到模式然后跟着做。
“Shots”就是例子。Zero-shot = 零个例子。Few-shot = 几个例子。它们不是 API 调用，不是 system prompt 的段落，不是训练迭代。它们是 prompt 中的示范配对。
什么时候用哪个
Zero-shot 管用的场景是简单、无歧义、期望输出显而易见的任务：情感分类、基本摘要、直接的问答。如果模型不用例子就能稳定输出正确格式，就别加。
需要 few-shot 的时候：
- 输出格式必须高度一致（模型老是在 JSON 和 markdown 之间切换）
- 任务有模糊的边界情况（什么算”高优先级”？）
- 纯文字指令产出的结果不稳定（你已经试过加细节了，还是会变）
- 你需要示范特定的判断模式（数据缺失时返回 null）
格式一致性大杀器
Few-shot 例子是格式一致性的”终极武器”。如果你的 zero-shot 提取在指令写得很清楚的情况下仍然格式不一致，2-3 个展示 输入 → 期望 JSON 的例子会比任何额外的文字描述都更有效地强制统一格式。
原因是：例子是具体的，指令是抽象的。当指令的解读有歧义时，例子通过展示输出到底该长什么样来消除歧义。
实践指南
- 2-4 个例子是推荐范围。一个可能不够建立模式。超过四个收益递减，还白烧 token。
- 例子应该覆盖边界情况——包含一个数据缺失的案例（展示返回 null）、一个模糊的案例（展示判断标准）、和一个标准案例。
- 例子是逐请求的上下文，不是永久的模型修改。它们只对当前请求生效。下一个不带例子的请求就没有这个效果。
- Few-shot 对于减少提取中的幻觉特别有效：用一个具体例子展示”信息不存在时返回 null”，教会模型在数据不在时老实承认。
一句话总结： Zero-shot 只用指令；few-shot 加 2-4 个具体的输入/输出例子，在强制格式一致性和处理边界情况方面比纯文字指令更有效。