复杂任务分解——Plan → Execute → Verify

为什么需要 Plan 模式

如果你让 AI"重构整个系统的认证模块"，它大概率会在几轮对话后突然中断——不是因为能力不够，而是因为会话超时了。

Qoder 内部内置了会话超时时间。在不使用 Plan 模式的情况下，经过一定数量的交互轮数后，会话会自动结束。这意味着，靠一次性的对话，你根本完不成复杂任务。

Plan 模式就是为了解决这个问题而设计的。它像一个可持续运行的工作流——你给 AI 一个总目标，它自己拆解成子任务，逐个执行，持续进行直到业务目标达成。

Plan 模式 vs 直接写

	直接写	Plan 模式
执行方式	一次性对话	工作流式持续运行
任务范围	适合单步、简单的操作	适合多步骤、跨文件的复杂任务
会话限制	有轮数超时限制	可持续直到任务完成
状态保持	容易丢失上下文	子任务间自动保持上下文
可审查性	改完直接生效，过程不透明	每一步可审查、可回滚

一句话总结：简单的事直接写，复杂的事用 Plan。

在产品层面，Growth AIOS 的触发器系统进一步扩展了这个思路——不仅可以手动触发工作流，还可以通过文件监控、定时任务等方式自动触发：

注意： Plan 模式适合跨多文件、需要多步推理的中大型任务。对于个人开发者来说，大多数日常编码用不上它——除非你要跑一个执行一晚上的后台任务。开启 Plan 模式后，AI 会保持长时间持续对话，这会显著增加 Token 消耗。用之前想清楚：这个任务真的需要 Plan 模式吗？

如何启用 Plan 模式

Plan 模式已经内置在 Qoder 的智能体模式中，不需要额外配置。有两种方式触发它：

自动调用： 智能体模式会根据你的请求自动判断是否需要规划。当任务涉及多文件修改、重构或高风险变更时，Qoder 会自动进入规划流程。

显式调用： 你也可以在输入框中直接输入 /plan 命令，后跟你的任务描述，强制进入规划模式。显式调用让你主动控制是否启用规划，而不是让 AI 来判断。

两种方式产出的结果完全一样，区别只在于谁来做这个判断。

操作流程

Plan 模式的工作流程分为六个阶段：

1. 描述任务

用自然语言描述你要做什么。好的描述包含三个要素：

• 目标： 要实现什么功能或解决什么问题
• 范围： 涉及哪些模块或文件（可选）
• 约束： 不能破坏什么、兼容性要求等

例如 case 2 中的导出功能需求，可以直接写成提示词给 Plan 模式处理。

2. 生成计划

Qoder 会分析你的需求和项目上下文，生成一份结构化计划，包含目标、技术方案、实施步骤、验收标准等。这个阶段不会修改任何文件——产出仅是一份可审阅的计划。

3. 审阅与调整

执行前仔细看一遍计划。你可以：

• 直接编辑计划文本
• 通过对话让 Qoder 调整（如"最后加一步更新文档"）
• 确认没问题后进入下一步

这对应第一章中提到的人机协作原则——AI 出方案，人做决策。

4. 启动执行

确认计划后，Qoder 开始按步骤执行。每个步骤的状态会实时显示在聊天底部（未开始 / 进行中 / 已完成）。根据你的设置，终端命令或 MCP 工具调用在执行前可能还需要你手动确认。

5. 执行中调整

执行过程中如果发现问题，可以随时暂停、在聊天中说明新的要求，Qoder 会更新计划后继续。对于测试失败、依赖缺失等阻塞性问题，Qoder 会在对话中明确指出阻塞点，并规划下一步。

6. 收尾与回顾

所有步骤执行完毕后，Qoder 会按步骤总结完成了哪些工作（如每个步骤具体修改了哪些文件）。你可以结合 diff 视图或本地测试，对最终结果进行代码评审。如有后续需求，可以开始一个新的 Plan 流程继续迭代。

使用示例：用 /plan 开发导出功能

结合 case 2 的场景，在 Qoder 智能体模式中输入：

/plan 为数据看板页面新增"导出报表"功能。后端新增导出 API，格式 CSV，仅管理员可导出。前端看板右上角添加导出按钮和下载逻辑。
约束条件：不要改动现有 API 的响应格式，保持向后兼容。

Qoder 收到后，会先分析需求和项目上下文，生成一份结构化计划，大致如下：

# 实施计划

## 目标
为数据看板页面新增 CSV 导出功能，仅管理员可用

## 实施步骤
1. 后端：创建导出 Service
   - 查询看板数据→序列化为 CSV→写入响应流
   - 权限校验：检查当前用户角色是否为 Admin
2. 后端：在 Controller 中注册导出路由
   - GET /api/dashboard/export
3. 前端：添加导出按钮和下载逻辑
   - DashboardPage 右上角新增导出按钮
   - 调用导出接口，处理文件下载
4. 联调验证

## 验收标准
- 管理员点击导出按钮→下载 CSV 文件
- 非管理员点击导出按钮→提示无权限
- 所有现有接口响应格式不变

