少样本学习提示词指南-含示例选择和格式设计2版

少样本学习提示词指南——含示例选择和格式设计少样本学习|示例选择|格式设计|提示词工程2026年9月26日一、为什么“给几个例子”比你想象的重要你让模型把客户工单按紧急程度分类，只给了指令没有给例子。模型时而把账单问题标为“高”，时而又标为“中”，还会自创一个你没定义的“关键”级别，每条回答后面还附上一段解释。现在你在这条指令前面粘贴三个已经标注好的工单——工单、标签、工单、标签。模型突然就稳定了：每次新工单返回一个干净的标签，格式统一，类型正确。模型本身没有变。你只是展示了模式。这个“模糊指令”和“几个具体示例”之间的差距，就是少样本学习要解决的问题。少样本提示（Few-shotPrompting）的核心思路是：不告诉模型“该怎么做”，而是直接给它看“做对了的例子”。模型通过模仿提示中示例的输入输出映射关系，推断出任务模式并套用到新的查询上。这条路径最早由2020年的GPT-3论文《LanguageModelsareFew-ShotLearners》正式确立——研究表明，在提示中提供2-5个输入输出示例，模型就能在推理阶段学会新任务，无需更新权重。少样本提示的三个层级：层级机制适用场景代价零样本只给指令，不给例子简单、模型已熟悉的任务输出格式不稳定，标签空间不可控单样本给一个例子只需锚定输出形状的简单任务示例一旦有偏差，模型会放大偏差少样本给2-5个例子标签空间固定、格式严格、需要统一风格的任务每个示例都消耗token，过多会稀释注意力选择原则：先用零样本试，只在输出偏离预期时才加示例。每加一个示例都是每次调用要付的token成本，多不自动等于好。二、示例选择：选什么比选几个更重要2.1数量：3到5个是性价比最高的区间对多数任务而言，3到5个示例是性价比最高的区间，超过8个示例后边际收益急剧下降，反而会因为上下文过长稀释模型的注意力。一项实验显示，5-shot配置在各项任务中表现最优（平均准确率71.12%），但超过10个示例后，性能不再有显著提升。数量选择的决策标准：任务复杂度推荐示例数理由不这样做的后果简单分类/格式化2-3个模式容易识别，不需要更多加太多示例浪费token且可能引入噪声多类别分类3-5个每个类别至少需要一个示例类别覆盖不全，模型对未见类别表现差格式严格的抽取3-5个需要展示多种边界情况示例太少，模型遇到边界情况会自由发挥推理类任务3-5个需要展示推理过程示例太多会让模型机械模仿而非理解一个容易忽略的问题：示例数量并非越多越好。提供太多示例会让AI“眼花缭乱”，反而不知道该模仿哪一个；示例如果有错误，AI会把错误也学过去。2.2四种示例选择策略选什么示例比选几个示例更关键。以下四种策略分别适用于不同场景：策略一：语义相似度选择将示例库中的所有输入编码为向量，检索与当前查询语义最接近的k个示例注入提示词。这是生产环境中应用最广泛的策略。维度说明实现方式用sentence_transformers将示例和查询编码为向量，通过向量点积计算相似度，取Top-K最佳适用问答、文本分类、信息抽取优势示例与当前输入高度相关，模型不需要跨领域推理劣势需要维护向量库，增加工程复杂度不用的后果示例与输入不相关时，模型可能被引向错误的输出模式LangChain团队发现，语义相似的示例能提升工具调用性能，同样的模式也适用于分类和检索增强任务。策略二：多样性采样最大化示例对不同模式和边界情况的覆盖。使用K-Means等聚类算法找到多样化的示例簇，从每个簇中选一个代表。维度说明实现方式对示例输入做聚类，从每个簇中心附近选取一个示例最佳适用展示任务的全貌，防止模型偏向某一种模式优势确保示例覆盖所有可能变体，模型不会只学到单一模式劣势单个示例与当前查询的相关性可能不高不用的后果示例全是同一类简单案例的变体，模型遇到不同模式时束手无策策略三：KATE（kNN增强的上下文示例）KATE的核心思想是：从训练集中检索与当前查询最相似的k个示例，而不是随机选择。Liu等人2021年的研究证明，这种方法显著优于随机选择。策略四：难度梯度排列最有效的少样本往往以一个简单案例开头让模型建立基本模式认知，中间包含一个边界案例展示处理规范，最后以一个复杂案例锚定质量上限。位置示例类型作用不这样做的后果第1个简单案例建立基本模式认知模型一开始就被复杂案例搞晕第2个边界案例展示处理规范模型遇到边界情况不知如何处理第3个复杂案例锚定质量上限模型不知道“好的输出”能好到什么程度难度梯度策略示例：任务：将客户邮件分类为“投诉/咨询/建议”三类。

