prompt 工程学习总结

1 提示词工程

Zero-Shot / Few-Shot
1. 注：这个词语在学习gpt系列中 gpt3 的时候提及过，Zero-Shot/Few-Shot 的概念并非 GPT-3 首创，但 GPT-3 是首个让大语言模型（LLM）的 Zero/Few-Shot 能力大规模落地并引发行业关注的模型。
2. Zero-Shot 依赖模型的通用知识，适合简单任务；
3. Few-Shot 通过示例降低任务理解难度，适合复杂或特定场景。
4. Zero-Shot：(零样本提示)：不给任何示例，直接用自然语言描述任务要求让模型来完成
  1. 核心原理：利用模型预训练时学到的通用知识，映射新任务与已知概念的关联
  2. 使用场景：简单分类、基础文本生成、任务描述明确的场景
  text 复制代码
```
示例:
提示词："将以下英文句子翻译成中文：'Hello, how are you?'"
模型输出："你好，最近怎么样？"
此场景中，模型未获得任何翻译示例，仅通过自身知识完成任务
```
5. Few-Shot(少样本提示)：在提示词中提供少量任务示例，帮助模型理解任务逻辑并生成答案。
  1. 核心原理：基于小样本归纳，让模型快速适配特定任务范式，降低微调成本
  2. 使用场景：数据稀缺的定制化任务、格式约束严格的输出（如结构化报告）
  text 复制代码
```
请判断以下句子的情绪是「积极」还是「消极」：

示例1：今天的阳光特别好，心情也跟着明媚起来 → 积极
示例2：错过末班车，又淋了雨，真的太倒霉了 → 消极
示例3：新入手的书内容超精彩，熬夜都想读完 → 积极

现在请判断：
句子：这款新出的耳机音质超棒，佩戴也很舒服 → "积极"(模型输出)
```
COT(Chain-of-Thought)：通过提示引导模型将复杂问题拆解为分步推理链条 ，逐步推导答案，而非直接给出结论。核心思想是让模型显式表达"思考过程"，类似人类解决问题时的逐步分析。
1. 区别于传统的 Prompt 从输入直接到输出的映射 <input------>output> 的方式，CoT 完成了从输入到思维链再到输出的映射，即 <input------>reasoning chain------>output>
2. 使用场景：数学计算、逻辑推理、多步骤决策
  text 复制代码
```
普通提示：
问题：1个书架有3层，每层放5本书，共有多少本书？
答案：15本

cot 提示：
问题：1个书架有3层，每层放5本书，共有多少本书？
推理：
1. 每层5本书，3层的总书数 = 5 × 3
2. 5 × 3 = 15
答案：15本
```
3. 一个完整的包含 CoT 的 Prompt 往往由指令（Instruction），逻辑依据（Rationale），示例（Exemplars）三部分组成
  1. 一般而言指令用于描述问题并且告知大模型的输出格式
  2. 逻辑依据即指 CoT 的中间推理过程，可以包含问题的解决方案、中间推理步骤以及与问题相关的任何外部知识
  3. 示例则指以少样本的方式为大模型提供输入输出对的基本格式，每一个示例都包含：问题，推理过程与答案。
4. 零样本思维链（Zero-Shot CoT）：无需示例，仅通过提示词（如"请分步骤思考"）触发模型生成思维链。适用于快速引导模型进行推理。
5. 少样本思维链（Few-Shot CoT）：提供少量带思维链的示例，让模型模仿示例结构进行推理。例如，先给出几个问题及其分解步骤，再让模型处理新问题
ToT（Tree of Thought，思维树）:将问题求解视为树状搜索过程 ：模型生成多个可能的解题路径（分支），对每条路径的中间结果进行评估，选择最优分支继续探索，直至找到答案。
1. 在ToT中，为了帮助模型识别最有效的思维序列，系统使用了常用的搜索算法，比如广度优先搜索（BFS）和深度优先搜索（DFS）。
  1. BFS:核心是 "层层推进" ：先访问离起点最近的节点（当前层），再依次访问下一层的所有节点，像 "水波扩散" 一样。
    1. 核心数据结构：队列（Queue）（先进先出，类比排队取餐）。
    2. 通俗理解：找迷宫出口时，先搜完当前位置周围的所有路径，再往更远的地方搜。
  2. DFS:核心是 "一条路走到黑" ：沿着一条路径一直走到尽头，再回溯（退回来）走其他未探索的路径。
    1. 核心数据结构：栈（Stack） （后进先出，类比摞起来的盘子）或递归（递归本质是调用栈，类比套娃）。
    2. 通俗理解：找迷宫出口时，先往一个方向走到死胡同，再回头换方向继续走。
