"Let's think step by step" 哪里不够好
如果你用过 Chain-of-Thought，那你一定写过这句咒语：
Let's think step by step.
这句话是 Zero-Shot CoT 的全部精华。它确实有用——在数学、逻辑、多步推理任务上，加上这八个字母，准确率经常能从 17% 跳到 58%。但用久了你会发现，它有一个反复出现的致命弱点：AI 会"一步接一步"地走，但它不保证这一步步走的是对的路径。
先看一个真实场景。给模型一道稍复杂的数学题：
一个水池有 A、B 两个进水管和一个出水管 C。A 单独开 4 小时注满，B 单独开 6 小时注满，C 单独开 8 小时排空。三管同时开，几小时注满？
加上 Let's think step by step 之后，模型的输出大致是：
思考过程：
- A 的速度是 1/4 池/小时
- B 的速度是 1/6 池/小时
- C 是出水管，速度是 1/8 池/小时
- 三管同时开的净速度 = 1/4 + 1/6 - 1/8 = ...
- 取个公分母，算一下 = 6/24 + 4/24 - 3/24 = 7/24
- 所以 1 池需要 24/7 ≈ 3.43 小时
答案：约 3.43 小时
看起来很顺，结果也对。但同样的题，换个稍微复杂一点的版本，CoT 就容易翻车：
一个水池有 A、B 两个进水管，A 单独开 4 小时注满，B 单独开 6 小时注满。出水管 C 在水位达到半池时才会自动开启，C 单独开 8 小时排空一池水。三管同时开，几小时注满？
这道题的关键在于"水位达到半池时 C 才开启"——它不是单一速率的匀速过程，而是分两个阶段：第一阶段只有 A+B，第二阶段才加入 C。CoT 的"think step by step"会本能地把它当成一个连续过程，直接算 A+B-C 的净速度，得出一个错误但自信的答案。它不会主动停下来想一想"这里是不是该分段处理"。
看看 CoT 在这题上的典型错误输出：
思考过程：
- A 速率 1/4 池/小时，B 速率 1/6 池/小时
- C 速率 1/8 池/小时（出水）
- 净速率 = 1/4 + 1/6 - 1/8 = 7/24 池/小时
- 注满时间 = 24/7 ≈ 3.43 小时
答案：约 3.43 小时
和第一题的答案一模一样——但题目里"C 半池才开"这个关键条件被完全无视了。模型不是不会算分段，而是它在第一步"算速率"时就把全部注意力放在了三个速率上，那个触发条件没被主动处理，等推理推进到后面就更想不起来回头查了。
再看一个非数学的例子，多步骤任务遗漏步骤的情况。让模型写一个"用户注册后发欢迎邮件"的完整流程：
用一句话提示：请一步步写出用户注册后发送欢迎邮件的完整后端流程，让我们逐步思考。
CoT 的输出大致是：
- 用户提交注册表单
- 后端校验表单数据
- 把用户写入数据库
- 调用邮件服务发欢迎邮件
- 返回成功
看起来完整，但仔细想会发现几个被跳过的步骤：
- 校验"邮箱是否已存在"（不能光校验格式，还要查重——否则同邮箱能注册多次）
- 写数据库前要"密码加盐哈希"（明文存是安全事故，但 CoT 在"写入数据库"那步不会主动想到要先哈希）
- 发邮件是异步的，要考虑"邮件服务挂了怎么办"（重试/队列/降级——但 CoT 在"调用邮件服务"那步默认它一定能调通）
- 注册成功后要"生成会话/token"让用户直接登录（不是存完就结束——但 CoT 在"返回成功"那步不会想到该顺手发个 token）
- 写入数据库和发邮件之间有"事务/一致性"问题（DB 写成功但邮件发失败，要不要回滚？要不要先写 DB 再异步发邮件？）
- 安全相关：限流防爆破注册、敏感字段日志脱敏（但 CoT 不会主动列安全横切关注点）
这些步骤不是模型不会，而是它在"一步步往下写"时，注意力被当前那步占满，没想到要主动把"异常处理""一致性""安全"这些横切关注点列出来。等推理走到"发邮件"那一步，它已经在想邮件内容了，不会再回头补"那 DB 和邮件之间的一致性呢"。CoT 是顺着主线往下走，横切关注点天然会被漏——因为它们不属于任何单一步，而是贯穿全程的约束，需要先有一个全局计划把它们显式列出来才会被处理。这恰恰是 P&S 计划阶段的价值：先扫描"这个流程有哪些横切关注点"，再把它们分配到对应步骤里。
这就是 CoT 的三个典型失败模式：
- 跳步：把本该分段的过程当成连续过程，直接套单一公式（水池题）
- 遗漏关键步骤：题目里有条件或流程里有环节，但模型生成时注意力被主线占据，把它丢了（注册流程题）
- 计算出错：推理方向对了，但中间某一步的算术错了一个符号，后面全错
这三个问题有一个共同根源：CoT 是"边想边写"，模型在生成第一步时，并不知道第二步、第三步会遇到什么。它没有全局规划，只是局部地"下一步该说什么"。这就像一个人蒙着眼睛走迷宫——每一步都看似合理，但整体路径可能从一开始就走偏了。CoT 的"think step by step"只在每一步局部合理，不保证全局最优。
Plan-and-Solve（Wang et al., 2023, ACL）就是冲着这个弱点来的。它的核心思路简单到有点朴素：
先让模型制定一个分步计划，再让模型按这个计划逐步执行。
听起来像是把"think step by step"拆成了两句话——但就这么一个改动，在 GSM8K 数学基准上把 Zero-Shot CoT 的准确率提升了 7-10 个百分点。这不是魔法，而是把"盲走迷宫"改成了"先看一眼地图再走"。本文会讲清 P&S 为什么有效、三种主流改进变体、和 CoT/ToT/ReAct 的边界，最后给一个完整可复用的模板和三个实战场景。
Plan-and-Solve 的核心思想
一句话定义
Plan-and-Solve = 让 AI 先制定分步计划，再按计划逐步执行。两阶段：计划阶段 → 执行阶段。
它的本质是把"想清楚要做什么"和"动手做"这两件事拆开。CoT 把这两件事揉在一起——模型每生成一步，既是在"想下一步做什么"，又是在"做这一步"。P&S 强制先有一份独立的计划，把"全局路径"先定下来，再进入"逐步执行"。
这个拆分看似微小，但它对应了人类专家解决问题的方式。一个有经验的工程师接到需求不会立刻开始写代码，而是先在白板上画架构图、列任务清单、标依赖关系——这份"先想清楚再动手"的纪律性，正是 CoT 缺失的。P&S 把这份纪律性强制塞进 Prompt。
两阶段架构图解
一个完整的 Plan-and-Solve 流程，逻辑上是两个串行阶段：
┌─────────────────────────────────────────────────────────────┐
│ 阶段 1：计划阶段（Plan） │
│ --------------------------------------------------------- │
│ 输入：任务描述 + 已知约束 │
│ 输出：一份分步计划（3-7 个子步骤） │
│ 每步包含：要做什么 / 需要什么输入 / 产出什么 / 依赖哪一步 │
│ 心态：先想清楚整条路径，不要动手算 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 2：执行阶段（Solve） │
│ --------------------------------------------------------- │
│ 输入：第一阶段产出的计划 │
│ 动作：逐步执行计划，每步输出该步结果 │
│ 约束：按计划顺序走，不跳步；如发现计划有误可标注 │
│ 心态：我有了地图，照着走，每一步只关注当前这一步 │
└─────────────────────────────────────────────────────────────┘
│
▼
最终答案
两阶段各司其职，关键在于职责分离：
| 阶段 | 关注点 | 不做什么 | 输出 |
|---|---|---|---|
| 计划阶段 | 全局结构、步骤拆解、依赖关系 | 不动手算具体数值、不写最终答案 | 分步计划 |
| 执行阶段 | 单步正确性、按计划走 | 不重新规划全局路径、不擅自跳步 | 每步结果 + 最终答案 |
这个"不做什么"列很重要。计划阶段的纪律是"只拆解不算"——很多模型在计划阶段忍不住就开始算数值，结果计划阶段退化成了一份带数字的草稿，失去了"先看全局"的意义。执行阶段的纪律是"只做不重新规划"——一旦开始执行，就照着既定计划走，发现某步有问题可以标注，但不要推翻整个计划重来（那是回溯修正型的事）。两个阶段各自专注一件事，互不越界。
P&S 论文给出的最朴素的 Prompt 就是这两句话的拼接：
Let's first understand the problem and devise a complete plan.
Then, let's carry out the plan to solve the problem.
翻译过来就是："先理解问题并制定完整计划，然后执行计划求解。"——本质就是把 Let's think step by step 升级成 Let's first plan, then solve。改进极小，但效果显著。论文还发现一个细节：单纯说"devise a plan"不够，加上"understand the problem"效果更好——因为这强制模型在计划前先做一次"题目里有哪些已知条件和约束"的扫描，正是这一步把隐藏条件逼出来的关键。
为什么"先计划"能提升准确率
直觉上你会怀疑：模型在计划阶段就能想对路径，为什么在执行阶段反而更准？难道计划阶段不是同一次推理吗？这里有三层原因，每一层都对应一种典型错误。
第一层：计划阶段强制做"全局扫描"，逼出题目里的隐藏约束。
CoT 的问题不在模型"不会算"，而在它"没注意到该分段"。前面的水池题，C 管"半池才开"这个条件，在 CoT 模式下很容易被淹没——因为模型在第一步就把注意力放在"算 A、B、C 的速率"上了，这个条件没被主动处理。而 P&S 在计划阶段会先问"这个任务需要几步、每步要做什么"，这时候模型更容易停下来识别"哦，这里有个条件触发的分段，应该拆成两阶段算"。计划阶段本质是把"题目里有哪些约束"这件事显式化了一遍。
这层原因主要降低的是"跳步"错误。计划阶段的"先扫描全部条件再拆步骤"这一动作，等于给题目做了一次体检，把 CoT 模式下会被漏掉的条件（C 半池才开、注册流程里的查重/哈希/事务）提前揪出来。
第二层：分步降低了单次生成的认知负荷。
CoT 是一条连贯的推理链，模型在写第 5 步时，既要记得第 1-4 步的中间结果，又要算当前这步，还要预判第 6 步。注意力被摊薄。P&S 把全局路径固化成计划后，执行阶段每一步只需要关注"当前这步按计划该做什么"——前面有什么中间结果、后面要走什么路径，都已经在计划里写定了，不用边写边记。每一步的认知负荷更低，单步出错率下降。
这层原因主要降低的是"计算出错"。当模型不用同时操心"全局路径"和"当前计算"时，它能把更多注意力放在当前这一步的算术上，符号算反、单位搞错这类低级错误明显减少。这就像人做长除法时，先把竖式骨架搭好再逐位算，比一边想"接下来该怎么除"一边算更不容易算错。
举个具体对照。算一道五步的工程应用题"先求速度、再求时间、再求距离、再换算单位、最后求和"，CoT 模式下模型在第 4 步换算单位时，常常会忘了第 1 步用的是 km/h 还是 m/s，导致单位错配——因为它在写第 4 步时，脑子里还压着"第 5 步要求和"的预判，注意力被摊薄。P&S 模式下，计划已经把"第 1 步用 km/h、第 4 步要换算成 m"写定了，执行第 4 步时模型不用回忆第 1 步的单位，直接看计划就知道要换算，单位错配的概率显著下降。
第三层：计划本身是一份"可对照的 checklist"，使偏差可被发现。
CoT 没有计划，所以"走偏了"无从对照——模型写到哪里算哪里，错了也意识不到。P&S 有计划，执行阶段每完成一步都可以对照"这一步是否与计划一致"。一旦某步结果与预期不符，模型（或人）能立即定位"是计划错了，还是执行错了"。这份可对照性是 CoT 完全没有的，也是后续改进变体（自验证、分步自检、回溯修正）的基础——没有计划做对照，"自检"就无从检起。
具体来说，CoT 出错时你拿到一份"看起来流畅但结果错了"的推理链，要 debug 只能从头逐句读，往往读到一半才猜出哪步错。P&S 出错时你拿到的是"计划 + 执行"两份对照——先看计划对不对（结构层），再看执行和计划哪里不一致（执行层），定位错误的成本是 O(看计划) 而非 O(读整条链)。这份"可定位性"在多步代码生成里尤其值钱：一份代码 bug，对着计划能快速看出是"计划漏了某步"还是"某步执行和计划不符"，不用通读全部代码。
这层原因直接催生了后文的三个改进变体。因为有了计划，验证才有了对照物；因为有了对照物，错误才能被定位；因为错误能被定位，才能谈"就地修正"或"回溯重做"。P&S 的三个变体全部建立在"计划提供可对照性"这个地基上。
论文实测数据（GSM8K 数学推理，GPT-3.5 级别模型，近似值）：
| 提示方式 | GSM8K 准确率 | 相对 Zero-Shot CoT 提升 |
|---|---|---|
| 直接问（无 CoT） | ~17% | 基线 |
Zero-Shot CoT（think step by step） | ~17-21% | +0-4% |
| Plan-and-Solve（原始版） | ~26-28% | +7-10% |
| Plan-and-Solve + 自验证（PS+） | ~28-30% | +9-12% |
注意几个关键规律：
- P&S 对"需要分阶段的复杂题"提升最大（如水池条件触发、多步应用题），对"一步就能算的简单题"提升很小——简单题本来就没什么可计划的，计划阶段反而是 overhead，甚至可能因为计划阶段"想多了"引入不必要的复杂化。
- P&S 的收益主要体现在"少跳步、少遗漏条件"，而不是"算得更准"——它降低的是结构性错误，不是计算错误。这就是为什么它的改进变体大多围绕"验证"做文章——计划解决了结构问题，剩下的是计算问题，靠验证兜底。
- P&S 是 Zero-Shot 的——不需要给示例，只需要改提示语。这是它相对 Few-Shot CoT 的最大优势：成本几乎为零，且无需为每个任务构造示例。
一个最小对照：CoT vs P&S 在同一道题上的输出差异
拿前面的复杂水池题（C 管"半池才开"）做对照，能直观看到 P&S 的价值。
CoT 版输出（典型错误样例）：
A 速率 1/4，B 速率 1/6，C 速率 1/8。
净速率 = 1/4 + 1/6 - 1/8 = 6/24 + 4/24 - 3/24 = 7/24。
注满一池时间 = 24/7 ≈ 3.43 小时。
答案：约 3.43 小时。
错在哪？直接当成连续过程套了净速率公式，把"C 半池才开"这个条件扔了。错误根源是跳步——没识别出题目需要分段处理。
P&S 版输出（计划阶段先识别分段）：
=== 计划 ===
1. 算 A、B 的速率（1/4、1/6 池/小时）
2. 识别 C 的触发条件：水位到半池时才开，因此要分两阶段
3. 第一阶段：只有 A+B，算注满半池的时间 t1
- A+B 合速率 = 1/4 + 1/6 = 5/12 池/小时
- 注半池：t1 = (1/2) / (5/12) = 6/5 = 1.2 小时
4. 第二阶段：A+B-C，算从半池注到满池的时间 t2
- 净速率 = 1/4 + 1/6 - 1/8 = 7/24 池/小时
- 再注半池：t2 = (1/2) / (7/24) = 12/7 ≈ 1.71 小时
5. 总时间 = t1 + t2 = 1.2 + 1.71 = 2.91 小时
=== 执行 ===
（按计划逐步算出上面每一步的数值）
=== 验证 ===
分两段处理，半池触发条件已纳入。最终约 2.91 小时。
关键区别不是"算得更准"，而是计划阶段就识别出"这里要分段"——这是 CoT 在边走边写时最容易漏掉的东西。CoT 在第一步把注意力放在"算三个速率"上，触发条件被淹没；P&S 在计划阶段先做全局扫描，触发条件被显式拆成两个阶段。这就是 P&S 的核心价值：用一份计划，把题目的隐藏结构逼出来。
三种改进变体
原始 P&S 只有两阶段：计划 + 执行。但执行阶段可能算错，计划也可能有缺陷。围绕"如何发现并修正这些错误"，衍生出三种主流改进变体。它们的核心区别在验证的时机和粒度：
| 变体 | 验证时机 | 验证粒度 | 出错时能否回退 | 适用任务 |
|---|---|---|---|---|
| 原始 P&S | 无（或末尾一次性） | 无 | 否 | 结构清晰的常规题 |
| 自验证型（PS+） | 全部执行完后 | 整体结果 | 否 | 单一答案的推理题 |
| 分步自检型 | 每步执行后立即 | 单步结果 | 否（但可标注） | 多中间值的长链推理 |
| 回溯修正型 | 每步执行后立即 | 单步 + 路径 | 是（可回到上一步） | 解空间大、易走错的题 |
从上往下，验证越来越密、容错越来越强，但 token 消耗也越来越高。选型不是"越往下越好"，而是按任务的"错得起程度"匹配——简单题用自验证就够了，乱上回溯修正型既慢又贵。下面逐个讲清每种变体的机制、完整 Prompt 示例和适用场景。
变体一：自验证型（Plan-Solve-Verify）
机制：在原始两阶段后追加一个"验证阶段"——让模型把最终答案代回原题，检查是否自洽。这是 P&S 论文里效果最好的版本（即 PS+），也是最便宜的改进：只多加一句话。
核心思路：执行完之后，不要直接输出答案，而是回头问自己"这个答案满足题目所有条件吗？"。这是把"做完不检查"改成"做完回头验"，对应人类做数学题的"代入验算"习惯。
完整 Prompt 示例：
请按以下步骤解决这个任务。
任务：{{task}}
## 执行流程
### 第一步：制定计划
先制定分步计划：3-7 个子步骤，每步说明做什么、产出什么、依赖哪一步。
### 第二步：按计划执行
逐步执行计划，每步输出结果。
### 第三步：自验证
把最终答案代回原题，逐条检查：
1. 是否满足题目里所有显式约束（数字、条件）
2. 是否处理了所有隐含约束（如"整数解""非负"等）
3. 把答案反向代入，看是否成立
如发现矛盾，指出哪一步出错，重新执行该步。
## 输出格式
用 "=== 计划 ===" / "=== 执行 ===" / "=== 验证 ===" 分隔输出。
适用场景：答案可以反向验证的封闭型任务——数学题、逻辑谜题、有唯一解的推理题。这类任务的"对错"是客观的，模型把答案代回去就能验出对错，自验证成本极低、收益极高。典型如"鸡兔同笼"（验脚数对不对）、"行程问题"（验位置对不对）、"方程求解"（验代入等式成立不成立）。
实测效果：在 GSM8K 上，自验证型比原始 P&S 再提升 2-3 个百分点，而 token 消耗只增加约 15%（验证阶段通常很短，就是代回去算一遍）。这是性价比最高的改进。
为什么有效：执行阶段算错一个符号，整条推理链看起来仍然"流畅"——模型生成时不会停下来检查"我刚才那步对吗"，因为生成机制是单向的。验证阶段强制它停下来，把答案代回去，如果代不回去（如算出"鸡 13.5 只"），错误立刻暴露。这层"反向回路"是单向 CoT 和原始 P&S 都没有的。
局限：自验证只能验"答案代回是否成立"，不能验"推理过程是否最优"。对开放型任务（文案、方案）无效——开放题没有"代回验"的标准，一个 Slogan 写得好不好没法代回原条件验。
变体二：分步自检型（Step-wise Self-Check）
机制：不是等全部执行完再验证，而是每执行完一步，立即检查这一步：这步的计算对吗？这步的产出符合计划预期吗？发现不对就标注，但不回退（继续按修正后的路径走，或在后续步骤里补偿）。
核心思路：把验证下沉到每一步，而不是堆到最后。这样错误不会沿推理链累积——一步错了立刻被发现，不会污染后面五步。这对应人类做长流程任务时"每做完一步就回头瞄一眼"的习惯，而不是"全做完再统一检查"。
完整 Prompt 示例：
请按以下步骤解决这个任务。
任务：{{task}}
## 执行流程
### 第一步：制定计划
制定 3-7 个子步骤的分步计划，标注依赖关系。
### 第二步：逐步执行 + 分步自检
对计划中的每一个步骤，按以下结构输出：
【步骤 N】
- 计划内容：复制计划里这一步要做什么
- 执行：实际执行，给出这一步的结果
- 自检：
· 这步的计算/推理是否正确？重新核对一次
· 这步产出是否符合计划预期？如不符，说明偏差
· 是否影响后续步骤？如影响，说明如何调整后续计划
完成所有步骤后进入第三步。
### 第三步：总结
汇总各步结果，给出最终答案。
## 输出格式
用 "=== 计划 ===" / "=== 执行 ===" / "=== 验证 ===" 分隔。
执行阶段每个步骤用【步骤 N】标注。
适用场景：长推理链任务——多步应用题、多步代码生成、多步数据推导。这类任务的痛点是"中间某步算错，后面全错"，分步自检能在错误刚发生时就抓住，避免链式累积。典型如 5 步以上的应用题、多函数协作的代码、多阶段的数据推导。
实测效果：在 5 步以上的长链推理上，分步自检型比自验证型再提升 3-5 个百分点，token 消耗增加约 30-40%（每步多一次核对）。对 3 步以内的短任务收益不明显——短链本来就不容易累积错，自验证型就够了，分步自检反而啰嗦。
为什么有效：自验证型是"全做完再代回验"，问题是——如果第 2 步错了，第 3-7 步都建立在错误基础上，等验证阶段发现"代不回去"时，已经不知道是哪步错了，只能整条重来。分步自检把验证时机前移到每步之后，错误刚发生就被定位，修正成本极低（只重做一步，不是整条链）。这本质是用"早发现"换"低成本修正"。
局限：每步自检会让输出变长、变慢。对短任务过载；对"这步本身就需要外部信息才能验"的任务（如调 API、查数据库）无效——模型自己验不了，得靠工具返回。这种场景应该用 ReAct，把工具返回的 Observation 作为每步的验证依据。
变体三：回溯修正型（Backtracking）
机制：在分步自检基础上更进一步——发现某步出错时，允许回退到出错那一步重新做，而不是只在后续步骤里补偿。这把 P&S 从"线性执行"升级为"带栈的执行"——可以 push/pop。
核心思路：有些错误没法靠"后续补偿"修——比如计划方向就错了，后面所有步骤都建立在错误前提上，必须回退到出错的根节点重做。回溯修正型允许模型显式说"回退到第 K 步"，并从那里重启。这对应人类解题时"啊这条路不通，回到岔路口换条路"的回溯思维。
完整 Prompt 示例：
请按以下步骤解决这个任务。
任务：{{task}}
## 执行流程
### 第一步：制定计划
制定 3-7 个子步骤的分步计划，标注依赖关系，并预估每步可能的失败模式。
### 第二步：逐步执行 + 分步自检 + 回溯
对每个步骤按以下结构输出：
【步骤 N】
- 执行：给出这一步的结果
- 自检：这步是否正确？是否符合计划预期？
- 决策：
· 若正确 → 继续下一步
· 若错误且可就地修正 → 修正后继续
· 若错误源于更早的步骤（计划或前提有误）→ 显式声明"回溯到第 K 步"，从第 K 步重新执行，并在重新执行时说明为何原路径不通
允许最多 3 次回溯。超过 3 次则停下，输出当前最优结果并标注"未收敛"。
### 第三步：总结
汇总最终路径，给出最终答案，并标注走过的完整路径（含回溯点）。
## 输出格式
用 "=== 计划 ===" / "=== 执行 ===" / "=== 验证 ===" 分隔。
回溯时用 "↩ 回溯到第 K 步：原因" 标注。
适用场景：解空间大、容易走错的探索型任务——组合优化（行程规划、排班）、博弈决策、技术方案选型。这类任务的共同点是"前一步选错方向，后面所有努力都白费"，必须靠回溯重来。典型如"排班同时满足最少人手和无人连续 7 天"（约束互相冲突，试一条路容易碰壁）、"技术选型在性能/成本/团队能力间权衡"（选错栈后面重构代价大）。
实测效果：在这类探索型任务上，回溯修正型比分步自检型提升明显（准确率/满意度再提 5-8%）；但在封闭型数学题上提升很小——数学题算错通常是个别计算错误，就地修正即可，不需要整路径回溯，回溯反而拖慢。
为什么需要回溯：分步自检型发现错误后只能"标注 + 后续补偿"，但有些错误是结构性的——计划本身的前提就错了，后续所有步骤都建立在错的前提上，补偿无从补起。比如规划任务里"第 3 步选了三线齐开"，自检发现超载，但这是计划阶段的决策错了，不是执行错，光在第 4、5 步补偿没用，必须回退到第 3 步重新决策。回溯就是处理这种"根节点错误"的机制。
局限：token 消耗最高（可能 2-3 倍于原始 P&S），且需要设回溯次数上限（通常 3 次），否则模型可能陷入"回溯-再错-再回溯"的死循环。本质上是把 P&S 往 Tree of Thoughts 方向推了一步，但仍是单向主线 + 有限回溯，不是真正的多路并行搜索——真正要并行试多条路，还是得上 ToT。
三种变体的选择决策
你的任务有唯一正确答案吗？
├── 是（数学/逻辑）
│ 推理链有多长？
│ ├── 短（≤3 步） → 自验证型（PS+）
│ └── 长（≥4 步） → 分步自检型
└── 否（方案/选型/规划）
一步选错会全盘皆输吗？
├── 否 → 分步自检型
└── 是 → 回溯修正型
一句话：答案可反向验证用自验证，推理链长用分步自检，路径易错且错得起用回溯。选型的本质是"任务错得起的程度"——越错不起（封闭题、唯一解），验证越要兜底在最后（自验证）；越错得起（探索型），验证越要前置（分步自检）+ 容许重来（回溯）。
三种变体在同一道题上的执行对比
光讲机制容易抽象，下面用同一道题分别跑三种变体，直观看到它们的输出差异。题目就用前面的复杂水池题（C 管"半池才开"）：
A 单独开 4 小时注满，B 单独开 6 小时注满。C 在水位达到半池时才开启，C 单独开 8 小时排空一池水。三管同时开，几小时注满？
正确答案是分两段算：第一阶段（0→半池）只有 A+B，第二阶段（半池→满）才有 A+B-C，约 2.91 小时。为了展示三种变体的差异，我们让模型在执行中犯错——前两种变体（自验证、分步自检）犯的是算术层错误：第二阶段净速率本应是 1/4 + 1/6 - 1/8（C 是出水管要减），模型却漏减了 C，写成 1/4 + 1/6 + 1/8（把出水当进水）。第三种变体（回溯修正）犯的是结构层错误：计划本身漏了"分两段"，把题目当成连续过程——这种错误只有回溯修正型能修。看三种变体分别怎么处理。
变体一（自验证型）的执行：
=== 计划 ===
1. 算 A、B 速率
2. 识别 C 半池才开 → 分两段
3. 第一阶段：A+B 算到半池
4. 第二阶段：A+B-C 算到满池
5. 总时间相加
=== 执行 ===
【按计划逐步算】
... 第二阶段净速率写成 1/4 + 1/6 + 1/8 = 13/24（错误：漏减 C）
... t2 = (1/2) / (13/24) = 12/13 ≈ 0.92 h
... 总时间 = 1.2 + 0.92 = 2.12 小时
=== 验证 ===
代回：第二阶段净速率应为 A+B-C（C 是出水管，要减）。
我算成了 A+B+C，符号错了。
重新执行第 4 步：净速率 = 1/4 + 1/6 - 1/8 = 7/24
t2 = (1/2) / (7/24) = 12/7 ≈ 1.71 h
总时间 = 1.2 + 1.71 = 2.91 小时 ✓
答案：约 2.91 小时。
自验证型的特点：错误一直流到验证阶段才被发现。中间第 4 步算错时，模型自己没意识到（因为生成是单向的，算完就往下走），直到验证阶段"把答案代回原题"才看出"等等，C 是出水管，我第二阶段怎么加上了"。然后回退重算第 4 步。代价是：中间的 0.92 h、2.12 h 这些中间结果都白算了，验证阶段才推翻重来。但好处是结构最简单，token 最省。
变体二（分步自检型）的执行：
=== 计划 ===
[同上，5 步]
=== 执行 ===
【步骤 4】第二阶段：A+B-C 算到满池
- 计划：净速率 = A+B-C
- 执行：净速率 = 1/4 + 1/6 + 1/8 = 13/24
- 自检：
· 这步推理正确吗？⚠️ 不正确。C 是出水管，速率应为减号，我写成了加号。
· 产出符合计划预期吗？不符，计划写的是 A+B-C，我执行成了 A+B+C。
· 影响后续吗？影响 t2 计算。就地修正：净速率 = 1/4 + 1/6 - 1/8 = 7/24。
t2 = (1/2) / (7/24) = 12/7 ≈ 1.71 h
- 修正后继续第 5 步
【步骤 5】总时间 = 1.2 + 1.71 = 2.91 h
=== 验证 ===
代回自洽 ✓
答案：约 2.91 小时。
分步自检型的特点：错误刚发生就被抓住。第 4 步算完，自检环节立刻对照"计划写的是 A+B-C，我执行成了 A+B+C"，发现符号错了，就地修正，不需要等验证阶段。代价是：每步多写一次自检（token +30-40%），且执行阶段输出更长。好处是：错误不累积，修正成本极低（只重做当前这一步的算术，不重做整条链）。
变体三（回溯修正型）的执行（假设这次错误更结构化——计划本身漏了"分两段"）：
=== 计划 ===
1. 算 A、B、C 速率
2. 净速率 = A+B-C
3. 注满时间 = 1 / 净速率
（⚠️ 计划漏了"C 半池才开"这个分段条件，当成连续过程）
=== 执行 ===
【步骤 2】净速率 = 1/4 + 1/6 - 1/8 = 7/24
- 自检：计算正确。但...等等，计划没处理"C 半池才开"。
- 决策：错误源于步骤 1 的计划——计划把题目当成连续过程，漏了分段。
↩ 回溯到第 1 步：原因——计划未识别 C 的触发条件，需重新规划。
【步骤 1'】重新规划
- 识别 C 半池才开 → 分两段
- 第一阶段：A+B 到半池
- 第二阶段：A+B-C 到满池
【步骤 2'】第一阶段：A+B = 5/12，注半池 t1 = (1/2)/(5/12) = 1.2 h
- 自检：正确
【步骤 3'】第二阶段：A+B-C = 7/24，注半池 t2 = (1/2)/(7/24) = 1.71 h
- 自检：正确
【步骤 4'】总时间 = 1.2 + 1.71 = 2.91 h
=== 验证 ===
路径：1→2→(回溯)→1'→2'→3'→4'
答案：约 2.91 小时。
回溯修正型的特点：能修结构性错误。这次错误不是某步算术错了，而是计划本身漏了分段——光靠分步自检的"就地修正"救不回来（因为整个计划前提都错了）。回溯修正型允许回退到计划阶段（第 1 步）重新规划，把"分两段"补进来。代价是 token 最贵（重做了整个计划和执行），且需要回溯次数上限防死循环。好处是：能处理"前提错"这种分步自检救不了的错误。
三种变体的关键差异一览：
| 维度 | 自验证型 | 分步自检型 | 回溯修正型 |
|---|---|---|---|
| 错误发现时机 | 全部做完后 | 每步做完后 | 每步做完后 |
| 能修算术错误 | ✅（代回发现） | ✅（自检发现） | ✅ |
| 能修结构/计划错误 | ❌（只验答案） | ❌（只检单步） | ✅（回退到计划） |
| 修正成本 | 高（可能整链重来） | 低（只重做一步） | 中-高（重做一段路径） |
| Token 消耗 | 1.5× | 1.3-1.4× | 2-3× |
| 输出长度 | 中 | 长 | 最长 |
这个对比道出一个关键认知：三种变体不是"越往后越强"，而是分工不同。自验证型抓"答案代回成不成立"，分步自检型抓"单步执行对不对"，回溯修正型抓"计划前提对不对"。它们抓的是不同层次的错误——算术层、执行层、结构层。一道题如果三个层次都可能错，理论上可以叠加使用（先回溯修正型保计划对，再分步自检保执行对，最后自验证保算术对），但实际中按任务特征选一种就够，叠加会过载。
与传统 CoT / ToT / ReAct 对比
P&S 经常和 CoT、ToT、ReAct 放在一起讨论，但它们的定位差异很大。先把核心差异讲清楚，避免选型时搞混。
核心机制对比
| 维度 | Zero-Shot CoT | Plan-and-Solve | Tree of Thoughts | ReAct |
|---|---|---|---|---|
| 推理结构 | 单链，线性 | 单链，但先计划 | 多路树形，可回溯 | 循环（思考→行动→观察） |
| 是否有计划阶段 | 否（边想边写） | 是（显式计划） | 否（边搜边评） | 否（边想边做） |
| 是否需要示例 | 否 | 否 | 否 | 否 |
| 自我评估 | 无 | 可选（验证阶段） | 有（每节点打分） | 有（基于 Observation） |
| 回溯能力 | 无 | 仅变体三 | 有（核心特性） | 有（基于 Observation 调整） |
| 工具调用 | 无 | 无 | 无 | 有（核心特性） |
| Token 消耗 | 1× | 1.3-1.5× | 3-5× | 2-4× |
| 实现复杂度 | 极低（一句话） | 低（两阶段） | 高（需搜索框架） | 中-高（需工具接入） |
这张表的关键解读：
- P&S 是四者里实现成本最低的"结构化推理"：它只比 CoT 多一个计划阶段，不需要 ToT 的搜索框架，也不需要 ReAct 的工具接入。改一句话就能用。
- P&S 和 CoT 都是"纯推理"，不调工具、不展开多路。区别只在有没有计划阶段。所以 P&S 是 CoT 的"近亲升级"，而不是 ToT/ReAct 那种范式跃迁。
- ToT 和 ReAct 各自解决一个 CoT/P&S 都解决不了的问题：ToT 解决"需要同时试多条路"，ReAct 解决"需要调外部工具"。P&S 在这两方面都不行——它仍是单链、仍不调工具。
准确率对比（GSM8K 数学推理，近似值）
| 方法 | GSM8K 准确率 | 相对直接提问提升 | 成本 |
|---|---|---|---|
| 直接提问（无 CoT） | ~17% | 基线 | 1× |
| Zero-Shot CoT | ~17-21% | +0-4% | 1× |
| Plan-and-Solve | ~26-28% | +9-11% | 1.3× |
| Plan-and-Solve + 自验证 | ~28-30% | +11-13% | 1.5× |
| Few-Shot CoT | ~30-35% | +13-18% | 1×（但需示例） |
| Self-Consistency（5 采样） | ~30-33% | +13-16% | 5× |
| Tree of Thoughts | ~28-32% | +11-15% | 3-5× |
关键解读：
- P&S 是性价比最高的改进之一：在 Zero-Shot（零示例、单次调用）的前提下，把 CoT 的准确率几乎翻倍。Few-Shot CoT 和 Self-Consistency 准确率更高，但前者需要构造示例、后者需要 5 倍 token——P&S 啥都不要，只改一句话。
- P&S 不是天花板。在你能给示例、能多采样、能接工具的场景里，Few-Shot CoT、Self-Consistency、ReAct 的上限更高。P&S 的定位是"零成本下限"——当你什么额外资源都不想花时，它给你最大收益。
- 注意 ToT 在 GSM8K 上并不比 P&S 高多少。原因是 GSM8K 大部分题是线性推理，不需要多路搜索——ToT 的多路优势在组合优化/博弈类任务上才显现，数学题用 ToT 是杀鸡用牛刀。
适用场景对比
| 任务类型 | CoT | P&S | ToT | ReAct |
|---|---|---|---|---|
| 数学/逻辑推理 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 多步应用题（需分阶段） | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 创意发散/命名 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 博弈/组合优化 | ⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 多步代码生成 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 需要查数据/调 API | ⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 项目规划/方案 | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 简单事实问答 | ⭐ | ⭐ | ⭐ | ⭐⭐⭐ |
选型决策树：
你的任务特征是什么？
├── 需要调外部工具/API → ReAct
├── 创意发散/博弈/组合优化 → ToT
├── 数学/逻辑/多步推理（零成本）
│ 题目是否需要分阶段处理？
│ ├── 是 → P&S（变体一/二）
│ └── 否 → CoT 即可，P&S 收益小
└── 多步骤生成（代码/方案）
是否需要先规划再执行？
├── 是 → P&S
└── 否 → 直接 Few-Shot
一句话总结四者定位：CoT 是"边想边说"，P&S 是"先想清楚路径再说"，ToT 是"同时想几条路再选最优"，ReAct 是"想了就做、做了再想"。它们解决的问题层次不同，不冲突，可叠加（如 P&S + 自验证、ToT + ReAct）。
完整可复用的 P&S Prompt 模板
把前面所有经验抽象成一个通用模板。模板默认采用"分步自检型"（性价比最高的稳健版本），可通过参数切换到自验证或回溯模式。
请按以下步骤解决这个任务。
## 任务
{{task}}
## 执行流程
### 第一步：制定计划
请先制定一个详细的分步计划来解决这个任务。计划应该：
1. 将任务分解为 3-7 个可执行的子步骤
2. 每个子步骤说明：要做什么 / 需要什么输入 / 产出什么
3. 标注步骤之间的依赖关系（哪一步依赖哪一步的产出）
4. 识别可能的难点和应对策略
5. 预估每步可能的失败模式（可选，用于回溯模式）
### 第二步：按计划执行 + 分步自检
对计划中的每一个步骤，按以下结构输出：
【步骤 N】
- 计划：复制计划里这一步的内容
- 执行：实际执行，给出这一步的结果
- 自检：
· 这一步的计算/推理是否正确？核对一次
· 产出是否符合计划预期？如不符，说明偏差原因
· 是否影响后续步骤？如影响，说明如何调整
{{verify_mode}}
### 第三步：验证和总结
执行完所有步骤后：
1. 把最终结果代回原任务，检查是否满足所有要求
2. 回顾是否有遗漏的步骤或未处理的约束
3. 输出最终答案，并标注完整执行路径
## 输出格式
用 "=== 计划 ===" / "=== 执行 ===" / "=== 验证 ===" 三个标记分隔各阶段输出。
执行阶段每个步骤用【步骤 N】标注。
其中 {{verify_mode}} 是可切换的验证模式，按任务类型填入：
| 任务类型 | {{verify_mode}} 填入 | 对应变体 |
|---|---|---|
| 封闭型推理题（数学/逻辑） | 若某步自检发现错误，标注并重新执行该步。执行完成后把最终答案代回原题验证。 | 自验证型 |
| 长链推理/多步代码 | 默认（分步自检，不回退） | 分步自检型 |
| 探索型/易走错路径 | 若某步错误源于更早步骤，显式声明"回溯到第 K 步"并重新执行，最多回溯 3 次。 | 回溯修正型 |
模板使用建议：
| 字段 | 必填 | 说明 |
|---|---|---|
task | 是 | 任务描述，含所有已知条件和约束 |
verify_mode | 否 | 默认分步自检；按上表切换 |
如何扩展：可在模板末尾追加 ## 领域约束 区块，写明任务的红线（如"结果必须为整数""不许引入新依赖""方案预算不超过 X"），计划阶段会把这些约束纳入步骤拆解，自检阶段会把它当 checklist。这是把业务硬约束内化进 P&S 的关键手段——不写领域约束，P&S 只能保证"结构对"，加进去才能保证"满足业务红线"。
模板设计要点：
- 计划阶段强制"做什么/输入/产出/依赖"四要素——这逼计划从"大纲"变"可执行 checklist"
- 执行阶段强制"复制计划内容 + 自检三项"——这保证执行不偏离计划，且偏差可被发现
- 验证阶段强制"代回原题"——这是抓计算错误的最后闸门
- 三个
===分隔标记——这是给人看的可读性设计，也方便后续用脚本解析各阶段
三个实战场景
下面给三个完整场景，每个都展示 P&S 模板填好后的样子和执行结果。三个场景分别覆盖 P&S 最擅长的三类任务：数学推理、多步骤代码生成、项目规划。
场景一：数学推理（封闭题，自验证型）
任务：一道分阶段处理的应用题。
甲乙两人从 A、B 两地相向而行，甲速度 6 km/h，乙速度 4 km/h。A、B 相距 50 km。甲出发 1 小时后乙才出发。乙出发后一只狗以 10 km/h 从乙这边出发，在甲乙之间来回跑（碰到甲就折返，碰到乙就折返）。问：甲乙相遇时，狗一共跑了多少千米？
填好后的 Prompt（节选关键部分）：
任务：[上面的题面]
{{verify_mode}}：若某步自检发现错误，标注并重新执行该步。执行完成后把最终答案代回原题验证。
模型执行结果（完整）：
=== 计划 ===
1. 算甲单独走的时间（乙出发前甲已走 1 小时，走 6 km）
2. 算乙出发时两人剩余距离：50 - 6 = 44 km
3. 算两人相向而行的合速度：6 + 4 = 10 km/h
4. 算乙出发后到相遇所需时间：44 / 10 = 4.4 小时
5. 狗的速度恒定 10 km/h，跑的时间 = 相遇时间 = 4.4 小时
6. 狗跑的距离 = 10 × 4.4 = 44 km
难点：狗来回跑看似复杂，但"狗跑的总时间 = 两人相遇时间"，距离 = 速度 × 时间，无需逐段算折返。
=== 执行 ===
【步骤 1】甲 1 小时走 6 km，剩 44 km。自检：正确。
【步骤 2】合速度 10 km/h，相遇时间 44/10 = 4.4 h。自检：正确。
【步骤 3】狗跑 4.4 h × 10 km/h = 44 km。自检：正确。
=== 验证 ===
代回：两人相遇时位置距 A 为 6 + 6×4.4 = 6 + 26.4 = 32.4 km，距 B 为 4×4.4 = 17.6 km，32.4 + 17.6 = 50 ✓。
狗跑 44 km，时间 4.4 h，速度 10 km/h 自洽 ✓。
答案：狗跑了 44 千米。
为什么 P&S 在这道题上比 CoT 强：这题有个经典陷阱——很多人（和裸 CoT）会陷入"算狗第一次碰到甲用了多久、再碰到乙用了多久……"的无穷分段。因为狗每次折返距离都在变，逐段算是个无穷级数，算到天黑也算不完。P&S 的计划阶段会主动识别"狗跑的总时间 = 相遇时间"这个不变量，避开分段陷阱。这就是计划阶段"全局扫描"的价值——它先问"这题的整体结构是什么"，而不是一头扎进"狗第一次跑多久"。
为什么选自验证型：这题答案可以代回验（相遇位置自洽、狗速×时间=距离自洽），是典型的封闭题，自验证型就够，不需要分步自检（推理链只有 3 步，不长）或回溯（路径唯一，没有岔路）。
场景二：多步骤代码生成（分步自检型）
任务：实现一个带校验的"用户注册函数"，要求多步骤、易在某步出错。
用 Python 写一个
register_user(username, email, password)函数：
- 校验 username（3-20 字符，仅字母数字下划线）
- 校验 email（基本格式 + 域名非临时邮箱）
- 校验 password（≥8 字符，含大小写和数字）
- 校验 username/email 是否已存在（模拟一个
users_db字典）- 密码加盐哈希后存储
- 返回
{user_id, username, email}，失败返回{error, field}
填好后的 Prompt：
任务：[上面的需求]
领域约束：不许引入 bcrypt 之外的哈希库；email 校验用正则，不要联网。
{{verify_mode}}：分步自检（默认）。
模型执行结果（完整）：
=== 计划 ===
1. 定义校验函数 validate_username / validate_email / validate_password（各产出 bool + 错误原因）
2. 定义 check_exists(username, email) 查 users_db
3. 定义 hash_password(pw) 用 bcrypt 加盐哈希
4. register_user 主函数：按 1→2→3 顺序校验，任一失败即返回 error
5. 全部通过则哈希密码、生成 user_id、存入 db、返回结果
依赖：4 依赖 1-3；5 依赖 4。
难点：email 临时邮箱域名的判断（需维护黑名单）；bcrypt 用法（要 bytes）。
=== 执行 ===
【步骤 1】定义三个校验函数。
- 计划：产出 bool + 错误原因
- 执行：
USERNAME_RE = re.compile(r'^\w{3,20}$')
EMAIL_RE = re.compile(r'^[^@\s]+@[^@\s]+\.[^@\s]+$')
TEMP_DOMAINS = {'mailinator.com', 'tempmail.com', 'guerrillamail.com'}
def validate_username(u): ... 返回 (ok, reason)
def validate_email(e): ... 格式 + 域名不在 TEMP_DOMAINS
def validate_password(p): ... 长度 + 含大小写 + 含数字
- 自检：username 正则 ^\w{3,20}$；email 用基础正则 + 临时域名黑名单；password 用正则确认含大小写+数字+长度。正确。
【步骤 2】定义 check_exists。
- 计划：查 users_db 里 username 和 email 是否已存在
- 执行：
def check_exists(username, email):
for u in users_db.values():
if u['username'] == username: return ('username', '已存在')
if u['email'] == email: return ('email', '已存在')
return None
- 自检：同时查 username 和 email。正确。
【步骤 3】定义 hash_password，用 bcrypt.hashpw。
- 计划：bcrypt 加盐哈希
- 执行：
import bcrypt
def hash_password(pw):
return bcrypt.hashpw(pw.encode(), bcrypt.gensalt())
- 自检：⚠️ bcrypt 要求输入 bytes，password 需 .encode()。修正：加盐前 encode。偏差已修正。
【步骤 4】register_user 主函数串联校验。
- 计划：按 username→email→password→exists 顺序校验
- 执行：
def register_user(username, email, password):
for fn, field in [(validate_username, 'username'), ...]:
ok, reason = fn(...);
if not ok: return {'error': reason, 'field': field}
exists = check_exists(username, email)
if exists: return {'error': exists[1], 'field': exists[0]}
h = hash_password(password)
...
- 自检：校验顺序为 username→email→password→exists，每步失败返回 {error, field}。正确。
【步骤 5】哈希、存库、返回。
- 计划：生成 user_id、存入 db、返回结果（不含 hash）
- 执行：
user_id = str(uuid.uuid4())
users_db[user_id] = {'username': username, 'email': email, 'hash': h}
return {'user_id': user_id, 'username': username, 'email': email}
- 自检：user_id 用 uuid4；存入 db 的字段含 username/email/hash；返回不含 hash。正确。
=== 验证 ===
代回原需求：① username 校验 ✓ ② email 校验含临时邮箱黑名单 ✓ ③ password 含大小写+数字+长度 ✓ ④ 存在性检查 ✓ ⑤ bcrypt 加盐哈希 ✓ ⑥ 返回结构 ✓。
约束检查：未引入 bcrypt 之外的库 ✓；email 未联网 ✓。
为什么 P&S 在这道题上比裸生成强：裸生成最常犯的错是"忘记 bcrypt 要 bytes"或"校验顺序写错（先查 db 再校验格式，导致脏数据查 db 报错）"。P&S 在计划阶段就把校验顺序定死（格式→存在性），在执行第 3 步自检时抓到 bytes 问题并就地修正。计划阶段定顺序、自检阶段抓细节，两层防御。
为什么选分步自检型：代码生成是长链多步任务（5 步、每步有多个中间值），某步错了（如 bytes 遗漏）会污染后面所有步骤。分步自检在第 3 步就把 bytes 问题抓出来就地修，避免它流到第 4、5 步。如果用自验证型（最后才验），等发现 hash 存不进去时，已经不知道是哪步错了。如果用回溯型则过度——代码错误通常是就地可修，不需要整路径回退。
场景三：项目规划（回溯修正型）
任务：给一个 SaaS 产品的"用户增长"项目做 3 个月规划。
背景：SaaS 工具，当前 MAU 5 万，付费率 3%。目标 3 个月内 MAU 到 8 万、付费率到 5%。团队 3 人增长 + 1 设计 + 1 开发兼职，每月推广预算 2 万元。
填好后的 Prompt：
任务：[上面的需求]
领域约束：不许依赖"病毒裂变"（产品形态不支持）；推广预算硬上限每月 2 万。
{{verify_mode}}：回溯修正型，最多回溯 3 次。
模型执行结果（完整）：
=== 计划 ===
1. 拆解目标：MAU +3 万、付费率 +2pp
2. 拆解为获客 / 激活 / 留存 / 付费转化四条线
3. 各线拟定动作并标资源消耗
4. 排节奏：第 1 月试投放、第 2 月放大、第 3 月收割
5. 风险与退路
=== 执行 ===
【步骤 3】（拟定动作）
- 计划：各线拟定动作并标资源消耗
- 执行：
获客：信息流投放、内容种草、SEO 三线齐开
激活：新手引导优化
留存：邮件召回
付费转化：试用→付费漏斗优化
- 自检：⚠️ 信息流 + 内容 + SEO 三线齐开，3 人团队 + 月 2 万预算，超承载力。
· 是否影响后续步骤：是，资源超载，整个节奏排不下去
- 决策：错误源于步骤 3 的动作贪多。回溯到第 3 步重新拟定。
↩ 回溯到第 3 步：原因——3 人团队无法同时支撑三线获客，预算也不够分。
【步骤 3'】（重新拟定）
- 计划：重新拟定动作
- 执行：
获客：聚焦信息流单线（预算集中、可量化）
激活：新手引导优化（开发兼职可做）
留存：邮件召回（低成本自动化）
付费转化：漏斗优化（增长团队主导）
- 自检：单线聚焦获客，其余靠低成本优化，团队可承受。符合预期。
【步骤 4】排节奏
- 计划：第 1 月试投放、第 2 月放大、第 3 月收割
- 执行：
第 1 月：信息流小预算（8 千）测 CPC，同时上线新手引导优化
第 2 月：CPC 达标则放量到 1.8 万，启动邮件召回
第 3 月：收 ROI，重点优化试用→付费漏斗
- 自检：预算不超（8k+18k+18k=44k < 60k），团队不超载。正确。
【步骤 5】风险与退路
- 计划：每个动作标两周止损线
- 执行：
信息流：两周 CPC 超预期则暂停，切 SEO（低预算）
漏斗优化：两周转化率无提升则回退到原漏斗
- 自检：每个动作有退路。正确。
=== 验证 ===
代回目标：MAU +3 万靠信息流获客（按 CPC 假设估算可达）；付费率 +2pp 靠激活漏斗优化。预算不超 6 万（3×2）。团队不超载。
答案：聚焦信息流获客 + 漏斗优化的单线方案，分 3 个月递进。
路径：1→2→3→(回溯)→3'→4→5
为什么 P&S 在这道题上比"直接要方案"强：直接问"给我个增长方案"，模型会给你一份面面俱到但落不了地的"三线齐开"漂亮话方案——因为模型默认想展示"全面"，不会主动算"这方案 3 人团队撑不撑得起"。P&S 在计划阶段把动作拆出来后，自检阶段立刻发现"3 人团队 + 2 万预算撑不起三线"，触发回溯，砍到单线聚焦。计划让贪多暴露，自检让超载被发现，回溯让方案收敛到可落地。这是 P&S 在规划类任务上的三层价值。
为什么选回溯修正型：规划类任务的错误是结构性的——第 3 步选了三线齐开，第 4、5 步（排节奏、风险）都建立在"三线齐开"这个错误前提上，光在后续步骤补偿没用（资源就那么多），必须回退到第 3 步重新决策。这正是回溯修正型的设计目的。封闭题（如数学）用不上——数学题算错通常就地可修，不需要整路径回退。
P&S 的局限性和适用边界
P&S 不是万能的。它有清晰的适用边界，越界使用反而拖累。
局限一：对"一步就能算"的简单题无收益
如果任务本身就一两步（"2+3 等于几""巴黎是哪国首都"），P&S 的计划阶段是纯 overhead——计划的内容就是"直接算/直接答"，多写一遍计划既不提升准确率，又浪费 token。这类任务该直接问就直接问，最多加一句 CoT。
判断标准：如果任务天然步骤数 ≤ 2，别用 P&S。强用 P&S 不仅没收益，还可能引入"计划阶段想多了"的副作用——模型在计划阶段把简单题复杂化，反而执行阶段绕弯。
局限二：计划阶段本身可能出错
P&S 假设"模型在计划阶段能想对路径"。但如果模型对任务领域不熟（如医学诊断、法律条款适用），它在计划阶段就会拆错步骤，执行阶段再准也救不回来——错误的前提，再精确执行也是错的。
典型表现：模型把不相关的步骤列进计划、漏掉真正关键的步骤、或者把顺序排错（如先做依赖项的下游再做上游）。这种错误在执行阶段会被自检发现"和计划预期不符"，但模型不一定能修对——因为它本来就不知道正确路径是什么。
对策：对高风险领域，计划阶段必须叠加领域知识注入（在 Prompt 里写明拆解规则/红线），或让人审核计划再放行执行。参考 Self-Refine 的"质量放大器不是质量保证"原则——P&S 同理：它放大执行准确率，不能凭空创造领域判断力。模型不知道的步骤，计划阶段也变不出来。
局限三：开放型任务没有"代回验证"标准
自验证型和分步自检型的核心是"把结果代回去验"。但文案、命名、创意这类开放任务没有"代回验"的标准——一个 Slogan 写得好不好，没法代回原条件验。对这类任务，P&S 的验证阶段基本失效，收益主要来自计划阶段（先想清楚受众/卖点/调性再写），而不是验证阶段。
典型表现：模型在验证阶段只能给出"我觉得这个 Slogan 还不错"这种主观判断，无法像数学题那样"代回原条件验成立"。验证阶段退化成走过场。
对策：开放型任务用 P&S 时，应弱化验证阶段，强化计划阶段（让计划详细到"每段写什么、用什么证据、打什么痛点"）；最终质量优化交给 Self-Refine 的"批评-修订"循环——Self-Refine 的批评维度清单（抽象形容词/证据缺失/痛点贴合）才是开放任务的"验证标准"。
局限四：回溯修正型易陷入死循环
回溯修正型如果不在 Prompt 里设回溯次数上限，模型可能反复"回溯-再错-再回溯"，token 烧干也没收敛。这在解空间大、约束互相冲突的任务上尤其常见（如排班同时满足"最少人手"和"无人连续 7 天"——这两条本身可能就矛盾，模型回溯多少次都找不到可行解）。
典型表现：模型在第 3 步回溯，重做第 3 步又错，再回溯……循环到 token 上限被截断，输出半截。
对策：回溯次数硬上限设 3 次；超过即输出当前最优解并标注"未收敛，需人工介入"。不要让模型无限回溯。同时，如果某任务频繁触发"未收敛"，说明这任务可能本就没有可行解（约束冲突），或模型对该领域缺乏判断力——这时该上 ToT（多路并行试）或人工拆约束，而不是死磕 P&S 回溯。
局限五：不能替代工具调用
P&S 全程是"纯推理"，没有工具调用。涉及实时数据（汇率、股价、天气）、需要外部计算（大数据集统计）、需要联网验证（事实查证）的任务，P&S 救不了——模型在执行阶段会幻觉数据。
典型表现：任务要算"今天美元兑人民币汇率"，P&S 计划阶段写"第 1 步查汇率"，但执行阶段没有工具，模型只能"凭记忆"编一个数（可能是几个月前的、可能是错的），后面所有计算都建立在错数据上。
对策：这类任务用 ReAct，把工具调用嵌进循环（Thought→Action→Observation），用 Observation 的真实返回替代模型的"记忆"。P&S 适合"所有信息都在题面里"的封闭推理，不适合"需要外部信息"的开放推理。
局限六：跨调用无状态，超长任务需分块
P&S 是单次调用内完成的范式——计划阶段和执行阶段在同一次生成里。但有些任务的总步骤数远超单次上下文能装下的量（如"重构一个 5000 行的模块"可能要几十个步骤，远超一次能稳定执行的量）。这时候 P&S 的"一次性计划 + 一次性执行"会崩——计划阶段拆出 30 步，执行到第 15 步上下文就开始稀释，模型忘掉前面的中间结果，自检也对照不上。
典型表现：执行到后半段，模型开始"重复已经做过的步骤"或"忘记计划里的某步"，自检环节报"与计划不符"但说不清怎么修。
对策：超长任务要把 P&S 当成"分块执行器"而非"一次性求解器"——先在第一次调用里只做计划阶段（拆出 N 个步骤并标依赖），然后按依赖关系把执行分多次调用，每次执行一个"计划块"（3-7 步），下次调用把上次的产出作为输入继续。这本质上是把 P&S 和 Prompt Chaining 叠加：P&S 管单块内的"计划+执行+验证"，Chaining 管块间的串联。单次调用内别让 P&S 执行超过 7-9 步，超过就该分块。
适用边界总结
| 任务特征 | P&S 是否推荐 | 原因 |
|---|---|---|
| 数学/逻辑/多步推理（零成本） | ✅ 强烈推荐 | 计划阶段逼出隐藏结构 |
| 多步骤代码生成 | ✅ 推荐 | 计划定顺序、自检抓细节 |
| 项目规划/方案 | ✅ 推荐 | 计划让贪多暴露、回溯收敛 |
| 简单事实问答 | ❌ 不推荐 | 步骤≤2，计划是 overhead |
| 创意/命名/文案 | ⚠️ 弱推荐 | 验证失效，仅计划阶段有用 |
| 需要调 API/查数据 | ❌ 不推荐 | 用 ReAct |
| 博弈/组合优化 | ⚠️ 弱推荐 | ToT 更合适 |
| 高风险领域（医/法/金融） | ⚠️ 谨慎 | 需叠领域知识 + 人工终审 |
| 超长任务（>9 步） | ⚠️ 分块用 | 单次调用会上下文稀释，需配合 Prompt Chaining 分块 |
常见误区
❌ 误区一：把 P&S 当 CoT 的"换皮版"
错误做法：认为 P&S 就是 CoT 加了句"先制定计划"，本质一样。
实际区别：CoT 是"边想边写"，模型在生成第一步时不知道第三步会遇到什么，容易跳步、漏条件。P&S 强制先有一份独立计划，把全局路径先定下来，再执行。这两者结构上完全不同——CoT 是局部贪心（每步局部合理），P&S 是先全局规划再执行（先看地图再走）。前者像蒙眼走迷宫，后者像先看地图再走。
正确做法：把 P&S 当成"CoT 的结构化升级"，核心区别在计划阶段的存在与否，而不是措辞变化。判断一个 Prompt 是不是真 P&S，看它有没有一份独立的、先于执行的计划输出——如果计划和执行混在一起（边规划边做），那只是 CoT 套了个壳。
❌ 误区二：计划阶段让模型"自由发挥"，不给拆解维度
错误做法：计划 Prompt 只写"请先制定一个计划"，让模型自己决定怎么拆。
实际情况：模型在无约束时，计划会偏向"列大纲"而非"拆可执行步骤"——写出来的计划像目录（"1. 分析需求 2. 设计方案 3. 实现"），不是 checklist（"1. 校验 username 格式，产出 bool 2. 校验 email，产出 bool..."），执行阶段无法对照。结果是计划阶段形同虚设，退化回 CoT——计划写了个空壳，执行还是边想边写。
正确做法：计划 Prompt 显式要求每步包含"做什么/输入/产出/依赖"四要素，并限制 3-7 步（太少不够拆，太多发散失焦）。这四要素是把计划从"大纲"逼成"可执行 checklist"的关键——有了"产出什么"，执行阶段才能对照"我这一步的产出对不对"；有了"依赖哪一步"，执行阶段才知道顺序不能乱。
❌ 误区三：执行阶段不对照计划，自由发挥
错误做法：计划写完就忘，执行阶段模型想到哪写到哪，不回头对照"这一步是否与计划一致"。
实际情况：没有对照，P&S 就退化回 CoT——计划白做了。模型在执行第 4 步时可能为了"流畅"跳过计划里的第 3 步，或把第 2 步的产出用错。没有"对照计划"这一问，P&S 的"可对照性"优势归零，等于花钱买了个计划当摆设。
正确做法：执行阶段每步必含"自检：是否符合计划预期"这一项。这是 P&S 区别于 CoT 的执行层标志。如果发现某步和计划不符，要么就地修正执行、要么标注"计划有误需调整"——但绝不能默默偏离计划还假装一切正常。
❌ 误区四：所有任务都套回溯修正型
错误做法：觉得回溯修正型最"高级"，所有任务都套，包括简单数学题。
实际情况：回溯修正型 token 消耗最高（2-3×），且对封闭题收益小——数学题算错通常是个别计算错误，就地修正即可，不需要整路径回溯，回溯反而拖慢。无脑套回溯型既慢又贵，还可能因回溯次数耗尽输出"未收敛"的次优解——本来一道数学题一遍算对，套回溯型反而被模型"怀疑自己错了"来回折腾。
正确做法：按前文选择决策树选变体——封闭题用自验证，长链用分步自检，探索型才用回溯。回溯是兜底，不是默认。判断标准是"任务错得起吗"——封闭题错不起（唯一解，错就全错），靠自验证兜底；探索型错得起（多解，试一条不通换一条），靠回溯换路。
❌ 误区五：不做验证就信任最终答案
错误做法：执行完直接输出最终答案，跳过验证阶段。
实际情况：P&S 降低的是"跳步/漏条件"这类结构性错误，不能保证"计算全对"。一道题计划对了、每步也对照了，但某步的算术错了一个符号，最终答案照样错。验证阶段（把答案代回原题）是抓计算错误的最后一道闸门——计划管结构，验证管计算，两层都过才算稳。
正确做法：封闭题必做自验证（代回原题检查）；开放题虽不能代回，但也应做"是否覆盖所有需求点"的 checklist 验证。验证阶段是 P&S 的安全网，不能省。省了验证，等于"盖了地基不验房"——结构对不代表结果对。
❌ 误区六：把 P&S 和 Self-Refine 搞混
错误做法：以为 P&S 的"先计划再执行"和 Self-Refine 的"先生成再批评修订"是一回事。
实际区别：
| 维度 | Plan-and-Solve | Self-Refine |
|---|---|---|
| 拆分的两件事 | 计划 vs 执行 | 生成 vs 修订 |
| 顺序 | 先计划，再执行（串行一次性） | 生成→批评→修订（可循环） |
| 解决的问题 | 推理跳步/漏条件 | 输出不够好 |
| 验证对象 | 中间步骤/最终答案 | 输出整体质量 |
| 适用任务 | 推理/代码/规划 | 文案/方案/代码 |
| 是否可循环 | 否（一次性） | 是（2-3 轮） |
两者可组合：先用 P&S 出一版结构正确的推理/方案，再用 Self-Refine 批评-修订润色质量。P&S 管"对不对、全不全"（结构层），Self-Refine 管"好不好"（质量层）。一个任务可以两层都过：P&S 保证没跳步没漏条件，Self-Refine 保证表达精准有力。
❌ 误区七：把 P&S 当 ToT 的廉价替代，期待它解决探索型难题
错误做法：在博弈、组合优化这类"需要同时试多条路"的任务上用 P&S，期待它替代 ToT。
实际情况：P&S 是单链推理（最多带有限回溯），本质还是"想一条路"。它不能像 ToT 那样同时展开多条思路、并行评估、剪枝。在真正的探索型任务上，P&S 会卡在"选了一条路就走到底，即使这条路是错的"——回溯只能退一步重做同一条路，不能换条路并行试。比如"24 点游戏"这种组合优化，P&S 选了"先乘再减"就只能在这条路上回溯，不能同时试"先加再除"。
正确做法：探索型任务用 ToT；P&S 适合"路径基本唯一、只需想清楚顺序"的任务。两者不替代，互补——ToT 找路径，P&S 沿路径精确执行。理论上可组合：ToT 选出最优路径后，用 P&S 把这条路径精确执行一遍。
❌ 误区八：在闲聊/轻量对话里也套 P&S
错误做法：学会 P&S 后上瘾，连"帮我推荐部电影""总结一下这段话"这种轻量对话也套上 计划→执行→验证 三段式。
实际情况：这类任务天然一两步，且对响应"自然流畅"有要求。套 P&S 后，每次回答都变成"=== 计划 === 1. 回忆相关电影 2. 筛选 3. 推荐 === 执行 === ... === 验证 === ..."，既慢又机械，用户体验骤降。P&S 的计划阶段对这种任务纯属 overhead——计划内容就是"直接答"，多写一遍毫无收益，反而把一句能说完的话拆成三段。
正确做法：P&S 只在"推理结构复杂、错一步全盘皆输"的任务上用。闲聊、轻量问答、简单总结这类，直接问或最多加一句 CoT。判断标准：如果这题的正确答案"不需要先想清楚步骤也能答对"，就别上 P&S。P&S 是为复杂推理设计的纪律，不是为所有对话准备的礼节——把重武器用在轻任务上，既浪费又碍事。
这和 Self-Refine 的"别对所有任务套 3 轮"是同一类错误：把一个为特定场景设计的技巧泛化到所有场景。任何 Prompt 技巧都有适用边界，越界使用不仅无收益，还会拖累体验。
与其他 Prompt 技巧的关系
P&S 不是孤立的，它和已有 Prompt 技巧形成组合拳：
| 技巧 | 与 P&S 的关系 |
|---|---|
| Chain-of-Thought | P&S 是 Zero-Shot CoT 的直接进化版——在 think step by step 前加一个计划阶段 |
| Self-Consistency | SC 靠多采样投票解客观题，可与 P&S 叠加（多次跑 P&S 取多数）提升鲁棒性 |
| Tree of Thoughts | ToT 多路并行搜索，P&S 单链+有限回溯；探索型用 ToT，线性型用 P&S |
| ReAct | ReAct 解决"需要调工具"的多步任务，P&S 解决"信息全在题面"的纯推理；互补 |
| Step-Back Prompting | Step-Back 先抽象再具体，可与 P&S 叠：先 Step-Back 抽出原理，再 P&S 分步执行 |
| Self-Refine | P&S 管"对不对"，Self-Refine 管"好不好"；先 P&S 出正确结构，再 Self-Refine 润色 |
| Few-shot Prompting | Few-Shot 定格式/风格，P&S 定执行流程；可叠加 |
| Meta-Prompting | Meta 优化 Prompt 本身，P&S 是 Prompt 内的执行范式；不同层 |
推荐组合：
- 数学/逻辑高鲁棒：P&S（自验证）+ Self-Consistency（3-5 采样投票）→ 既抓结构又抓随机计算错误
- 多步骤代码生成：P&S（分步自检）+ Few-Shot（给代码风格示例）→ 结构对 + 风格统一
- 复杂规划：P&S（回溯修正）+ Step-Back（先抽象出方法论）→ 大方向不偏 + 细节可回溯
- 高风险推理：P&S + 领域知识注入 + 人工终审 → 结构正确 + 合规
在不同模型上的适配与调参
P&S 的效果不是"对所有模型一视同仁"。不同模型族（Claude / GPT / Qwen）在计划能力、自检能力、指令遵循上有差异，P&S Prompt 的调法也要跟着变。这一节给一些实测观察和调参建议。
模型差异观察
| 维度 | Claude 系列 | GPT 系列 | Qwen 系列 |
|---|---|---|---|
| 计划阶段质量 | 高，擅长拆结构 | 中-高，拆解偏稳健 | 中，拆解有时偏大纲 |
| 自检诚实度 | 高，会主动报错 | 中，有时报喜不报忧 | 中，需显式提示才自检 |
| 回溯执行 | 较好，能稳定重做 | 一般，重做时易"假装改了" | 一般，需限定回溯格式 |
| 长链推理稳定性 | 高 | 高 | 中-高 |
| 对 P&S 指令遵循度 | 极高 | 高 | 高 |
几个关键观察：
- Claude 在计划阶段最擅长"逼出隐藏结构"。给它 P&S，它经常在计划阶段就主动识别出"这里有个触发条件需要分段"。所以在 Claude 上，原始 P&S（不加验证变体）就已经很强，自验证型边际收益相对小。
- GPT 系列在自检阶段有"自我安慰"倾向——执行错了，自检环节有时会说"基本正确，符合预期"，把错误蒙混过去。所以在 GPT 上，分步自检型需要在 Prompt 里强制要求"自检时必须重新独立计算一遍核对"，否则自检会走过场。
- Qwen 在计划阶段容易写成"大纲"而非"可执行 checklist"。需要在 Prompt 里非常明确地要求每步写"做什么/输入/产出/依赖"四要素，否则计划会退化成目录。
通用调参建议
不管用哪个模型，P&S Prompt 有几个调参旋钮，按任务和模型调：
旋钮一：计划阶段的步骤数限制（3-7 vs 5-9）
- 任务天然步骤少（数学题）→ 限制 3-5 步，多了反而发散
- 任务天然步骤多（代码生成、规划）→ 放宽到 5-9 步
- 模型爱发散（Claude/Qwen）→ 加硬上限，"最多 7 步，超过请合并"
- 模型偏保守（GPT）→ 可稍放宽，鼓励拆细
旋钮二：自检的强度（轻量 vs 重量）
- 封闭题、短链 → 轻量自检（只问"对吗"）
- 长链、开放题 → 重量自检（要求"重新独立计算/推导一遍核对"）
- GPT 系列建议默认重量自检（防"自我安慰"）
- Claude 可默认轻量（它自检较诚实）
旋钮三：回溯次数上限（3 次 vs 5 次）
- 探索型任务 → 3 次（够换一条路试）
- 约束冲突型任务 → 慎用回溯，可能本就无解
- 任何情况 → 不超过 5 次，否则易死循环
旋钮四：验证阶段的形式（代回 vs checklist）
- 封闭题（有唯一解）→ "把答案代回原题验证"
- 开放题（无唯一解）→ "对照需求清单逐项打勾"
- 高风险任务 → 两种都做（代回 + checklist）
一个调参实例
以"用 GPT 做多步代码生成"为例，因为 GPT 有"自我安慰"倾向，分步自检型要这样调：
### 第二步：逐步执行 + 重量自检
对每个步骤：
【步骤 N】
- 计划：[复制]
- 执行：[实际执行]
- 自检（必须重新独立核对，不要复述执行过程）：
· 重新独立推导/计算这一步，写出推导过程，与执行结果对比
· 如不一致，以独立推导为准，修正执行
· 明确说"核对一致"或"发现偏差并已修正"，不许说"基本正确"
关键改动是"必须重新独立核对，不许复述执行过程，不许说基本正确"——这三条专治 GPT 的自我安慰。Claude 上可以删掉这几条约束（它会老实自检），但 GPT 上建议保留。
这个调参思路同样适用于 Self-Refine——Self-Refine 的批评阶段在 GPT 上也要防"自我安慰"，批评维度必须显式列出且要求"只列问题不许说没问题"。两个技巧的调参逻辑同源：凡是"让模型自我评估"的环节，都要防模型报喜不报忧。
成本与延迟实测
P&S 的准确率提升不是白来的——它比 CoT 多花 token、也多花延迟。在决定是否上 P&S、上哪个变体前，先看一组实测成本数据（以 GSM8K 题目为基准，近似值，模型为 GPT-3.5 级别，单题统计）。
Token 与延迟对比
| 方法 | 平均输入 token | 平均输出 token | 总 token | 相对 CoT | 端到端延迟（相对） |
|---|---|---|---|---|---|
| 直接提问 | ~60 | ~30 | ~90 | 0.5× | 1× |
| Zero-Shot CoT | ~60 | ~180 | ~240 | 1×（基线） | 1.2× |
| Plan-and-Solve | ~80 | ~320 | ~400 | 1.7× | 1.6× |
| P&S + 自验证 | ~80 | ~380 | ~460 | 1.9× | 1.8× |
| 分步自检型 | ~80 | ~480 | ~560 | 2.3× | 2.1× |
| 回溯修正型（含 1 次回溯） | ~80 | ~700 | ~780 | 3.3× | 2.9× |
| Self-Consistency（5 采样 CoT） | ~60 | ~900 | ~960 | 4× | 5×（并发后约 1×） |
几个关键解读：
- P&S 原始版的成本增幅温和（1.7×），主要来自计划阶段的额外输出，性价比极高。
- 分步自检型成本跳升明显（2.3×），因为每步都多写一次自检。但相比 Self-Consistency 的 4×，仍便宜一半。
- 回溯修正型一旦触发回溯，成本不可控——表里只算 1 次回溯就到 3.3×，3 次回溯可能破 5×。这也是为什么回溯型必须设次数上限。
- Self-Consistency 虽然 token 最贵，但延迟可并发摊薄（5 次采样并发，墙钟延迟接近 1×）。P&S 是单次调用，延迟无法并发优化。所以"成本敏感"选 P&S，"延迟敏感"反而 Self-Consistency（并发）可能更快。
选型的成本视角
把准确率和成本放一起看，能得出更现实的选型结论：
| 你的约束 | 推荐方法 | 理由 |
|---|---|---|
| 只能单次调用、零示例 | P&S（自验证） | 准确率/成本比最优 |
| 能多采样、延迟可并发 | Self-Consistency + CoT | 延迟可摊薄，准确率高 |
| 能给示例 | Few-Shot CoT | 1× 成本拿 +13-18% |
| 任务超长、易走错 | P&S（回溯）但接受 3× 成本 | 准确率优先 |
| 严格预算上限 | P&S 原始版（不加变体） | 1.7× 成本拿 +7-10% |
一句话：P&S 是"单次调用下准确率/成本比之王"，但不是"绝对准确率之王"。如果你能多采样、能给示例、能接受更高成本，别的技巧上限更高；如果你什么都只能花一次、给零示例，P&S 是你最好的朋友。
实测中的一个坑：回溯修正型的成本不可预估，是它最难管理的地方。上表里回溯型只算了 1 次回溯到 3.3×，但实际是否触发回溯、回溯几次，取决于题目难度和模型对该领域的判断力——同一套 Prompt 在简单题上 1.7×（不回溯），在难题上可能 4-5×（多次回溯）。这意味着如果你按平均成本做预算，遇到难题批次会严重超预算。生产环境用回溯型，建议：(1) 在 Prompt 里硬限回溯 3 次；(2) 监控单次调用的输出 token，超过阈值就提前截断；(3) 对成本敏感的场景，宁可降级到分步自检型（成本可预估）也别上回溯型。
一张图总结
任务 + 约束
│
▼
┌───────────────────────────┐
│ 阶段 1：计划（Plan） │ ← 全局扫描，逼出隐藏结构
│ · 3-7 个子步骤 │
│ · 每步：做什么/输入/产出/依赖│
│ · 识别难点与失败模式 │
└───────────────────────────┘
│
▼
┌───────────────────────────┐
│ 阶段 2：执行（Solve） │ ← 按计划走，不跳步
│ · 逐步执行 + 分步自检 │
│ · 每步对照计划预期 │
│ · 偏差则标注/回溯 │
└───────────────────────────┘
│
▼
┌───────────────────────────┐
│ 阶段 3：验证（Verify） │ ← 答案代回原题
│ · 满足所有显式约束？ │
│ · 处理所有隐含约束？ │
│ · 反向代入是否成立？ │
└───────────────────────────┘
│
▼
最终答案
（标注执行路径，含回溯点）
三种变体对应验证的不同强度：
- 自验证型：只在阶段 3 做一次整体验证（最便宜，封闭题首选）
- 分步自检型：阶段 2 每步都自检（中等成本，长链推理首选）
- 回溯修正型：阶段 2 每步自检 + 允许回退重做（最贵，探索型首选）
小结
Plan-and-Solve 是 Prompt 工程在推理结构层的进化：从 CoT 的"边想边写"升级到"先计划再执行"。核心要点：
- 两阶段架构：计划阶段（全局扫描、拆步骤）→ 执行阶段（按计划走、不跳步），职责分离是关键
- 为什么有效：计划阶段强制做全局扫描逼出隐藏约束、分步降低单次认知负荷、计划本身是可对照 checklist
- 三种改进变体：
- 自验证型（PS+）：执行后整体代回验，封闭题首选，+2-3 个百分点
- 分步自检型：每步执行后立即检查，长链推理首选，防错误累积
- 回溯修正型：发现错误可回退重做，探索型任务首选，但 token 最贵
- 与同类对比：P&S 是 Zero-Shot 下的性价比之王（+7-10 个百分点），但 Few-Shot CoT、Self-Consistency、ToT、ReAct 在各自擅长场景上限更高
- 适用边界：数学/逻辑/多步代码/规划强推荐；简单问答/创意文案/需调工具/高风险领域需谨慎或不推荐
- 三个止损意识：简单题别用 P&S、回溯必设上限、开放题弱化验证强化计划
何时该想到 P&S（一句话速查）：
- 题目有"分阶段/条件触发"的结构 → 上 P&S，计划阶段会逼出分段
- 多步骤任务里某步漏了会全盘皆输 → 上 P&S，计划先列全步骤
- CoT 反复在"跳步/漏条件"上翻车 → 上 P&S，计划阶段先体检
- 推理链 ≥4 步且中间值多 → 上分步自检型，防错误累积
- 任务有唯一解可代回验证 → 上自验证型，最便宜
- 路径易选错且能换条路重来 → 上回溯修正型
- 多步代码生成（每步产出影响后续）→ 上分步自检型，错误早发现
- 项目规划/方案（资源/约束多）→ 上回溯修正型，超载可回退
何时该放弃 P&S：
- 题目一两步就能答 → 直接问或 CoT，P&S 是 overhead
- 需要联网/调 API → 上 ReAct，P&S 是纯推理
- 创意发散/博弈组合 → 上 ToT，P&S 是单链
- 闲聊/轻量对话 → 别上 P&S，会拖累体验
- 开放型文案（无代回验证标准）→ 弱化 P&S 验证，强化计划
- 高风险领域（医/法/金融）→ P&S 之上必须叠领域知识 + 人工终审
最后一句话：P&S 的价值不在"让模型更聪明"，而在"让模型先看一眼地图再走"。CoT 是蒙眼走迷宫，每一步都合理但整体可能跑偏；P&S 强制先看地图，把题目的隐藏结构（分段、约束、依赖）逼出来，再按图索骥。它放大的不是模型的智力，而是模型"先规划后执行"的纪律性——这也是为什么它对"结构错了全盘皆输"的多步任务提升最大，对"本来就一两步"的简单任务几乎无收益。它和 Self-Refine 是一对互补的工具：P&S 管结构对不对，Self-Refine 管质量好不好——一个保下限，一个提上限。
Prompt 工程进阶系列下一篇将讲 Prompt 自动化与编排：如何把多份 Prompt 串联成完整工作流。