给示例和写说明差在哪？few-shot 与指令

给两三个例子让模型照着做，还是把要求写成一段说明？这是提示词工程里最常见的分岔。智谱清言、豆包对两种写法都支持，选哪种取决于任务性质和维护习惯。先说结论：求风格、求格式，示例好用；求规则、求边界，指令好用。

结论先行：两种写法各配什么活

示例擅长的场景：文案风格、表格格式、固定的处理套路——这些「做出来什么样」不好描述，给样例最直接。指令擅长的场景：硬性规则、禁止事项、可枚举的条件——这些「什么能做、什么不能做」写清单最清楚。两者也常组合使用：指令定规则，示例定味道，各管一段互不干扰。还有一种组合用法：指令写在示例前面，规则先立、样子后看，模型两样都吸收，比单用任何一种都稳。

差异一：模型理解的方式

指令走的是语义理解：模型读你的要求，按自己的经验执行，理解偏差随时可能发生。示例走的是模式归纳：模型从输入输出对照里提取规律，规律提取得准，执行就稳。两种方式出错的样子不同：指令错在「理解歪了」，示例错在「归纳歪了」。判断哪边出错，就看输出是偏离了你说的，还是偏离了你给的，对症下药才快。判断哪边出错有个小技巧：换成不同措辞的指令结果变好，是指令问题；换样例结果变好，是示例问题。示例的质量门槛也更高：一个走样的样例能带偏全局，指令写差了至少还能靠示例拉回来，示例写差了就是全盘跑偏。

差异二：改起来的成本

改指令动笔就行：把规则写细、写严，立刻生效，成本极低。改示例要重新挑样本：样本一换，模型归纳出的规律全变，可能修好一处、带坏三处。所以频繁变更的要求用指令承载，长期稳定的风格用示例承载。反过来，说不清的口味偏好，与其写十句指令，不如给两个满意的样例，让模型自己对齐感觉。样本还要定期复查：业务变了，旧样例归纳出的规律可能过时，半年不换的样例值得重新审一遍。

差异三：吃掉的上下文

示例占空间，一组样例几百字起步，多组示例会明显挤占留给正文的上下文。指令通常几十到一百字就能写清一组规则。上下文紧张的任务，先保指令，示例精选一两组。处理长文档时这个差异更明显：示例放太多，正文反而放不下，主次颠倒。给示例要像给佐料，提味即可，别喧宾夺主。省上下文还有一招：把示例压缩成最小可辨识版本，删掉与风格无关的内容，规律还在，字数减半。

示例在数据场景的应用，见数据分析的口径提示；示例和推理提示的配合，参考思维链和直接回答；示例给完后想再加硬约束，看约束解码和格式提示；示例固定但追问灵活的写法，见单轮精写和多轮追问。

示例与指令速查表

• 风格格式给示例，规则边界写指令
• 常变的要求用指令，稳定的偏好用样例
• 上下文紧张时先保指令
• 两者矛盾时模型多半跟示例走

一句话收住：说不清的给样例，说得清的写规则。

拿不准选哪种时，先用指令写一版，不满意再补一两组示例，这是成本最小的试法。两种写法都试过再定，比一开始就站队要理性得多。

关于few-shot的三个常问问题

• 给几个示例合适？：两组起步、四组封顶，重点保证样例风格一致且覆盖典型情况。
• 示例和指令矛盾时听谁的？：模型多半跟示例走，所以两者必须对齐，发现矛盾先改示例。
• 示例可以用真实数据吗？：可以，但要做脱敏处理，样例会被模型当规律学习，敏感内容务必清理。