授权与合规声明
本文为作者原创技术分享，内容基于公开可查的一手资料与本人工程实践，仅供学习交流。文中命令、配置与代码片段请在自建隔离环境中验证后再用于生产；如引用第三方项目，请以官方文档与许可证为准。本文不含任何攻击步骤、利用载荷或绕过手法。

一、为什么加几个例子就变聪明（ICL 现象）

1.1 不微调，只靠上下文

大模型在推理时，把"任务说明 + 若干示例 + 待预测样本"拼成一段上下文喂进去，就能在不更新任何参数的情况下完成新任务。这种能力叫上下文学习（In-Context Learning, ICL），最早在 GPT-3 论文中被系统展示（Brown et al., 2020）。它和微调、检索增强都不一样：模型权重一点没动，只靠你给的那几行例子"现学现卖"。

1.2 这种"学会"到底靠什么

ICL 不是一个被完全解释透的机制。工程上更实用的态度是：把它当成一种"示范即指令"的接口——你给的例子，本质上在替模型锚定输出格式、语气和决策边界。理解了这一点，后面"怎么选、怎么排、用几个"才有抓手。

二、示例从哪来（人工 / 检索 / 自生成）

2.1 人工挑选：成本最低，但依赖经验

最朴素的做法是人工写几个典型样本。好处是可控、可解释；坏处是覆盖不全，且容易带入你自己的偏差。适合任务边界清晰、样本空间小的场景。

2.2 检索相似样本：让"近邻"决定输出

另一种做法是拿待预测样本去语料里检索最相近的若干条，作为示例。相关研究表明，示例与待预测样本的相似度，比示例本身的"质量评分"更影响结果（Liu et al., 2021）。也就是说，挑"和这道题像的"，往往比挑"公认好答案"更稳。

2.3 模型自生成：用模型自己造例子

还可以让模型先针对任务造一批示例，再拼回提示里。这条路在部分任务上被报告有效，但示例质量参差，可能把错误前提一并带进去。本文把它列为"待验证"的实践，落地前建议小流量对照。

三、示例怎么排（顺序敏感、难度梯度、近邻优先）

3.1 顺序真的有影响

别以为示例顺序无关紧要。已有研究明确记录：交换示例先后，模型输出分布会变化（Zhao et al., 2021）。所以当你发现 few-shot 表现忽好忽坏，先别急着改模型，先固定示例顺序、多跑几轮看方差。

3.2 难度梯度与近邻优先

两个可落地的排法：一是"由易到难"铺梯度，让模型先进入状态；二是把与待预测样本最相近的示例放在靠近预测位的一侧（近邻优先），因为越靠近预测位，对输出的锚定越强。具体哪种更好，建议用你自己的验证集说话，别照搬别人的经验。

四、几个就够了（数量与收益递减）

4.1 边际收益递减

加例子不是越多越好。经验上，few-shot 的收益在头几个示例最明显，往后边际递减，再多甚至可能挤占上下文、稀释注意力。把"数量"当成可调超参，而不是越大越好。

4.2 数量怎么定

一个务实的做法：从 0 / 1 / 3 / 5 几个档位起步，在你的验证集上跑一遍，画一条"示例数—准确率"曲线，选拐点附近的档位。本文关于"最佳示例数"的结论标记为待验证——它高度依赖任务、模型和上下文长度，没有放之四海皆准的数。

五、什么时候反而别用（示例冲突 / 长尾 / 成本）

5.1 示例冲突与长尾

当任务本身定义模糊、或候选示例彼此矛盾时，few-shot 反而会把模型带偏。长尾样本同理：你手头大多是正例，塞几个少见的负例，模型可能直接忽略。这类场景，先厘清任务边界，比硬塞例子更关键。

5.2 成本与延迟

每个示例都要占 token、占上下文。高频调用、长示例、低价值任务的场景，叠加示例的边际收益可能不抵成本。评估时把"示例带来的准确率提升"和"每次调用的额外开销"放在一起算。

