Prompt 工程进阶：让 AI Agent 稳定完成复杂编码任务的四种思维模式

写一个 Python 函数，计算斐波那契数列第 N 项
把这个数组排序
修复这段代码中的空指针异常

帮我在不停服的情况下，把用户认证模块从 Session 模式迁移到 JWT 模式，
历史 Token 要兼容，新旧系统要并行运行两周观察...

问题：{problem}
请按以下步骤分析：
Step 1: 理解问题的核心约束是什么
Step 2: 列出可能的解决方案
Step 3: 评估每个方案的优劣
Step 4: 选择最优方案并说明原因

这个 Bug 的表现是：登录成功率达到 72%，比正常值低了 26 个百分点
相关文件：auth.py, session.py, jwt_handler.py

请按以下步骤做根因分析：
1. 【定位异常点】在什么位置，预期行为和实际行为第一次出现分歧？
2. 【追溯因果链】从异常点向前追溯，谁导致了这个问题？
3. 【识别根因类型】是信息不足、假设错误、还是逻辑缺陷？
4. 【给出修复方案】具体改什么，怎么验证

输出格式：
- 异常点：[文件:行号] 描述
- 因果链：[步骤1] → [步骤2] → [步骤3]
- 根因：[一句话描述]，类型：[信息不足/假设错误/逻辑缺陷]
- 修复方案：[具体代码改动]

# ❌ 模糊的步骤（LLM 可能跳过或合并步骤）
请分析这个问题，然后给出解决方案。

# ✅ 明确的步骤（每个步骤都有产出物）
请按以下步骤分析：
Step 1: 列出可能的原因（至少 3 条）
Step 2: 对每条原因，说明如何验证（需要什么信息/操作）
Step 3: 根据验证结果，排除或确认原因
Step 4: 对确认的原因，给出具体修复方案

Step 1: 列出可能原因
  → 输出：原因列表
Step 2: 对每条原因，说明验证方法
  → 输入：原因列表
  → 输出：{原因: 验证方法} 映射
Step 3: 执行验证，排除不可能的原因
  → 输入：验证方法映射
  → 输出：存活的原因
Step 4: 针对存活原因，给修复方案
  → 输入：存活原因
  → 输出：修复方案

注意：在步骤 1 和 2 中，你的输出是「猜测」，用 [猜测] 标记。
只有在步骤 3 中通过实际验证的，才能移除 [猜测] 标记。
最终结论中不能包含任何 [猜测] 标记。

当前决策点：[描述问题]

探索路径 A：[方案A描述]
  - 优势：...
  - 风险：...
  - 预期结果：...
  - 适用场景：...
探索路径 B：[方案B描述]
  - 优势：...
  - 风险：...
  - 预期结果：...
  - 适用场景：...
探索路径 C：[方案C描述]
  ...

评估维度（按重要性排序）：
  1. [维度A]（权重：X%）
  2. [维度B]（权重：Y%）
  3. [维度C]（权重：Z%）

各路径在评估维度上的得分：
  路径A: {维度A: X分, 维度B: Y分, ...}
  路径B: ...
  路径C: ...

推荐路径：[综合评分最高者]
推荐理由：[不仅要说出结论，还要说明在其他路径的权衡中放弃了什么]

决策：电商系统从单体拆分为微服务，订单服务如何拆分？

路径A - 按业务能力拆分（订单、支付、物流各自独立）
  优势：边界清晰，团队自治性强，独立发布不影响其他服务
  风险：跨服务事务难题（分布式事务、Seata/2PC），分布式锁复杂度高
  预期结果：服务独立性强，但事务一致性需要额外处理
  适用场景：团队规模大（>10人），独立发布需求强烈

路径B - 按读写分离拆分（查询服务 + 写服务）
  优势：技术统一，事务简单（单数据库内），读写分离性能好
  风险：查询服务和写服务仍在同一领域模型，边界仍然模糊
  预期结果：性能提升明显，但架构问题没有根本解决
  适用场景：读多写少（>10:1），一致性要求高

路径C - 先不拆分，优化单体（模块化重构 + 数据库分库）
  优势：风险最低，改动最小，可以逐步演进
  风险：没有解决根本的耦合问题，未来还是要拆，延迟了问题
  预期结果：短期内稳定，但技术债务累积
  适用场景：时间压力大（<3个月），系统稳定优先

