推理增强Prompt：Plan-and-Solve规划求解

可视化演示

展示Plan-and-Solve的规划与求解两阶段流程、计划步骤逐步执行过程、及与Zero-shot CoT的对比分析。

问题根源：单步思考为何容易翻车

新手厨娘打开菜谱 App，屏幕只有一句话：“按步骤做。”她深吸一口气，撸起袖子直接开火——先把姜丢进锅，又把排骨放进去，结果姜炒糊了，排骨还是硬的。问题不在于她不够努力，而在于她手上没有一张全局的烹饪流程图：先做什么、后做什么、哪些步骤之间存在依赖，全凭感觉。

在推理增强 Prompt 里，Zero-shot CoT 就是那个只有一句话的菜谱。它的做法是在 Prompt 末尾加上“让我们一步一步地思考”（Let's think step by step），模型确实会输出一串推理步骤，但因为缺少显式规划，很容易出现三类问题：推理步骤遗漏、步骤跳跃和计算错误。模型不是不会推，而是没有“先想清楚整体再动手”的约束，生成到哪算哪。

我们可以用一个简单模型来理解这种现象：假设一条推理链有 \(n\) 个中间步骤，每一步独立的成功概率是 \(p_i\)，那么整条链最终成功的概率就是每一步成功概率的连乘。

每多一个没被规划的步骤，成功概率就被乘上一次；就像一道菜每多一个环节，翻车的风险就叠加一次。这就是为什么我们需要先帮模型把“流程图”画出来——于是便有了 Plan-and-Solve。

核心原理：先规划后执行

经验丰富的主厨走进厨房前，会先在便签上写清楚：今天做什么菜、需要哪些食材、先焯水还是先腌肉、最后用什么火候收汁。这张便签就是“规划”，而真正点火、翻炒、调味的过程才是“执行”。两者分开做，思维才不乱。

Plan-and-Solve 的核心思想正是如此：把一次复杂推理显式拆成两个阶段。第一阶段让模型理解题目并制定计划；第二阶段让模型按计划逐步求解。它不是一个神秘的模型，而是一种提示模板的编排方式，通过修改 Prompt 文本，迫使模型的输出先出现“计划”，再出现“执行”。

相比 Zero-shot CoT 的“单步指令”，Plan-and-Solve 在结构上增加了一个“规划入口”，从而减少步骤遗漏和跳步。用数学语言描述，整个流程是：

把“怎么做”和“做”分开，是这道流程的灵魂。主厨不会一边想计划一边炒菜，模型也不应该一边推理一边临时决定下一步。先规划后执行，让推理有章可循。

规划阶段：把菜谱写清楚

一份好菜单，至少要回答三个问题：做什么菜（目标）、需要哪些食材（条件）、按什么顺序做（流程）。Plan-and-Solve 的规划阶段，就是让模型在真正计算之前，先回答同类问题。

具体来说，规划阶段的输出应该包含：理解题目目标、拆解子问题、确定求解顺序、标注关键公式。以一道小学数学应用题为例：“小明有 12 个苹果，吃掉 3 个后又买了 5 个，现在有多少个？”好的计划不是直接写答案，而是先写“初始有 12 个；吃掉 3 个用减法；再买 5 个用加法；最后验算数量非负”。

在数学上，计划可以看成一个有序的步骤序列：

菜谱写得越清楚，开火之后就越不慌。规划阶段写得越好，求解阶段就越不容易临时“翻车”。

求解阶段：按计划逐步执行

菜单写好后，主厨的工作还没结束：他得按顺序把菜下锅，计时，尝味，最后装盘。求解阶段就是“把计划落到实处”的过程，它要求模型对计划中的每个步骤依次执行，并输出对应的中间结果。

在实际操作中，求解阶段要避免三个坏习惯：跳步、合并、换序。如果计划写的是“先算括号内再算括号外”，求解时就不能突然先算乘法。每执行完一个步骤，还应该做一次快速检查：这个结果和上一步是否自洽？有没有超出题目的约束范围？

用状态转移的语言描述，求解阶段从初始状态出发，每一步都在当前状态上应用一个计划步骤，得到新状态：

规划与执行形成闭环：计划告诉我们“做什么”，执行负责“做出来”。就像主厨只有严格按照菜单顺序烹饪，才能保证端上桌的菜和设计时一个味道。

提示模板：把菜谱写进 Prompt

如果主厨想把经验传给学徒，最好的方式就是写一份标准菜谱。Plan-and-Solve 也一样，它最终落地为一套提示模板。模板的价值不在于文采，而在于结构：明确要求模型先输出“计划”，再输出“执行”。

最经典的英文模板来自论文原文：“Let's first understand the problem and devise a plan to solve the problem. Then, let's carry out the plan to solve the problem step by step.” 翻译成中文后，可以这样组织：

这段模板的要点是把“规划”和“执行”的标签写死，让模型的输出天然分成两段。我们还可以针对具体场景定制变体，比如在代码任务中把“验算”改成“单测”，在数学任务中把“公式”改成“方程”，在 Agent 任务中把“计算顺序”改成“工具调用顺序”。

抽象地看，模板的作用就是定义了一个计算流程：

