目录
- 一、先厘清概念
- [二、Zero-Shot Prompt 的特点](#二、Zero-Shot Prompt 的特点)
- [三、One-Shot Prompt 的特点](#三、One-Shot Prompt 的特点)
- 四、核心差别对比
- 五、适用场景建议
- [更适合 Zero-Shot 的场景](#更适合 Zero-Shot 的场景)
- [更适合 One-Shot 的场景](#更适合 One-Shot 的场景)
- 六、实践建议
- 七、小结
一、先厘清概念
在写 Prompt 时，我们经常听到 Zero-Shot 、One-Shot 和 Few-Shot 。它们描述的是同一件事：在任务描述之外，是否给模型提供示例，以及提供多少个示例。
示例数量并不是一个非黑即白的问题，而是一条连续的"约束光谱"。从 0 个示例到 1 个示例，再到多个示例，模型收到的参照信息越来越多，输出也越来越容易被约束。
- Zero-Shot Prompting：不提供任何示例，只描述任务和要求，让模型直接完成。它依赖的是模型的预训练知识、语言理解能力和指令遵循能力。
- One-Shot Prompting ：在任务描述之后，提供 一个 示例，再让模型处理真实输入。这个示例通常会承担"模板"的角色，帮助模型理解你期望的输出格式、语气和处理方式。
- Few-Shot Prompting：提供多个示例，通常用于更复杂、边界更模糊的任务。本文重点讨论前两者。
从实用角度看，判断一种 Prompt 属于哪一类，可以观察这几个维度：
- 任务描述之外，是否给了示例；
- 给了几个示例；
- Prompt 的总长度和 token 消耗；
- 对输出格式、风格、结构施加的约束程度；
- 编写和维护 Prompt 的时间成本。
理解这两者的差别，能帮你在不同任务中更准确地控制成本、稳定性和输出质量。这不仅是"省 token"的问题，更关系到生产环境中结果是否可控、是否适合自动化处理。
二、Zero-Shot Prompt 的特点
Zero-Shot 的核心是：只给指令，不给示范。模型需要完全依赖预训练阶段学到的知识和指令遵循能力来完成任务。
这里要强调一点：Zero-Shot 并不等于"什么都不给"。指令本身就是一种强约束。它真正缺少的，是"示例示范"------也就是通过一个具体案例，让模型明确"输入长什么样，输出就必须长成什么样"。
优点：
- Prompt 简短，token 消耗少。 没有示例意味着输入更短，调用成本更低、响应速度更快，适合高频调用。
- 编写快速，适合大量通用任务。 不需要为每个任务专门准备样例，写完指令就能直接使用。
- 对模型的基础能力要求较高，能检验模型本身是否理解任务。 如果一个简单指令模型都无法正确执行，通常说明任务描述不够清晰，或者模型能力不足，此时再考虑补示例或换方式。
局限：
- 输出格式不稳定，容易"自由发挥"。 同一个任务，不同次调用可能得到不同的排版、措辞和结构。
- 当任务定义存在歧义时，模型可能理解偏差。 例如"把日期格式化"，模型可能不确定你要的是
YYYY-MM-DD、MM/DD还是中文日期。 - 对专业术语、特殊格式、品牌语气等要求较难一次性对齐。 因为没有示范，模型只能"猜"你期望的口径。
典型示例：
text
请把下面的句子翻译成英文：
今天天气很好，我们去公园散步吧。模型可能输出：
text
The weather is nice today. Let's go for a walk in the park.也可能输出成另一种表达，例如把时态处理得不同。两种翻译意思都成立，但措辞、时态和语气并不受控。这里没有给任何翻译风格示例，模型直接输出即可。
因此，Zero-Shot 更适合那些任务清晰、答案开放、格式不强制的场景。简单来说：只要结果能看、能用、不要求统一格式，Zero-Shot 通常就够了。
三、One-Shot Prompt 的特点
One-Shot 的核心是：先给一个高质量示例，再让模型照着做。这个示例会成为模型对齐格式、语气和任务边界的重要参照。
可以这样理解：Zero-Shot 只是告诉模型"做什么"，而 One-Shot 进一步展示了"做出什么样子"。示例把抽象的要求落成了一个具体范本，模型只需要尽量模仿那个范本，就能大幅提升一致性。
优点：
- 输出格式更稳定，容易控制。 有了参照系，模型更容易锁定 JSON、表格、列表等结构。
- 能向模型示范你期望的语气、颗粒度和结构。 示例里多长、多详细，输出通常也会跟随同样的颗粒度。
- 对结构化抽取、格式转换、风格模仿类任务尤其有效。 这类任务往往"单靠描述说不清"，给一个例子反而最省事。
局限：
- Prompt 更长，token 消耗略高。 增加示例会增加输入长度，需要在成本与效果之间权衡。
- 如果示例质量差或与真实输入差异大，反而会误导模型。 示例越不具代表性，模型越容易学到错误的特征，这就是常说的"示例偏差"。
- 示例本身可能带来偏见，需要谨慎选择。 示例中的语气、立场、标签方式，都可能被模型放大或复制。
典型示例：
text
请把用户输入改写为简洁的新闻标题。
示例：
输入：公司发布了新一代智能手表，续航提升明显。
输出：新一代智能手表发布，续航大幅提升
现在请改写：
输入：研究团队在电池材料领域取得重要突破。
输出：示例部分已经把"怎样算简洁、信息如何压缩、句式如何组织"都示范了一遍，模型接下来只需要照着做。理想情况下，模型应输出类似"研究团队电池材料研究取得重要突破"的表达。
由此可见，设计 One-Shot 示例时，真正重要的是输入输出必须同分布，输出内容要干净、无多余信息，这样示例才能稳定发挥"模板"的作用。
四、核心差别对比
| 维度 | Zero-Shot | One-Shot |
|---|---|---|
| 是否提供示例 | 不提供 | 提供一个 |
| Prompt 长度 | 较短 | 稍长 |
| token 成本 | 较低 | 略高 |
| 输出稳定性 | 相对较弱 | 更稳定 |
| 格式控制能力 | 一般 | 较强 |
| 编写成本 | 低 | 中 |
| 适用任务 | 通用、明确、开放 | 格式明确、风格统一、结构化 |
从表格可以看出：Zero-Shot 更便宜、更省事，但可控性弱；One-Shot 略贵一点，却能换来明显更高的稳定性。两者的取舍本质上是成本、速度与输出可控性之间的平衡。
需要注意，Zero-Shot 和 One-Shot 并不是对立关系，而是同一坐标系上的两个点。实际使用时，完全可以先从 Zero-Shot 开始，发现输出不稳定后再加一个示例；如果还不够，再逐步增加示例，自然过渡到 Few-Shot。关键在于：用最小的示例成本，买到足够的稳定性。
五、适用场景建议
更适合 Zero-Shot 的场景
- 摘要、翻译、改写、扩写等通用语言任务。 这些任务的目标相对开放，答案不唯一，通常不需要严格锁定格式。
- 简单的文本分类、情感判断、关键词提取。 只要模型能输出大致符合要求的结果，就能直接使用。
- 头脑风暴、创意发散、初稿生成。 这类场景更需要模型发挥，而不是被示例限制住表达方向。
- 任务本身定义清晰，不需要额外示例约束。 当指令已经足够准确时，再加示例只会增加成本。
- 高频、低延迟、低成本的调用。 在批量处理、AP 请求量大的系统中，省下的 token 会非常可观。
更适合 One-Shot 的场景
- 要求输出特定 JSON、表格、列表等结构化格式。 尤其是结果要进入下游程序自动处理时，格式错误会比多消耗 token 更麻烦。
- 需要模仿固定语气、品牌风格或人物口吻。 语气这种东西很难用抽象语言描述清楚，给一个标准示例更容易对齐。
- 数据转换，例如"日期格式统一""手机号脱敏"等。 这类规则相对固定，带一个示例就能把处理口径锁死。
- 命名规范、标签体系、分类标准相对复杂的任务。 当规则复杂或边界模糊时，一个范式示例往往比长篇规则说明更有效。
- 团队协作、口径统一。 如果希望多位同事或多次调用产出相同风格，One-Shot 可以充当轻量的"风格标准卡"。
六、实践建议
-
先试 Zero-Shot，再决定是否加示例。 很多简单任务并不需要示例，直接写清楚要求即可。不要一开始就堆示例，那只会推高成本。
-
One-Shot 的示例必须与真实输入同分布。 如果你要处理医疗文本，就不要用娱乐新闻做示例。示例的领域、长度、语气都要尽量接近真实输入。
-
示例要简洁、明确，输出部分不要有多余内容。 一个干净、可复制的示例比一个冗长的示例更有效。输出中一旦混入解释、标点或多余字段，模型可能把这些也当成规则。
-
把格式要求写进指令，而不只是依赖示例。 例如同时说明"请输出 JSON，字段包括 name 和 score"。指令保证规则被明确表达，示例负责展示具体形态，二者配合更稳。
-
当 Zero-Shot 输出不稳定时，优先增加一个示例。 这是成本与效果之间性价比很高的折中方案。大多数格式不稳的问题，加一个正确示例就能显著改善。
-
把 Prompt 拆成"指令 + 约束 + 输出格式 + 示例"四个部分。 这样结构清晰，便于定位问题。比如输出不对时，可以先检查格式说明是否写清楚，再判断是否需要强化示例。
七、小结
Zero-Shot 和 One-Shot 并不是"谁更好"的关系，而是针对不同任务成本与稳定性需求的选择。当你追求快速、低成本、任务清晰时，优先考虑 Zero-Shot；当你需要锁定输出格式、风格或结构时，One-Shot 往往能带来明显提升。
一个实用的决策思路是：
- 任务足够简单，格式不强制，先用 Zero-Shot；
- 输出需要严格的格式、口径或风格，加一个示例，进入 One-Shot；
- 一个示例仍不稳定，或任务规则确实复杂，再继续增加示例，逐步转向 Few-Shot。
掌握两者的边界，你就能在 Prompt 设计中更灵活地做取舍，用最小的成本获得更稳定的输出。