提示词里加 few-shot 怎么写：让大模型稳定输出的 3 种写法

很多人觉得大模型「看心情输出」，同一句话问两次结果不一样。其实稳定输出不靠运气，靠的是提示词里的 few-shot——也就是在问题前面先给几个「标准答案样例」，让模型照着学格式和尺度。本文讲清楚 few-shot 是什么、为什么有效，并给你 3 种实用写法，覆盖分类、抽取、格式转换三类高频场景。把样例写对，AI 的输出会立刻从「自由发挥」变成「按模板交卷」。提示词工程不是玄学，是可复用的工程方法，写一次就能在无数次调用里复用，这正是 AI 编程提效里最容易被忽视的一环。

一、为什么 few-shot 能让输出更稳

大模型本质是模式匹配，你给它看几个「输入长这样、输出长那样」的例子，它就会倾向于延续这个模式。相比纯文字描述「请按 JSON 返回」，直接给它一个 JSON 样例，歧义小得多。尤其在让模型按你给的样例生成代码或测试用例时，一致性提升非常明显。few-shot 的核心价值，是用具体示范代替抽象描述，把模型从「猜你想干嘛」拉到「照这个做」。它不改变模型能力，只是把你的意图表达得足够具体。

二、写法一：分类任务的样例

做情感、意图、标签这类分类时，给 2-3 个带标签样例，比写一长段规则更管用。

任务：判断用户留言的情绪，只回 positive / negative / neutral。
例1：这功能太好用了 → positive
例2：又崩了，气死 → negative
例3：什么时候出网页版 → neutral
输入：客服半天不理人 →

样例要覆盖边界，尤其 neutral 这种容易被误判的。分类逻辑如果涉及代码判定，可以配合 Python3 教程把规则落进脚本做二次校验，让模型和程序双保险。大模型在分类任务上对样例极其敏感，几个好样例往往胜过千言万语的规则描述。

还有一个细节容易被忽略：样例的顺序会影响输出。模型有「近因偏差」，更倾向模仿排在最后的样例风格，所以如果某类结果你最看重，把它放在样例末尾更有利。同时要避免样例本身分布失衡，比如给了九个 positive 只有一个 negative，模型会悄悄偏向多数类。调样例就像调砝码，哪边结果不对就往哪边加一条对照样例，几次下来输出就会稳在你想要的位置。

三、写法二：信息抽取的样例

从长文本里抽字段，最怕模型自己发明键名。用 few-shot 锁定输出结构，几乎能消除这类漂移。

从简历中抽取信息，严格按如下 JSON 输出：
{"name":"", "years":0, "skills":[]}
例：张三，5 年经验，会 Python、SQL →
{"name":"张三","years":5,"skills":["Python","SQL"]}
现在抽取：李四，3 年，会 Java、Linux →

关键点是「严格按如下结构」，并让样例和真实输入尽量同分布。数据清洗这类活儿，软件测试教程里的等价类思路也能帮你设计覆盖更全的样例，避免只在理想数据上验证。输出格式一旦锁定，后续解析就稳了，这正是 few-shot 最值钱的地方。

还有一个常见翻车点：样例里的字段和真实数据对不上。比如样例写的是标准手机号，真实输入却混了座机或空值，模型就可能卡在格式上乱填。应对办法是在样例里特意放一两条「脏数据」对照，告诉模型遇到异常该怎么兜底，而不是硬套结构。抽取类任务最怕沉默失败——它不报错但悄悄给你错误结果，所以样例里把边界情况演一遍，比事后写一堆校验代码更划算。

四、写法三：格式转换的样例

把一种格式转成另一种，比如把日志转成表格、把需求转成测试用例，给一个完整示例最省心。

把下面需求转成 pytest 用例骨架：
需求：函数 add(a,b) 返回两数之和，要测正常值与边界。
例（参考格式）：
def test_add_normal():
    assert add(2, 3) == 5
def test_add_boundary():
    assert add(0, 0) == 0

这种写法在大模型驱动的自动化里很常见，输出格式一旦锁定，后续解析就稳了。前端若要把结果渲染出来，JavaScript 教程的模板语法能接上，形成从生成到展示的闭环。格式转换类任务，few-shot 几乎是必选项，否则模型每次都可能换一种结构。

五、写好样例的原则与不适用场景

几个原则要记牢。第一，样例要和真实输入同分布，别拿理想句当样例、真实脏数据当输入，模型会懵。第二，样例之间不要自相矛盾，尤其标签定义要一致。第三，控制数量，3-5 个通常够，太多反而挤占上下文。第四，样例本身要正确，错的样例比没样例更糟——它会认真学你的错误。环境上，Linux 教程里的管道命令可以帮你批量构造和验证样例文件，让提示词工程也能工程化。什么时候不用 few-shot？开放式创作、纯闲聊、明显简单的问题，加样例反而约束了发挥。判断标准是「输出是否高度结构化、是否容易漂移」——是的话就加，否则留白。样例写对了，提示词这门手艺才算真正入门。

把样例写完后，别急着接生产，先用一小批真实输入跑一遍验证稳定性。重点看两件事：一是格式有没有偶尔跑偏，比如某次 JSON 少了个括号；二是边界输入会不会触发奇怪输出。发现问题就回到样例里补一条对照，而不是去改模型参数。提示词工程本质上是「用数据调提示词」，和用数据调模型是同一个思路，区别只是成本极低、迭代极快。等这一批样例在验证集上连续稳定，再放心接上自动化流水线，才算真正完成闭环。

小结

让大模型稳定输出的核心，是在提示词里写好 few-shot：分类给标签样例、抽取给结构样例、转换给格式样例。把握「同分布、不矛盾、数量适中、样例正确」四原则，再把不适用的场景留给零样本。提示词工程做到这一步，大模型就从「随机应变」变成「按模板交付」，可控性上了一个台阶。输出格式稳定了，自动化流水线才敢放心接上。

延伸学习

想系统提升 AI 协作开发能力，可以看 AI驱动的Python编程实战这门课程。
CSDI峰会开启：Agentic AI 落地应用的黄金期，智能系统重塑生产力帮你了解智能体落地的趋势。
想深入 AI 编程实战，可以参考 AI 人工智能教程。

常见问题

Q：few-shot 和零样本有什么区别

零样本是不给样例直接下指令，简单任务够用但容易漂移；few-shot 是给几个样例引导模式，适合结构化、要求一致的任务。两者可以混用，关键看稳定性需求。

Q：few-shot 样例应该放在系统提示还是用户消息里？

都可以，但通常把固定样例放在系统提示或对话开头，用户每次只换真正的输入，这样复用性好，也省 token。系统提示里的样例对所有对话生效，适合长期不变的规范；用户消息里的样例更灵活，适合随任务切换。

Q：样例会不会泄露隐私

会。如果样例里包含真实姓名、手机号等敏感字段，模型可能学进去并在别处复现。写样例务必脱敏，用占位数据替代真实信息。