评估维度（按重要性排序）：
  1. 业务风险（迁移期间不能影响现有用户）权重 40%
  2. 技术复杂度（团队能否 hold 住）权重 30%
  3. 长期可维护性 权重 20%
  4. 迁移成本 权重 10%

各路径综合得分：
  路径A: 业务风险(2/5) × 40% + 技术复杂度(2/5) × 30% + 长期可维护性(5/5) × 20% + 迁移成本(2/5) × 10% = 2.5
  路径B: 业务风险(4/5) × 40% + 技术复杂度(4/5) × 30% + 长期可维护性(3/5) × 20% + 迁移成本(3/5) × 10% = 3.7
  路径C: 业务风险(5/5) × 40% + 技术复杂度(5/5) × 30% + 长期可维护性(2/5) × 20% + 迁移成本(5/5) × 10% = 4.3

推荐路径：路径C（渐进式优化）
推荐理由：当前团队规模小（<5人），时间窗口有限（<3个月），系统稳定优先。
  路径A 的分布式事务复杂度团队目前无法支撑，路径B 没有根本解决问题。
  建议先用 2 个月做模块化重构 + 数据库分库，第三个季度再评估是否进一步拆分。

当前状态：[描述目前掌握的信息]
目标：[描述要达成什么]
可选行动：[列出可以做的行动]
已尝试：[列出已做过的行动和结果]

--- 循环开始 ---

下一步推理：[基于当前状态，分析下一步应该做什么]
选择行动：[从可选行动中选择一个，说明为什么选这个]
预期结果：[这个行动会得到什么信息]

执行 → 观察结果

新状态：[更新后的状态]
是否达成目标： [是/否]
如果否，继续循环；如果是，结束

--- 循环结束 ---

当前状态：我接手了一个 Python 微服务项目，技术栈未知
目标：找到用户认证相关的核心逻辑在哪里

已尝试：
  - 行动 1: ls -la 查看项目结构
    结果：看到 django/ apps/ tests/ requirements.txt
    推断：这是一个 Django 项目
  - 行动 2: 读取 README.md
    结果：技术栈是 Django 4.2 + PostgreSQL + Redis
    推断：认证可能用 Django 自带的 Session 或 JWT

当前状态：
  - 技术栈：Django 4.2 + PostgreSQL + Redis
  - 项目结构：django/ apps/ tests/
  - 认证方式：需要进一步探索

下一步推理：在 Django 中，用户认证通常在 django.contrib.auth 中，
  或者通过 django-allauth / django-rest-auth 处理。先找 app 目录结构，
  看有没有 accounts、users、auth 相关的 app。

选择行动：ls -la apps/ 或 find . -name "*auth*" 或 grep "login" in views.py
预期结果：找到认证相关的文件

[执行并获得结果...]

新状态：
  - 发现了 apps/auth/ 目录，包含 views.py, models.py, serializers.py
  - 发现了 JWT 相关配置在 settings.py 的 REST_FRAMEWORK 中
  - 没有找到 django-allauth，说明用的是自定义 JWT 实现

已尝试：
  - ls apps/ → 发现了 auth app
  - grep "login" apps/auth/views.py → 找到了 login view
  - 读取 apps/auth/views.py → 看到了 JWT token 生成逻辑

当前状态：
  - 认证核心逻辑在 apps/auth/views.py 的 login() 函数
  - 使用的是 PyJWT 库，token 有效期在 settings.py 中配置
  - 找到了关键文件：views.py, models.py, serializers.py, settings.py

是否达成目标：是（已找到认证核心逻辑的位置）

任务执行结果：[描述最终结果]
预期 vs 实际：[对比预期和实际结果]

反思问题：
1. 如果重新做这件事，我会在哪个步骤改变策略？
2. 我在哪里过度思考了（做了不必要的分析）？
3. 我在哪里思考不足（跳过了应该深入分析的步骤）？
4. 下次遇到类似任务，我会怎么做？

值得记录的模式：[提炼出可以复用的经验]

任务：用 Claude Code Review 这个 PR
PR 内容：
  - auth.py 的重构（从 Session 迁移到 JWT）
  - 新增了 rate limiting 中间件
  - 修改了 API 网关配置

执行结果：提出了 15 条修改建议

预期 vs 实际：
  预期：聚焦高优先级问题，帮助开发者快速改进
  实际：审查范围过广，包含了不必要的性能优化建议

