提示词工程的原理：上下文、few-shot 与 CoT

提示词工程常被当成"玄学话术"——加一句"你是一位资深专家"就灵了？对工程师来说，更值得问的是：它为什么有效，又为什么有边界？ 一旦从条件概率和上下文学习（in-context learning）的角度看，prompt 的所有技巧都会落回到同一个机制上，玄学就变成了可推理、可调试的工程。

直觉：你在塑造一个条件分布

LLM 做的事是采样

$x_t \sim P_\theta(\cdot \mid x_{<t})$

参数 $\theta$ 训练完就冻结了。prompt 唯一能动的，是条件 $x_{<t}$ 。 所以提示工程的本质不是"和模型对话"，而是：构造一段前缀，把后续生成的概率质量，从默认的、平均的、人均水平的分布，挪到你想要的那块高质量区域。

模型在预训练里见过无数"问题→优质解答""指令→规范执行"的文本片段。当你的 prompt 在风格、结构、措辞上像某一类高质量文本的开头，模型就会沿着那条分布把它续写完整。"你是资深专家"之所以偶尔有用，不是模型真变专家了，而是这句话把生成条件锚定到了语料中"专家撰写的内容"那个子分布——它在做风格与质量的条件选择，不是能力注入。

三大支柱

1. 上下文（context）：模型当下唯一的"工作记忆"

模型没有跨请求的记忆，每次推理只看得到这一次喂进去的 token。所谓"记住了上文"，只是因为上文还在窗口里。这带来两条铁律：

相关信息必须在窗口内。要它基于某份文档作答，就得把文档（或检索到的片段）放进 prompt，不能指望它"想起来"。
位置会影响利用率。实践中模型对开头和结尾的信息更敏感，长上下文里夹在中间的关键内容容易被"读漏"（俗称 lost in the middle）。所以把指令和最关键的约束放在头部或尾部，往往比埋在中段更稳。

2. Few-shot：用示例代替难以言说的规则

很多任务"怎么做"很难用自然语言讲清，但给几个输入-输出对，模型立刻就懂。这就是 few-shot / in-context learning：不更新任何权重，仅凭上下文里的示例，模型现场"适配"出任务模式。

将下列句子分类为 正面 / 负面：

句子：这家店服务一流，下次还来。
情感：正面

句子：等了一个小时菜还没上，气死了。
情感：负面

句子：环境不错但价格偏贵。
情感：

几个工程要点：

格式一致性 > 示例数量。示例之间的分隔符、字段名、标点要严格统一。模型会把这套格式当成"任务协议"模仿，格式飘忽会显著抬高解析失败率。
示例在演示"映射函数"，不在教知识。研究普遍观察到：示例的格式和分布比标签本身是否字字正确更关键——它主要告诉模型"输出长什么样、按什么规则映射"，而非补充事实。
小样本不是越多越好。示例吃 token、推高成本和延迟，3~5 个覆盖典型与边界情况，通常比堆 20 个更划算。
当心顺序偏置。示例排列顺序、类别是否均衡，都会轻微左右结果，分类任务尤其敏感。

3. 思维链（CoT）：把算力花在中间步骤上

对多步推理（数学、逻辑、代码追踪），直接问答案常出错；让模型先写推理过程再给结论，准确率往往明显提升。一句简单的"让我们一步步想（let’s think step by step）"就能触发。

为什么有效？回到自回归本质：模型每个 token 的计算量是固定的，它没有"想很久再开口"的隐式慢思考通道。复杂问题若要求一步出答案，等于逼它在常数算力内完成多步运算。而 CoT 把推理摊开成一串显式 token——

$P(\text{answer} \mid q) = \sum_{r} P(\text{answer} \mid r, q)\, P(r \mid q)$

中间步骤 $r$ 被写进上下文后，每一步都成了后续步骤的条件，等于把一次性难题拆成若干个简单的下一步预测，并让模型在生成 token 的过程中"展开"算力。这也解释了它的边界：

CoT 主要帮多步推理任务；对单步事实查询、简单分类，它只是徒增 token 和延迟。
推理链可能看着对、实则后合理化。模型有时先有了倾向答案，再编一段自洽的"理由"。CoT 提升的是平均正确率，不等于可信的因果解释，别把它当审计依据。
进阶变体：self-consistency 采样多条推理链投票取众数；ReAct 把"推理"与"调用工具/检索"交替进行。它们都建立在"把思考显式化为 token"这同一块基石上。

一个可复用的 prompt 结构

把上面三根支柱组合起来，一个稳健的工程化 prompt 通常长这样：

[角色/视角]   设定回答所处的子分布（资深后端工程师、严谨审稿人……）
[任务指令]    一句话说清要做什么，越具体越好
[约束/格式]   输出格式、长度、禁止项；要 JSON 就给 schema
[上下文/材料] 待处理的数据、检索到的文档（关键信息放头或尾）
[少量示例]    1~5 个格式统一的 input→output（需要时）
[触发推理]    多步任务加“先逐步推理再给最终答案”
[输入]        本次真正要处理的内容

把它当接口契约来设计：明确入参、明确出参 schema、明确边界行为（材料缺失怎么办、无法判断回什么）。这比反复加形容词有效得多。

工程权衡与常见误区

每个技巧都有 token 成本。few-shot 和 CoT 都吃上下文、推高延迟与费用。在准确率收益和成本之间权衡，能用更短 prompt 达到目标就别堆料。
prompt 是脆弱的、模型相关的。同一句魔法咒语换个模型版本可能就失效。把关键 prompt 纳入版本管理并建回归测试集，像对待代码一样对待它。
别用礼貌词当性能旋钮。“请”"谢谢"基本不影响正确率；真正起作用的是具体性、结构、示例和约束。
指令冲突会被无声吞掉。又要"简洁"又要"详尽"，模型只会随机偏向一边。先自检 prompt 内部是否自相矛盾。

小结

提示词工程不是话术，而是对一个冻结模型的条件分布做塑形。上下文决定它当下能看到什么，few-shot 用示例传递难以言说的映射规则，CoT 把算力摊进显式的中间步骤。理解了"prompt 唯一能动的就是那段前缀"，你就能解释每个技巧为何有效、在哪失效，并把它当成有契约、有成本、需测试的工程接口来设计，而不是对着模型念咒。