大任务拆解与迭代式推进

大任务一次性交付往往改动面大、测试不充分、审查困难、回退成本高。把它拆成一系列独立、可验证、可回退的小步，再按依赖顺序迭代推进，是代理协作中控制复杂度的核心方法。本节给出拆解标准、排序方法和迭代节奏。

一、为什么要拆，而不是一次做完

• 风险可控：每步影响面小，出错容易定位和撤销。
• 审查可行：小步 diff 清晰，便于逐轮用 /diff 与测试把关。
• 反馈及时：早发现方向偏差，避免在错误路线上累积大量改动。
• 结果可积累：每步都能形成可保留的成果，不会因中途失败全部作废。

二、合格小步的四个标准

标准	含义	不满足时的表现
独立可验证	该步完成后能用测试/构建/具体行为判定成败	必须等全部做完才知道对错
边界清晰	涉及文件与职责范围明确，不夹带无关改动	一步里混入多个不相关修改
可回退	即使撤销也不破坏整体可运行状态	中途状态无法单独保留
依赖有序	先做被依赖的基础步，再做上层功能步	先改界面后补底层，反复返工

三、常用拆解维度

• 按层次：先数据/模型与类型，再业务逻辑，最后界面与文案。
• 按数据流：输入解析 → 核心处理 → 输出/展示，逐段打通。
• 按用户旅程或功能闭环：先跑通最小主路径（happy path），再补异常分支与边界。
• 按风险高低：先低风险、易验证的基础整理，再动高风险核心逻辑。
• 先骨架后细节：先建立结构与接口约定，再填充实现与优化。

四、迭代推进节奏（六步循环）

1. 整体计划：用 /plan 让代理先给出任务分解与步骤顺序，确认后再执行。
2. 第一步最小实现：选最基础、可验证的一步，先跑通主路径。
3. 审查与验证：看范围、读关键 diff、跑测试与构建，确认该步达标。
4. 确认成果：合格则保留，再进入下一步；不合格先在本步收敛。
5. 小步沉淀：按团队节奏在合适节点整理提交，让每步成果可追溯、可回退。
6. 逐步扩展：依次补异常处理、边界条件、文档与测试，避免一次铺开。

五、拆解示例：把一个复合需求拆成序列

以"为某工具增加缓存并重构相关函数、补充测试与说明"为例，不直接整体下达，而拆为：

步骤	内容	验收方式
1 现状梳理	定位目标函数与现有测试，说明调用关系	输出影响范围与计划，不改动代码
2 抽取稳定边界	先做不改变行为的小范围整理	现有测试全绿、行为不变
3 主路径缓存	实现最小缓存主路径	目标场景行为正确、测试通过
4 边界与失效处理	补过期、空值与异常输入分支	新增边界用例通过
5 测试与说明收尾	补测试覆盖与必要注释/文档	测试与构建整体通过

六、识别范围蔓延

• 代理在实现中不断追加新文件、新依赖或新功能，超出原始目标时，应明确叫停并拉回当前步骤。
• 若发现需求本身包含多个独立交付物，应拆成多个任务分别推进，而不是并入一个长会话。
• 上下文过长时用 /compact 保留当前步骤要点；切换到新任务用 /clear 并依赖 CLAUDE.md 续接。