审阅计划没问题后，在聊天中确认执行，Qoder 就会按步骤开始工作。每个步骤完成后，聊天底部会显示进度更新。如果某一步出了问题（如测试失败），直接在聊天中说明情况，Qoder 会调整计划后继续。

从输入需求到拿到结果，你只需要做三件事：写提示词 → 审阅计划 → 确认执行。中间的所有代码编写、文件修改、命令执行都由 Plan 模式自动完成。

为什么需要任务分解

即使有了 Plan 模式，你也不能只给一句"把接口统一迁移了"就指望它自动完成。AI Agent 的能力依然有边界——把一个 Agent 搞不定的大任务，拆成多个 Agent 能搞定的小任务，才是 Plan 模式正确的使用方式。

每个小任务的目标明确、范围可控、结果可验证。

Growth 产品线的接口统一迁移重构案例，就是这一原则的典型应用。

案例1：接口统一迁移重构

任务背景

Growth 产品矩阵的多个模块使用了不同风格的 API 接口：有 RESTful、有 RPC 风格、有混合模式。需要统一迁移到 RESTful 规范。

任务分解过程

[大任务] 接口统一迁移重构
  │
  ├── [子任务 1] 接口清单梳理
  │   目标：列出所有需要迁移的接口
  │   工具：grep + glob 搜索代码库
  │   产出：接口映射表
  │
  ├── [子任务 2] 接口定义迁移
  │   目标：将 Controller 中的接口定义改为 RESTful
  │   工具：edit / Write
  │   产出：改完的 Controller 文件
  │
  ├── [子任务 3] 客户端调用适配
  │   目标：更新前端和服务间调用的接口地址
  │   工具：search + edit
  │   产出：改完的调用方代码
  │
  └── [子任务 4] 验证
      目标：确认所有接口调用正常
      工具：Browser Agent + 终端运行测试
      产出：测试通过报告

为什么这样拆

每个子任务都有明确的三要素：

子任务	Plan（目标）	Execute（工具）	Verify（验收）
接口清单梳理	列出全部接口	grep/glob	清单完整无遗漏
接口定义迁移	改为 RESTful	edit/Write	路由符合规范
客户端调用适配	更新调用地址	search/edit	地址映射正确
验证	确认正常	Browser/Test	全部测试通过

案例2：跨端新功能并行开发

任务背景

看板页面需要新增"导出报表"功能。涉及后端新增导出 API、前端新增导出交互、前后端都需要更新的类型定义，以及权限校验。

任务分解过程

[大任务] 看板导出功能
  │
  ├── [子任务 1] 统一类型定义（基础，优先执行）
  │   目标：定义导出请求/响应的 TypeScript 类型
  │   工具：Write / edit
  │   产出：types/export.ts
  │
  ├── [子任务 2] 后端 API 实现（可与子任务 3 并行）
  │   目标：实现导出 Controller + Service + 路由注册
  │   工具：edit / Write
  │   产出：新增及修改的后端文件
  │
  ├── [子任务 3] 前端交互实现（可与子任务 2 并行）
  │   目标：添加导出按钮、进度提示、下载处理逻辑
  │   工具：edit / Write
  │   产出：改完的前端组件 + hooks
  │
  └── [子任务 4] 端到端验证
      目标：按钮能点、文件能下、权限拦截正常
      工具：Browser Agent + 终端运行测试
      产出：测试通过报告

为什么这样拆

这是 Plan 模式处理跨层任务的典型结构：

• 子任务 1（类型定义）是所有后续工作的契约基础。它的改动量最小、风险最低，适合最先固化和审查。
• 子任务 2 和 3 没有相互依赖——只要接口契约确定了，前后端可以独立并行开发。Plan 模式会分别执行，互不干扰。
• 子任务 4 是集成验证。只有在前面的任务都完成后，才需要执行这一步。
• 如果某个子任务执行失败（如后端 API 测试没通过），Plan 模式可以只回滚或重试该子任务，不影响其他已完成的工作。

两种任务依赖模式

从两个案例可以看出，复杂的开发任务通常由两种依赖模式组成：

依赖模式	特征	示例
顺序依赖	后一个任务必须等前一个完成	类型定义 → 后端实现；后端实现 → 端到端验证
并行独立	多个任务互不依赖，可同时执行	后端实现 ↔ 前端实现

Plan 模式的自动任务分解会识别这两种模式：先处理顺序依赖中的前置任务，再并行执行独立任务，最后做集成验证。

任务分解的原则

1. 粒度控制

好的子任务应该在一个 diff 中看清影响范围。如果一步改了 20 个文件，说明粒度太粗了。

粒度	特征	风险
太粗	一步改十几个文件	影响面大，难以审查和回滚
太细	一步只改一行	步骤数爆炸，总效率低
适中	一步改 3-5 个文件	影响范围清晰，可独立验证

2. 顺序依赖

子任务之间应尽量减少依赖。如果任务 B 必须在任务 A 之后执行，确保 A 的产出物（接口文档、数据模型）在 B 执行前已经固化。

3. 可验证性

每个子任务必须有一个明确的"完成"标准。不能量化的子任务说明拆得不够细。

---

Growth AIOS 产品参考

以下为 Growth AIOS 产品中对应的触发器管理界面截图：