2. 使用场景：创意生成、复杂规划、多解问题
3. 优势：
  1. 避免单一思维链的局限性，通过并行探索提升解题成功率。
  2. 适用于存在多个可行解的场景，可优化答案质量。
  3. ToT的灵活性和适应性比 COT更强。
GoT（Graph-of-Thoughts，思维图谱）：将问题拆解为图结构 ，节点代表关键概念或中间结论，边代表概念间的关系（如因果关系、依赖关系）。模型通过遍历图节点，整合多源信息进行推理(不是很熟悉知识图谱，此处仅了解)。
1. 使用场景：知识图谱构建、多源信息融合推理，复杂知识推理，跨领域问答
2. 优势：
  1. 支持处理多维度、非线性的复杂关系，适合需要全局视角的任务。
  2. 可扩展性强，易于整合外部知识库。

PoT（Plan of Thought，思维规划）：强调预先制定解决问题的总体规划 ，将任务分解为明确的阶段或子目标，按计划逐步执行

PoT是将问答背后的推理过程公式化为一个可执行程序（Program） ，将程序解释器输出作为最终答案的一部分。
1. 思维程序（PoT）是一种独特的LLM推理方法。它不仅仅是生成自然语言答案，而是要求创建一个可执行程序，可以在Python等程序解释器上运行，从而产生实际的结果。这样，PoT的表达更加清晰、准确，尤其是对于需要进行数值计算的数学类型逻辑问题更是如此。
2. 需要注意的是，PoT的程序执行不一定针对最终答案，而是可以作为最终答案的中间步骤的一部分。
核心方法
1. 分层规划：将任务分为高层目标（如"完成市场分析报告"）和低层子任务（如"数据收集→趋势分析→结论撰写"）。
2. 时序约束：提示模型考虑任务的时间顺序和依赖关系（如"必须先完成A，才能进行B"）。
3. 动态调整：在执行过程中根据反馈优化计划（如遇到障碍时切换子任务顺序）。
使用场景：复杂数学运算、数据处理、规则化推理
优势
1. 提升任务执行的条理性，减少冗余或遗漏。
2. 适合需要分阶段完成的复杂任务，降低认知负荷
总结与趋势
1. CoT仍是基础范式，尤其适合教育、逻辑推理场景。
2. GoT凭借图结构的灵活性，成为处理复杂任务的新标杆，可能逐步取代ToT。
3. PoT在需要高精度计算的领域（如工程、金融）具有不可替代性。
实践经验：
1. 简单问题：优先使用CoT，保持推理的简洁性。
2. 开放问题：尝试ToT，探索多种可能性后再收敛答案。
3. 复杂知识问题：结合GoT，利用外部知识图谱增强推理深度。
4. 长流程任务：采用PoT，确保任务按计划有序推进。
实际使用：与大模型手动交互；工程化封装成模板

框架	核心逻辑	结构特点	适用任务类型	典型场景
CoT	线性分步推理	链式结构	单路径、逐步推导问题	数学题、逻辑推理
ToT	多路径搜索与评估	树状结构	多解探索、需全局优化的问题	游戏策略、创意生成
GoT	图结构关系整合	网状结构	多维度关联、跨领域推理问题	知识图谱问答、复杂因果分析
PoT	分层规划与任务分解	层级结构	分阶段执行、时序依赖问题	项目管理、长文本生成

ReAct(Reason-Act 推理 - 行动模式)：让模型交替执行 "思考下一步动作" 和 "执行工具调用"，实现闭环决策
1. 虽然CoT增强了大模型的推理能力，但它的推理过程主要依赖大模型内部的知识库，缺乏与外部世界的实时互动，这可能导致知识滞后、产生错误信息或让错误不断传递。ReAct（Reasoning and Action）框架则依据结合"推理"（Reasoning）与"行动"（Action），解决了这一挑战。
  1. 它让大模型在推理时能与外部工具或环境互动，获取最新信息、执行具体操作，并根据反馈调整后续步骤。
  2. 这种动态交互让大模型具备了"边思考边行动、边观察边调整"的能力，核心运作机制可总结为"思考（Thought）→行动（Action）→观察（Observation）"的循环。