反思问题：
1. 如果重新做，我会先问「这个 PR 的业务背景是什么」
   原因：有些改动看起来奇怪，但可能是业务特殊需求，
   比如 rate limiting 的阈值可能是运维根据实际流量设置的，
   不应该直接建议降低

2. 我在哪里过度思考了：
   花了很多时间分析 rate limiting 的算法复杂度（O(1) vs O(n)），
   但这个 PR 只是引入了基础版本，算法优化是后续的事

3. 我在哪里思考不足：
   没有检查 API 网关配置修改是否和运维的部署流程冲突，
   导致开发者反馈「这个配置要等下周才能发布」

4. 下次遇到类似任务：
   - 先问上下文（业务背景、优先级、后续计划）
   - 区分「必须改」和「建议改」，减少噪音
   - 性能问题要有数据支撑，不要凭感觉说「这里可能慢」

值得记录的 Pattern：
- PR Review 前先问上下文（业务背景 + 优先级）
- 区分「代码规范问题」和「架构设计问题」，前者必须改，后者看场景
- 性能分析要有数据支撑，不要凭感觉

1. 用 ToT 探索多条路径，列出各路径的优劣
2. 选定路径后，用 CoT 详细规划执行步骤
3. 执行过程中，用 ReAct 处理意外情况
4. 完成后，用 Reflexion 复盘

1. 用 ReAct 逐步探索环境，每步都记录推理过程
2. 探索完成后，用 Reflexion 总结学到了什么
3. 把学到的知识抽象为 Pattern，存入记忆系统

1. 先用 CoT 分析已知信息，列出可能的原因树
2. 用 ReAct 逐个验证原因，每个验证都要有「假设-行动-观察」
3. 找到根因后，用 Reflexion 总结这次调试学到了什么

## 任务：多文件代码重构

### Phase 1: 理解与探索（ReAct）
当前状态：[待填写]
目标：在不破坏功能的前提下，重构 {target_modules}
约束：
  - 迁移期间服务不能停
  - 历史数据必须兼容
  - 单元测试覆盖率不能下降

请用 ReAct 方式探索：
1. 读取目标模块的核心文件，理解当前架构
2. 识别模块间的依赖关系（画依赖图）
3. 找出最关键的「不能动的边界」
4. 确定重构的「安全起点」和「危险区域」

### Phase 2: 方案规划（ToT）
基于探索结果，探索三条重构路径：

路径A - 渐进式重构（每次改一个文件，逐步上线）
路径B - 复制增量式（新建模块，流量逐步切换）
路径C - 协议兼容式（保持接口不变，重写内部实现）

请评估每个路径的：
  - 实施风险（1-5分，越高越危险）
  - 回滚难度（1-5分，越高越难回滚）
  - 需要的测试工作量（1-5分，越高越费时）

推荐路径：[从风险和成本角度推荐一个]

### Phase 3: 执行规划（CoT）
选定的路径是：[路径X]
执行步骤：
Step 1: [具体做什么，产出什么，验证什么]
Step 2: ...
Step 3: ...

每个步骤的风险点和缓解措施：
  Step 1 风险：...，缓解：...
  Step 2 风险：...，缓解：...

### Phase 4: 执行与验证（交替使用 ReAct）
按 Phase 3 的步骤执行，每个步骤：
1. 说明要做什么
2. 执行（展示使用的命令/操作）
3. 观察结果
4. 判断是否符合预期
   - 符合则继续下一步
   - 不符合则回退或调整方案后重试

### Phase 5: 复盘（Reflexion）
任务完成后回答：
1. 重构过程中遇到了哪些意外情况？
2. 哪个步骤花的时间超出预期，为什么？
3. 下次类似任务会做什么不同的事？
4. 有没有形成可复用的 Pattern？（如有，请描述并给出适用场景）

遇到复杂推理 → 先用 CoT 设计步骤
遇到多方案权衡 → 在 CoT 基础上加 ToT
遇到环境未知 → 切换到 ReAct 循环
任务完成后 → 运行 Reflexion 提炼经验

Prompt Patterns（在任务规划阶段设计结构）
    ↓
Self-Correction（在执行中发现错误后的即时纠错）
    ↓
Continuous Learning（在时间维度上积累经验）
    ↓
Reflexion（把单次经验提炼为可复用 Pattern）