复杂任务先别开工：把需求变成可执行计划

“帮我重构一下这个模块。”

这类需求足够让 Codex 开始搜索代码，却不足以支撑一次中等复杂度的交付。重构要解决什么问题，哪些行为不能变化，涉及几个模块，做到什么程度算结束，都还没有答案。直接开工后，每一次新发现都可能把任务带向另一个方向。

小编现阶段的判断是：复杂任务里的计划，不是提前猜出所有步骤，而是把目标、未知项、依赖、完成条件和当前状态摆到台面上。这样 Codex 才能知道下一步，用户也能看出它为什么继续、为什么调整，以及究竟做到哪里。

一、什么任务值得先停下来规划

给一个变量改名、修正文案、补一个明确断言，通常没有必要先写计划。目标、改动点和验证方式都很清楚，执行与检查可能比规划本身还短。

任务出现下面这些特征时，先规划通常更划算：

• 需求只描述了结果，没有说明现状和限制；
• 需要跨多个文件、模块或技术阶段；
• 后一步依赖前一步的调查结果；
• 存在多个可行方向，选择会改变改动范围；
• 完成与否不能通过一个明显结果判断；
• 中途很可能出现新证据，需要调整原路线。

判断时不看文件数量。修改一个配置文件也可能影响整套发布链路；跨三个文件的机械替换反而可以直接完成。更有用的问题是：执行中是否存在会改变后续动作的未知项，任务结束时是否需要多份证据才能说明完成。

本文用一份可读的 Markdown 计划说明方法。这是项目自己的工作产物，不依赖 Codex 某个界面是否提供“计划”按钮。产品界面变化了，目标、依赖和状态仍然可以留在仓库里核对。

二、先把一句需求拆成四种信息

计划先处理输入，再安排步骤。需求里混在一起的事实、假设、未知项和用户选择，需要先分开。

假设有这样一个简化需求：

把用户模块重构得更容易维护，接口行为不要变化。

目前能确认的只有目标倾向和一个约束。至于“难维护”体现在哪里、接口范围有哪些、测试能否覆盖现有行为，都需要回到仓库调查。

可以先写成下面的工作区：

“当前假设”不能换一种写法就变成事实。若只凭目录名猜测职责混杂，后续计划应先安排只读调查，暂缓创建拆分类和迁移代码的步骤。

2.1 目标要描述变化后的状态

“完成重构”只是动作名称。更可执行的目标会说明对象、预期变化和保持不变的部分，例如：

在不改变用户模块公开行为的前提下，分离当前已经确认的职责边界，使修改其中一类逻辑时不再同时触碰无关实现，并保留现有回归检查。

这句话尚未给出最终方案，但已经能筛掉无关动作。某个改动若既没有分离已确认职责，也没有帮助保持行为，就不属于当前目标。

2.2 非目标负责挡住“顺手优化”

复杂任务很容易在调查时发现旁支：旧依赖可以升级，命名可以统一，测试框架也该换。它们可能都有价值，却会扩大本次任务。

非目标可以直接写：

• 不新增用户业务功能；
• 不更换测试框架；
• 不处理目标模块之外的历史命名问题；
• 不发布或部署。

非目标只限定当前任务，并不否定这些事情以后再做。哪些范围变化需要停下来重新确认，留到下一篇讨论。

三、让阶段由依赖关系决定

需求边界清楚后，再安排阶段。阶段不应只是“第一步、第二步”的时间顺序，每一段都要说明它依赖什么、产出什么，以及什么条件满足后才能进入下一段。

对于上面的重构任务，可以形成这样的骨架：

阶段	依赖	主要产物	阶段完成条件
现状调查	已确认的目标与非目标	调用入口、职责分布、测试与风险清单	关键判断都有文件或测试依据，未知项已收敛到可决策范围
方案收敛	现状调查完成	改动边界、保留行为、受影响文件和回退思路	方案能对应目标，未把非目标带入范围
实施修改	方案与依赖已明确	最小充分代码改动及同步调整	计划内改动已落盘，新发现已回写计划
阶段检查	实施完成	与当前风险对应的检查结果	本阶段约定的证据齐全，失败项有明确状态

表里的“阶段检查”只说明计划需要什么证据，不展开测试层次和独立审查。如何从风险反推验证组合、怎样形成最终工程结论，是第四章的任务。