这份资料里有一份"few-shot 示例选排对照清单"，把上面这些要点整理成了可对照的清单，做上下文学习调参时直接套用即可，扫码即可获取：

六、落地模板与避坑

6.1 一个可复用的组装模板

核心是把"说明 + 示例 + 预测位"三段解耦，示例部分做成可替换的列表。下面是一段示意代码，把任务说明、示例和待预测样本拼成提示。

⚠️ 代码待验证

# 组装 few-shot 提示（示例与预测位三段解耦）
task_intro = "把用户评论分成 正向 / 负向 两类，只输出标签。"
demos = [
    {"text": "物流很快，包装结实", "label": "正向"},
    {"text": "客服半天不回，体验差", "label": "负向"},
]
parts = [task_intro]
for d in demos:
    parts.append(f"评论：{d['text']}\n标签：{d['label']}")
parts.append(f"评论：{pending_text}\n标签：")
prompt = "\n\n".join(parts)

拼好后的形态长这样，预测位留空让模型续写：

把用户评论分成 正向 / 负向 两类，只输出标签。

评论：物流很快，包装结实
标签：正向

评论：客服半天不回，体验差
标签：负向

评论：收到货发现少了一本
标签：

6.2 常见坑

• 示例格式和预测位不一致（比如示例输出带解释，却要求预测位只给标签）。
• 把验证集里的样本当示例，造成信息泄露。
• 示例太多导致上下文溢出，截断后反而更糟。

七、小结

few-shot 不是"魔法模板"，而是一组关于"示例怎么选、怎么排、用几个"的工程决策。抓三件事：来源上优先近邻检索、排布上固定顺序并靠近预测位、数量上用验证集找拐点。把它当成可调超参来实验，比盲目堆例子更稳。

这份资料里有一份"few-shot 示例选排对照清单"，把上面这些要点整理成了可对照的清单，做上下文学习调参时直接套用即可，扫码即可获取：

附表 A：本文引用事实与出处对照表

事实	出处	本文位置	核验状态
GPT-3 论文系统展示 few-shot 上下文学习能力	Brown et al., 2020, arXiv:2005.14165	第一章 1.1	一手来源
示例顺序会影响模型输出分布	Zhao et al., 2021, arXiv:2102.09690（Calibrate Before Use）	第三章 3.1	一手来源
示例与待预测样本相似度比示例本身评分更影响结果	Liu et al., 2021, arXiv:2101.06804	第二章 2.2	一手来源
few-shot 示例数量存在收益递减	无单一可核一手来源	第四章 4.1	待验证
模型自生成示例可提升表现	无统一可核一手来源	第二章 2.3	待验证
存在"最佳示例数量"的通用结论	无放之四海皆准来源	第四章 4.2	待验证

附表 B：术语速查表

术语	含义
ICL（In-Context Learning）	上下文学习，仅靠推理时给定的上下文完成新任务，不更新参数
few-shot / zero-shot	提示里给若干示例 / 不给示例
检索式示例	按相似度从语料取近邻样本作为示例
近邻优先	把最相似的示例排在靠近预测位的一侧
边际递减	示例数增加到一定程度后，收益不再线性增长

---

写在最后：这篇用到的资料

写这篇文章时，我正琢磨怎么把 few-shot 的示例选排调得更稳，顺手也整理了几份配套的东西：

• 全套 AGI 大模型学习路线：从大模型提示与智能体开发一路打通到实战项目的主线地图。
• Claude Skills 全指南知识库：把常用大模型提示与智能体开发技巧沉淀成可复用的技能包。
• LangGraph + MCP 智能体实战视频目录：边看边练的智能体开发项目。

资料是我自己整理的，放在下面这个码上，扫码即可获取：

资料较多，建议先看「全套 AGI 大模型学习路线」，再挑一个实战项目跟练。