说说你常用的 Prompt 技巧;few-shot 什么时候有效、什么时候反而有害?

Q1-08Prompt 模式高频few-shotin-context learning提示词消融验证

谁在问:一面必问;2026 起常带「示例是否还有用」的反向追问

口语化问法

  • 你平时写提示词有什么套路?说几个你真用过的。
  • few-shot 你一般给几个例子?怎么定的?
  • 现在模型这么强了,示例还有用吗?

考察意图

这题最容易答成一串名词罗列(角色扮演、few-shot、CoT、分隔符……),而面试官真正在看的是:

  1. 你知不知道 few-shot 传递的是什么——格式还是知识;
  2. 你有没有见过它起反作用,这是「用过」和「调过」的分界;
  3. 你的提示词改动有没有验证闭环,还是凭手感来回改。

参考答案

图 2 · 60 分与 90 分差在哪:代价、演进、怎么验证

60

60 分答案(及格线)

常用的有:把稳定指令放 system、明确角色和任务边界、用分隔符区分指令与数据、指定输出格式、给少量示例、复杂任务拆步骤。

few-shot 在任务表述比较难说清、或者输出格式特殊时最有效——直接给几个例子比写三段说明更省事。示例太多会拉高成本,也可能让模型过拟合到示例的风格上。

90

90 分答案(有生产经验的回答)

先纠正一个常见误解:few-shot 主要传递的是「格式与任务边界」,不是「知识」。 它告诉模型「答案长什么样、什么算合格」,不是「怎么想才能想对」。把它当成廉价训练是根本性的误判。

由此推出它的双向效应:示例把模型的输出空间锚定到示例附近——收敛(格式统一、边界清晰)和收窄(探索空间被限制)是同一件事的两面。老模型默认输出太发散,收敛的收益远大于收窄的损失;新模型本身格式和判断力已经够好,天平就翻了过来。官方在自家实践里也走了这一步:给示例反而把新一代模型约束在了更窄的探索空间,于是从「给示例」转向「设计更有表达力的接口」——比如把状态定义成一个明确的枚举,枚举值本身就在提示用法,比三个示例更省更准。

我踩过的具体反作用有三类:示例污染(抽取任务里模型把示例中的公司名抄进了结果)、标签偏置(示例里某一类占多数,输出就偏向那一类,且最后一个示例影响最大)、覆盖诱导(遇到示例没覆盖的输入版式,模型硬套最接近的那个示例)。

所以我现在的做法是:从 0 个示例开始加,一次加一组、跑一次评测,涨不动就停;能用 schema 表达的格式约束整体迁到结构化输出里,示例只保留传递判断尺度的那两三个;并且优先用一个负例(这类输入要拒绝,因为……)代替三个正例。

追问链

图 1 · 五层追问树:面试官会往哪儿挖
从「示例教的是格式还是知识」一路挖到「8000 token 砍不砍」

  1. few-shot 到底在教模型什么?知识还是格式?

    期望主要是格式与任务边界 —— 输出结构、粒度、什么算合格、什么该拒绝;它几乎注入不了模型原本不具备的知识,模型不知道的事实,给再多示例也变不出来
    信号说「让模型学会这个任务」 → 停在直觉层;能分开「教它长什么样」和「教它怎么做对」 → 想过机制
  2. 示例数量怎么定?顺序有影响吗?

    期望数量靠消融定、不靠经验值:从 0 开始逐组加、每加一组跑一次评测,涨不动就停 —— 实践中常发现一半示例贡献为 0;顺序有影响,最后一个示例影响通常最大,该放最有代表性的,类别还要平衡否则带出标签偏置
    信号说「一般给 3~5 个」且没有下文 → 背的;说「做过消融,从 12 个砍到 3 个评测没掉」 → 调过的
  3. 你见过 few-shot 起反作用的情况吗?

    期望至少举一类具体的:示例污染(抽取任务里把示例中的公司名抄进结果)/ 标签偏置(某一类占多数就偏向那一类)/ 覆盖诱导(没覆盖的版式硬套最接近的示例)/ 干扰推理模型的内部推理。加分是说清怎么发现的 —— 评测掉了,还是线上冒出了示例里的内容
    信号本题最强的分水岭:举不出任何反例 → 基本可判定没在生产环境里调过提示词
  4. 官方从「给示例」转向「设计接口」,你怎么理解这个说法?

    期望示例是用具体样本暗示规则,接口是把规则直接编码进结构本身:与其给三个示例演示状态怎么填,不如定义成 pending / in_progress / completed 枚举 —— 枚举值本身就在告诉模型用法,还顺便被约束解码硬保证,既省 token 又不引入示例的收窄与污染
    信号能把「接口设计」落到枚举、字段命名、参数表达力上 → 真理解了;只复述「要设计好工具」 → 听过没消化
  5. 接手的提示词有 20 个 few-shot、占 8000 token 且每次都带,要求成本砍一半不降质

    期望先别砍,先看缓存命中率:这 8000 token 若命中良好,边际成本只有原价的十分之一 → ② 拆一遍输入/输出/工具结果,大头在输出侧就砍错了 → ③ 真要砍先做消融,一次去一组,大概率一半贡献为 0 → ④ 格式类示例迁到结构化输出由 schema 硬保证 → ⑤ 只留传递判断尺度的 2~3 个放前缀末尾 → ⑥ 查示例污染,有的话砍掉反而提质
    信号第一句是「先看缓存命中率和成本构成」 → 优秀;「按比例删到 10 个」 → 既没验证也没搞清钱花在哪
前两层还在讲用法,第 3 层才开始验真 —— 举不出一个反作用的具体案例,就是没在生产里调过提示词;第 5 层再验一次:砍示例之前先不先看缓存命中率。

评分要点

  1. 明确 few-shot 传递的是格式与边界,不是知识
  2. 能说清收敛与收窄的双向效应
  3. 至少举出一类具体的反作用,最好是自己踩的
  4. 示例数量用消融决定,而非固定经验值
  5. 知道顺序与类别平衡的影响
  6. 知道 2026 年的方向是「从给示例转向设计接口」
  7. 有评测闭环,提示词改动能被验证
  8. 降本时先看缓存命中与成本构成,再动示例

常见错误

把技巧罗列成名词清单,每个都说不出用在哪个具体场景。
把 few-shot 说成「给模型举例子让它学会这个任务」。
认为示例越多越准,或固执地回答「一般给 3~5 个」而无依据。
被问「现在还有用吗」时答「当然有用,这是基础技巧」,没有条件判断。
从来没有评测集,提示词全靠肉眼看几个 case 决定。
含糊标志词:「多试几次就好了」「调一调提示词一般就能解决」「这个凭经验」。

关联学习