好的提示模板就像一张标准菜谱，学徒照着做也能做出八分味道。通过把两阶段结构固化在文本里，我们不必修改模型，就能显著提升多步推理的稳定性。

请先理解题目并制定一个完整的分步计划，然后按照计划逐步求解，最后输出答案。要求输出格式：Plan:1. 明确已知条件和目标2. 列出需要的关键公式或规则3. 确定计算顺序和验算方法Solve:按计划一步步计算，并在每一步后给出简短解释题目：{problem}

效果对比：为什么更稳

同一个厨房，一张菜单配一份执行清单，和没有菜单直接开火，出菜质量能一样吗？显然不一样。Plan-and-Solve 相比 Zero-shot CoT，最大的提升在于多步推理任务上的稳定性。

在论文的评测中，Plan-and-Solve 在 GSM8K、MultiArith 等一系列数学推理数据集上，准确率普遍高于 Zero-shot CoT，尤其当问题包含多个计算步骤时，优势更明显。原因并不复杂：Zero-shot CoT 是“边想边写”，模型可能在第三步就把第一步的结论忘掉；而 Plan-and-Solve 先写计划，相当于给模型一个外部记忆，让每一步的执行都有依据。同时，因为输出中明确分出了计划与执行，人工排查错误时也能更快定位是“计划错了”还是“计算错了”。

用公式表达这种相对提升：

多花的几秒思考时间，换来的是更稳的出菜质量。对生产环境而言，稳定比偶尔的惊艳更重要，这正是 Plan-and-Solve 能站稳脚跟的原因。

应用局限：不是万能刀

再好的菜谱，也不能保证每个客人都说好吃；再好的 Plan-and-Solve，也有自己的边界。它并不是一个“加了就变强”的魔法词。

首先，Token 开销增加。规划阶段会额外产生一段计划文本，意味着每次请求都要多消耗几十到几百个 Token，推理延迟也因此上升。其次，对简单任务可能得不偿失。如果题目是“1+1 等于几”，还先写计划再执行，反而显得笨拙且容易引入无关信息。最后，对极其复杂的任务，Plan-and-Solve 依然可能失败——模型可能写出一个漂亮的计划，却在执行时算错；或者计划本身就有逻辑漏洞，执行得越认真错得越远。

因此，实践中常常把它和其他方法组合使用，比如在计划阶段引入外部工具校验，或结合自我一致性采样，甚至让模型先自我批判再修正计划。综合下来，时间成本会更高：

知道边界，才知道把工具用在刀刃上。Plan-and-Solve 适合多步推理、数学应用、逻辑检查这类“值得先规划”的任务；面对简单问题，就该收起菜单，直接上菜。

AI 应用场景

Python 演示

"""Plan-and-Solve prompt workflow demo:split a complex problem into planning and solving.No external API, use mocked output for offline run."""  def make_ps_template(problem: str) -> str:    """Build a Plan-and-Solve prompt template."""    return (        "Please first understand the problem and devise a detailed plan. "        "Then carry out the plan step by step.\n"        "Output format:\n"        "Plan:\n"        "Solve:\n"        "Problem: " + problem + "\n"    )  def parse_plan_and_solve(output: str) -> dict:    """Split model output into plan and solve parts."""    plan_part = ""    solve_part = ""    if "Plan:" in output and "Solve:" in output:        plan_part = output.split("Plan:")[1].split("Solve:")[0].strip()        solve_part = output.split("Solve:")[1].strip()    return {"plan": plan_part, "solve": solve_part}  def mock_llm(prompt: str, steps: tuple) -> str:    """Mock a model output for demo purposes."""    return "Plan:\n" + steps[0] + "\nSolve:\n" + steps[1]  def demo() -> None:    problem = "Xiao Ming has 12 apples, eats 3, then buys 5 more."    prompt = make_ps_template(problem)    output = mock_llm(        prompt,        (            "1. initial count is 12\n"            "2. eating 3 means subtract 3\n"            "3. buying 5 means add 5",            "12 - 3 = 9; 9 + 5 = 14, answer: 14.",        ),    )    result = parse_plan_and_solve(output)    print("Prompt template:\n", prompt)    print("Plan:\n", result["plan"])    print("Solve:\n", result["solve"])  if __name__ == "__main__":    demo()

1. def make_ps_template(problem: str) -> str:构造带“Plan:”和“Solve:”分节的提示模板，强制模型按结构输出。
2. "Please first understand the problem and devise a detailed plan."提示的核心是“先理解并制定计划”，对应规划阶段。
3. "Then carry out the plan step by step."后半句引导模型进入执行阶段。
4. "Output format:\nPlan:\nSolve:"用固定标签约束输出结构，方便后续解析。
5. def parse_plan_and_solve(output: str) -> dict:把模型输出按“Plan:”和“Solve:”切分开，便于检查计划与执行是否完整。
6. output.split("Plan:")[1].split("Solve:")[0].strip()提取中间的计划文本，去除首尾空白。
7. def mock_llm(...)离线模拟一次模型输出，方便在没有 API 的环境下演示流程。
8. if __name__ == "__main__":提供可执行入口，直接运行即可看到完整工作流。

常见误区

面试题