如何给 AI 提供少样本示例：用几个例子校准输出

少样本示例的作用，是让 AI 看到输入应该如何处理、输出应该长什么样，以及哪些边界不能越过。示例写得漂亮并不够，关键是让其中的处理规律能够迁移到新的输入。

例如，你希望 AI 把用户反馈整理成问题、影响和建议三个字段。只说“请按这个格式输出”，模型可能仍然不清楚一条反馈中哪些内容属于事实，哪些内容属于判断。给出几组输入和对应输出，再补一句判断说明，任务就会具体很多。

少样本提示适合格式稳定、判断规则可以示范、又不值得专门训练模型的工作。它可以帮助模型适应团队的写法、分类方式和交付粒度，但它不是把几段答案粘进去让模型照抄。示例必须和规则一起使用。

准备示例之前，先写出任务中最容易出错的地方。是字段分类容易混淆，还是语气和格式不稳定？是遇到空值不知道怎么处理，还是同一条输入可能有多个合理答案？示例应该优先覆盖这些难点，而不是把简单情况重复很多遍。

如果任务包含多个判断维度，可以把目标拆开。例如，会议记录整理要教会模型识别决定事项、待办、负责人和截止时间；文章改写要教会模型保留事实、调整段落和控制语气。一个示例不一定同时示范所有规则，但整组示例应该覆盖任务的关键路径。

示例还要说明什么不应该做。可以放一个边界案例，展示材料没有写明负责人时如何标记未指定，或者资料没有给出数字时如何写待确认。负面边界很有价值，因为很多错误不是格式不会，而是模型在空白处自作主张。

目标越清楚，示例越容易挑选。不要一上来收集大量历史答案，先列出任务规则，再从真实案例中挑能说明这些规则的内容。

好的示例组不是三份几乎一样的输入，而是让模型看到同一任务在不同条件下如何处理。可以变化主题、长度、语气、字段是否缺失和信息是否冲突，同时保持输出结构和判断逻辑稳定。

例如，做文本分类时，示例中可以包含明显属于某类的内容、边界模糊的内容、同时涉及两类的内容和无法判断的内容。这样模型学到的是分类边界，而不是某几个关键词。做摘要时，则可以加入短文、长文和带有重复信息的材料，示范信息取舍。

输出要有规律，但不能僵硬。字段顺序、标题格式和标记方式应当一致；内容长度可以根据输入变化。若示例中的每个答案都正好三句话，模型可能把句数误当成规则。需要在 Prompt 中说明哪些是固定格式，哪些可以随任务调整。

示例中的输入和输出最好使用清楚的分隔符，并标注示例一、示例二。长文本不要让示例和正式材料混在一起，否则模型可能把示例中的事实带入当前任务。

少样本不等于越少越好。示例数量应该由任务复杂度和边界数量决定。一个只有固定字段转换的任务，两个或三个示例可能足够；如果任务涉及分类、优先级和异常处理，就需要覆盖不同组合，而不是只放最常见的标准案例。

优先选择代表性强的示例。一个能展示缺字段处理的案例，可能比五个完整输入更有价值；一个能展示冲突处理的案例，可能比很多简单案例更能减少错误。示例不应只展示模型已经容易做对的部分。

示例之间不要互相矛盾，除非你明确解释差异。若同样的输入在不同示例里得到不同处理，模型需要知道是因为读者、时间范围、优先级还是其他条件发生了变化。没有解释的差异会让示例失去校准作用。

当模板面向多人使用时，示例还要保持足够短。太长的示例会挤占上下文，使用者也很难判断哪些内容是规则、哪些内容只是案例背景。

只给输入和输出，有时还不够。模型能看到结果，却不一定知道为什么这样处理。对关键示例补一行判断说明，可以把隐含规则显式写出来。例如：这条反馈虽然提到速度，但核心问题是错误提示不清，因此归入可用性问题；这里没有明确截止时间，所以保留为待确认。

判断说明不需要写成长篇分析，重点是解释容易混淆的选择。尤其要说明为什么没有采用另一个看起来也合理的分类、为什么删掉某段信息、为什么保留某个限定条件。

如果任务的最终输出不需要展示推理过程，可以把判断说明写成给模型的示例注释，并要求最终答案只输出规定格式。这样既能帮助模型理解规则，也不会让用户看到一大段无关解释。

