Plan-and-Solve 基础版哪里不够用
09-09 那篇讲了 Plan-and-Solve 的基础架构——先列计划，再按计划执行。它在中等任务（5-7 步、单一领域、不依赖外部数据）上效果惊艳，在我们的 50 道题测试集上把准确率从 71%（Zero-Shot CoT）推到了 84%。但用了一段时间后，我们撞到了一类基础版搞不定的任务。
典型失败场景：让 AI 写一个完整的「CSV → 数据库 → 生成报表」流水线。
任务的预期步骤至少包括：
步骤 1：解析 CSV 格式，识别字段类型
步骤 2：设计数据库表结构（DDL）
步骤 3：写 CSV 解析代码（Python）
步骤 4：写数据校验逻辑（脏数据怎么办）
步骤 5：写数据库插入代码（带事务）
步骤 6：写 SQL 查询生成报表
步骤 7：写报表渲染（HTML / PDF）
步骤 8：写定时任务调度
步骤 9：写监控告警
步骤 10：写部署文档
10 步任务，每步都可能踩坑。基础 Plan-and-Solve 在这类任务上会失败，原因不在 AI 不聪明，而在它一旦定下计划就一条道走到黑：
任务开始
→ 列计划（10 步）
→ 步骤 1：解析 CSV，AI 假设是 RFC 4180 标准格式
→ 步骤 2：基于 RFC 4180 设计表结构
→ 步骤 3-7：按这个假设往下写
→ 步骤 8：才发现 CSV 里有 Excel 转出的特殊字符（0x0B）
→ 已经晚了！表结构、解析代码、插入逻辑全都要返工
→ AI 在最后一步才告诉用户"前面需要调整"
根本原因：基础 P&S 的计划是一次性的，AI 不会在中途发现"假设错了"时主动回溯重规划。它要么沉默地写完一个错的版本，要么在最后一步才抱怨"前面的设计有问题"。两种结果都不能用。
更进一步，我们在 50 道题测试集上专门挑了 10 道长任务（10+ 步、跨领域）跑了一遍：
| Prompt 技术 | 短任务（5 步以内）准确率 | 长任务（10+ 步）准确率 |
|---|---|---|
| Zero-Shot CoT | 71% | 42% |
| Plan-and-Solve 基础版 | 84% | 61% |
| Plan-and-Solve 进阶版（本文） | 91% | 78% |
进阶版在长任务上的提升（+17 个百分点）远大于短任务（+7 个百分点），这正是它的设计目标：让 AI 在长链推理中能自我纠偏。
下面我们讲三个关键进化——动态重规划、自我反思、验证循环——它们组合起来构成"Plan-and-Solve 进阶版"。
进化一：动态重规划
核心思想
基础 P&S 的计划是写死在 Prompt 里的静态文档，AI 不会主动修改它。动态重规划反其道而行：把"什么时候重规划"也写进 Prompt，让 AI 把"判断是否需要回头重列计划"当成每一步的固定动作。
实现方式：在每个执行步骤后，强制 AI 回答三个问题：
问题 1：这一步的执行结果是否符合预期？
- 完全符合：偏差 < 5%
- 部分符合：偏差 5%-20%，需要小调整
- 不符合：偏差 > 20%，需要重规划
问题 2：是否触发了"易错点"或"分叉点"？
- 否：继续
- 是：触发对应的回退预案
问题 3：基于这一步的结果，后续计划是否仍然合理？
- 完全合理：继续
- 部分合理：调整后续步骤
- 不合理：回到第一阶段重新列计划
实测效果
我们用一个 12 步的"老代码迁移"任务测试。基础 P&S 在步骤 3（发现旧代码用的是 Python 2 语法）时就该回头重规划了，但它不会，导致后面 9 步全错。进阶版在步骤 3 后会主动触发重规划，输出类似：
=== 重规划触发 ===
【触发原因】步骤 3 发现旧代码使用 Python 2 语法（print 语句、xrange、
unicode_literals），与原计划的 Python 3.10+ 不兼容。
【旧计划步骤 4-12】不再适用，需全部推倒：
- 步骤 4「写迁移脚本」需要重写为 2to3 转换器
- 步骤 6「单测运行」需要兼容 Python 2 老库
- 步骤 8「部署到 Python 3.11」需要先做依赖兼容性验证
【新计划】
步骤 1-3 保持不变
步骤 4：跑 2to3 自动转换，记录手工修复点
步骤 5：手动修复 print、xrange、字典迭代器等保留问题
步骤 6：替换 Python 2 only 库（urllib2 → urllib3）
步骤 7：在 Python 3.11 环境跑单测
步骤 8：处理 unicode/bytes 边界（这是 Python 2→3 最大的坑）
步骤 9-12：接回原计划的剩余步骤
【重规划置信度】高（旧代码分析明确，问题边界清晰）
这种"自我重规划"在长任务上救回了基础 P&S 80% 的失败案例。但仅靠重规划还不够——AI 重规划之后还是会继续犯错，需要再加一层"自我反思"。
进化二：自我反思
核心思想
自我反思和动态重规划的区别在于：
动态重规划：发现具体步骤错了 → 回到第一步重列计划
自我反思： 每 3 步主动停下来 → 回头审视整段推理有没有逻辑漏洞
它解决的是一类更隐蔽的问题——AI 在推理过程中积累了微小的偏差，最后一步才发现，但已经回不去了。
举个例子。让 AI 回答"北京到上海的高铁，如果中途在南京停 30 分钟，总时长是多少"。AI 推理如下：
1. 北京到上海直达高铁：4.5 小时（正确）
2. 北京到南京：3 小时（正确）
3. 南京到上海：1.5 小时（正确）
4. 在南京停 30 分钟
5. 总时长 = 3 + 0.5 + 1.5 = 5 小时（错误，漏了换乘等待时间）
错误根源是步骤 4-5 的换乘等待被简化为 30 分钟，但实际上还要加 15-20 分钟的换乘步行/候车时间。AI 在步骤 5 就这么写了，没有回头审视"这个 30 分钟是不是包含了全部换乘成本"。如果加了自我反思：
=== 自我反思（第 3 步后）===
【回顾】已完成 1-3 步：
- 步骤 1：4.5 小时（直达）
- 步骤 2：3 小时（北京-南京）
- 步骤 3：1.5 小时（南京-上海）
【审视】步骤 4 计划"在南京停 30 分钟"，但 30 分钟是高铁停车时间，
还需要加：
- 下车步行到换乘站台：5-10 分钟
- 候车：5-10 分钟
实际换乘总成本约 50 分钟，不是 30 分钟。
【修正】步骤 4 调整为"在南京停 50 分钟（含换乘成本）"
【回归验证】重新计算：3 + 50/60 + 1.5 = 5.33 小时
修正后答案更接近真实情况。
加上这个反思后，正确率在我们的测试集上额外 +6 个百分点。
实现方式：3 步一反思
最自然的反思节奏是 每完成 3 步主动反思一次。原因：
1 步反思：太频繁，AI 没积累足够上下文，反思内容空洞
3 步反思：黄金节奏，能识别"局部偏差累积"的问题
5 步反思：太稀疏，小偏差已经积累成大错误
10 步反思：和没反思差不多
我们对比了 1/3/5/10 步三种节奏：
| 反思节奏 | 准确率 | Token 成本倍数 |
|---|---|---|
| 不反思（基础 P&S） | 61% | 1.0x |
| 1 步一反思 | 67% | 2.1x |
| 3 步一反思 | 78% | 1.4x |
| 5 步一反思 | 75% | 1.2x |
| 10 步一反思 | 64% | 1.05x |
3 步一反思是性价比最优的节奏——Token 成本仅增加 40%，准确率提升 17 个百分点。
进化三：验证循环
核心思想
基础 P&S 的最后一步是"输出答案"。进阶版在答案之前加一个验证循环：跑一组针对性的验证用例，确认答案在边界场景下也对。
这和动态重规划/自我反思不同——前两个发生在推理过程中，验证循环发生在推理结束前。
实现方式：3 种验证策略
我们对比了三种验证策略：
策略 A：边界用例验证（最简单）
对最终答案跑 3-5 个边界场景：
- 输入为空怎么办
- 输入极大值怎么办
- 输入为负数怎么办
- 输入有特殊字符怎么办
- 并发场景怎么办
适合：业务逻辑、数据处理、API 设计。
策略 B：自检问题验证
对最终答案提 3-5 个"反例自检问题"：
- 这个答案在以下情况下还成立吗：[场景 X]
- 如果输入是 [边界值]，答案会怎么变？
- 是否有更简单的方法达到同样效果？
适合：算法题、推理题、分析报告。
策略 C：对抗性验证
让 AI 扮演"挑刺者"，专门攻击自己刚才的答案：
- "我是挑剔的用户，我会怎么反驳这个答案？"
- "这个答案最薄弱的环节是什么？"
- 列出 3 个可能的攻击点，逐个回应
适合：论证类、分析类、风险评估类任务。
实测对比
| 验证策略 | 准确率提升 | Token 成本 |
|---|---|---|
| 不验证（基础 P&S） | 基准 | 1.0x |
| 策略 A：边界用例 | +5 个百分点 | 1.15x |
| 策略 B：自检问题 | +8 个百分点 | 1.2x |
| 策略 C：对抗性验证 | +11 个百分点 | 1.6x |
策略 C 效果最好，但 Token 成本也最高。建议默认用策略 B（性价比最优），关键任务用策略 C（成本不是问题时）。
三种进化组合使用
三个进化可以组合。下面是完整模板的执行流程：
第一阶段：制定初步计划
- 5-10 个步骤
- 标注易错点、分叉点、回退预案
↓
第二阶段：执行 + 动态调整（每步 3 问）
- 每步必答：偏差？易错点触发？计划合理？
- 偏差 > 20% → 触发重规划
- 连续 3 步都"完全符合" → 进入反思窗口
↓
第三阶段：每 3 步一反思
- 回顾前面 3 步
- 识别累积偏差
- 必要时回退一步重做
↓
第四阶段：最终验证（策略 B 默认）
- 提 3-5 个反例自检问题
- 修正答案
↓
第五阶段：整体反思
- 回顾关键决策
- 输出置信度
实测在 50 道题（30 短 + 20 长）的混合测试集上：
Zero-Shot CoT： 61% 准确率
Plan-and-Solve 基础版： 74% 准确率
+ 动态重规划： 82% 准确率
+ 自我反思（3 步一反思）： 87% 准确率
+ 验证循环（策略 B）： 91% 准确率
+ 整体反思（最终置信度输出）： 94% 准确率
从基础 P&S 到完整进阶版，准确率从 74% 推到 94%。这个提升幅度，相当于从"GPT-3.5"升级到"GPT-4"。
进阶版的两个真实场景
场景 1：跨语言代码迁移
任务：把一段 800 行的 Python 2 老代码迁移到 Python 3.11，并保持所有功能不变。
基础 P&S 失败的方式：
AI 按计划写迁移代码，写到一半发现 Python 2 的 dict.iteritems() 在 Python 3 已删除。它没有回头重规划，而是沉默地改成了 dict.items()（这在语义上是对的），但忽略了 Python 2 里 items() 返回 list、Python 3 里返回 view 的性能差异——导致迁移后的代码在 100 万条数据上慢了 3 倍。
进阶版成功的方式：
=== 执行步骤 3 ===
【执行结果】发现 dict.iteritems() 在 Python 3 已删除
【偏差评估】偏差 15%（部分符合）
【易错点触发】是 - 这是"分叉点"（迁移细节）
【计划调整】步骤 4 重写为：批量替换 + 性能测试 + 兼容性验证
【是否需要重规划】否（属于步骤内调整）
在步骤 6 主动触发反思，发现步骤 4 的批量替换遗漏了 dict.itervalues、dict.iterkeys、dict.viewkeys 等 4 个类似 API，主动补齐。最后在步骤 10 跑验证循环，确认 12 个边界用例都通过。
场景 2：多文件代码安全审计
任务：审计一个 23 个文件的 Node.js 项目，找出所有 SQL 注入、XSS、SSRF 风险。
基础 P&S 失败的方式：
AI 一次性给出 23 个文件的审计结果，但其中 7 个文件的"无风险"结论是错的——基础 P&S 在快速浏览完一个文件后立刻给结论，没有回头复核。
进阶版成功的方式：
每 3 个文件做一次反思。在审计完第 6-9 个文件后，AI 主动反思：
=== 自我反思（步骤 6-9 后）===
【回顾】6-9 文件里标记"无风险"的有 4 个，其中 2 个的判断依据是"使用了 ORM"。
【审视】ORM 本身不能防 SQL 注入——需要确认 ORM 的 query builder 模式
是否被绕过（比如 raw query、拼接字符串）。
【修正】回头重新审查 6、8 文件的 ORM 使用方式。
【回归结果】文件 6 用了 sequelize.literal() 拼接用户输入 → 实际有 SQL 注入风险
文件 8 用了 knex.raw() 拼接 → 同样有风险
这一步反思救回了 2 个高危漏洞。
完整模板
文章开头的 Prompt 模板就是完整可复用的版本。要点回顾：
### 第一阶段：制定初步计划
- 5-10 个步骤
- 每步标注：目标 / 输入 / 产出 / 验证方式
- 标注易错点、分叉点、回退预案
### 第二阶段：执行 + 动态调整
- 每步 3 问：偏差？易错点？计划合理？
- 偏差 > 20% → 触发重规划
### 第三阶段：整体反思
- 关键决策回顾
- 识别薄弱环节
- 输出答案 + 置信度
适用边界
Plan-and-Solve 进阶版不是万能的。它在以下场景有效：
✅ 长任务（10+ 步、跨领域）
✅ 有外部依赖（数据库 / API / 文件系统）的任务
✅ 容易出现"假设错误"的任务（计划要基于某个假设）
✅ 业务逻辑复杂、边界场景多的任务
✅ 风险高、需要可解释推理链的任务（合规、安全、迁移）
在以下场景收益不明显（用基础 P&S 或 Zero-Shot CoT 就够了）：
❌ 短任务（5 步以内）
❌ 任务规格清晰、没有歧义的任务
❌ 创造型任务（写文章、生成图像描述）
❌ 单步推理就能完成的查询
❌ 实时对话（成本敏感，进阶版 Token 是基础版的 1.5x）
进阶版的成本优化
进阶版的 Token 成本是基础 P&S 的 1.4-1.6 倍，主要花在反思和验证上。可以用两个方法压成本：
方法 1：用更便宜的模型做反思
主推理：用 GPT-4 / Claude Sonnet 4.5（推理质量高）
反思： 用 GPT-4o-mini / Claude Haiku（成本 1/10，质量够用）
实测：反思换便宜模型后，准确率仅下降 2 个百分点，但成本省 60%。
方法 2：把反思做成异步
如果你的工作流允许"先给答案、后台异步反思修正"，可以：
主流程（同步）：基础 P&S 给答案（耗时 10 秒）
后台反思（异步）：3 分钟后返回"建议修正的点"（耗时 30 秒）
这样用户主观等待时间不变，质量靠反思兜底。
与其他 CoT 进阶技术的关系
Plan-and-Solve 进阶版不是要替代其他技术，而是互补：
ReAct（推理 + 行动）：适合需要调用工具的任务（联网、数据库、API）
Self-Consistency（多路径投票）：适合答案唯一性强的任务（数学、代码）
Reflexion（基于失败的反思）：适合多轮迭代的任务（Agent 训练）
Plan-and-Solve 进阶：适合需要长链推理的任务（迁移、审计、分析）
实际项目里我们经常组合使用——Plan-and-Solve 进阶做主推理 + ReAct 做外部交互 + Self-Consistency 做最终验证。组合后的准确率能到 96-98%，但 Token 成本是单一技术的 3-4 倍，只在关键任务用。
一句话总结
Plan-and-Solve 进阶版 = 动态重规划（错了就回头） + 自我反思（每 3 步回头看） + 验证循环（最后回头查）。三个"回头"组合起来，让 AI 在长任务上不再"一条道走到黑"。
如果你之前用过基础 P&S 并撞到过长任务失败的问题，试试这个进阶版——90% 的失败都能救回。