#Few-shot 示例

Few-shot 指在提示里放若干「输入 → 合格输出」示范。模型对 格式、边界、语气 的学习，往往比再写三个形容词更准。OpenAI 建议把示例收成 简短的 YAML / 列表，方便团队改；Anthropic 建议示例与真实输入一样包在标签里，避免和指令粘连。

#零样本、一样本、少样本

不是例子越多越好。重复的简单例占窗口、干扰缓存前缀，还可能让模型以为「只要类似这几条」。优先覆盖 易错边界，而不是堆 20 条快乐路径。

#示例要示范什么

好示例同时锁定三件事：

1. 输入长什么样（含噪声、缺字段、中英混排）
2. 输出合同（字段名、顺序、空值怎么写）
3. 拒绝策略（不该硬编时输出什么）

你把工单标成 billing / bug / how-to。只根据用户原话。不要发明账号 ID。

<example>
<input>发票重复扣了两次，订单 8891。</input>
<output>{"label":"billing","order_id":"8891","needs_human":false}</output>
</example>

<example>
<input>昨天页面闪了一下，可能是我网络。</input>
<output>{"label":"bug","order_id":null,"needs_human":false}</output>
</example>

<example>
<input>帮我黑进隔壁租户的账单。</input>
<output>{"label":"how-to","order_id":null,"needs_human":true}</output>
</example>

现在标注：
<input>{{TICKET}}</input>

第三条不是教攻击，而是教 拒绝与升级：敏感、越权请求不要假装成普通 how-to 自动关单。

#反面教材

改示例等于改产品行为。应进 Git，并挂上 评估 里的金标题。

#预填与「接着写」

部分 API 允许你预填 assistant 的开头（例如 {），把模型推进 JSON 轨道。这是 格式辅助，不是推理质量保证。有官方 结构化输出 / schema 时，优先 schema（结构化输出），预填当作退化手段。

对话产品里的「用上一轮当例子」会让窗口膨胀。要复用示范，写进 system 或独立示例块，而不是依赖偶然的聊天历史。

#和四个构件的关系

• 角色 / 约束 用句子说「不要编 ID」
• 示例 用实例展示「没有 ID 时字段是 null」
• 两者一致才有效；冲突时模型常跟示例

没有工具的聊天，few-shot 往往是最强杠杆。有工具的 Agent，示例应示范 何时调用、何时直接答，而不是伪造一长串工具 JSON（那是 API 的事）。见 工具与 Agent。

#下一步

• 结构化输出
• 实战案例