零样本、示例与反例
本节目标
理解 zero-shot 与 few-shot 的取舍，能选择覆盖边界的示例，并避免示例泄漏、顺序偏差和格式不一致。
把零样本当作可比较的基线
**零样本（zero-shot）**只给规则与输入，成本低、维护简单。**少样本（few-shot）**提供若干输入—输出对，适合标签边界、语气、格式或例外规则难以仅靠文字说明的任务。工程上可先保留一个零样本版本作为对照，再让评测结果决定是否加例子；这不是所有模型都应“先零样本”的教条。
供应商建议可能不同，也可能随模型家族变化。以 2026-07-21 的文档为例，OpenAI 强调示例要覆盖多样输入，Google 的 Gemini 提示设计文档则明确建议始终包含 few-shot 示例。这些都不是跨模型的普遍定律；应固定模型配置，在自己的输入分布上比较零样本与少样本版本。
示例不是越多越好。它们占用上下文，并可能让模型模仿偶然特征。few-shot 是推理时上下文，不等于对模型进行训练。选择示例时覆盖：
- 一个典型正例；
- 一个容易与邻近类别混淆的边界例；
- 一个缺少信息、应返回
unknown的例子； - 一个包含不可信命令但应当按数据处理的反例。
对齐格式和标签
规则说 technical，示例却输出 tech，模型会收到冲突信号。示例的字段、大小写、空值处理和解释长度必须与输出契约一致。
输入：页面显示“付款成功”，但下载按钮是灰色。
输出：{"label":"technical","reason":"付款完成后下载功能不可用","evidence":"下载按钮是灰色"}
输入：只写了“帮帮我”。
输出：{"label":"other","reason":"没有足够信息判断问题类型","evidence":null}对生产数据做去标识化，不要把真实账号、密钥或受保护个人信息放入提示仓库。训练/评测样例也要分开，避免反复针对测试集调提示后把“记住答案”误认为泛化。
“反例”也应给出期望行为：展示带有越权命令或邻近标签的输入，并配上正确输出。不要只陈列一个错误答案再让模型猜哪里错；模型可能直接模仿错误格式或措辞。提示内示例、开发集和保留评测集应是不同资产，任何样例一旦被反复用于调参，就不再是可靠的保留样例。
用最小对照实验判断价值
固定模型配置与评测集，比较：
- 只有规则的 v1；
- 增加典型例的 v2；
- 增加边界例的 v3。
记录总体正确率之外的错误类别，例如“缺失信息时乱猜”“JSON 无法解析”“边界类混淆”。若 v3 只改善训练样例而损害新样例，应回退或重选示例。
常见误区
- 只选完美例子：无法教会模型遇到模糊输入时怎么办。
- 标签分布失衡：十个例子九个都是同一类，会产生非预期偏向。
- 把长推理当标准答案：泄露内部信息、增加成本，也未必改善最终任务指标。
- 示例与当前业务漂移：规则改了，旧例子没更新。模板和样例必须一起版本化。
练习与自测
为“客服消息三分类”写 4 个示例，至少包含一个“信息不足，应归为 other”和一个含提示注入文本的案例。字段必须与 本库响应 schema 一致。遮住输出后请同伴标注；若人类也无法一致判断，先修改标签定义，而不是继续堆例子。
掌握检查
- 我能说明零样本与少样本的成本、收益和适用条件。
- 我的示例覆盖典型、边界、信息不足和对抗输入，而不是只选“好看”的正例。
- 示例的字段、标签、空值和长度约束与正式契约完全一致。
- 我用同一模型配置和保留样例比较版本，不凭供应商口号决定策略。
下一步
进入 结构化输出与契约，把示例中的约定变成程序可检查的合同。
参考资料
- OpenAI：Prompt engineering（访问于 2026-07-21）
- Anthropic：Prompt engineering overview（访问于 2026-07-21）
- Google：Prompt design strategies（访问于 2026-07-21）