提示词工程方法地图：从 Prompt 到工具集成

提示词工程最容易被误解成“把问题问得更漂亮”。

真正有用的提示词工程更像一套排障方法。模型答得不稳定，可能不是模型不够强，而是任务没有说清楚、步骤没有拆开、资料没有补齐、工具没有接上，或者需要程序来处理精确计算。

这张图把常见方法分成五层：

Prompt -> Chain -> Graph -> Generate -> Integrate

方法地图

flowchart LR
  A["Prompt<br/>把任务表达清楚"] --> B["Chain<br/>把推理拆成步骤"]
  B --> C["Graph<br/>让思路分叉和合并"]
  C --> D["Generate<br/>生成提示或背景知识"]
  D --> E["Integrate<br/>接入资料、工具和程序"]

这五层不是从低级到高级的排行榜，而是五种不同的补强方式。

Prompt 处理表达问题。比如让模型把一段客服反馈归类，提示里需要写清楚分类标签和输出格式。

Chain 处理推理问题。比如一道数学应用题不能只要答案，要让模型先列变量、再列公式、最后计算。

Graph 处理多路径问题。比如做技术选型时，模型需要同时比较成本、生态、性能、维护难度，再合并成建议。

Generate 处理提示和背景知识不足的问题。比如模型可以先生成几个候选提示词，再用测试样例筛选效果更好的一个。

Integrate 处理外部信息和执行能力不足的问题。比如回答公司内部制度时，模型不能靠记忆猜，要检索文档；计算日期差时，应该交给程序。

Prompt：先把任务边界说清楚

Prompt 层的方法最基础，也最容易立刻用起来。

Zero-shot

Zero-shot 指不提供样例，直接给任务。它适合规则清楚、风险不高的场景。

把下面这段用户反馈归类为：支付问题、账户问题、性能问题、其他。
用户反馈：我点付款后页面一直转圈。
只输出分类名。

这个例子里，模型不需要学习样例，只要按给定标签判断。为了减少跑偏，提示里限定了标签范围和输出格式。

Few-shot

Few-shot 指给几个输入输出样例，让模型模仿规律。

输入：退款一直不到账
输出：支付问题

输入：忘记密码，收不到验证码
输出：账户问题

输入：首页加载很慢
输出：性能问题

输入：点付款后页面一直转圈
输出：

当任务的判断标准不容易用一句话讲清楚时，Few-shot 很有用。比如“语气是否礼貌”“标题是否像知识库文章”“反馈属于哪个业务线”，样例往往比抽象规则更稳定。

Act

Act 是让模型按某个角色或动作模式工作。它不是简单角色扮演，而是限制模型的回答职责。

你是代码审查助手。只检查潜在 bug、边界条件和缺失测试。
不要重写整段代码。

这个例子把模型限制在“审查”而不是“重构”。边界越清楚，输出越不容易发散。

ReAct

ReAct 把推理和行动交错起来。模型先想下一步该做什么，再执行一个动作，观察结果后继续推理。

一个资料查询任务可以这样设计：

问题：某个库的新版本是否改变了默认配置？
思考：需要查 release notes。
行动：搜索该库 release notes。
观察：版本说明里提到默认缓存策略变化。
回答：说明变化、影响和迁移建议。

ReAct 的价值在于让模型不要闭门造车。遇到依赖外部信息的任务，它可以先查、再答。

Directional Stimulus Prompting

Directional Stimulus Prompting 是给模型一些方向性线索，让它朝指定重点生成。

写一段关于 RAG 的解释。
方向性线索：外部知识库、检索、上下文拼接、减少幻觉、不能保证绝对正确。

这不是把答案写好，而是把注意力放到关键点上。它适合摘要、改写和内容生成任务，尤其适合避免模型漏掉重要角度。

Chain：把推理过程拆开

Chain 层解决的是“模型一步跳到结论”的问题。

Chain of Thought

Chain of Thought，通常简称 CoT，是让模型先写出中间推理，再给答案。它适合多步推理任务。

一个会议从 14:30 开始，持续 95 分钟，中间休息 10 分钟。
请先计算结束时间，再给答案。

模型如果直接回答，容易在时间换算上出错。要求它先算 95 分钟 = 1 小时 35 分钟，再加休息时间，错误更容易被发现。

flowchart TD
  A["原始问题"] --> B["拆出已知条件"]
  B --> C["逐步计算或推理"]
  C --> D["检查中间结果"]
  D --> E["输出答案"]

CoT 的关键不是让答案变长，而是让中间步骤可检查。

