过时的 Few-Shot 示例以及你的提示词仓库所忽略的半衰期

打开任何已经上线超过九个月的 AI 功能的系统 Prompt。向下滚动，越过角色描述，越过格式规则，越过安全护栏。停在标题为 <examples> 或 ## Examples 的块，或者是你的团队在某人把前三个好用的 Slack 线程复制到代码块的那天给它起的任何名字。读一读它们。有 60% 的可能性，其中至少有一个引用了已经更名的功能、一个已不存在的按钮，或者产品经理在两个季度前悄悄砍掉的工作流。

这种衰退从评测（eval）仪表盘上是看不出来的。评测得分是绿色的。它们已经绿了好几个月了。它们之所以是绿色的，是因为评测集是针对 Few-shot 示例所引用的同一个产品界面编写的，两者已经同步老化。模型正在完美地模仿去年的产品，而在一个以此标准打分的测试集上，它是合格的，然而真实用户在与今年的产品互动，并默默忍受由此产生的幻觉（confabulations）。这就是没有人写进 LLMOps 路线图的半衰期。

Few-shot 示例通常被视为一次性产物：有人在初始 Prompt 迭代期间手工挑选了它们，展示了比 Zero-shot 高出 4 个点的提升，提交代码，然后就离开了。Prompt 的其余部分——角色描述、工具 Schema、输出格式——会被定期编辑，因为这些部分的更改会产生立即且可见的失败。而 Few-shot 则会产生缓慢且不可见的失败。它们像化石层一样留在 Prompt 中，编码了被捕获那一周的产品分类体系。

为什么这种腐败始终不可见

过时的 Few-shot 最令人不安的特性是，它们的失败形式正是你的评测套件为了避开而构建的。标准的评测集在固定的输入-输出对网格上对准确性进行评分。如果 Few-shot 说“当用户询问 Insights Dashboard 时，回复 X”，而你的评测案例也说“用户询问 Insights Dashboard，预期回复 X”，那么这两个产物都指向产品的同一个考古层。评测通过了。Prompt 是正确的。但在六个月后，产品将该功能称为 Analytics Workspace，而模型继续以从容的自信称其为 Insights Dashboard。

这是没有人明确指出的评测耦合问题。Few-shot 示例和评测案例往往是共同创作的——同一个工程师、同一周、同一个产品快照。它们共享同一个事实来源，这意味着它们共享同一个失败模式。当产品发生变化时，这两个产物会一起过时，而你的 CI 中没有任何东西能捕捉到它，因为两者相对于彼此都不是异常的。

第二个不可见向量是 Few-shot 示例更多地是在教授行为而非内容。一个见过三个“以带有项目符号的两段话进行回复”示例的模型，即使示例的内容已经过时，也会以带有项目符号的两段话进行回复。结构的提升在过时中幸存下来，这就是为什么评测数据没有崩盘。语义准确性则会逐度下降，低于任何汇总指标的阈值。

第三个不可见向量是生产日志的幸存者偏差。那些尝试了更名后的功能并得到错误回复的用户，要么放弃了，要么提交了一个低优先级的支持工单，或者私下记录下 AI “有点奇怪”并绕过它。这些信号都不会传回 Prompt 仓库。与此同时，遗留路径上的用户仍然能得到正确的答案，因为 Prompt 对他们所处的世界来说是正确的。汇总的满意度指标保持平稳。漂移隐藏在长尾之中。

过时的 Few-Shot 内部究竟在腐烂什么

让我们逐一梳理这些失败模式，因为“过时”这个词太笼统，无法作为行动指南。有趣的衰退往往是机械性的。

更名的功能：示例引用了 Insights Dashboard；产品现在称其为 Analytics Workspace。模型在回复新用户时使用旧名称，用户在 Google 上搜索却一无所获。支持团队收到了工单。

被移除的界面：示例引导用户“点击右上角的齿轮图标并选择导出”。齿轮图标在八个月前就被行内的上下文菜单取代了。模型给出了自信但错误的导航指令，用户照做后却发现走进了死胡同。

重构的 API 形状：示例显示一个工具调用返回 {"user_id": ..., "subscription_tier": "pro"}。API 现在返回 {"user_id": ..., "plan": {"tier": "pro", "billing_cycle": "annual"}}。运行时工具调用仍然有效，因为你的代码进行了适配，但模型的下游推理引用了旧的字段形状，这会作为不存在的幽灵键（phantom keys）泄露到回复中。

漂移的人设和语气：示例编写时品牌语调是“俏皮的技术宅”。今年的语调是“冷静且咨询式”。Few-shot 仍然显示感叹号和“Awesome!”开场白。每一次回复都带着一丝前一个品牌时代的陈旧气息。

过时的政策边界：示例展示了对某一类内容的拒绝模式，而该类别后来已从“拒绝”改为“提供披露后回答”。模型在政策现在允许的案例中继续拒绝，而政策团队对此毫无头绪。

过时的推理模式：示例展示了一个三步分解，这对于旧的、更小的模型是有意义的。当前的模型可以在一个步骤中解决相同的问题，强制冗长的分解会浪费 Token 并增加延迟。示例所教授的策略比模型自己发明的还要差。

