复杂任务先出计划再动手：Plan Mode 的正确用法

前几篇文章里，Reasonix 给人的印象是"AI 直接干活"——你说一句话，它就读文件、写代码、跑命令，一气呵成。

但如果任务太复杂呢？比如"重构整个用户模块"——你敢让 AI 直接上手就改吗？

Plan Mode 就是解决这个问题的：先让 AI 出一份书面计划，你审核通过后，它再动手。

一、为什么需要 Plan Mode？

先讲一个真实场景。

你想让 AI 做这个任务：

"帮我把这个单体应用拆成微服务架构"

如果你直接让 AI 开干，它可能会： 1. 创建一个新的目录结构 2. 开始移动文件 3. 修改引入路径 4. 改了 10 个文件之后发现方向不对 5. 你让它回退，但这 10 个文件的改动需要手动撤销

问题出在哪？ AI 没有"全局规划"的能力——它是一步步推理的，第一步做完才想第二步。对于复杂任务，这会导致：

• 方向错了：AI 理解偏差，走到半路才发现
• 改了不该改的：AI 不知道怎么拆分，直接开始改代码
• 浪费 token：走了弯路才发现不对，前面的 token 全白费

二、Plan Mode 有两种打开方式

方式一：手动开启（推荐新手）

在 reasonix chat 里，任何时候输入：

/plan

AI 就会暂停当前的工作模式，切换到"只读规划"模式。

方式二：自动开启（进阶）

[agent]
auto_plan = "on"

开启后，Reasonix 会自动判断任务的复杂程度。如果看起来比较复杂，会自动进入 Plan Mode。

你也可以设置一个便宜的模型来做分类判断，省下大模型的 token：

[agent]
auto_plan = "on"
auto_plan_classifier = "deepseek-flash"

这样每次只花不到 ¥0.001 来判断"这个任务要不要走计划模式"。

三、Plan Mode 的完整流程

第一步：AI 只读探查

进入 Plan Mode 后，AI 只能使用只读工具——可以读文件、搜索代码、查看目录，但不能写文件、不能执行命令。

你：/plan
你：帮我把这个单体应用拆成微服务架构

AI：好的，我先看一下现有代码结构。
    → read_file cmd/main.go
    → ls internal/
    → grep "database" internal/**/*.go
    → read_file internal/handler/user.go
    → read_file internal/service/user.go
    ……

AI 会花时间读代码、理解架构，但绝不会动任何文件。

第二步：AI 输出书面计划

读完之后，AI 会输出一份结构化的计划：

📋 重构计划：单体应用 → 微服务

## 当前架构分析

当前是典型的单体三层架构：
- handler 层：处理 HTTP 请求
- service 层：业务逻辑
- model 层：数据模型

所有模块共享同一个数据库连接，没有服务边界。

## 建议拆分方案

### 第一阶段：拆出用户服务（预计影响 8 个文件）
1. 新建 internal/user-service/ 目录
2. 从 internal/handler/user.go 提取用户 handler
3. 从 internal/service/user.go 提取用户业务逻辑
4. 新建 internal/user-service/model/ 数据模型

### 第二阶段：拆出订单服务（预计影响 6 个文件）
……

### 第三阶段：API 网关（预计 3 个新文件）
……

## 风险提示
- 用户服务和订单服务共享了数据库事务，需要先处理分布式事务
- 当前测试覆盖率 60%，建议拆完后补测试

第三步：你审核计划

这时候你来决定：

• 同意：继续执行，AI 开始动手改代码
• 修改：跟 AI 讨论调整方案，比如"用户服务不要单独拆，先拆订单服务"
• 否决：放弃这个方案，换个思路

你：第一阶段可以，但订单服务先不拆，等用户服务稳定了再拆。

AI：好的，调整计划。
    第一阶段只拆用户服务，第二阶段暂停。
    我现在开始执行？
    
你：可以，开始吧。

第四步：AI 执行计划

你批准后，AI 获得写入权限，开始按计划改代码。每改完一步，会在终端显示进度：

执行计划：第一阶段——拆出用户服务

[1/4] 创建目录结构
  → mkdir -p internal/user-service/model

[2/4] 提取用户 handler
  → write_file internal/user-service/handler.go

[3/4] 提取业务逻辑
  → write_file internal/user-service/service.go

[4/4] 更新 main.go 引入新服务
  → edit_file cmd/main.go

每一步前后，AI 还会自动运行测试确认没改坏：

→ go test ./internal/user-service/...
  ✓ ok 0.32s

→ go test ./...
  ✓ ok 1.45s

四、结合 todo 追踪进度

在 Plan Mode 执行过程中，/todo 特别有用。

查看当前进度

你：/todo

AI：📋 重构进度
    ├─ 第一阶段：拆出用户服务
    │  ├─ ✅ 创建目录结构
    │  ├─ ✅ 提取 handler
    │  ├─ ✅ 提取业务逻辑
    │  └─ ⏳ 更新 main.go
    ├─ ⏸ 第二阶段：拆出订单服务（暂停）
    └─ ⬜ 第三阶段：API 网关