Self-Consistency

Self-Consistency 是让模型生成多条推理路径，再选择最一致的答案。

题目：小李有 3 盒笔，每盒 12 支，送出 5 支后还剩几支？
路径 A：3 x 12 = 36，36 - 5 = 31。
路径 B：12 + 12 + 12 = 36，送出 5 支，剩 31。
路径 C：3 + 12 - 5 = 10。
多数路径得到 31，答案取 31。

它适合答案可以聚合的任务，比如数学题、选择题、常识判断。代价是调用次数更多。

Tree of Thoughts

Tree of Thoughts 把一条推理链扩展成多条候选路径。模型可以生成多个想法，评估它们，再选择继续展开的分支。

比如让模型规划一篇技术博客：

分支 A：按历史发展写，从 Prompt 到 Agent。
分支 B：按问题类型写，表达、推理、搜索、工具。
分支 C：按初学者使用顺序写，先日常提示，再系统集成。
评估：初学者更容易按问题类型理解，所以保留分支 B。

ToT 适合有搜索空间的问题。写大纲、解谜、策略规划、架构方案比较，都比单链推理更适合用树。

Reflexion

Reflexion 让模型在失败后写下反思，再把反思用于下一轮尝试。

一个代码修复任务可以这样用：

第一次尝试：修复了空指针，但测试仍失败。
反思：失败原因不是空指针，而是数组越界；需要检查循环边界。
第二次尝试：把 i <= length 改成 i < length。

它适合多轮任务，比如代码调试、网页操作、复杂问答。反思不是情绪总结，而是可复用的错误诊断。

Graph：复杂任务不是一条直线

Tree 可以分叉，但真实任务经常还需要合并。Graph of Thoughts 把“想法”看成图里的节点，不同节点可以互相依赖、互相校验，也可以汇合成一个结论。

flowchart TD
  A["问题：是否采用 RAG"] --> B["资料规模"]
  A --> C["更新频率"]
  A --> D["准确性要求"]
  A --> E["系统成本"]
  B --> F["适用性判断"]
  C --> F
  D --> G["风险判断"]
  E --> G
  F --> H["最终建议"]
  G --> H

举个例子，团队要判断一个客服机器人是否需要 RAG。资料规模、更新频率、准确性要求、系统成本是四个子问题。资料规模和更新频率决定 RAG 是否必要；准确性要求和成本决定 RAG 怎么做。最后两个局部结论合并，才是完整建议。

GoT 特别适合技术调研、竞品分析、架构评审。它让模型不必把所有东西塞进一条线性回答里。

Generate：让模型参与生成提示和背景知识

Generate 层不是让模型直接给最终答案，而是让模型先生成辅助材料。

Automatic Prompt Engineer

Automatic Prompt Engineer，简称 APE，是让模型生成多个候选提示，再用测试结果筛选。

比如要做情感分类，可以让模型先生成候选提示：

候选 1：判断文本情绪是正面、负面还是中性。
候选 2：你是客服质检员，请判断用户反馈表达的是满意、不满还是中立。
候选 3：只输出 positive、negative、neutral，不要解释。

然后拿一批标注样例测试。如果候选 3 在格式上最稳定，但候选 2 在语义上更准，可以把两者合并成更好的提示。

Generated Knowledge Prompting

Generated Knowledge Prompting 是先生成相关知识，再用这些知识回答问题。

问题：为什么金属勺子放进热汤里会变热？
生成知识：金属导热性强；热量会从高温物体传向低温物体。
回答：热汤的热量沿着金属勺子传导，所以勺柄也会升温。

这个方法适合常识推理，但要小心：模型生成的背景知识也可能错。涉及产品版本、法律条款、医学信息、论文结论时，生成知识应该和检索资料一起使用。

Integrate：提示词工程变成系统工程

Integrate 层把模型接到外部系统上。很多应用不是靠一句提示词变强，而是靠资料、工具和程序一起工作。

RAG

RAG 是 Retrieval-Augmented Generation，也就是检索增强生成。它先从外部资料中检索相关内容，再把检索结果交给模型生成回答。

企业知识库问答是最典型的例子：

用户问：年假可以跨年保留吗？
系统检索：员工手册里的年假条款。
模型回答：根据检索到的条款，说明可保留天数、截止日期和例外情况。

RAG 的重点不是“让模型知道更多”，而是让回答有资料来源。它也不是万能的：检索不到、检索错了、文档本身过期，都会影响答案。

Automatic reasoning

Automatic reasoning 是一篇论文提出的技术，全称是 Automatic Reasoning and Tool-use。可以理解成自动生成多步推理流程，并在需要时调用工具。

