复杂需求的拆解与规划

大需求不拆，Codex 必然翻车

直接丢给 Codex 一个「给项目加导出功能」这种大需求，它大概率会乱：上下文爆炸、顾此失彼、做出来的不合你要的。拆解复杂需求，是让 Codex 稳定处理大任务的前提。

这一节学「怎么把一个复杂需求拆成可执行的步骤」。

---

为什么要拆

一个复杂需求直接做，有三个问题：

• 上下文爆炸：一次要处理的东西太多
• 不可控：不知道它会先做什么、做到哪
• 难验证：做一半，你不知道对不对

拆开后：每步小、可控、可验证，步步为营。对 file-lib 的 v2.0「文件监听」功能，如果你直接说「加个 watch 功能」，Codex 要从哪开始、做到哪算完、中途对不对，全都模糊。拆开之后，每一步你都能验收。

---

拆解的思路

把大需求拆成「可独立完成、可独立验证」的步骤。以一个「加导出功能」为例：

目标：为项目增加导出功能
拆解：
1. 定义导出格式与字段（做什么格式、导出哪些字段）
2. 后端：生成导出文件接口（输入条件，输出文件）
3. 前端：加导出入口 + 下载（按钮、调用、下载）
4. 测试：覆盖正常导出、空数据、异常

每步都能「做完 + 验证」，而不是一个大黑盒。对应 file-lib 的「文件监听」v2.0，拆解思路是这样：

目标：file-lib 支持 watch 文件监听
拆解：
1. 定义监听 API（监听哪些事件？改、删、增？回调签名？）
2. 核心：实现监听引擎（用 fs.watch，跨模块检测）
3. CLI：接入 --watch 参数（bin/cli.js 加参数）
4. 测试：覆盖文件新增/修改/删除、目录不存在

四步，每步都是「能独立完成 + 能独立验证」的一块。

---

每个子任务也要描述清楚

拆出来不等于结束，每个子任务要给 Codex 描述清楚（沿用三要素）：

子任务2：后端导出接口
【目标】实现 GET /export/orders 生成订单导出文件
【输入】start_date, end_date
【输出】CSV 文件，字段：订单号, 金额, 时间
【约束】金额用分存储，导出时转元；数据量大时分页处理
【验收】调用接口能下载到正确 CSV

拆解 + 每个子任务说清，Codex 才做得稳。对 file-lib 的「监听引擎」子任务：

子任务2：file-lib 监听引擎
【目标】新增 lib/watch.js，提供 watch(dir, cb) 监听目录变化
【输入】dir：目录路径；cb：回调函数
【输出】监听器对象，含 close() 停止监听方法
【约束】基于 fs.watch；目录不存在时返回错误而非崩溃；
        支持 file-change / file-add / file-delete 三种事件
【验收】新建/修改/删除文件时，cb 被正确触发

五要素齐全，Codex 拿到就知道「做成什么样算对」。

---

定好顺序：依赖关系

子任务之间往往有依赖，要排好顺序：

• 先做基础的：定义格式 → 再做后端 → 再做前端
• 后做依赖前做的：前端要等后端接口先定

1 定义格式 → 2 后端接口 → 3 前端入口 → 4 测试

顺序清楚，Codex 不会「前面没定就做后面」。file-lib 的 watch 功能依赖关系是：先定 API（子任务1）→ 再做核心引擎（依赖 API 定义）→ 再 CLI 接入（依赖引擎）→ 最后测试（依赖全部）。写清楚依赖，Codex 就不会「引擎还没写就去做 CLI」。

---

一个可复用的拆解模板

【总目标】……
拆解：
1. 【子目标】…… 【产出】…… 【验收】……
2. 【子目标】…… 【产出】…… 【验收】……
…
【顺序】1 → 2 → 3（依赖关系）

套模板，复杂需求也能拆得清清楚楚。这也是你下一节复盘时要沉淀成资产的东西——把「拆解模板」固化下来，复杂任务直接套。

---

常见坑：拆解时把「动词」写得太含糊

拆解常犯的错是：子任务写得很含糊，比如「子任务2：优化性能」——「优化」不是可验收的结果。Codex 做到什么程度算「优化完」？没法验收，就会无限做下去或随便糊弄。

避坑办法：每个子任务的动词必须是可测量的结果，而不是过程描述。对比一下：

✗ 子任务2：优化 watch 引擎的性能
✓ 子任务2：watch 引擎在监听 1000 个文件时，内存占用 < 50MB，
          事件触发延迟 < 100ms（写一个 benchmark 测试验证）

把「优化」改成「达到某个可测指标」，Codex 才知道做到哪算对、你才知道怎么验收。含糊的动词 = 无法验收 = 拆解白拆。

---

小结

1. 大需求不拆，Codex 必翻车：上下文爆炸、不可控、难验证
2. 拆成「可独立完成、可独立验证」的步骤
3. 每个子任务描述清楚（目标/输入/输出/约束/验收）
4. 排好依赖顺序，别前面没定做后面

下一节，讲高质量提示词与反馈循环。