在让 Gemini 3.1 Pro 做任务时，Few-shot 的作用常常被低估：很多人只是在提示词里塞几段“看起来像答案”的示例，结果出现两类问题——输出漂移与泛化失控。更稳的做法是把 Few-shot 当作一种“可验证规格（spec）”，用工程化流程保证：示例可覆盖、边界可控、输出可审计。

为了让这篇文章更贴近落地，我将按“入口定位—选择标准—核验排查—Evidence Pack 归档—发布门禁”的思路来讲：如何构建高质量 Few-shot 示例来提升 Gemini 3.1 Pro 的表现。

---

1）选择标准：你的 Few-shot 必须覆盖哪些“任务维度”

Few-shot 并不是越多越好，而是要覆盖你真正关心的差异面。建议你先把任务拆解成 5 个维度，并为每个维度至少准备 1~2 个示例：

1. 常规路径（Nominal）：输入满足所有假设时的正确输出
2. 边界条件（Boundary）：缺字段、格式不全、长度极短/极长
3. 反例（Counterexample）：容易做错的输入（模型常见误判）
4. 风格/格式约束（Format）：必须输出特定结构（JSON/YAML/表格）
5. 置信度表达（Uncertainty）：当信息不足时如何输出“缺失说明”或“拒答”

实操建议：如果你的任务是结构化输出（KULAAI（dl.877ai.cn）），那 Few-shot 的“格式正确性”覆盖应当最高优先级。

---

2）入口定位：把示例变成“受控上下文 + 约束输出”

为了降低模型对示例“意图”的误读，你需要在提示词中对示例关系做清晰约束，避免它把示例当作“随便学学”。

2.1 受控上下文（Context）

• 目标任务定义（例如：摘要、抽取、分类、改写、评审等）
• 关键输入字段说明（每个字段含义、可取值范围）
• 允许/禁止的内容类型（如禁止编造事实、禁止输出敏感信息）

2.2 约束（Constraints）

• 输出必须符合的 schema（字段名、类型、顺序、单位）
• 当缺少信息时的处理策略（例如 unknown / insufficient_evidence）
• 需要的推理层级是否允许/禁止（很多场景不需要展示完整 chain-of-thought）

2.3 输出结构（Output Schema）

把输出写成“硬规则”，例如：

• JSON：必须能被 jsonschema 校验
• YAML：必须能通过 yamllint 且包含固定顶层键
• 文本：必须符合固定段落模板（如：Problem / Method / Result / Limitation）

---

3）Few-shot 示例写法：高质量示例的“模板化结构”

下面给出一个通用 Few-shot 书写结构（你可以直接套用）：

3.1 示例块（Example Block）结构

每个示例建议包含三段：

1. Input:（可读、无歧义、最小化噪声）
2. Reasoning/Steps:（可选，若你允许模型显式推理；不建议在高敏场景要求展示）
3. Output:（必须严格按 schema/格式给出）

关键点：示例的 Input 应尽量“贴近真实数据”，但要避免把真实项目的敏感文本原样泄露到提示词中；可以用脱敏后的等价样本。

3.2 示例的“对齐原则”（Alignment Rules）

• 任务对齐：示例答案必须严格体现“你要的目标变量/输出字段”
• 风格对齐：输出措辞、单位、格式必须与目标一致
• 误差对齐：在不确定时示例必须展示你期望的“不确定表达”方式

3.3 示范数量（How many shots）

经验上优先考虑“有效多样性”而不是数量：

• 结构化抽取/分类：通常 3~8 个示例够用
• 复杂推理链：用更少但更高质量的示例，并强化规则与校验

---

4）核验思路：如何判断 Few-shot 是否真的提升，而不是“看起来更顺”

把评估当作质量门禁而不是主观感受。建议你用“故障树”排查：

1. 格式是否稳定
   • JSON 能否 100% 解析？字段是否缺失？
2. 覆盖维度是否改善
   • 对边界/反例是否也变好？还是只在常规样本上好看？
3. 是否出现幻觉或编造
   • 对“不足信息”的输入，输出是否仍然给了不存在的内容？
4. 是否出现任务偏移（Task Drift）
   • 是否把摘要写成评论、把抽取写成翻译等？
5. 提示词长度与复杂度是否引发退化
   • shots 多了是否反而让模型忽略约束？

你可以对每个 shot 做“消融实验”（删掉某个示例再测）来判断哪个示例贡献最大。

---

5）Evidence Pack：让 Few-shot 构建过程可审计、可回归

为了后续团队协作与复盘，建议每次 Few-shot 迭代都生成 Evidence Pack，内容至少包括：

• task_name
• dataset_version（测试集版本号）
• fewshot_version（示例集版本号）
• prompt_template_version
• model（确认 Gemini 3.1 Pro 参数，如 temperature、top_p、max_output_tokens）
• shots_used[]（每个示例的 ID 或哈希）
• evaluation_metrics（准确率、schema-valid rate、拒答率等）
• before_vs_after（改动前后对比）
• error_analysis（列出 Top N failure modes）

这样你才能回答：“这次 Few-shot 是怎么把表现拉上去的？”

---

6）发布门禁（Gate）建议：Few-shot 也要“上线审批”

当你把 Few-shot 提示词用于生产或对外服务时，建议设置门禁条件：

1. 格式门禁：输出必须通过解析与 schema 校验（例如 99%+）
2. 安全门禁：不得出现敏感信息泄露、不得编造事实（对“不足输入”必须拒答/标注 unknown）
3. 准确门禁：核心指标达到阈值（例如分类准确率 ≥ X 或 F1 ≥ Y）
4. 回归门禁：对旧测试集不得明显退化（例如下降不超过 Z）
5. 可回放门禁：固定提示词版本与输入样本，保证结果可复现

这些门禁可以写进 CI 流水线：每次改提示词即自动跑评测。

---

7）最终落地清单：你可以直接照做的 Few-shot 构建步骤

1. 定义输出 schema 和约束（先写校验规则，再写示例）
2. 准备覆盖维度样本：nominal + boundary + counterexample + format + uncertainty
3. 将示例输入脱敏并标准化：减少噪声、提升可比性
4. 每个示例只做一件事：输出要与你的目标字段严格对应
5. 用小规模评测验证：先 50~200 条测试集看 schema-valid 与关键指标
6. 做消融实验：验证每个 shot 是否有贡献
7. 生成 Evidence Pack 并设定门禁阈值：上线前审批

---

结语：高质量 Few-shot 的本质是“把隐性规则变成可执行规格”

Few-shot 写得好，你得到的是稳定的任务对齐与可控的格式/不确定性行为；写得差，你得到的只是“示例越多越乱”。工程化的关键是：示例覆盖维度、约束输出结构、用核验与门禁证明收益。当你把这套流程做成模板化资产，Gemini 3.1 Pro 的表现就会越来越接近“可预期的系统”，而不是“每次都要靠运气”。