一个旅行预算任务可以这样拆：

步骤 1：查询机票价格。
步骤 2：查询酒店均价。
步骤 3：用计算器汇总交通、住宿和餐饮预算。
步骤 4：按预算上限给出方案。

这类方法比单纯 CoT 更接近工作流。模型不只写推理，还决定什么时候查资料、什么时候计算、什么时候汇总。本质上，它是 ReAct（Reasoning + Acting）思想在"自动化"方向的延伸，强调模型能自主规划整个"思考+行动"的流程，而不需要人工硬编码步骤。

Tool-use

Tool-use 是让模型调用外部工具。工具可以是搜索、数据库、计算器、代码解释器、浏览器，也可以是公司内部 API。

问题：下周三距离今天还有多少天？
错误做法：模型凭感觉回答。
工具做法：调用日期计算工具，得到精确天数，再生成回答。

Toolformer 这类研究关注的是模型如何学会调用工具。实际应用里，工具调用的稳定性往往比提示词华丽程度更重要。

Program-aided Language Models

Program-aided Language Models，简称 PAL，是让模型把问题转成程序，把计算交给解释器。

prices = [19.9, 35.5, 12.0]
discount = 0.8
total = sum(prices) * discount
print(total)

模型适合理解题意和写代码，程序适合精确计算。遇到数学、表格、日期、统计任务时，PAL 通常比纯文字推理可靠。

flowchart LR
  A["用户问题"] --> B["模型判断任务类型"]
  B --> C{"需要外部能力吗？"}
  C -->|查资料| D["RAG 检索文档"]
  C -->|查状态或执行动作| E["Tool-use 调用工具"]
  C -->|精确计算| F["PAL 生成并运行程序"]
  D --> G["生成答案"]
  E --> G
  F --> G

初学者怎么选方法

遇到一个任务，可以先判断它缺什么。

flowchart TD
  A["模型输出不好"] --> B{"缺清楚格式？"}
  B -->|是| C["用 Prompt / Few-shot"]
  B -->|否| D{"缺推理步骤？"}
  D -->|是| E["用 CoT / Self-Consistency"]
  D -->|否| F{"有多条方案？"}
  F -->|是| G["用 ToT / GoT"]
  F -->|否| H{"缺背景资料？"}
  H -->|是| I["用 Generated Knowledge 或 RAG"]
  H -->|否| J{"需要执行或计算？"}
  J -->|是| K["用 Tool-use / PAL"]
  J -->|否| L["简化提示，重新定义任务"]

如果只是把一段文字改短，Prompt 就够了。比如“压缩到 100 字，只保留结论和行动项”。

如果要解一道多步题，用 Chain。比如“先列公式，再计算，再检查单位”。

如果要比较三种技术方案，用 Tree 或 Graph。比如“分别评估 Next.js、Astro、纯静态站点，再合并成建议”。

如果要回答公司制度，用 RAG。比如“只根据员工手册回答，找不到就说资料不足”。

如果要处理 Excel、日期或金额，用 PAL。比如“读取表格后计算每月增长率，并输出代码和结果”。

一个好提示长什么样

好的提示通常包含任务、输入、约束、输出格式和校验方式。

任务：解释 RAG 的工作流程。
读者：刚接触大模型应用的开发者。
要求：每个步骤都举一个客服知识库的例子。
输出：先给一句话定义，再用 Mermaid 画流程图，最后列出两个常见坑。
校验：不要说 RAG 可以完全消除幻觉。

这个提示能工作，是因为它同时处理了五件事：读者是谁、讲什么、怎么讲、输出长什么样、哪些话不能说。

提示词工程的核心不在于堆技巧，而在于识别任务缺口。缺格式就补格式，缺例子就补例子，缺资料就接检索，缺计算就跑程序。

参考资料

• Jason Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022.
• Xuezhi Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, 2022.
• Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
• Google Research, ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
• Shunyu Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, 2023.
• Maciej Besta et al., Graph of Thoughts: Solving Elaborate Problems with Large Language Models, 2023.
• Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023.
• Yongchao Zhou et al., Large Language Models Are Human-Level Prompt Engineers, 2022.
• Jiacheng Liu et al., Generated Knowledge Prompting for Commonsense Reasoning, ACL 2022.
• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• Timo Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools, 2023.
• Bhargavi Paranjape et al., ART: Automatic multi-step reasoning and tool-use for large language models, 2023.
• Luyu Gao et al., PAL: Program-aided Language Models, 2022.