complete_step：证据驱动的进度确认

这是 Reasonix 一个独特的设计——每一阶段的完成都需要带证据确认。

AI 完成一个子任务后，不应该直接跳到下一步，而是先出示证据：

AI：第一阶段完成。

证据：
1. ✅ go test ./internal/user-service/... 通过
2. ✅ go build ./cmd/reasonix 编译通过
3. ✅ 新代码无 lint 警告

是否确认进入第二阶段？

这样你就不会在事后才发现"哦，原来刚才那一步把测试搞坏了"。

五、Plan Mode vs 直接干：什么时候用

不是所有任务都需要 Plan Mode。选错了反而浪费时间。

不需要 Plan Mode 的场景

# 这些直接干就行
reasonix run "给这个函数加上错误处理"
reasonix run "把 README 里的 typo 修一下"
reasonix run "格式化所有 Go 文件"

特点：

• 改动范围明确（1-2 个文件）
• 风险低（改坏了也容易恢复）
• 不需要"设计方案"

推荐用 Plan Mode 的场景

# 这些最好先出计划
/plan
你：重构用户认证模块，从 Session 改成 JWT
你：设计数据库分表方案
你：把这个项目升级到最新的框架版本

特点：

• 改动范围大（多个文件、多个模块）
• 有设计决策（用什么方案？怎么拆分？）
• 风险高（改坏了影响面大）

快速判断表

六、完整实战：一个 Plan Mode 的完整会话

下面是一个真实风格的 Plan Mode 对话，让你感受全流程：

你：帮我重构这个项目的日志系统，从 logrus 迁移到 slog

你：/plan

AI：好的，我先看一下现有的日志使用情况。
    → grep "logrus" internal/**/*.go
    → grep "log\." internal/**/*.go
    → head -20 go.mod
    → read_file internal/logger/logger.go
    
    分析完成。以下是我的计划：

📋 日志系统迁移计划

当前状况：
- 使用 logrus，涉及 23 个文件
- 有自定义的日志格式化器（internal/logger/logger.go）
- 日志初始化在 cmd/main.go

建议方案：
1. 创建 internal/logger/slog.go：封装 slog，保持接口兼容
2. 逐个文件替换 logrus 调用（23 个文件）
3. 删除 logrus 依赖
4. 更新 go.mod

风险：
- 替换过程中可能出现编译错误
- 建议分批替换，每批 5 个文件后跑一次测试

是否开始执行？

你：可以，但先替换 handler 目录下的文件，其他的我来。

AI：好的，那我先处理 handler 目录下的 6 个文件。
    
    [1/6] → edit_file internal/handler/user.go
    [2/6] → edit_file internal/handler/order.go
    [3/6] → edit_file internal/handler/product.go
    [4/6] → edit_file internal/handler/cart.go
    [5/6] → edit_file internal/handler/payment.go
    [6/6] → edit_file internal/handler/shipping.go
    
    → go test ./internal/handler/...
    ✓ ok 0.15s

    6 个文件已替换，测试通过。要处理其他目录吗？

你：/todo

AI：📋 迁移进度
    ├─ ✅ handler/ 目录（6/6 文件）
    ├─ ⬜ service/ 目录（8 个文件）
    ├─ ⬜ model/ 目录（4 个文件）
    ├─ ⬜ cmd/ 目录（1 个文件）
    └─ ⬜ 清理 logrus 依赖

七、auto_plan 的最佳设置

[agent]
# 推荐设置：新手先用 off，熟悉后改成 on
auto_plan = "on"

# 用便宜的 flash 模型做分类判断
auto_plan_classifier = "deepseek-flash"

不同阶段的推荐配置：

/auto-plan on     # 开启自动计划
/auto-plan off    # 关闭自动计划

比改配置文件方便。

写在最后

Plan Mode 是 Reasonix 区别于其他 AI 编程工具的一个关键设计。

Cursor 和 Claude Code 也有类似的功能，但 Reasonix 的 Plan Mode + complete_step 证据确认 + /todo 进度追踪组合起来，形成了一套完整的复杂任务管理方案。

简单任务直接跑，复杂任务先计划。这是你用 Reasonix 效率最高的姿势。

进阶篇到此全部结束。 从第 05 篇到第 08 篇，我们覆盖了：

• MCP 插件生态：让 AI 触达外部世界
• 斜杠命令 + @ 引用：精准指挥 AI
• Skills 技能系统：让 AI 按你的方式工作
• Plan Mode + todo：复杂任务不翻车

你可能会想：能不能让便宜的 flash 做规划、贵的 pro 只负责执行？这样既省钱又保证质量。Reasonix 还真支持这个——两个模型各跑各的会话，缓存互不干扰，各自保持高命中率。

关注我，带你用最少的钱，薅最狠的 AI 羊毛。

📌 互动话题：你遇到过什么"AI 直接上手搞砸了"的场景？如果当时用了 Plan Mode 会不会不一样？评论区聊聊。