其中的每一项对于汇总评分来说都是不可见的，但对于任何对照当前产品阅读 Prompt 的人来说都是显而易见的。工作不在于检测——而在于定期重新阅读的纪律。

真正行之有效的维护纪律

解决方法并不是“更频繁地审查提示词”。每个团队都这么说，但没人真的去做，而且被审查的往往只是有人正在积极编辑的部分。Few-shot 示例需要一套专门的维护纪律，因为它们的衰退方式与提示词的其他部分不同，必须对其进行专门的维护。

第一部分是溯源元数据 (provenance metadata)，这被视为每个示例的硬性要求。没有元数据的示例就像一个悬挂指针 —— 没人知道它是为了防范哪种失败模式、引用的是哪个版本的产品，或者它是否在上次模型迁移中幸存。我推动团队使用的元数据块包括：示例编写日期、所假设的产品版本或功能开关 (feature flag) 状态、添加该示例是为了解决哪种失败模式（如果有的话，附上事件或评估案例的链接）、校准时参考的模型版本以及负责的工程师。这些都不需要放在提示词本身中 —— 可以放在 sidecar 文件、示例上方的 docstring 或提示词构建步骤在组装前会剔除的结构化注释块中。重点是，未来的你可以在无需进行“考古”的情况下回答“为什么这个示例在这儿？”。

第二部分是定期审查，且与提示词编辑脱钩。我见过行之有效的默认节奏是：对于早于六个月的示例每季度审查一次，此外在每次模型迁移时进行强制审查。这种审查不是“评估分数是否仍然通过” —— 那个问题已经有了答案，且并不相关。审查是由两名工程师对照当前产品大声朗读每个示例，并询问：这是否仍然描述了事物的运作方式？如果不是，修复或删除。如果是，更新元数据中的“最后审查日期”。对于一个拥有 12 个示例的提示词，整个练习只需一个小时，却能节省下游四分之一的故障排查时间。

第三部分是评估解耦。解决“绿色评估 (green-eval) 问题”的结构化方案是，根据与 few-shot 示例不同的事实来源来编写评估案例。最简单的方法是从生产环境的 trace 中获取评估案例 —— 真实的终端用户输入，而非人工挑选的 —— 并由能够访问当前产品文档的判别器 (judge) 进行评分。评估集仍然会漂移，但它与提示词库的漂移周期不同，这意味着至少其中之一能捕捉到衰退。更好的做法是：建立一个小型“功能词汇”评估，专门探测更名后的界面 —— 给模型一个查询，并检查其回复是否使用了当前名称而非历史名称。这种评估快速、廉价，且能捕捉到上述大部分失败模式。

第四部分是删除偏好。我观察过最强的团队坚持一条规则：一个示例必须在每次季度审查中证明其存在的合理性，否则就会被删除。示例并不是免费的。它们消耗 token，以不一定理想的方式塑造行为，并且会不断堆积。一个单调增长的提示词库，其半衰期正在下降。那些能够交付可靠 AI 功能的团队，是敢于删除内容的团队。

一套具体的审查协议

针对每个 few-shot 示例，按顺序询问：

• 它是否引用了自示例编写以来已更改的任何产品界面 —— 功能名称、按钮、 URL、工具 schema、API 字段？
• 它的语调、长度或结构是否符合当前的品牌调性及当前模型的性能？
• 添加它所针对的失败模式是否仍然存在，或者模型是否已经进步到不再需要它了？
• 是否有更新的生产环境 trace 能更好地展示同样的经验教训？
• 如果删除这个示例，提示词是否仍能通过评估？

最后一个问题最有用，也最少被提及。如果删除一个示例不会改变评估分数，那么该示例要么与另一个示例重复，要么与提示词的其余部分重复，或者是在防范一个你已不再面临的失败模式。在任何一种情况下，该示例都在占用 token 并塑造行为，却没有任何可衡量的提升，应当被删除。这种“移除后的评估分数检查”是一项廉价测试，你可以在几分钟内针对任何非琐碎示例运行，而大多数团队从未运行过。

对于每个幸存的示例，更新溯源元数据，更新“最后审查日期”，然后继续。整个协议对于典型的提示词只需 40 分钟。其复合价值在于，你的提示词库不再堆积“化石层”，你的回复不再悄悄引用已废弃的功能，而你的评估看板也会成为一个你真正可以信任的指标。

半衰期是真实存在的，你可以选择它

Few-shot 示例不是配置，也不是样板代码。它们是提示词中与产品最相关、与语境结合最紧密、衰退最快的部分。由于该领域尚未给这个问题命名，两年来它们一直被当作配置对待。本应捕捉到衰退的评估看板却没有捕捉到，因为看板和示例共享同一个随时间老化的事实来源。

选择你重新阅读 few-shot 的节奏。如果你不选择，那么节奏就会变成“每当有真实用户大声投诉，以至于有人不得不去提示词库里‘深挖’时”。这是默认做法，它比每季度一次更慢，也比有计划的审查更痛苦。交付 AI 功能时间最长的团队并不是提示词库规模最大的团队，而是每个季度删除示例最多的团队。