示例1（简单案例）：

输入：我的订单还没发货，请帮我查一下。

输出：{"category":"咨询","confidence":"高"}

示例2（边界案例）：

输入：你们这个功能设计得真“好”，让我找了半小时都没找到。

输出：{"category":"投诉","confidence":"中","note":"反语表达，实质为投诉"}

示例3（复杂案例）：

输入：产品本身没问题，但如果能增加夜间模式就更好了。另外上次发货比预计晚了两天，虽然最后收到了。

输出：{"category":"建议","confidence":"高","note":"混合了建议和轻微投诉，以建议为主"}2.3示例选择的三大原则无论用哪种策略，选择示例时需遵循三个原则：原则含义违反的后果高度相关性示例与当前问题属于同一类型或领域模型被引向错误的方向输出格式正确示例本身必须是高质量的正确示范模型把示例中的错误也学过去简洁明了示例不要太长，避免干扰核心指令示例占据过多注意力，指令被忽略2.4负向示例：什么时候需要“反面教材”有些任务光靠正向示例不够——模型需要看到“什么是不该做的”。常见场景包括：安全审核（区分攻击性内容和正常批评）、内容过滤（区分垃圾内容和正常推广）。负向示例的用法：在示例后追加一条“反例”，标注为“错误做法”，并简要说明原因。❌错误示例：

输入：这个产品的电池续航太差了。

输出：{"category":"咨询"}

❌错误原因：客户明确表达了不满，应归类为“投诉”而非“咨询”。

✅正确示例：

输入：这个产品的电池续航太差了。

输出：{"category":"投诉"}注意：负向示例不是越多越好。在安全审核类任务中，模型本身就有“过度拒绝”的倾向，过多的负向示例反而会加剧误判。2.5顺序效应：同一组示例换个排列，准确率可能骤降这是少样本提示中最容易被忽略、但对结果影响最大的因素之一。Zhao等人2021年的研究发现，仅仅重新排列同一组示例的顺序，GPT-3的准确率就可能从接近最优水平掉到接近随机水平。而且，增加模型规模或增加示例数量并不能消除这种方差。三种常见的顺序偏差：偏差类型表现应对方法多数标签偏差示例中某类标签占多数时，模型偏向预测该类确保各类别示例数量均衡近因偏差模型倾向于重复最后一个示例的标签不要总把同一类别的示例放在最后常见词偏差模型倾向于输出常见token而非罕见token对罕见标签增加权重校准实操建议：如果发现模型输出偏向某一类别，不要只加示例，先检查示例的类别分布是否均衡、最后一个示例是什么类别。调整顺序后再测试，往往比增加示例更有效。三、格式设计：让模型“照葫芦画瓢”3.1格式设计的三条铁律铁律一：所有示例的格式完全一致。相同的分隔符、相同的字段顺序、相同的标点风格。不一致的格式会让模型在不同格式之间“漂移”，输出变得不可预测。铁律二：示例的输出格式必须是你最终期望的格式。示例就是“事实上的格式规范”。你给的示例是简洁的JSON，模型就会输出简洁的JSON；你给的示例是带解释的段落，模型就会输出带解释的段落。铁律三：用清晰的分隔符标记示例边界。如果没有分隔符，示例挤在一起像一团散装文，模型分不清哪里是一个示例的开始、哪里是结束。3.2示例边界标记：三种主流方式方式一：XML标签（推荐用于Claude和大多数模型）<example>

<input>输入内容1</input>

<output>输出内容1</output>

</example>

<example>

<input>输入内容2</input>

<output>输出内容2</output>

</example>

现在处理：

<input>你的实际输入</input>方式二：对话格式（推荐用于ChatCompletionsAPI）用户：输入内容1

助手：输出内容1

用户：输入内容2

助手：输出内容2

用户：你的实际输入

助手：方式三：简洁标记（推荐用于token敏感的场景）Input:输入内容1

