Few-shot提示词，也叫少样本提示，指的是在调用大模型时，把几个完整的输入输出示例直接写进请求内容里，让模型参照这些示例来完成后续任务。它和零样本提示的最大区别在于，前者提供的不只是规则描述，还有具体的执行样本。模型看到示例后，会倾向于模仿示例的格式、语气和输出结构，这就是常说的上下文学习能力。这种能力让模型无须经过微调，就能在推理阶段快速适配新的任务。
示例的作用可以理解为一种隐式约束。比如让模型做关键词提取，如果只写“请提取关键词”，模型可能输出一段解释或者用各种符号分隔。但如果你给两个示例，明确展示输入是一句评论、输出是用逗号分隔的五个词，那么模型大概率会按照这个格式返回。few-shot真正解决的是任务描述与模型理解之间的偏差，它把模糊的自然语言指令转化为可复制的模式。
一、Few-shot的核心机制与示例数量选择
大模型执行few-shot任务时，并不会真正修改自身权重。示例被拼接到上下文窗口后，模型通过注意力机制从前面的示例中提取任务模式。可以理解为示例在推理时临时充当了参数，引导模型在输出分布中聚焦到更符合任务目标的区域。这一点与微调有着本质区别，微调会改变模型参数，而few-shot只影响当前请求的上下文。
示例数量并不是越多越好。对于简单的分类或格式转换任务，通常2到5个示例已经足够让模型稳定工作。继续增加示例会消耗上下文长度，还可能引入噪声。尤其是当示例之间存在矛盾标注时，过多样例反而会让模型感到困惑。实际测试中，先给出两个正例和一个负例，往往比塞满八个同类正例效果更好。示例数量应该根据任务复杂度动态调整，复杂生成任务可以适当增加到六个左右，但关键仍是示例质量。
另一个需要关注的是示例顺序。将边界样例放在靠前位置，能更早帮助模型划定输出边界；把最标准的样例放在最后，则可以让模型在生成前最后一次看到理想输出格式。有些开发者会忽略顺序影响，但实验表明，最后一条示例对模型输出的影响往往最大。
二、高质量示例的三个设计原则
设计few-shot示例的第一个原则是格式严格一致。示例之间的输入和输出结构必须统一，包括标点、标签名称、换行位置和数字格式。比如做句子情感分类时，如果第一个示例输出是“正面”，第二个却写成“积极”，模型就会产生不确定性。统一的格式可以显著减少模型自由发挥的空间，让输出更容易解析。
第二个原则是样本要覆盖边界情况。只给典型示例会让模型在遇到边缘输入时表现不稳定。举例来说，如果任务是判断评论是否包含脏话，示例中既要有明显包含脏话的句子，也要有虽然没有脏字但带有侮辱语气的句子，还要有完全正常的句子。这样模型才能理解任务边界，而不是简单匹配关键词。
第三个原则是标签分布尽量均衡。如果做二分类，示例中正负样本的数量不应该过于悬殊。三分类任务同样要避免某个类别只在示例中出现一次。不均衡的示例会让模型倾向于输出高频标签，这一点与人做选择题时的偏好类似，模型会下意识选择出现次数更多的答案。
下面是一个结构清晰的文本分类few-shot提示词模板，可以直接参考这种格式：
句子：这家店的服务太差了。 标签：负面 句子：物流很快，包装也很完整。 标签：正面 句子：味道一般，但环境不错。 标签：
上面这个模板中，示例之间用空行分隔，输入和输出都放在固定位置。这种高一致性的写法，比一段话里混着描述和示例的效果要好得多。
三、实战：用Few-shot构建分类与代码生成提示词
先来看一个使用Python调用大模型接口的完整示例。这个例子把few-shot示例作为消息历史传入，让模型完成用户评论的情感分类：
import openai
def few_shot_classify(text):
prompt = [
{"role": "system", "content": "你是一个情感分类助手，只输出 positive 或 negative。"},
{"role": "user", "content": "这家店的服务太差了。"},
{"role": "assistant", "content": "negative"},
{"role": "user", "content": "物流很快，包装也很完整。"},
{"role": "assistant", "content": "positive"},
{"role": "user", "content": text},
]
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=prompt,
temperature=0.0,
)
return response["choices"][0]["message"]["content"]
print(few_shot_classify("味道一般，但环境不错。"))
这个示例中有两个关键点。第一，system消息仍然需要说清任务，不能因为给了示例就省略角色设定。第二，示例中的assistant回复严格限制为单个标签，这能引导模型在最后一轮也返回同样的简洁形式。temperature设置为0可以进一步降低输出随机性，适合需要稳定结果的场景。
在代码生成任务中，few-shot同样有效。假设你想让模型把自然语言描述转换成SQL查询，可以给两到三个描述与SQL的对应示例，让模型理解表结构、字段命名和查询风格。下面是一个简化示例：
描述：查询所有年龄大于30岁的用户姓名 SQL：SELECT name FROM users WHERE age > 30 描述：查询最近一周注册的女性用户邮箱 SQL：SELECT email FROM users WHERE gender = 'female' AND created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY) 描述：统计每个部门的平均工资 SQL：SELECT department, AVG(salary) FROM employees GROUP BY department
注意代码块中的 SQL 条件里使用了 > 来表示大于号，这是因为在 HTML 展示环境中需要转义。实际写入提示词时，直接使用普通的大于号即可。通过这几个示例，模型能学会表名、字段名以及 SQL 语法的风格，后续生成的可执行性和一致性都会提高。
四、常见误区与调优技巧
一个常见的误区是把示例写得太长，把无关信息也塞进示例里。比如在做分类时，示例中给出一整段背景故事再说答案，模型会分不清哪些信息是决定输出的关键。示例应该保持精简，只保留对输出有直接影响的输入特征和标准输出。如果示例本身包含大量噪音，模型会模仿噪音的分布，反而降低准确率。
另一个误区是示例与真实任务的数据分布不一致。用人工编写的规范句子做示例，但实际线上输入可能是口语化、带错别字或不完整的文本。这种情况下，应该从真实日志中挑选有代表性的样本，经过简单脱敏后作为示例。这样模型的输出会更贴近实际使用场景。
调优few-shot提示词时，可以尝试动态检索示例。维护一个小型示例库，根据当前输入与候选示例的相似度，选择最接近的几个样例拼接到提示词中。这种方法比固定示例更灵活，尤其在输入分布较宽时效果明显。下面是一个动态构建提示词的伪代码示例：
def build_prompt(query, candidate_examples, k=4):
selected = select_top_k_by_similarity(query, candidate_examples, k)
examples = []
for item in selected:
examples.append(f"输入：{item['text']}\n输出：{item['label']}")
example_block = "\n\n".join(examples)
return f"请根据以下示例对最后一条输入进行分类，只输出标签。\n\n{example_block}\n\n输入：{query}\n输出："
此外，复杂任务不要指望一次few-shot解决所有问题。可以把大任务拆成多个子步骤，每个步骤分别设计少量示例。例如先抽取关键信息，再做情感判断，最后汇总标签。这样每一步的示例负担更轻，整体稳定性更高。
掌握few-shot提示词技巧，核心在于把示例当成任务规格说明来设计。少而精、格式统一、覆盖边界，再结合动态选择和温度控制，就能让大模型在没有微调的情况下输出更可靠的结果。
Few-shot提示词示例引导大模型输出修改时间：2026-10-04 06:55:45