你描述得很到位：语气、长度、结构、用词。模型产出的”按字面”符合描述，“按形态”完全不像你心里那个东西。你追问”更像一个技术速记，少一点营销腔”——更接近了，还是不对。来回三轮后你贴了一个真”技术速记”的样例，下一次输出就接近完美。这是”描述 vs 示例”的不对称：语言模型仿示例形状远比按形容词构造可靠。一个好例子抵几段规则。
本文讲什么时候光靠描述会失败，以及怎么用 1-3 个示例把你想要的形状锁住。
常见原因
1. 描述靠口味形容词
“快”、“punchy”、“温暖”、“技术风”——每个都解析成模型对该标签的平均态，几乎不是你的态。
如何判断：你的描述里 3+ 个形容词、0 个示例。
2. 形状约束写了不展示
“用 3 个 bullet，每个 1 个标题加 1 句解释”。比形容词具体但形状还是欠缺——什么类型的标题、冒号位置、句子多长。
如何判断：结构规则是 prose，不是模板。
3. 示例错域
你用一篇精修过的新闻通稿当锚，目标是内部 Slack 闲聊。模型仿了通稿语域，写出来太正式。
如何判断：你用的示例和目标域语气/体裁不一致。
4. 示例互相矛盾
示例 1 短、示例 2 长、示例 3 有 bullet。模型平均后混乱。更糟的是它复用了错例。
如何判断：你的 2-3 个示例在长度、语气、结构上不一致。
5. 没反例
反例（“不要这样”）的锚定力常常和正例一样。没反例时模型可能错向漂而不自知。
如何判断：只有正例，没有拒绝例。
动手前先确认
- 找一个真实可接受输出的示例（档案里找或手写一个）。
- 找一个不可接受输出的示例，并写明它为什么不行。
- 记下可接受示例的语气、长度、结构、用词。
- 确认示例和目标域一致。
- 决定示例放在 prompt 哪里（通常输出规范前最好）。
需要收集的信息
- 当前 prompt + 所有描述。
- 漂掉的输出。
- 一段你想要的样例，逐字节。
- 一段你想避免的样例 + 理由。
- 模型和 system prompt。
最短修复路径
Step 1：加一个正例
像这样：
\`\`\`
环境变量没载入，因为 Vercel 的 secret 按 env scope。
把 `STRIPE_KEY` 从 dashboard 的 "Development" 挪到 "Production"。
重新部署。应该就好。
\`\`\`一个标注示例对输出形状的影响超过 5 句描述。
Step 2：加一个反例并写理由
不要这样：
\`\`\`
在如今快速发展的开发环境中，环境变量在部署中起着关键作用。
让我带你走一遍……
\`\`\`
理由：营销腔、开头废话、迟迟不切入修复。“理由”让对比可执行。
Step 3：示例和目标域一致
输出是 Slack 内部消息就用 Slack 风格示例；是 PR 描述就用 PR 描述。跨体裁迁移脆。
Step 4：可变输入用 2-3 个示例
任务要应用到很多不同输入时，给 2-3 个覆盖典型场景的示例：
示例（随输入变化）：
输入："Vercel 部署失败"
输出："检查 vercel.json 的 build 命令。最常见原因是……"
输入："Firebase auth 不工作"
输出："打开 Firebase Console > Auth > Settings。Authorized domains 要包含……"
现在为以下输入产出：
输入："<真实输入>"Step 5：示例放约束后、交付前
[顶部]
任务 + 约束
[中间]
示例（1-3）
[底部]
现在为 <输入> 产出示例紧贴交付指令时最显眼。
Step 6：示例固化到规范文件
高频生产 prompt 把示例存版本化文件。标准升级就更新示例，从文件重建 prompt。这样长寿工作流不会因示例漂而坏。
怎么确认已经修好
- 新输出在形状上贴合正例（长度、结构、语域）。
- 新输出不像反例。
- 同 prompt 跑 3 次，3 个形态一致。
- 同事不需要 prompt 就能挑出”好”那个。
如果还是没修好
- 示例可能太少——加第 3、第 4 个。
- 示例可能互相矛盾——审一遍一致性。
- 让模型显式抽模式：“注意示例的结构：开头一行、修复一行、预期结果一行。复用此结构。”
- 复杂形状切到 JSON schema 输出，机械强制。
预防建议
- 默认：任何带风格要求的 prompt 至少配 1 个示例。
- 常做任务建可复用示例库。
- 当心跨域错位：邮件别用合同当锚。
- 每季度审一次示例库，剔除已不符合当前风格的。
- 团队工作流商定标准示例——A 用模板 A、B 用模板 B 就会漂。
- 不确定就写一个示例。5 分钟省一小时反复 prompt。