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