Few-shot 不是「举例越多越好」，而是「每个例子都在教一个决策边界」。 堆 12 条相似好例，不如 3 条好例 + 1 条易错反例。

精选清单

  1. 任务同构：输入输出字段与线上一致。
  2. 标签口径统一：同一错误不要有时叫「拒识」有时叫「其他」。
  3. 覆盖边界：至少一条「刚好不合格」、一条「刚好合格」。
  4. 无捷径泄漏：例子里不要出现仅靠关键词就能抄的答案（除非你真要教关键词规则）。
  5. 脱敏：客户名、手机、内部代号已替换。
  6. 长度可控：单例过长会挤占真正查询的上下文。

操作流程

  • 从真实错题集抽候选 → 人工改成示意数据 → 按清单打分 → 只留高分。
  • 每月替换 1 条过时例子，而不是全盘重写。

已有相近文章 Few-shot 选择清单，本文更偏「策展与打分」；可对照着做。

迷你提示

评估下列候选 few-shot 是否保留（是/否+理由）：
维度：同构、口径、边界、捷径风险、敏感信息、长度。
只保留总分最高的 3 条，并指出缺失的边界类型。

相关阅读：Few-shot 选择清单、量规评分输出，见 AI 技能。

打分表（示意）

同构 0–2、口径 0–2、边界 0–2、无捷径 0–2、脱敏 0–1、长度 0–1，低于 7 分淘汰。季度复盘时看线上 bad case：若某类错误频发而例子库没有边界例，就补那一类，而不是平均加点「好例子」。

自动化方面，可用另一提示审核候选例是否泄漏答案捷径，但最终去留仍人工。注意：本文的策展清单与站内另一篇选择清单互补——一篇偏挑选步骤，一篇偏长期维护与打分。

反例的价值

一条高质量反例能教会模型「边界在哪里」。反例要标注「为何不合格」，否则模型可能模仿反例格式。反例中的敏感内容同样要脱敏。若任务是分类，正反例比例按真实先验大致匹配，避免全是极端案。

策展会议每月一次即可：30 分钟看打分表与线上 bad case。提示词正文保持短，例子库外置文件，便于版本管理。

版本冻结

上线前冻结例子集版本号，线上 bad case 先进入候选池，不立刻热更新冲垮基线。A/B 时一次只换例子或只换指令，便于归因。策展清单打分表可放进表格，让非提示工程师也能参与投票。示意分值为虚构量表。 精选的终点是「例子开始重复教同一边界」——那时该停。维护比堆量重要。示意打分表可按任务改维度。

例子库也要做废弃：产品改规则后，旧例会教错边界。设回顾日，过期例子归档而不是删除（便于对照）。示意维护节奏可按迭代速度调整。