Output:输出内容1

Input:输入内容2

Output:输出内容2

Input:你的实际输入

Output:3.3示例格式设计模板模板一：分类任务角色：你是一名【具体职位】。

任务：将以下【输入类型】分类为【类别1/类别2/类别3】。

<examples>

<example>

<input>【示例输入1】</input>

<output>{"category":"【类别】","reason":"【一句话原因】"}</output>

</example>

<example>

<input>【示例输入2】</input>

<output>{"category":"【类别】","reason":"【一句话原因】"}</output>

</example>

</examples>

现在处理：

<input>【实际输入】</input>

约束：只输出JSON，不要额外解释。模板二：信息抽取任务任务：从以下文本中提取【字段1】、【字段2】、【字段3】。

<examples>

<example>

<input>【示例文本1】</input>

<output>{"字段1":"值","字段2":"值","字段3":"值"}</output>

</example>

<example>

<input>【示例文本2】</input>

<output>{"字段1":"值","字段2":"值","字段3":null}</output>

</example>

</examples>

约束：字段值必须来自原文，没有则填null。

现在处理：

<input>【实际文本】</input>模板三：风格模仿任务任务：以【目标风格】改写以下内容。

<examples>

<example>

<input>【原始内容1】</input>

<output>【改写后内容1】</output>

</example>

<example>

<input>【原始内容2】</input>

<output>【改写后内容2】</output>

</example>

</examples>

约束：保留所有数据，不添加原文中没有的信息。

现在处理：

<input>【实际内容】</input>3.4格式设计的四个细节细节一：示例的输出字段名要与下游系统一致。如果下游代码用data["customer_name"]读取，示例中的字段名就必须是customer_name，不能写customerName或name。细节二：缺失值的处理方式必须在示例中体现。如果某些字段可能为空，至少有一个示例展示空值如何处理（填null、填"N/A"、还是省略字段）。缺少这个示例，模型遇到空值时可能自由发挥。细节三：示例的数量要与类别数量匹配。做三分类任务，至少每个类别有一个示例。做五分类任务，至少覆盖四个类别。示例中完全没出现的类别，模型大概率无法正确处理。细节四：不要用“反面教材”替代“正面示例”。告诉模型“不要输出X”的效果远不如展示“应该输出Y”。四、三种可直接套用的提示词模板4.1模板一：分类打标（适合简单分类任务）角色：你是一名【职位/身份】。

任务：将以下【输入】分类为【类别A】/【类别B】/【类别C】。

<examples>

<example>

<input>【示例输入1】</input>

<output>{"label":"【类别A】","reason":"【原因】"}</output>

</example>

<example>

<input>【示例输入2】</input>

<output>{"label":"【类别B】","reason":"【原因】"}</output>

</example>

</examples>

约束：

-只输出JSON，不要包含解释性文字。

-类别只能是【类别A】/【类别B】/【类别C】之一。

-reason字段不超过20字。

现在处理：

<input>【实际输入】</input>4.2模板二：信息抽取（适合从文本中提取字段）任务：从以下文本中抽取结构化信息。

<examples>

<example>

<input>【示例文本1】</input>

<output>{"name":"值1","date":"2026-01-15","amount":5000,"note":"值2"}</output>

</example>

<example>

<input>【示例文本2】</input>

<output>{"name":"值3","date":"2026-03-20","amount":null,"note":null}</output>

</example>

</examples>

约束：

-只输出JSON。

-字段值必须来自原文。

-找不到的字段填null，不得编造。

-date格式统一为YYYY-MM-DD。

现在处理：

<input>【实际文本】</input>4.3模板三：风格模仿（适合需要统一风格的内容生成）角色：你是一名【风格描述，如“面向30-40岁职场女性的生活方式博主”】。

任务：以以下示例的风格改写输入内容。

<examples>

<example>

<input>【原始内容1】</input>

<output>【改写后内容1】</output>

</example>

<example>

<input>【原始内容2】</input>

<output>【改写后内容2】</output>

</example>

</examples>

约束：

-保留原文所有数据和事实。

-字数与示例保持一致。

-不添加原文中没有的信息。

现在处理：

<input>【实际内容】</input>五、完整案例：从零样本翻车到少样本稳定输出背景：某电商客服团队需要将每日客户工单自动分类为“物流问题/产品质量/售后咨询/其他”四类，并提取订单号。初始使用零样本提示，效果极不稳定。零样本版本：任务：将以下客户工单分类为物流问题/产品质量/售后咨询/其他，并提取订单号。

