提示词基础

提示词究竟是什么。

当你调用 LLM 时，模型看到的一切都是文本：一段它必须续写的令牌序列。没有隐藏通道，没有"模型自然就知道的设置"。指令、数据、示例、对话历史、工具定义——所有这些都被拼接成一个输入，交给一个下一令牌预测器。内化这一点能消解大多数提示词困惑：模型读不到你的意图，只能读到编码意图的那些令牌。

这意味着"模型为什么会做 X？"这个问题，几乎总能归结为"提示词里的什么让 X 成了概率最高的续写？"。好的提示词工程，就是把令牌排列得让期望答案成为阻力最小的路径这门功夫。

撬动质量的四个杠杆。

1. 具体的指令

含糊的指令产生含糊的输出。"总结一下这个"没有定义长度、受众和重点，于是模型选了一组多半不是你想要的默认值。"用两句话为工程师总结这条工单，重点放在复现步骤上"则关闭了不想要的续写路径。具体不是礼貌——它是约束，而约束才让输出可预测。

2. 充分的上下文

模型只知道两样东西：训练数据里有的，以及这个提示词里有的。如果答案依赖你的代码库、你的政策文档或昨天的事故，那材料就必须在提示词里。一个常见的失败是：问一个模型不可能知道答案的问题，然后惊讶它编了一个。

3. 示例（当任务模糊时）

对于难以描述但易于演示的任务——语气、格式、边界情况处理——一两个范例往往胜过一整段指令说明。这就是少样本提示（few-shot），有单独一篇详述；要点是：示例是一个杠杆，不是最后的救命稻草。

4. 明确的输出形式

如果下游代码要消费这个输出，就准确说明它应长什么样："只返回一个 JSON 对象，键为 summary 和 priority；不要有散文。"形式未指定，模型就会即兴发挥格式，而即兴的格式会让解析器崩溃。

一个改写前后的对比。

同一个任务，先是糟糕的写法，然后是好的写法：

BAD
"Look at this review and tell me about it.
Great product but shipping took 3 weeks and box was crushed."

GOOD
"Classify the customer review below into exactly one of:
positive, negative, mixed.
Then extract any complaint as a short phrase.
Return JSON: {"sentiment": ..., "complaint": ...}

Review: Great product but shipping took 3 weeks and box was crushed."

糟糕版本产出一段无法解析的散文，以及一个模型从未明确给出的情感标签。好的版本点明了任务、约束了标签集合、固定了输出形式——四个杠杆中用了三个，只多花了四行。

像工程师而非赌徒那样迭代。

错误的循环是"改一个词、跑一次、凭感觉判断"。单次运行是有噪声的，因为模型从一个概率分布中采样（见《LLM 思维模型》）。正确的循环是：

• 收集 10–20 个有代表性的输入，包含会咬你的边界情况。
• 每次只改提示词里的一处。
• 跑完整套；比较聚合质量，而非某次走运的输出。
• 只有当改动在平均意义上有帮助且未让边界情况退化时才保留它。

提示词就是代码。它们应当进版本控制、配一套小型评测集，并以证据而非"哪种措辞显得聪明"来支撑改动。

最小可用提示词模板。

大多数生产提示词可拆为五个带标签的部分。给它们命名，能把"重写提示词"变成"哪个部分弱了？"

# 1. ROLE / FRAMING  — who the model is acting as
You are a support-triage assistant.

# 2. TASK            — the single instruction, specific
Classify each ticket and extract the blocking issue.

# 3. CONTEXT         — the data + rules it needs
Categories: billing, bug, feature-request, other.
Policy: anything mentioning "data loss" is priority=high.

# 4. EXAMPLES        — 1-2 worked cases (optional)
Ticket: "App crashed, lost my draft" -> {"cat":"bug","priority":"high"}

# 5. OUTPUT FORMAT   — exact shape, restated last
Return only JSON: {"cat": ..., "priority": ...}

你不会每次都需要全部五个，但当一个提示词表现不佳时，按顺序走一遍这些槽位，比把整段重写更快找到缺口。