示例（少样本）是提示词里最贵的部分
示例能显著提升稳定性，但也吃 token、吃注意力。给多少、给什么，需要设计而不是堆。
三个原则
一、少而准
- 通常 2~3 个示例就能覆盖格式与风格；再加往往收益递减；
- 一个完整正例 + 一个边界例（字段为空、输入极短、含噪声）比五个同类正例有用；
- 如果非要更多，先检查是不是任务描述本身没写清。
二、覆盖"容易出错的地方"
示例的作用不是"说明任务"（描述已经说了），而是钉住容易漂的点：
- 输出格式的边界（空值怎么写、列表只有一项怎么写）；
- 判断口径的边界（"部分相关"算不算相关）；
- 语气与长度（先给结论、最多几行）。
三、保持与真实分布一致
- 示例的输入风格要接近线上真实输入（长度、语言、是否含噪声）；
- 别用"教科书式"的干净例子，否则线上遇到真实噪声就崩；
- 示例里的字段值不要与真实数据冲突（会让模型照抄错误值）。
该不该用示例：一个判断顺序
- 任务能不能用规则解决？（能就别上模型）
- 任务描述 + 输出 schema 够不够？（够就别加示例）
- 还漂 → 加 1 个正例；
- 仍漂 → 加 1 个边界例（通常这一步收益最大）；
- 还漂 → 考虑换模型或拆分任务（不要继续堆示例）。
成本与可维护性
- 每个示例都会进入每次调用，成本 × 调用量；
- 示例改了要重跑评测（示例也是一种"代码" ✔ 要版本化）；
- 把示例与提示词一起放进版本库，并在变更说明里写清"为什么加这个例子"。
常见反模式
- 把示例堆到十几个，靠"感觉更稳"；
- 示例与 schema 不一致（示例里多了字段）；
- 示例用的是过时口径，没人知道为什么这么写；
- 把用户投诉的案例原样塞进示例（含个人数据，合规风险）。