2. 流程：接收目标→推理第一步行动→执行→观察结果→基于结果推理第二步行动→循环直至完成目标；无预先完整规划，依赖实时反馈动态决策，强调 "思考 - 行动 - 反馈" 的闭环
  1. Thought (思考): Agent 首先基于当前目标和之前的观察进行内部"思考"。这通常是利用 LLM 生成一段描述当前状态、分析问题、制定下一步行动策略或分解任务的文本。
  2. Action (行动):基于思考的结果，Agent 决定执行一个具体的行动。这通常是调用一个工具（如搜索引擎、计算器、API）并附带必要的参数，或者是向用户请求更多信息，甚至是判断任务已经完成并生成最终答案。
  3. Observation (观察): 执行行动后，Agent 会从环境或工具那里获得一个结果或反馈，这就是"观察"。例如，搜索引擎返回的搜索结果、API 调用的输出、代码执行的错误信息等。
  4. 回到 Thought: Agent将这个观察结果纳入考量，开始新一轮的思考，评估上一步行动的效果，判断是否必须调整策略，并规划下一步的行动。这个循环不断重复，直到 Agent 判断任务目标已经达成。
3. prompt 的巧妙设计：
  1. 管用思考 (Thought): 指示LLM 分析当前状况、回顾目标、评估已有信息、识别知识差距、制定行动计划。常常包含 "Think step-by-step" 或类似的指令。
  2. 做出行动决策 (Action):指示 LLM 以特定格式（如 JSON）输出要调用的器具名称和参数，或者输出最终答案。
  3. 解读观察结果 (Observation):帮助 LLM 理解软件返回的信息，并将其融入下一步的思考中。
  4. Prompt 还需要包含可用工具的描述以及一些示例（Few-shot examples），来帮助 LLM 更好地理解如何在这个循环中工作。
4. 优点分析
  1. 灵活性高: ReAct 能够根据每一步的观察结果动态调整策略，对预料之外的情况或工具执行失败具有较强的适应性。
  2. 处理知识密集型任务: 经过迭代地应用工具（如搜索）获取信息，ReAct 能较好地处理需外部知识的任务。
  3. 透明度: "Thought"步骤提供了 Agent 决策过程的中间记录，便于理解和调试。
5. 缺点分析
  1. 可能陷入无效循环: 如果 Agent 的思考或工具使用出现偏差，可能会导致在几个步骤之间重复循环而无法取得进展。
  2. 效率较低: 每一步都需 LLM 进行思考和决策，对于长流程任务，LLM 调用次数多，可能导致较高的延迟和成本。
  3. 错误累积: 前一步的错误（如错误的思考或应用调用失败）可能会影响后续步骤，导致最终结果偏差。
6. 使用场景：智能体（Agent）、需要外部工具的任务（如信息检索、数据分析）
  1. 任务简单、无需长期规划（如单轮问答、API 调用）。
  2. 希望快速部署，避免训练成本。

Plan-Act（规划 - 执行）模式：一种线性的 "先规划后执行" 模式 ，核心是 "先制定完整计划，再按计划逐步执行"，无中间反馈调整环节：

流程：接收目标→拆解为固定子任务序列→按顺序执行所有步骤→输出结果；
特点：规划阶段一次性确定所有行动路径，执行过程中不根据实际结果修改计划；

Plan-and-Execute 框架：结构化规划与顺序执行：与 ReAct 的迭代试错不同，Plan-and-Execute (P-a-E) 采取了一种更结构化、更线性的途径。

Planning (规划) 阶段: 首先，Agent（通常通过一次或少数几次 LLM 调用）基于用户给定的初始目标，生成一个完整的、通常是分步骤的执行计划。这个计划列出了为达成目标所需执行的所有步骤及其顺序。
Execution (执行) 阶段: 然后，Agent严格按照预先制定的计划，一步一步地顺序执行。通常每一步会涉及调用一个或多个程序。只有当前步骤成功达成后，才会进入下一步。
规划器 (Planner): 负责一个专门的 LLM 调用，其 Prompt 旨在输出一个清晰的步骤列表或带有依赖关系的计划就是理解初始目标并生成结构化的执行计划。这通常。计划的质量直接决定了 Agent 的最终表现。
执行器 (Executor): 负责解析计划，并按顺序调度工具执行每个步骤。它需要管理步骤间的状态传递（如上一步的输出作为下一步的输入），但不负责重新规划（除非设计了非常复杂的错误处理逻辑）。

注：这些都更偏向于在 Agent 中使用，以下为介绍的三种模式的对比，以及落地较多的四种范式

维度	Plan-Act 模式	ReAct 模式
规划方式	预先制定完整、固定的计划	无预先计划，每步动态推理
反馈机制	无执行中反馈，计划一旦确定不修改	每步执行后均根据结果反馈调整策略
灵活性	低，无法应对计划外的异常情况	高，可适配环境变化或意外结果
适用场景	简单、确定性高的任务（如固定流程自动化）	繁琐、不确定性高的任务（如多平台比价、故障排查）
决策逻辑	静态的 "计划驱动"	动态的 "反馈驱动"