判断说明本身也要遵守事实边界。它应该解释示例中的处理依据，不要借着示例引入材料之外的业务规则。

示例的一个风险，是模型记住了示例中的词语，却没有学会处理方法。输入材料中出现相似主题时，它可能直接复用示例里的句子、人物或数字。解决办法是要求它只学习结构和判断规则，正式任务中的事实必须来自当前材料。

可以在模板中加入：示例仅用于说明格式和处理方式，不得复制示例中的具体事实、数字、名称或句子；回答正式任务时，只使用本次输入材料。对于写作任务，还可以要求例子中的句式只作为参考，避免全文套用相同开头。

测试时要使用和示例不同的新输入。如果新输入只是把示例中的名词替换掉，无法判断模型是否真正迁移了规则。最好准备几个没有见过的组合，包括缺字段、长文本、冲突信息和超出范围的内容。

如果模型仍然照抄，可以减少示例中的装饰性表达，改用短而清楚的输入输出，并把固定格式直接写成规则。示例负责展示难点，规则负责说明原则，两者不要互相替代。

示例是否有效，不能只看它们本身输出得好不好，还要看模型对新输入的表现。可以另外准备一组不放进 Prompt 的测试案例，覆盖常见情况、边界情况和异常情况，然后逐项检查格式、准确性和错误类型。

测试结果最好记录成简单表格：案例编号、输入特征、期望处理、实际结果、问题类型和是否需要更新示例。若多个案例都犯同一种错误，说明模板缺规则或示例没有覆盖；若只有一个案例异常，先检查输入是否超出任务边界。

不要因为增加示例后某个案例变好，就认为模板整体变好。示例可能帮助一个边界，却让另一个任务被错误归类。每次调整后都要重新跑一小组代表性测试，观察是否出现新的偏差。

当任务、资料格式或模型版本发生变化时，也应重新评估示例。示例不是永久有效的配置，它和输入形式、输出要求及使用环境绑定。

下面的模板适合把历史处理案例整理成一套可复用示例。先放规则，再放示例，最后放本次任务，顺序清楚时更容易避免示例内容泄漏到正式回答。

示例 Prompt： 任务：把用户反馈整理为问题类型、事实描述、影响和建议动作。 固定规则：只根据当前输入判断；缺少依据的内容标记为待确认；不要补充用户没有说过的数字、人物或原因；输出四个字段，字段顺序保持不变。 示例一输入：用户说提交后一直没有提示，不知道是不是成功了。 示例一输出：问题类型：可用性；事实描述：提交后缺少明确反馈；影响：用户无法判断操作结果；建议动作：补充成功、失败和处理中状态。 示例一说明：输入没有说明系统是否真的提交失败，因此只描述反馈缺失，不把结果判断为失败。 示例二输入：客服经常需要解释同一个字段怎么填写，但记录里没有统一说法。 示例二输出：问题类型：内容与规范；事实描述：字段填写说明不统一；影响：用户和客服理解不一致；建议动作：统一字段说明并在相关页面复用。 示例二说明：建议动作只根据现象提出，不假设具体业务原因。 本次输入：<<<粘贴新的用户反馈>>>。 输出要求：只输出规定的四个字段；如果无法判断问题类型，列出候选类型和需要补充的信息。

如果示例比较多，可以把示例放在单独的资料区，并在 Prompt 中说明每个示例的用途。不要让模板同时承担任务说明、示例仓库和长篇背景介绍，否则使用者很难维护，模型也更容易抓错重点。

少样本示例真正要解决的是迁移：面对没见过的新输入，模型仍能按照同一规则处理。判断一组示例好不好，可以问三个问题：示例是否覆盖了最容易出错的边界？新输入的事实是否能和示例内容完全分开？输出中的固定结构和可变内容是否有明确区分？

如果答案是否定的，就不要继续堆示例。先补规则、换案例或拆分任务。示例数量增加并不会自动带来稳定性，有时反而让 Prompt 变长、重点变散、错误更难定位。

从真实任务中挑选少量代表性案例，明确输入、输出和判断说明，用新案例测试，再根据偏差更新。这样建立起来的少样本 Prompt，才会真正成为团队可复用的工作资产。