我是怎么理解 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 ThoughtsToT这样的工作。在 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而是可以同时优化instructionexemplarssoft 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)