你描述得很到位：语气、长度、结构、用词都说了。模型产出的东西”按字面”符合描述，“按形态”却完全不像你心里那个。你追问”更像一个技术速记，少一点营销腔”——更接近了，还是不对。来回三轮后你贴了一个真正的”技术速记”样例，下一次输出就接近完美。
这就是”描述 vs 示例”的不对称：语言模型仿示例的形状，远比照形容词构造形状可靠。一个好例子抵几段规则。
**最快修复：**别再堆形容词。贴一个标注过的正例（Like this: 后面跟真实文本），如果形状还是漂，再加一个标注过的反例并写一句理由。要放两三个示例时，给每个加上各自的分隔标记，让模型能把示例和你的指令区分开。本文讲什么时候光靠描述会失败、该用几个示例、以及示例放在哪。
什么时候示例反而是错的工具
先说一个 2026 年才变化的注意点。示例是控制格式、语气、结构最可靠的杠杆——也就是本文要解决的问题。但它不总是控制推理准确性的正确杠杆。在纯推理任务（数学、多步逻辑、硬核 debug）上，往会思考的模型——比如 GPT-5.5 Thinking/Pro、或开了 extended thinking 的 Claude Opus 4.7——前面堆少样本示例，反而会加噪声、降低准确率。这些模型在内部推理，不需要靠一个范例去模仿。截至 2026 年 6 月，OpenAI 和 Anthropic 的指引都是：推理任务就干净地描述目标和输出格式，别放范例。
经验法则：用示例控制输出长什么样，用干净的指令控制模型怎么想。
常见原因
1. 描述靠口味形容词
“快”、“punchy”、“温暖”、“技术风”——每个都解析成模型对该标签的平均态，几乎不是你的那个态。
**如何判断：**你的描述里有 3 个以上形容词、0 个示例。
2. 形状约束只写了没展示
“用 3 个 bullet，每个 1 个标题加 1 句解释。“比形容词具体，但形状还是欠缺——什么类型的标题、冒号放哪、句子多长。
**如何判断：**你的结构规则是 prose，不是一个模型能直接照抄的字面模板。
3. 示例来自错误的域
你用一篇精修过的新闻通稿当锚，目标却是内部 Slack 闲聊。模型仿了通稿的语域，写出来太正式。
**如何判断：**你贴的示例和目标域在语气或体裁上不一致。
4. 示例互相矛盾
示例 1 短、示例 2 长、示例 3 有 bullet。模型把它们平均后就乱了——更糟的是，它可能给你的输入复用了错的那个。
**如何判断：**你的 2-3 个示例在长度、语气、结构上不一致，而且这种不一致不是由输入差异决定的。
5. 没反例
反例（“不要这样”）的锚定力常常和正例一样强。没有它，模型可能朝错的方向漂，却完全没有信号知道自己跑偏了。
**如何判断：**你只有正例，没有被拒绝的例子。
6. 示例没有分隔
你把示例当作普通 prose 直接和指令混在一起贴进去，模型分不清示例在哪结束、任务从哪接上。结果它要么把半个示例当成规则，要么把半条规则当成示例的一部分。
**如何判断：**示例文本和周围指令之间，没有任何 fence、标签或标记把它们隔开。
你属于哪一类
| 症状 | 可能原因 | 去看 |
|---|---|---|
| 输出很泛、是标签的”平均态” | 只有形容词的描述 | Step 1 |
| 往营销腔或废话漂 | 没有反例 | Step 2 |
| 语气不对（太正式 / 太随意） | 错域示例 | Step 3 |
| 每次跑结果不一致 | 示例互相矛盾 | Step 4 + Step 6 |
| 模型把你的示例当成指令 | 示例没分隔 | Step 6 |
| 形状对但逻辑 / 事实错 | 这是推理任务，不是形状任务 | 见上面”什么时候示例反而是错的工具” |
动手前先确认
- 找一个真实可接受输出的示例——从档案里翻一个，或手写一个。
- 找一个不可接受输出的示例，并写明它具体为什么不行。
- 记下可接受示例的语气、长度、结构、用词。
- 确认示例和目标域一致。
- 决定示例放在 prompt 哪里（通常紧贴交付指令前最好）。
需要收集的信息
- 当前 prompt 及其全部描述。
- 漂掉的那个输出。
- 一段你想要的样例，逐字节。
- 一段你想避免的样例，附理由。
- 用的模型和任何 system prompt。
最短修复路径
Step 1：加一个正例
Like this:
\`\`\`
Hey — the env var didn't load because Vercel scopes secrets per environment.
Move `STRIPE_KEY` from "Development" to "Production" in Project Settings > Environment Variables.
Redeploy. That should fix it.
\`\`\`一个标注过的示例，对输出形状的影响超过五句描述。
Step 2：加一个反例并写理由
Not like this:
\`\`\`
In modern software development, environment variables play a crucial role in deployments.
Let me walk you through the process step by step...
\`\`\`
Reason: too marketing-y, opens with filler, takes too long to reach the fix.那行 “reason” 才是让对比可执行的关键——没有它，模型只学到”避开这几个词”，而不是背后的毛病。
Step 3：示例和目标域保持一致
输出是内部 Slack 消息就用 Slack 风格示例；是 PR 描述就用 PR 描述。跨体裁迁移很脆：拿通稿当示例，每次都会把 Slack 消息往通稿语域拉。
Step 4：用 1-5 个示例，按输入多样性匹配
单一固定任务，一个强示例通常就够。任务要跑很多不同输入时，给几个覆盖典型场景的。截至 2026 年 6 月，各家指引都收敛到很小的数：OpenAI 建议 1-5 个 input/output 对，而且只在 zero-shot 不灵时才加；Anthropic 建议 3-5 个示例效果最好，并让它们足够多样，免得模型抓住某个无意的表面模式。超过五个很少有帮助，反而开始增加延迟和 token 消耗。
Examples (vary by input):
Input: "Vercel deploy failed"
Output: "Check the Build Command in vercel.json. The most common cause is..."
Input: "Firebase auth not working"
Output: "Open Firebase Console > Authentication > Settings. Authorized domains must include..."
Now produce output for:
Input: "<the actual user input>"Step 5：示例放在约束之后、交付之前
[顶部]
任务 + 约束
[中间]
示例（1-5）
[底部]
现在为 <输入> 产出紧贴交付指令前的示例最显眼。一个例外：如果你还要贴一份大的参考文档（20k+ token），就把那份文档放到最顶上、把任务和问题留在最后——Anthropic 报告说，在长篇、多文档输入上，把问题放在末尾能把回答质量提升最多 30%。
Step 6：给每个示例都明确分隔
模型必须知道每个示例从哪开始、到哪结束，否则它会把示例和指令糊到一起。用一致的标记：
- **Claude：**把每个示例包进
<example>标签，再整组放进<examples>。Anthropic 文档说，这样 Claude 区分示例和指令比靠纯换行更可靠。 - **GPT-5.5 / 通用：**用
###或三引号"""标出边界，并给每对标注 input 和 output。
<examples>
<example>
Input: "Vercel deploy failed"
Output: "Check the Build Command in vercel.json..."
</example>
<example>
Input: "Firebase auth not working"
Output: "Open Firebase Console > Authentication > Settings..."
</example>
</examples>Step 7：把示例固化到版本化文件
高频生产 prompt，把示例存进版本化文件，再从该文件重建 prompt，标准升级时更新示例。这样能挡住”示例漂”——某次对内联示例的随手改动，会悄悄改变一条长寿工作流的每一个输出。
怎么确认已经修好
- 新输出在长度、结构、语域上贴合你的正例。
- 新输出不像你的反例。
- 同一个 prompt 跑三次，三个形态一致（用不同对话或关掉共享记忆来跑，免得上一次污染下一次）。
- 同事不需要你讲规则，就能挑出”好”的那个。
如果还是没修好
- 示例太少——加第 3、第 4 个（到五个为止）。
- 示例互相矛盾——审一遍长度、语气、结构的一致性。
- 让模型显式抽模式：加一句”Note the structure of the examples: opening line, fix line, expected-result line. Match this structure exactly.”
- 需要机械严格的形状，就切到 schema 强制输出。OpenAI（Structured Outputs / JSON schema）和 Anthropic（Structured Outputs）都能把响应约束到一个 schema，当形状每次都必须精确时，这比示例更稳。
- 如果错的是逻辑而不是形状，那你在推理那一类——去掉示例，改成干净地描述目标和输出格式（见开头那个注意点）。
预防建议
- 默认：任何带风格要求的 prompt 至少配 1 个示例。
- 给常做的任务建可复用示例库。
- 当心跨域错位：别用法律合同当锚去写随意的邮件。
- 每季度审一次示例库，剔除已不符合当前风格的。
- 团队工作流要商定标准示例——A 组用模板 A、B 组用模板 B，必然引发漂移。
- 拿不准就写一个示例。这五分钟，省下一小时的反复 prompt。
常见问题
**该用几个示例？**固定任务，一个好示例通常就够。要跑各种不同输入的任务，用几个覆盖整个范围的。截至 2026 年 6 月，OpenAI 建议 1-5 个 input/output 对，Anthropic 建议 3-5 个效果最好。超过五个基本只增加成本和延迟，还可能让模型过拟合到某个表面模式。
**为什么加了示例后输出反而变差了？**两个常见原因：要么示例互相矛盾、模型在做平均；要么你是在会思考的模型（GPT-5.5 Thinking/Pro、Opus 4.7）上做推理任务，范例只会加噪声。推理任务就把示例去掉，干净地描述目标。
**示例到底放 prompt 哪里？**放在任务和约束之后，紧挨着请求交付那行之前。例外是大的参考文档，放最顶上、把问题留到最后。
**正例和反例哪个更重要？**先放一个正例，它定下目标形状。当模型反复朝某个特定失败模式漂（营销废话、过度正式）时，再加一个带一句理由的反例。那句理由，才让反例教会一条规则，而不是只列一串禁用词。
**一定要用 XML 标签，还是 code fence 就够？**对 Claude，<example>/<examples> 标签是文档里的最佳实践，解析比 fence 更可靠。对 GPT-5.5 和大多数其他模型，### 或 """ 分隔加上标注好的 input/output 就行。不可妥协的那一点是：每个示例都要和你的指令清楚隔开。
**我的示例总是原样出现在输出里，为什么？**模型把示例当成答案的一部分了，因为它没被分隔。把它包进 <example> 标签或 """，再加一句”The examples above are for format reference only; do not repeat them.”