模块5：复杂问题的拆解策略
难度：⭐⭐⭐⭐ 高级 | 建议时长：3-4小时
目标：当一个提示词搞不定时，学会用思维树、ReAct 和提示词链拆解复杂任务
5.1 思维树（Tree of Thoughts, ToT）：像下棋一样思考
下棋不是只看一步
下象棋时，高手不会只想”我走这一步”，而是想”如果我走这步，对方会怎么走，然后我再怎么走”。如果推演几步发现这条路不行，就退回来换一条路。
思维树就是这个过程：探索多条思路，评估每条路的前景，放弃差的，深入好的。
思维树 vs 思维链
思维链（CoT）= 一条路走到底：
开始 → 步骤1 → 步骤2 → 步骤3 → 结论
思维树（ToT）= 先看有几条路，选最好的走：
┌→ 方向A → 评估：不太行 → 放弃，退回来
开始 → 分支 ├→ 方向B → 评估：有希望 → 继续深入 → 结论 ✅
└→ 方向C → 评估：一般 → 放弃
核心区别：思维树有”回溯”——发现走错了可以退回来换路。思维链没有。
使用模板
问题：[你的复杂问题]
请用思维树方法来解决：
第一步 - 生成候选方案：
提出 3-5 个不同的解决方向，每个用一句话概括。
第二步 - 初步评估：
对每个方向从可行性(1-5)、效果(1-5)、成本(1-5) 三个维度打分。
第三步 - 选择最优路径：
选得分最高的 2 个方向展开详细分析。
第四步 - 深入推演：
对选中的方向往前推演 2-3 步，分析可能结果和风险。
如果推演中发现行不通，退回来选其他方向。
第五步 - 最终决策：
给出推荐方案和实施建议。
实战1：产品功能优先级决策
问题：在线教育 App 下季度优先开发什么功能？
用户反馈最多的需求：直播课、AI批改作业、学习社区、家长端。
第一步 - 列出候选方案：
A：优先做直播课
B：优先做 AI 批改作业
C：优先做学习社区
D：优先做家长端
第二步 - 多维度评估：
| 方案 | 用户需求 | 技术难度 | 收入潜力 | 竞争壁垒 | 总分 |
|------|---------|---------|---------|---------|------|
第三步 - 对 Top2 方案推演 2-3 步：
（实施路径 → 可能遇到的问题 → 3个月后预期效果）
如果推演发现问题严重，退回选其他方案。
第四步 - 最终建议 + 风险提示。
实战2：技术选型决策
问题：新项目的后端框架选 Spring Boot、Go Gin 还是 FastAPI？
团队情况：5人，Java经验为主，需要3个月上线。
请用思维树方法分析：
第一步 - 列出候选方案：
A：Spring Boot（Java 生态，团队熟悉）
B：Go Gin（高性能，但团队需要学习）
C：FastAPI（Python，开发快，但团队不熟）
第二步 - 多维度评估：
| 方案 | 团队熟悉度 | 性能 | 开发速度 | 生态成熟度 | 招聘难度 |
|------|-----------|------|---------|-----------|---------|
| A | 5 | 4 | 3 | 5 | 5 |
| B | 2 | 5 | 4 | 4 | 3 |
| C | 2 | 3 | 5 | 3 | 4 |
第三步 - 对 A 和 B 深入推演：
A路径：团队直接上手 → 但 Spring Boot 启动慢、配置多
→ 推演：3个月能上线，但代码量大，后期维护成本高
B路径：需要2-3周学习 Go → 但之后开发效率高
→ 推演：学习期有风险，可能延期；但长期收益好
→ 问题：3个月deadline太紧，学习成本不可控 → 退回选A
第四步 - 最终建议：选 Spring Boot，理由是时间约束下
团队熟悉度是第一优先级。建议下个项目尝试 Go。
5.2 ReAct（推理+行动）：边想边干
侦探破案的思路
侦探破案不是先把所有可能都想清楚再行动。而是：有个线索 → 去查 → 发现新线索 → 再查 → 逐步逼近真相。
ReAct 就是让 AI 交替进行”思考”和”行动”，像侦探一样一步步解决问题。
Thought（思考）→ Action（行动）→ Observation（观察结果）
↑ ↓
└──────────── 循环直到解决 ←────────────┘
使用模板
请用"思考-行动-观察"的方式解决以下问题。
每一步都要：
1. Thought：你在想什么、计划做什么
2. Action：你要采取的行动
3. Observation：行动的结果
重复以上步骤直到得出最终答案。
问题：[你的问题]
实战：用 ReAct 排查 Bug
Bug：用户反馈登录页面点击登录按钮无反应。
Thought 1：按钮无反应，可能的原因：JS报错、事件没绑定、
网络请求失败、前端拦截。先检查最可能的原因。
Action 1：检查浏览器控制台是否有 JS 错误。
Observation 1：控制台报错 "TypeError: Cannot read property
'value' of null at login.js:42"
Thought 2：JS 执行出错了。第42行试图读取一个 null 对象
的 value 属性，可能是 DOM 元素没找到。
Action 2：检查 login.js 第42行和对应的 HTML 元素。
Observation 2：代码是 document.getElementById('pwd').value，
但 HTML 中密码框的 id 是 'password' 不是 'pwd'。
Thought 3：id 不匹配导致获取不到元素。简单的命名不一致 Bug。
Action 3：将 JS 中的 'pwd' 改为 'password'。
Final Answer：Bug 根因是密码框的 id 与 JS 代码中引用的
id 不一致。修复：统一 id 命名。
生活场景：用 ReAct 规划旅行
目标：规划一次 3 天的成都旅行，预算 3000 元。
Thought 1：需要考虑交通、住宿、景点、美食。
先确定大头——交通和住宿的预算。
Action 1：估算交通和住宿费用。
Observation 1：高铁/机票约 500-800，住宿3晚约 600-900，
剩余约 1300-1900 用于餐饮和门票。
Thought 2：预算还算充裕。接下来规划每天的行程，
成都核心景点有武侯祠、锦里、宽窄巷子、大熊猫基地、都江堰。
Action 2：按距离和主题分配到 3 天。
Observation 2：Day1 市区文化（武侯祠+锦里+宽窄巷子），
Day2 熊猫基地+春熙路，Day3 都江堰一日游。
Thought 3：看起来合理，但都江堰在郊区，
要确认往返时间和交通方式...
（继续循环直到计划完善）
5.3 提示词链（Prompt Chaining）：流水线作业
工厂流水线思维
手工作坊里一个人从头做到尾，效率低质量不稳定。工厂用流水线——每个工位做一道工序，上一道的产品是下一道的原料。
提示词链就是：把一个复杂任务拆成多个提示词，串联执行，每个提示词只做一件事。
一个提示词塞太多任务 → 每个都做不好
拆成 3 个提示词串联 → 每个都做得精
类比：
❌ 一个人同时当翻译、编辑、排版
✅ 翻译先翻 → 编辑再改 → 排版最后排
三种链式模式
模式A：顺序链（最常用）
上一步的输出直接作为下一步的输入。
步骤1（提取）→ 步骤2（改写）→ 步骤3（翻译）→ 步骤4（排版）
模式B：分支链
先分类，不同类别走不同的处理流程。
┌→ 正面评论 → 提取好评要点 → 生成感谢回复
分类 ──→├→ 负面评论 → 提取投诉原因 → 生成解决方案
└→ 咨询问题 → 识别问题类型 → 匹配FAQ回答
模式C：循环链
生成 → 检查 → 不达标就重新生成，直到满意。
生成初稿 → 质量检查 → 不达标？→ 修改指令重新生成 → 再检查 → 达标 ✅
实战案例：把一篇中文论文变成英文博客
第1步 - 提取（学术 → 要点）
提示词："阅读以下论文摘要，提取 3-5 个核心观点，
用通俗的中文复述，每个观点一句话。"
输入：[论文摘要]
输出：5个核心观点的中文列表
第2步 - 改写（专业 → 大众）
提示词："将以下学术观点改写为普通人能理解的表述，
使用日常类比和例子，保持准确性。"
输入：[第1步的输出]
输出：通俗版中文内容
第3步 - 翻译（中文 → 英文）
提示词："将以下中文翻译为地道的英文，
使用简洁的博客写作风格，不要学术腔。"
输入：[第2步的输出]
输出：英文博客正文
第4步 - 排版（纯文本 → 博客格式）
提示词："为以下英文内容添加博客格式：
吸引人的标题、引言段、小标题、结尾号召行动。"
输入：[第3步的输出]
输出：完整的英文博客文章 ✅
如果直接用一个提示词”把这篇中文论文改写成英文博客”，质量远不如四步链式处理。
实战案例2：客户反馈 → 产品改进报告
第1步 - 分类（杂乱 → 有序）
提示词："将以下客户反馈按类型分类：功能需求、Bug报告、
体验抱怨、正面评价。每条标注类别和关键词。"
输入：[50条客户反馈原文]
输出：分类后的反馈列表
第2步 - 聚合（散点 → 趋势）
提示词："分析以下分类后的反馈，找出 Top5 高频问题，
每个问题统计出现次数和典型原话。"
输入：[第1步的输出]
输出：5个高频问题 + 数据支撑
第3步 - 建议（问题 → 方案）
提示词："针对以下5个高频客户问题，各给出1个改进建议，
包含：问题描述、影响范围、建议方案、预期效果、优先级。"
输入：[第2步的输出]
输出：5条改进建议
第4步 - 排版（内容 → 报告）
提示词："将以下内容整理为正式的产品改进报告，
包含：摘要、数据概览、问题详情、改进计划、时间表。"
输入：[第3步的输出]
输出：完整的产品改进报告 ✅
5.4 任务分解的通用原则
什么时候该拆？
信号1：输出质量不稳定 → 任务太复杂，AI 顾此失彼
信号2：任务有多个独立子目标 → 每个子目标应该单独处理
信号3：中间结果需要人工检查 → 拆开才能在中间插入检查点
信号4：一个提示词超过 500 字 → 可能塞了太多要求
怎么拆？
按阶段拆：收集 → 分析 → 决策 → 执行
按角色拆：调研员收集资料 → 分析师做分析 → 决策者做判断
按输入类型拆：文本处理走一条链，数据处理走另一条链
拆多细？
判断标准：每个子任务的输出应该是”可以独立判断好坏”的。
✅ 好的拆法："总结文章" → "翻译摘要" → "排版"
每步输出都能独立检查质量
❌ 过度拆分："提取第一个关键词" → "提取第二个关键词" → ...
拆太细了，没必要
5.5 技术组合速查
CoT + 少样本 = 给出带推理过程的示例
ToT + CoT = 在思维树的每个分支上用思维链深入
ReAct + CoT = 在每步行动前做深入推理
提示词链 + 角色 = 每一步用不同角色处理
提示词链 + 自我一致性 = 关键步骤跑多次取最优
元提示 + 任意技术 = 让 AI 帮你设计使用特定技术的提示词
5.6 动手练习
练习1：思维树决策
你要选择学习一门新编程语言（Rust/Go/Kotlin），用思维树方法从至少 4 个维度评估，给出推荐。
练习2：ReAct 排查
模拟用 ReAct 排查：“你的网站突然变得很慢”。写出至少 4 轮 Thought → Action → Observation。
练习3：设计提示词链
设计一条提示词链完成：客户反馈文本 → 自动分类 → 生成回复草稿。写出每一步的提示词。
本章小结
✅ 思维树（ToT）：探索多条路径 + 评估 + 回溯，适合复杂决策
✅ ReAct：思考→行动→观察循环，适合调查排查类任务
✅ 提示词链：流水线作业，每个提示词只做一件事
✅ 三种链式模式：顺序链、分支链、循环链
✅ 任务分解原则：按阶段/角色/类型拆，每步输出可独立判断
✅ 技术可以自由组合，威力更大
下一步 → 06_工作效率场景.md