3.1 依赖必须指向可检查的产物

“先理解代码，再开始修改”仍然太虚。怎样才算理解，下一阶段拿什么继续，都没有说明。

把依赖写成产物后，关系会清楚很多：方案阶段依赖调用入口和状态流转图；实施阶段依赖已确定的改动文件与保持行为清单；阶段检查依赖实际差异和风险列表。接手者不必复述整段对话，只要核对这些文件或记录是否存在、内容是否够用。

3.2 风险会改变阶段顺序

风险会改变计划顺序。公开接口缺少回归测试，意味着调查阶段需要先找到可观察行为；生成代码混在模块中，意味着方案必须区分来源文件和派生产物；工作区已有用户改动，意味着实施前要先解析重叠范围。

计划里的风险至少要写清三件事：触发条件、可能影响、当前处理方式。例如：

具体用什么工具、需要什么权限来处理风险，属于 02-03 的范围。本文只要求风险能够影响阶段和下一步。

四、完成条件要能改变状态

很多计划有步骤，却没有状态判断。于是“代码已经改了”“命令跑过了”“还差一点”都可能被写成完成。

一个实用的阶段状态可以保持简单：

• pending：依赖尚未满足，或还未开始；
• in_progress：当前正在处理；
• completed：阶段完成条件已经有对应产物支撑；
• blocked：缺少继续所需的事实、输入或外部条件。

这组名称只是本文示例，不代表 Codex 的固定状态协议。仓库已有领域状态时应沿用真实来源。当前 JVS 项目的 topic.md 就使用 planned、drafted、reviewed 等文章状态，因为它需要表达“已规划”“草稿完成”和“独立审阅完成”的差别。

状态变化必须对应证据。以 JVS 项目为例，文章从 planned 进入 drafted，依据是目标正文已经写入、二次自审完成，且正文与 topic.md 的状态一致；进入 reviewed 还需要独立审阅报告。状态字段很短，背后仍然要有产物。

完成条件也不要写成“质量良好”“逻辑清晰”。这些词无法直接检查。更具体的写法是：

• 目标文件已经创建，路径与规划一致；
• 明确列出的内容要点都在正文中得到实质回答；
• 无法核验的事实已标为待验证；
• 指定自审完成，正文和状态文件重新读取一致。

这份清单只用于当前写作任务，把它的完成口径翻译成可检查对象。

五、计划要跟着证据变化

静态计划最危险的地方，是它看起来仍然有秩序。调查已经推翻了原假设，后面的阶段却照旧执行；任务表每项都被勾选，实际产出已经偏离最初目标。

更新计划时，建议保留三类变化：

• 事实变化：新读到的代码、测试或文档改变了原判断；
• 范围变化：目标或非目标发生变化；
• 执行偏差：实际产物、顺序或依赖与原计划不同。

例如，调查后发现用户模块本身职责并不混杂，维护问题来自共享缓存层。此时不应该把“拆分用户模块”硬做完。计划要把原假设标为已推翻，记录新证据，并重新判断目标对象。原阶段为何失效应该留在变更记录里，避免下一次又从旧假设出发。

一次更新可以很短：

记录“下一步”时，只选依赖已经满足的最小动作。任务还有十个阶段，不代表 Codex 此刻需要同时推进十件事。

六、用当前 JVS 项目看一份可追踪计划

当前系列本身就是一个可核验的计划实例。topic.md 记录了系列目标、内容边界、五个章节、十二篇文章、前置依赖、文件路径和文章状态。它没有把十二篇正文提前写出来，而是先给每篇文章一个清晰接口。

把这个实例压缩成任务计划，大致如下：

这份示例只使用磁盘上可以核对的规划和状态，没有把聊天里的“应该差不多”当成进度。读者迁移到代码任务时，可以替换目标、阶段与产物，但应保留同样的事实链：当前状态从哪里读，依赖由什么证明，完成条件对应什么产物。

一份计划能否工作，不看它有多少行，而看我们能不能据此回答四个问题：现在为什么做这一步，下一步依赖什么，什么证据会改变原计划，达到什么条件才能更新状态。

回答不出来，计划仍然只是愿望清单。回答得出来，Codex 才有机会在复杂任务里持续推进，避免每一轮都重新猜一次“接下来做什么”。