任务颗粒化计划
定义
任务颗粒化计划 是一种把设计文档或 spec 拆解为超细粒度执行步骤的计划方法。在本文语境中，它不是泛泛的“列待办”，而是必须把后续实现拆到每一步约 2 到 5 分钟即可完成，并且每一步都有明确的完成判定标准。
它的目标不是让计划看起来详细，而是让 AI 工程纪律 能真正落地：不管执行者是人类、当前会话中的 AI，还是新的 subagent，都能按同一份计划稳定推进，而不是在执行阶段临场补全需求、擅自解释意图或自由发挥。
在本文档中的语境
在 Superpowers 的完整开发链条中，任务颗粒化计划 出现在 brainstorming 之后，由 writing-plans skill 负责生成。其前提是：设计已经形成明确 spec，并且经过审阅；其作用是把“设计上已经决定的内容”转换成“可以逐项执行和核验的任务清单”。
这意味着它不是设计本身，也不是编码本身，而是设计与执行之间的硬连接层。brainstorming 的终态被明确限制为移交给 writing-plans，正是为了强制形成这层计划，而不是从设计直接跳到实现。
核心机制
1. 步骤粒度必须控制在 2 到 5 分钟
本文给出的关键约束是：每个步骤的粒度是 2-5 分钟。这不是大概估算，而是计划是否合格的核心标准。
符合这种粒度的计划，通常会把一个看似连续的动作拆成多个可独立核验的小步骤。例如：
- 写一个失败的测试
- 运行一次，确认它确实失败
- 写最小实现使测试通过
- 再运行测试，确认通过
- 提交变更
这里最关键的不是测试驱动这个形式本身，而是把“写测试”和“验证测试失败”拆成两个步骤。因为如果只写成“写并验证测试”，执行时就会重新出现自由裁量：到底只写了算完成，还是必须跑过才算完成？
把步骤压到 2 到 5 分钟，实质上是在消除这种模糊空间。
2. 每一步都必须可验证完成
任务颗粒化计划 的第二个核心要求是：每一步都要能明确判断是否完成。执行者在做完一步后，必须能够回答“完成了”或“没完成”，而不是“差不多”或“基本完成”。
因此，合格步骤通常具有以下特征：
- 动作单一，不混杂多个目标
- 输出明确，例如生成测试、修改一处实现、运行某条命令、确认某个结果
- 完成条件可观察，例如测试失败、测试通过、文件已写入、提交已完成
相反，如果一个步骤需要中途做解释、主观判断或临时补充细节，它往往就还不够细。
3. 零占位符规则
writing-plans 明确要求计划采用“零占位符”规则。以下写法都会被视为计划失败，而不是可接受的草稿：
TBDTODO- “后续实现”
- “添加适当的错误处理”
- “写上述内容的测试”
- “类似 Task N”
这些写法被禁止的原因很直接：它们把真正困难的决策推迟到了执行阶段。
例如，“添加适当的错误处理”没有说明错误类型、触发条件、处理方式和验证方式；“写上述内容的测试”没有给出具体测试对象和通过条件；“类似 Task N”则要求执行者自己回溯、推断并复用模式。这些都会让执行重新依赖上下文记忆和临场理解，而不是依赖计划本身。
4. 禁止模糊表述
零占位符之外，任务颗粒化计划 还禁止模糊表述。问题不只在于 TBD 这种显式占位，也在于那些听起来像计划、实则缺乏约束的措辞。
例如，“优化一下逻辑”“补充必要测试”“处理边界情况”“完善异常场景”都属于不合格表达，因为它们没有说明：
- 具体要改哪一部分
- 用什么动作完成
- 完成后怎么验证
- 哪些边界算范围内，哪些不算
这种禁止模糊的要求，使 任务颗粒化计划 与普通项目待办列表区别很大。它追求的不是覆盖主题，而是约束执行。
为什么这种方法有效
为 AI 提供稳定依据
原文强调，这种计划是为了让 AI 或人类都能一步步执行。对于 AI 来说，若计划中存在占位符或模糊描述，模型通常只会做两件事之一：
- 停下来继续追问
- 自己补全并开始发挥
两者都不理想。前者打断流程，后者引入不可控偏差。因此，任务颗粒化计划 的本质价值是：把执行所需的判断尽可能前移到计划阶段，让执行阶段更像按清单推进，而不是二次设计。
为人类执行减少遗漏
这种方法不只服务于 AI。同样的 2 到 5 分钟粒度，也能显著减少人类执行时常见的问题：
- 做了一半，不确定算不算完成
- 把验证步骤省略掉
- 误以为某个隐含前提已经处理
- 在一个大步骤中同时改了多件事，导致回滚困难
当每步都足够小、且完成判定明确时，执行过程更接近逐项勾选，而不是凭感觉推进。
为后续执行提供稳定依据
这是本文要求必须覆盖的核心事实：任务颗粒化计划 的作用之一，就是为后续执行提供稳定依据。
这里的“稳定”主要体现在三点：
- 执行顺序稳定，不依赖临场组织
- 完成标准稳定，不依赖个人口径
- 实现范围稳定，不因会话变长或上下文漂移而被改写
这也是它能支撑 subagent-driven-development 和 executing-plans 的原因。无论是新开的 subagent，还是在当前会话内串行推进，都可以把计划当作统一依据，而不是把“之前聊过什么”当作依据。
与执行方式的关系
在 subagent-driven-development 中
当环境支持 subagent 时，writing-plans 生成的这种细粒度计划最容易发挥价值。每个任务可以交给一个全新的 subagent 执行，而新 subagent 的上下文是干净的，它主要依赖计划文件和当前任务本身工作。
此时，计划越具体、越无占位符，subagent 越不容易在理解任务时偏航。两轮审查机制也更容易围绕明确步骤与明确输出展开，而不是围绕“你当时大概想表达什么”展开。
在 executing-plans 中
如果环境不支持 subagent，就需要在当前会话里串行执行所有任务。此时上下文会不断累积，更容易出现上下文漂移、前面任务影响后面判断、已完成内容被误改等问题。
在这种情况下，任务颗粒化计划 的细粒度和可验证性尤其重要，因为它相当于给长会话提供了反漂移锚点。执行者可以持续回到计划本身，而不是依赖会话记忆。