大任务怎么拆给 Claude Code

Claude Code 大任务拆分教程：任务越大越不能直接执行，要先拆成可验证的小任务，再逐个完成、验收和收口。

不要这样说

大任务不是不能做，而是不能一口气做。你要先让 CC 拆成可验证的小任务，每个小任务都能单独计划、执行、验收。

帮我做一个完整登录注册系统。

这句话会让任务目标、范围、验收、风险全部混在一起，CC 很容易扩大范围。

可以先判断任务是否过大：

/plan

我想完成一个较大的功能：【写功能名称】。

请先不要写代码。
请把它拆成 5 到 8 个小任务，每个小任务都要包含：
1. 任务目标。
2. 修改范围。
3. 禁止事项。
4. 验收标准。
5. 是否适合单独提交。
6. 推荐顺序。

最后请告诉我第一个最安全的小任务是什么。

拆任务时不要只看功能顺序，也要看风险顺序。低风险、可验证、能建立上下文的小任务应该排在前面。

一个复杂功能通常这样拆：

不要先做 UI 大改，再回头发现接口和权限不支持。

大任务里经常会冒出很多支线问题，比如顺手优化样式、补文档、重命名、清理旧代码。它们不一定没价值，但不能混进主线。

可以要求：

请把拆出来的任务分成主线任务和支线任务。

主线任务：完成当前目标必须做。
支线任务：有价值，但不阻塞当前目标。

请先只推进主线任务。

这样能避免任务越拆越散。

一个小任务应该满足：

请把这个大任务拆成任务表。

大任务：
【写大目标】

请用表格输出：
1. 序号。
2. 小任务名称。
3. 目标。
4. 修改范围。
5. 风险等级。
6. 验收标准。
7. 是否能单独提交。
8. 前置依赖。

最后推荐第一个最安全的小任务。

拆完以后最容易犯的错，是一次执行多个小任务。可以这样限制：

请只选择第一个小任务开始。

要求：
1. 不要同时做第 2、3、4 个任务。
2. 如果发现第一个任务依赖后续任务，请先说明。
3. 第一个任务完成后先验收和收口。
4. 我确认后再进入下一个任务。

请只执行第 1 个小任务。

要求：
1. 不要顺手做后面的任务。
2. 先给出最小修改计划。
3. 我确认后再修改。
4. 完成后用 /verify 验收。
5. 输出是否可以进入下一个小任务。

第 1 个小任务完成后，请先收口。

请输出：
1. 本小任务目标是否完成。
2. 修改了哪些文件。
3. 做了哪些验收。
4. 是否有剩余风险。
5. 是否可以进入第 2 个小任务。
6. 第 2 个小任务开始前需要重新确认什么。

这个小任务仍然太大。

请继续拆小：
1. 拆成 2 到 4 个更小步骤。
2. 每一步最多改 1 到 2 个文件。
3. 每一步都有独立验收。
4. 标出第一步。
5. 不要开始修改。

这些任务一旦混进主任务，往往会让验收变复杂。单独拆出来，反而更快。

请作为大任务总控，不要直接写代码。

请维护：
1. 当前正在做第几个小任务。
2. 已完成的小任务。
3. 已验证的小任务。
4. 暂缓的小任务。
5. 新发现但不属于当前范围的问题。
6. 下一步最小动作。

出现这些情况，先暂停：

暂停不是失败，而是重新把任务拉回可控范围。