范式名称	核心价值	典型应用
Self-Consistency（自洽性推理）	大幅降低模型幻觉，提升结果可靠性	数学计算、常识问答、事实性检索
Self-Refine（自我优化推理）	迭代提升内容质量，无需人工介入	文案撰写、报告生成、代码优化
Least-to-Most（由易到难提示）	拆解复杂问题，攻克 "无从下手" 的任务	数学证明、复杂代码编写、多步骤决策
Reflexion（反思式推理）	让模型从错误中学习，优化后续执行	工具调用调试、多轮对话纠错、故障排查

2 结构化提示框架

注：上面的都是提示词工程的不同思路方法，结构化提示框架更像是对提示词工程的一个规范模板，避免遗漏信息，按照模板填写对应信息即可，以下为当前主流的提示词工程框架及其核心要素、适用场景
ICIO 框架
1. 核心要素：
  1. Instruction（任务）：明确AI需要完成的具体任务（如翻译、写作）。
  2. Context（背景）：提供任务相关的上下文信息（如使用场景、目标受众）。
  3. Input Data（输入数据）：指定需要处理的具体数据（如待翻译的文本）。
  4. Output Indicator（输出格式）：定义输出的风格、格式或类型（如正式商务英语）。
2. 适用场景：数据转换（文本翻译、清洗）、内容创作（报告、文案）、技术任务（代码生成）。
CRISPE 框架
1. 核心要素：
  1. Capacity and Role（角色）：设定AI的角色（如数学老师）。
  2. Insight（背景）：提供角色扮演的上下文（如学生年龄、学习环境）。
  3. Statement（任务）：具体任务描述（如解答数学问题）。
  4. Personality（格式）：回答的风格（如友好、鼓励性语言）。
  5. Experiment（实验）：请求多个示例或变体。
2. 适用场景：角色模拟（教师、顾问）、个性化互动（幽默/正式语气）、多样化输出（多方案生成）。
BROKE 框架
1. 核心要素：
  1. Background（背景）：项目或任务的背景信息。
  2. Role（角色）：AI需扮演的角色（如项目经理）。
  3. Objectives（目标）：明确任务目标（如制定项目计划）。
  4. Key Result（关键结果）：输出的格式要求（如甘特图）。
  5. Evolve（改进）：根据反馈迭代优化。
2. 适用场景：项目管理（资源分配）、创意设计（多轮优化）、数据分析（动态调整）。
RASCEF 框架
1. 核心要素：
  1. Role（角色）：定义AI身份（如营销专家）。
  2. Action（行动）：具体任务（如制定邮件策略）。
  3. Script（步骤）：分步骤流程（如分析受众→设计内容）。
  4. Content（上下文）：背景信息（如公司定位）。
  5. Example（示例）：输出示例（如健康饮食推文）。
  6. Format（格式）：指定结构（如列表、段落）。
2. 适用场景：专业咨询（营销策略）、流程管理（项目管理）、标准化输出（模板化内容）。
CO-STAR 框架
1. 核心要素：
  1. Context（上下文）：任务背景。
  2. Objective（目标）：明确核心任务。
  3. Style（风格）：模仿特定写作风格。
  4. Tone（语气）：情感基调（正式/幽默）。
  5. Audience（受众）：目标用户群体。
  6. Response（回复格式）：输出结构（如列表、报告）。
2. 适用场景：广告文案、社交媒体内容、个性化报告。
RODES 框架
1. 核心要素
  1. Role（角色）：详细定义AI身份（如病毒推文作家）。
  2. Objective（目标）：具体任务（如撰写280字推文）。
  3. Details（细节）：约束条件（如禁用表情符号）。
  4. Examples（示例）：输入-输出范例。
  5. Sense Check（感知检查）：确认AI理解需求。
2. 适用场景：社交媒体运营、创意内容生成、新手友好型提示设计。
选择参考：
1. 技术任务：优先使用ICIO或BROKE，确保逻辑清晰。
2. 创意内容：CRISPE或RODES更适合角色化、风格化需求。
3. 复杂流程：RASCEF和CO-STAR提供结构化支持。
使用方法：手动交互/工程化封装

框架	核心特点	适用领域
ICIO	任务明确、格式标准化	技术任务、翻译、报告
CRISPE	角色扮演、多方案生成	教育、咨询、个性化互动
BROKE	动态优化、项目管理导向	长期项目、数据分析
RASCEF	流程化步骤、全面结构化	专业咨询、复杂流程管理
CO-STAR	多维度定制（风格/受众）	广告、社交媒体
RODES	新手友好、强调示例与反馈	创意内容、标准化输出

参考资料

1 2