041、Plan Mode 计划模式：复杂任务的自动规划、步骤分解与执行跟踪

041、Plan Mode 计划模式：复杂任务的自动规划、步骤分解与执行跟踪

从一次翻车现场说起

上周五晚上，我接手了一个遗留系统的重构任务——一个用了五年的订单处理模块，代码里充斥着if-else嵌套，业务逻辑散落在三个不同的Service里。按照以往的习惯，我直接打开CodeX，丢了一句“重构订单模块，用策略模式替换if-else，保持接口兼容”。结果呢？CodeX确实生成了代码，但生成的策略类里居然把订单状态枚举写死了，还漏掉了退款流程的分支。我盯着屏幕看了十分钟，才意识到问题出在哪：我给了它一个“大目标”，但没有告诉它“怎么拆”。

这就是Plan Mode要解决的核心痛点。当你面对一个复杂任务时，直接让AI生成最终代码，就像让一个实习生直接写核心业务——他可能写得出来，但大概率会漏掉边界情况。Plan Mode的本质，是把“我要什么”变成“我们怎么一步步做”。

Plan Mode 到底在做什么

CodeX的Plan Mode不是简单的“先做A再做B”的伪规划。它会在你输入任务后，主动做三件事：

怎么触发Plan Mode

有两种方式。第一种是显式调用：在对话中直接说“使用Plan Mode”或者“规划一下这个任务”。第二种是隐式触发：当你输入的任务描述超过一定复杂度（比如包含三个以上子目标），CodeX会自动切换到Plan Mode。我建议新手用显式调用，因为隐式触发的阈值有时候会误判——比如你只是描述了一个很长的需求，但实际逻辑很简单，它也会强行规划，反而浪费时间。

一个真实的规划案例

上周我处理过一个微服务接口迁移的任务，需求是“将用户模块的REST接口迁移到gRPC，保持现有客户端兼容”。我直接输入了这段描述，CodeX自动进入了Plan Mode。它生成的规划是这样的：

Step 1: 分析现有REST接口的请求/响应结构（依赖：无）
Step 2: 定义gRPC proto文件，保持字段名和类型一致（依赖：Step 1）
Step 3: 生成gRPC服务端桩代码（依赖：Step 2）
Step 4: 实现gRPC服务端逻辑，调用现有业务Service（依赖：Step 3）
Step 5: 编写适配层，将REST请求转换为gRPC调用（依赖：Step 1, Step 4）
Step 6: 编写单元测试，验证接口兼容性（依赖：Step 4, Step 5）
Step 7: 灰度发布，监控错误率（依赖：Step 6）

注意看Step 5的依赖——它同时依赖Step 1和Step 4。这意味着适配层的设计必须同时理解REST接口的输入输出和gRPC服务端的实现细节。如果按顺序执行，Step 5会在Step 4完成后才开始，但Plan Mode允许你提前准备Step 5的代码框架，等Step 4完成后再填充具体逻辑。这种“部分并行”的规划，比单纯的线性步骤要高效得多。

执行跟踪：别让AI自己跑偏

Plan Mode最容易被忽视的功能是执行跟踪。当你确认规划后，CodeX会逐步骤执行，并在每个步骤完成后询问你“是否继续”或“需要调整”。这里有个坑：很多人会直接点“全部执行”，结果AI在Step 3生成proto文件时，自动把字段名改成了驼峰命名（因为gRPC默认推荐驼峰），但Step 1分析出的REST接口用的是下划线命名。等到Step 5写适配层时，字段映射全乱了。

正确的做法是：每执行完一个步骤，检查生成的代码是否符合预期。特别是涉及命名规范、接口协议、数据格式的步骤，一定要手动确认。Plan Mode的“暂停”功能就是为这个设计的——你可以在任意步骤后暂停，修改规划，再继续。

踩过的坑和补救方案

坑1：规划过于理想化
有一次我让CodeX规划一个数据库分表迁移任务，它生成的步骤里居然没有“数据校验”这一步。结果迁移完成后，发现有几条数据因为主键冲突没写进去。后来我养成了一个习惯：在确认规划前，手动添加一个“数据一致性校验”步骤。Plan Mode允许你编辑规划，别怕麻烦。

坑2：依赖分析漏掉隐式依赖
比如“修改调用方”这个步骤，CodeX可能只考虑了接口变更，但没考虑调用方依赖的配置项、环境变量、甚至日志格式。这种隐式依赖很难靠AI自动识别，需要你在规划阶段主动补充。我的做法是：在规划确认后，口头问一句“这个步骤有没有遗漏的依赖？”，然后手动补上。

坑3：执行跟踪的“假成功”
CodeX执行完一个步骤后，会显示“完成”，但有时候它只是生成了代码，并没有验证代码是否能编译通过。比如Step 3生成proto文件后，它不会自动运行protoc编译器检查语法。所以，每个步骤完成后，我习惯手动跑一下对应的编译命令或单元测试。Plan Mode的“验证”功能可以配置自定义脚本，但默认是关闭的——记得在设置里打开。

个人经验：什么时候该用Plan Mode

不是所有任务都需要Plan Mode。简单任务（比如“给这个函数加个日志”）直接对话就行，Plan Mode反而会引入不必要的步骤。我的判断标准是：如果这个任务需要我手动写超过5个步骤的TODO列表，那就用Plan Mode。如果我自己都说不清楚步骤，那AI也规划不好——这时候应该先自己理清思路，再让AI辅助。

另外，Plan Mode特别适合“重构”和“迁移”类任务。这类任务的特点是：目标明确，但步骤多、依赖复杂、容易出错。CodeX的规划能力在这类场景下表现最好，因为它可以基于代码库的静态分析结果（比如函数调用关系、类继承结构）来生成更准确的依赖图。

最后一句

Plan Mode不是万能药，它更像一个“结构化思考的脚手架”。你用它不是为了偷懒，而是为了让自己和AI在同一个频道上思考。下次遇到复杂任务，别急着让AI写代码，先让它给你画一张“地图”——你可能会发现，自己之前忽略的细节，都在那张地图上。