Plan-and-Solve Prompting：从"边想边做"到"先想再做"的 LLM 推理革命

开篇：从一道数学题的困境说起

想象你让一个大语言模型（LLM）去解一道数学应用题：「小明有 12 颗糖，给了小红 5 颗，又买了 3 颗，现在有多少颗？」

如果 LLM 上来就蹦答案，错误率往往很高。但如果你加上「Let's think step by step」（让我们逐步思考），LLM 会分步推理，答案准确率大幅提升——这就是 Chain-of-Thought（CoT，链式思考）提示技术的威力。

然而，CoT 也有自己的问题：LLM 生成的推理步骤可能不完整、计算出错、或者逻辑跳跃。2023 年 ACL 顶会上，一支来自上海交通大学、南京大学等机构的研究团队提出了一个更聪明的方案：Plan-and-Solve Prompting（先计划再执行提示）——不是边想边做，而是先规划再动手。

图1：Plan-and-Solve Prompting 效果对比。左侧为基础 CoT，右侧为 PS+ 提示策略。

背景：CoT 的局限与 Plan-and-Solve 的突破

Chain-of-Thought 在 2022 年被 Google 研究者提出后，迅速成为 LLM 推理领域的标配技术。但早期 CoT 有一个核心缺陷：LLM 生成的推理步骤质量完全取决于模型自身的能力，没有任何结构化引导。

Plan-and-Solve 的核心洞察是：让 LLM 先「理解问题并制定计划」，再「按计划执行」，比直接让它边推理边解答效果更好。具体来说，PS（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.」

而进化版 PS+ 提示词则更为精细：

「Let's first understand the problem, extract relevant variables and their corresponding numerals, and devise a plan. Then, let's carry out the plan, calculate intermediate variables (pay attention to correct numerical calculation and commonsense), solve the problem step by step, and show the answer.」

研究团队在 13 个数学推理数据集上做了系统评测，包括 GSM8K、SVAMP、MultiArith、AddSub、AQuA 等。实验结果令人信服：PS+ 在 GPT-4 之前的所有 GPT-3.5 系列模型上，平均比基础 CoT 提升 5~10 个百分点，部分数据集提升超过 15%。

图2：不同提示策略在多个数据集上的准确率对比。PS+（橙色）一致优于标准 CoT（蓝色）。

代码解读：如何用代码复现这项研究

本仓库提供了完整的可复现代码，用于 ACL 2023 论文的实验验证。

项目结构

Plan-and-Solve-Prompting/
├── main.py              # 主入口，单线程推理
├── main_threads.py      # 多线程推理（支持8路并发API调用加速）
├── prompt.py            # 提示词模板管理
├── config.py             # 命令行参数配置
├── extracter.py          # 答案提取器（从模型输出中解析最终答案）
├── prediction_runner.py  # 模型调用封装
├── utils.py              # 工具函数（数据加载、日志、文件操作）
├── apikeys.json          # API Key 配置（需用户自行填写）
├── requirements.txt      # 唯一依赖：openai
└── dataset/              # 13个评测数据集
    ├── gsm8k/
    ├── SVAMP/
    ├── AQuA/
    └── ...（共13个）

核心运行流程

Step 1：配置 API Key

# apikeys.json
["sk-your-key-1", "sk-your-key-2", ...]

Step 2：选择提示策略

提示词 ID 对应不同策略：

ID	类型	触发句
101	CoT	Let's think step by step.
201	PS	Let's first understand the problem and devise a plan...
301	PS+	Let's first understand the problem, extract relevant variables...

Step 3：运行评测

# 单线程
python main.py --prompt_id 201 --dataset SVAMP --engine text-davinci-003 --learning_type zero_shot

# 多线程（更快）
python main_threads.py --prompt_id 201 --dataset SVAMP --engine text-davinci-003 --learning_type zero_shot

关键技术点

答案提取（extracter.py）：模型输出通常是「推理过程 + 最终答案」的混合文本，extracter 模块负责用正则表达式精确提取答案部分，支持数值型、选项型等多种答案格式，并与标准答案比对计算准确率。

提示词工程（prompt.py）：支持 zero-shot（无示例）和 few-shot（带示例）两种模式。在 few-shot 模式下，会从 demo 数据集中选取样本，以「问题→推理→答案」的格式作为上下文示例喂给模型。

多引擎支持：支持 text-davinci-002、text-davinci-003、code-davinci-002 三种模型引擎。研究团队还支持 Self-Consistency（自洽性）策略：对同一问题用不同 temperature 生成多个答案，通过投票选出最终结果。

学术影响与行业落地

被 LangChain 纳入核心组件

最值得关注的里程碑是：Plan-and-Solve Prompting 已被正式纳入 LangChain 的核心库，以「Plan-and-Execute」 Agent 模式呈现。这意味着全球数十万 LangChain 用户现在可以直接在生产项目中使用这一提示技术。

LangChain 创始人 Harrison Chase 在 Twitter 上盛赞这一整合：「这是对 LLM 规划能力的重要增强。」

对提示工程领域的启示

Plan-and-Solve 的意义不仅在于具体效果提升，更在于它开创了一种新的提示范式：两阶段提示（先规划后执行）。这一思想后来影响了 ReAct（推理+行动）、Reflexion（反思+改进）等一系列更复杂的 Agent 架构。

局限性

然而，Plan-and-Solve 也有其时代局限：

1. 模型依赖：代码仅支持 GPT-3.5 系列模型（text-davinci-002/003, code-davinci-002），尚不支持 GPT-4 及更新模型。研究发表时 GPT-4 尚未发布。
2. API 调用成本：评测涉及大量 API 调用，13 个数据集、数千道题目，累计成本不容忽视。
3. 无本地模型支持：完全依赖 OpenAI API，不支持本地部署的 LLM（如 Llama、ChatGLM）。

总结

Plan-and-Solve Prompting 是 LLM 提示工程领域的一篇里程碑论文，它用「先计划再执行」的思想，系统性地提升了 GPT-3.5 系列模型的数学推理能力。代码仓库提供了完整可复现的实验框架，是研究提示工程、评测 LLM 推理能力的绝佳起点。

无论你是想复现这篇 ACL 论文的学术研究者，还是希望提升 LLM 应用准确率的开发者，这个仓库都值得深入研究。