考察点
Zero-shot、Few-shot、CoT 是应用岗面试的常客（阿里云开发者社区的面试题里直接问过）。光答出定义只能拿基础分，面试官真正想听的是「示例怎么选」——这是纯经验活，选错示例比不选还糟。追问方向：示例顺序有影响吗、示例和线上数据分布不一致会怎样。
参考答案
先厘清概念
Zero-shot 是直接下指令不给示例；Few-shot 在 Prompt 里放几个输入-输出对，让模型通过上下文学习（In-context Learning）模仿任务模式，不更新任何参数。它的价值在于：格式对齐和边界对齐。模型见过示例后，输出格式几乎不会跑偏；「什么情况输出其他」这类难以用文字穷尽的判断边界，给两个示例比写三段规则管用。
选示例的四条经验
数量：3 到 5 个通常是甜点区。 一个示例模型可能过拟合到那个具体 case；超过 8 个，边际收益迅速递减，token 成本线性上涨，还可能引入自相矛盾。我做意图分类时实测过，3 个精选示例比 10 个随手挑的准确率高。
质量：典型性优先，覆盖边界。 每个示例应该代表一类典型输入，而不是五个差不多的普通 case。一定要包含边界样本——比如分类任务里「最容易误判的那两类各给一个」，多标签场景给一个「不属于任何类，输出其他」的负例。负例缺失是线上误判的常见根因：模型没见过「拒绝」的样子，就硬给每个输入安一个标签。
一致性：格式必须严格统一。 所有示例的输入结构、输出字段、标点习惯保持完全一致。模型对格式模式极其敏感，一个示例里输出 JSON、另一个输出自然语言，等于告诉模型「格式随便」。
分布：贴近线上真实输入。 示例从真实日志里挑并人工标注，不要自己编。自己编的示例往往太「干净」，线上用户输入的口语化、错别字、中英文混杂在示例里见不到，模型遇到就飘。
两个容易踩的坑
- 顺序偏差：有研究表明模型会倾向输出最后一个示例的标签类别（recency bias）。对策是让各类标签在示例序列里均匀分布，或者把评测集上过不了的 case 对应类别的示例放后面，然后评测验证。
- 静态示例覆盖不了长尾：输入空间太大时，固定几个示例不够。进阶做法是动态选例——把候选示例库向量化，请求来了先检索与当前输入最相似的 K 个示例再拼进 Prompt，相当于给示例选择也做了一层 RAG。这在多意图分类、代码生成场景效果明显，代价是多一次检索延迟。
什么时候不用 few-shot
任务本身简单（翻译、润色）、或者指令微调充分的新一代模型 zero-shot 已经够好，就别堆示例了，白烧 token。还有个判断角度：如果示例教模型的东西用文字规则能讲清楚，优先写规则——规则不占输入 token 的「模式空间」，更可控。
可能的追问
- Few-shot 和微调怎么分工？ 示例解决「格式和少量边界」，几十个 case 内能讲清的用 few-shot；成百上千条规律、稳定的风格或领域知识，该上微调。两者不互斥，微调过的模型照样可以 few-shot。
- 怎么验证示例选得好不好？ 固定评测集，只改示例做 A/B，看准确率；同时盯混淆矩阵，看边界示例有没有真的压掉对应误判。
- 示例会泄露或被注入利用吗？ 会。示例里的真实用户数据要脱敏；示例区也要和用户输入区用分隔符隔开，防止用户输入伪装成新示例污染模式。