工单内容：【粘贴工单】零样本输出问题：分类标签不统一：有时返回“物流问题”，有时返回“物流”，有时返回“配送问题”订单号有时提取、有时不提取输出格式不一致：有时是JSON，有时是自然语言段落诊断：模型不知道你要的标签集是什么，也不知道输出格式长什么样。这些都是“用指令说不清、用示例一展示就明白”的事情。改进：加入3个示例角色：你是电商客服系统的工单分类助手。

任务：将客户工单分类并提取订单号。

<examples>

<example>

<input>我买的杯子到现在还没发货，订单号是ORD-20260901-001，请尽快处理。</input>

<output>{"category":"物流问题","order_id":"ORD-20260901-001"}</output>

</example>

<example>

<input>收到的台灯有划痕，申请换货。订单ORD-20260903-005。</input>

<output>{"category":"产品质量","order_id":"ORD-20260903-005"}</output>

</example>

<example>

<input>想问一下这个保修期是多久？</input>

<output>{"category":"售后咨询","order_id":null}</output>

</example>

</examples>

约束：

-只输出JSON，不要包含解释性文字。

-category只能是“物流问题”“产品质量”“售后咨询”“其他”之一。

-找不到订单号时填null，不得编造。

现在处理：

<input>【实际工单】</input>改进后输出：分类标签严格限定在四个值内输出格式统一为JSON订单号缺失时正确填null准确率从约70%提升到约90%关键差异：零样本给的是“指令”，少样本给的是“接口规格”。示例不解释规则，但让模型从模式中推断规则。六、工程化实践：从手工调试到系统化运营6.1建立示例库当少样本提示从“一次性使用”变成“日常依赖”时，手工维护示例的效率会迅速下降。工程化的做法是建立一个“示例库”——把所有经过验证的高质量示例集中管理，按场景分类，需要时动态检索注入。示例库的四要素：要素说明管理方式示例内容输入-输出对，格式统一存储为JSON文件场景标签示例适用的业务场景按场景分类索引质量标记该示例的效果评分（如“已验证”“待审核”）人工标注更新时间该示例最后一次验证的时间自动记录6.2上下文窗口预算管理少样本提示的token成本不是免费的。每个示例都会占用上下文窗口，示例越多，留给实际任务的空间越小。建议在提示词设计中引入“预算感知”机制——根据任务复杂度动态调整示例数量。任务类型上下文预算分配（示例部分）理由简单分类≤20%模式容易识别，示例不需要太多格式抽取≤30%需要展示多种边界情况风格模仿≤40%风格传递需要足够多的示例推理任务≤25%示例要展示推理过程，但不能占满上下文6.3主动学习循环：用最少示例获得最大收益Active-Prompting的核心思想是：不去猜测该给哪些示例，而是让模型告诉你它在哪些案例上最不确定。流程分三步：步骤做什么目的Probe给模型一批未标注案例，让它回答并报告置信度找出模型最不确定的案例Annotate针对最不确定的那个案例，人工写一个高质量示例在最需要的地方补短板Lock将新示例加入示例库，重新测试效果系统化积累经过3-10轮这样的循环，通常能超过临时拼凑的示例效果，尤其在推理类任务上。6.4版本管理与回归测试成熟的团队应该维护一个“Prompt资产库”——将每个业务场景的Prompt进行版本管理，记录每一次修改的原因和对应的效果指标，建立Prompt的回归测试集。当模型版本升级或切换到新模型时，能够通过批量测试快速评估Prompt的兼容性，而不是靠“感觉好像变差了”这种模糊判断。七、不同使用强度的适配方案维度轻度使用中度使用重度使用适用人群偶尔用AI写文案、问问题日常办公辅助、内容创作内容团队、开发者使用频率每周1-3次每天3-10次每天20次以上示例数量1-2个3-5个3-5个+动态检索格式设计简单标记XML标签+JSON输出完整模板+Schema约束示例管理不建库，每次现写建个人模板库建团队共享示例库顺序管理不关注顺序留意类别均衡系统化测试顺序效果迭代方式不满意就加例子对比不同示例的效果用回归测试集做系统评测轻度使用：每次用AI前，给1-2个示例锚定