Prompt Engineering技术路线梳理
我是怎么理解 Prompt Engineering 技术发展路线的
最近我一直在系统地梳理Prompt Engineering（提示词工程）这条技术路线。
刚开始接触这个领域的时候，我对它的理解其实很浅，觉得它无非就是“把提示词写得更好一点”“多加点约束”“多举几个例子”。但越往后看论文、看综述、看各种方法的演化，我越觉得这件事没有那么简单。
我现在更愿意把 Prompt Engineering 理解成一条很清晰的技术演化链：它不是单纯研究“怎么写一句 prompt”，而是在不断回答一个更大的问题——怎样设计输入、推理过程和上下文组织方式，才能让语言模型更稳定、更强、更可控地完成任务。这条路线一路从模板化提示，走到推理提示、工具增强、自动优化，最后逐渐过渡到今天越来越常被提起的context engineering。
1. 我最开始理解的 Prompt Engineering：其实是“把任务翻译成模型更熟悉的形式”
如果从更早期的研究往回看，我觉得 Prompt Engineering 最原始的出发点非常朴素：
模型不是不会做任务，而是我们给它的任务表达方式不一定对。
早期很多工作会把分类、推断这类任务，改写成语言模型更熟悉的填空或补全形式。比如，不直接让模型输出“正面/负面”，而是把输入改写成一句等待补全的话，让模型在语言建模的框架里完成任务。这类思路后来又进一步发展出自动搜索模板、自动搜索触发词的方向，也就是从“人手写模板”开始，慢慢转向“机器帮你找更有效的模板”。
我自己现在回看这一阶段，会觉得它解决的是一个最基础的问题：
怎么把任务说清楚。
它的方法不复杂，核心就是两件事：
第一，把任务改写成模型原本擅长的输入形式。
第二，把输出类别、标签、结论，映射成语言表达中的词或短语。
但这一代方法也有明显局限。它对模板非常敏感，很多时候换个写法效果就不一样；同时它也比较“脆”，迁移到别的任务、别的模型时，往往不一定还能保持同样效果。也正因为这样，后面的研究才会越来越关心：有没有更通用、更灵活的提示方式。
2. 当大模型变强之后，Prompt Engineering 开始进入“指令与示例”时代
我觉得 Prompt Engineering 真正被更多人感知到，是因为大模型起来之后，大家发现：
原来很多任务不需要重新训练模型，只要在输入里讲清楚要求，再配几个例子，模型就能做得不错。
这就是后来大家非常熟悉的instruction prompting和few-shot prompting。再往后，随着 FLAN、InstructGPT 这类工作出现，大家逐渐意识到：模型之所以能“听懂”指令，不只是因为规模变大了，更因为它经过了专门的 instruction tuning 或 alignment 过程。也就是说，Prompt Engineering 之所以越来越实用，并不是孤立发生的，而是和模型训练范式的演进一起发生的。
如果从学习者角度来理解这一阶段，我会把它看作 Prompt Engineering 的第一次大扩展：
它不再只是研究“句子怎么写”，而是开始研究：
- 指令要不要明确写目标
- 要不要给输入输出示例
- 示例给几个合适
- 输出格式要不要规定
- 角色、边界、约束要不要提前说明。
这一阶段让我最大的感受是：
Prompt 不再只是“触发器”，而开始变成“任务规范说明书”。
但它的问题也很快显现出来。
对于简单任务，给指令、给例子往往就够了；可一旦任务变复杂，尤其涉及多步推理时，模型经常会出现一种情况：它好像理解了要求，但并不能稳定地一步推出来。这个问题，直接把 Prompt Engineering 推向了下一阶段。
3. CoT 的出现，让 Prompt Engineering 从“怎么说”走向了“怎么想”
如果让我选 Prompt Engineering 里最关键的分水岭，我大概会选Chain-of-Thought（思维链）。
因为 CoT 让我第一次真正感觉到：Prompt Engineering 开始不只是在设计输入文本，而是在设计模型的推理过程。
CoT 要解决的问题很明确：
很多复杂任务并不是模型完全不会，而是它直接输出答案时太容易跳步、算错、漏掉中间关系。于是研究者就让模型不要急着答，而是先把中间思考过程写出来。Wei 等人的工作表明，这种做法对算术、常识、符号推理都能带来提升。
我自己最初看到 CoT 的时候，会觉得它非常像一种“教学式提示”：
- 不再只给最终答案示例
- 而是给“题目—思考步骤—答案”的示例
- 让模型模仿这种分步解题方式。
再往后，Zero-shot CoT 又进一步让我意识到一件事：
有时模型缺的不是知识，而是没有被激活到正确的推理模式。Kojima 等人的工作表明，只是增加一句类似“让我们一步一步思考”的提示，有时就能显著改善零样本推理。这个发现其实很震撼，因为它说明 Prompt 有时候不是在“喂知识”，而是在“切换认知模式”。
但在我看来，CoT 的局限也很明显。
它虽然让模型开始“说出过程”，但这个过程本质上还是单链路的。只要前面某一步走偏，后面就可能沿着错误链条继续展开，看起来很有逻辑，实际却是在一本正经地错。
4. 当大家意识到“一条思路不够”之后，Prompt Engineering 开始进入搜索与工作流时代
这一步是我后来越看越觉得有意思的地方。
因为 CoT 的局限其实很自然地引出了一个问题：
如果一条思路不够，那能不能同时探索多条思路？
于是就有了像Tree of Thoughts（ToT）这样的工作。
在 ToT 的视角里，“thought” 不再只是模型顺着写出来的一段中间文本，而是变成了可以扩展、评估、保留、剪枝的搜索节点。也就是说，Prompt Engineering 到这里已经有点不像“写 prompt”了，而更像是在设计一种搜索式推理框架。
我会把 ToT 理解成对 CoT 的一个很自然的升级：
- CoT 是一条链
- ToT 是一棵树
- 链适合线性展开
- 树适合多路径探索、比较与回溯。
当然，ToT 的代价也很直观：
既然要探索多条路径，就意味着更多 token、更长延迟、更复杂的决策与评估流程。这个缺点虽然很容易从方法结构本身推导出来，但它恰好也说明了一个趋势：Prompt Engineering 已经在从“文本设计”转向“推理资源管理”。
与此同时，在更工程化的方向上，大家也开始用prompt chaining或workflow来处理复杂任务。
与其把所有要求都挤在一个 prompt 里，不如把任务拆成几个阶段：先理解任务，再检索，再生成草稿，再校验，再输出结果。到了 DSPy 这类框架，语言模型调用甚至被进一步视作可编译、可优化的程序模块。换句话说，这时候的 Prompt Engineering 已经明显朝着“LM program 设计”发展了。
5. 当大家承认“纯语言推理有上限”之后，工具增强成为一个必然方向
这是我特别认可的一步，因为它很现实。
随着任务越来越复杂，大家逐渐意识到：模型会说，不等于模型会做；模型会拆题，不等于模型能稳定完成精确计算、可靠检索或环境操作。
于是 Prompt Engineering 继续往前演化，就来到了工具增强阶段。
PAL：把“想”与“算”分开
PAL 给我的启发很直接。它认为语言模型擅长的是理解题意、拆解思路、生成程序，而真正的计算与执行最好交给解释器。也就是说，不再让模型自己口头算到底，而是让它把中间推理写成程序，再交给 Python 去执行。
这背后的思想我觉得非常重要：
Prompt Engineering 不一定总是在优化模型内部推理，也可以是在优化“任务如何被外包”。
ART：自动推理并结合工具
ART 比 PAL 更进一步。它不只是把问题翻译成程序，还会结合 demonstrations 和工具使用过程，在多步推理中动态暂停、调用外部工具、再把结果接回来继续推理。这让我感觉 Prompt Engineering 到这里，已经和工具编排、任务流程设计深度绑定了。
ReAct：让“思考”和“行动”交替发生
ReAct 则是另一个非常关键的节点。
它的价值在于，它不再只研究“怎么让模型想得更好”，而是研究：模型在想的时候，能不能一边行动，一边根据外部反馈修正自己。于是它形成了很经典的 Thought—Action—Observation 循环。
我对这一阶段的总体理解是：
Prompt Engineering 到这里已经不只是“把 prompt 写清楚”，而是在设计一套语言模型与外部世界交互的协议。
6. 再往后，大家开始关心：模型第一次答得不对怎么办？
当工具增强和多步流程都出现之后，一个新问题就变得非常现实：
一次生成、一轮推理、一条轨迹，还是不够可靠。
于是 Prompt Engineering 又向前迈了一步，进入了我很喜欢的一类方法：反思、验证、修正。
Reflexion：把错误变成下一轮的经验
Reflexion 给我的感觉特别像人类学习过程中的“复盘”。它不通过修改模型权重来学习，而是让 agent 在每轮任务后，根据反馈生成一段文字反思，并把这段经验存进记忆中，供后续轮次使用。
我特别喜欢这个思想，因为它说明了一件事：
Prompt Engineering 的发展，已经从“如何触发模型能力”，走向了“如何让模型在交互中积累经验”。
Verification：先答，再查，再改
另一条支线是 verification 类方法，比如 Chain-of-Verification。
这类方法的核心不是让模型更会“第一时间答对”，而是承认第一版可能不可靠，于是主动插入检查步骤：先回答，再提出验证问题，再根据验证结果修正。它主要针对的就是幻觉与不一致问题。
我现在看这类方法，会觉得它们其实在推动 Prompt Engineering 完成一个很重要的转变：
从“生成一次”转向“生成—检查—修正”的闭环。
7. 当人工写 prompt 变得越来越累之后，Prompt Engineering 自然走向自动化
如果一路看到这里，我觉得有一个结论几乎是必然的：
既然 prompt 这么重要，而且还这么敏感，那为什么不把 prompt 本身也当作优化对象？
这就是 Automatic Prompt Engineering 出现的逻辑。
APE：让模型帮你写 prompt，再让系统帮你选
APE 的思路非常直接：先让模型生成多个 prompt 候选，再通过任务表现去筛选更优版本。看到这个方法的时候，我第一次有了很强的感觉：Prompt Engineering 在这里已经开始变成一个标准的“搜索—评估—选择”问题，而不是经验型手艺活。
更系统的 APO 视角
到了 2025 年的几篇综述里，这个方向已经被总结得很完整了。自动提示优化不只是改一句 instruction，而是可以同时优化：
- instruction
- exemplars
- soft prompts
- 混合提示形式
而优化方法也开始系统化，包括 foundation model 驱动搜索、进化方法、梯度方法、强化学习方法等。
我对这一阶段的理解很明确：
Prompt Engineering 到这里，已经彻底从“语言技巧”进入了“优化问题”的范畴。
8. 还有一条容易被忽略但很重要的支线：Soft Prompt
如果说前面大多数方法还属于“人能读懂”的自然语言提示，那么 soft prompt 这一支就更偏向技术研究了。
像 Prefix-Tuning、Prompt Tuning、P-Tuning v2 这些方法，本质上不再让人写 prompt，而是在 embedding 空间里学习一段连续向量前缀，把 prompt 变成可训练参数。
我会把它理解成 Prompt Engineering 技术路线中的一条“内化”分支：
- 前面的方法，是在人类可读的文本层面做设计
- 这一类方法，则直接进入模型表示空间做优化。
它的优点是灵活、可训练、参数高效；缺点则是不可读、跨模型迁移一般，而且更像 PEFT，不太像普通开发者理解中的“写提示词”。
9. 我现在对“最先进 Prompt Engineering”的理解：它已经越来越像 Context Engineering
如果让我现在重新回答“Prompt Engineering 发展到哪里了”，我不会再说“现在最先进的是某个单独的方法”。
我会说：最先进的趋势，是 prompt 这件事已经不再被当作一句孤立的文字，而是被放进更大的系统输入设计里。
也就是说，今天更前沿的方向，往往关注的不是单条 prompt，而是整个上下文怎么组织：
- instruction 怎么写
- exemplars 怎么选
- retrieval 结果怎么拼接
- 工具输出怎么回填
- memory 怎么管理
- verifier 怎么介入
- 整条 workflow 怎么编排
- 这些部分怎么自动优化。
所以在我眼里，这条路线的真正终点并不是“写出一句神 prompt”，而是：
把 prompt、上下文、工具、记忆、验证和流程统一看作一个整体输入系统去设计。
10. 如果让我用一句话总结我学到的东西
我现在会这样总结 Prompt Engineering 的技术发展路线：
- 最早，它是在研究怎么把任务说清楚；
- 后来，它开始研究怎么让模型一步一步想清楚；
- 再后来，它开始研究怎么让模型借助工具、验证和反思做清楚；
- 到今天，它越来越像是在研究怎样把整条上下文与任务流程设计清楚。
如果说我以前觉得 Prompt Engineering 是一门“写提示词的技巧”，那我现在更愿意把它看成：
一门围绕语言模型输入、推理和控制方式不断演化的方法学。
参考阅读
- Prompt Engineering 总述与分类综述。(arxiv.org)
- FLAN / instruction tuning 路线。(arxiv.org)
- Chain-of-Thought 与 Zero-shot CoT。(arxiv.org (arxiv.org))↳
- Tree of Thoughts。(arxiv.org)↳
- ReAct、PAL、ART。(arxiv.org (arxiv.org (arxiv.org))
- Reflexion 与 verification。(arxiv.org (arxiv.org))
- Automatic Prompt Engineering / Automatic Prompt Optimization。(arxiv.org (arxiv.org))↳
- Context Engineering 趋势。(arxiv.org)