AI-Wiki

定义

AI编程任务细粒度计划拆解，是指在Superpowers工作流里，使用 writing-plans skill 把已经成文并经审阅的设计说明继续拆成可直接执行的最小步骤清单。它不是“先有个模糊需求就直接列待办”，而是明确承接brainstorming阶段的产物：先有 spec，再把 spec 拆成执行计划。这个概念的核心不是“列任务”，而是把任务压缩到足够细，使人类或 AI 在执行时每一步都有明确完成条件，不需要临场补设计，也不允许靠猜。

在本文档中的语境

在原文描述的完整链路中，brainstorming负责设计，writing-plans 负责把设计转成实现计划，之后才进入subagent-driven-development或executing-plans。因此，它处在“设计 → 实现”的中间层，是关键桥梁，而不是可有可无的附加步骤。原文还特别强调：brainstorming的终态就是移交 writing-plans，而不是直接开始写代码。这说明计划拆解在该体系里是强制环节，不是建议环节。

输入前提：必须来自 spec，而不是直接面对模糊需求

writing-plans 的输入，是brainstorming阶段完成后的 spec。这意味着它处理的对象已经过设计讨论、章节确认、文档化、自检和用户审阅，而不是一句“帮我加个功能”这样的模糊指令。如果跳过 spec，直接从含糊需求生成计划，那么计划本身就会继承设计歧义，后续执行阶段仍然会出现上下文漂移、需求被 AI 自行发明、做到一半重新提问等问题。所以该机制隐含的边界是：它不替代需求澄清，也不替代设计产出；它是在设计已经定稿后，把设计压缩成可执行步骤。

关键机制：每个步骤必须控制在 2-5 分钟

该机制最重要的约束，是每个步骤的粒度必须控制在 2-5 分钟。这不是泛泛而谈的“尽量细一点”，而是非常具体的时间尺度要求。原文给出的示例结构如下：

Step 1：写一个失败的测试
Step 2：跑一下，确认它确实失败了
Step 3：写最小实现让测试通过
Step 4：跑测试，确认通过
Step 5：commit

这个示例体现了几个关键原则：

步骤必须足够小，小到 2-5 分钟内可以完成。
步骤必须可验证，每一步都能判断“是否已经完成”。
步骤必须围绕明确产出，而不是笼统地写成“实现功能 A”。
步骤顺序必须能直接执行，不要求执行者再做二次拆解。

为什么“写测试”和“确认失败”必须拆成两个步骤

原文专门强调，“写一个失败的测试”和“跑一下确认它失败了”不能合并成一步。原因不是形式主义，而是为了给每一步设置明确的完成判定标准。如果把两者合并，执行者可能会出现多种不确定状态：

测试代码写了，但还没运行，不知道是否真的能复现问题。
测试运行了，但失败原因不对，无法证明测试命中了目标行为。
测试本应失败却意外通过，说明需求理解、测试断言或现有代码状态有偏差。

拆成两个独立步骤后，完成标准就变得非常清晰：

“写测试”完成，表示测试文件或测试用例已经被具体写出。
“确认失败”完成，表示该测试已实际执行，且失败结果与预期一致。

这种拆法的价值在于，不管后续由当前会话执行，还是交给子代理执行，都不会停留在“我好像差不多做完了”的模糊状态，而是每一步都能被验收。

零占位符规则

writing-plans 还有一个非常严格的规则：计划中不允许保留任何占位符。原文把这类写法视为计划失败，必须修正。

明确被禁止的内容包括：

“TBD”
“TODO”
“后续实现”
“添加适当的错误处理”这类不写清具体处理方式的描述
“写上述内容的测试”这类不给出具体测试代码或测试内容的表述
用“类似 Task N”引用前文，代替当前任务的具体描述

这些限制说明，所谓计划不是提纲，也不是给未来的自己留个提醒，而是执行说明书。一旦还存在这些占位符，说明真正困难的设计决策并没有完成，只是被推迟到了执行阶段。

为什么必须零占位符

原文给出的理由非常直接：如果后续执行阶段遇到 TBD，Agent 通常只会走两条路。第一条路是停下来追问；第二条路是自行发挥。这两种情况都被视为失败：

停下来追问，会打断执行流，说明计划没有把必要信息准备好。
自行发挥，会让实现偏离原先设计，重新引入需求发明和上下文漂移。

因此，零占位符规则的本质是把不确定性前移，在计划阶段消灭空白地带，而不是把模糊留给执行阶段处理。这也是该机制能稳定支持 AI 执行的关键：计划必须写到足够具体，执行者只需要推进，不需要补完。

作为执行桥梁的作用

在整个Superpowers方法里，细粒度计划拆解承担的不是“文档整理”角色，而是执行入口控制。经过这一步后，设计被转换为一系列短时、可验证、可交接的动作。这样做至少解决了三类常见问题：

避免设计只存在于会话上下文中，执行越往后越漂移。
避免任务过大，导致 Agent 一次写出大段代码、局部正确但细节失真。
避免执行者在中途自行补全未定事项，破坏原有 spec。

换句话说，它把“知道要做什么”转成“知道下一步具体做什么，以及做完如何算完成”。

计划完成后的两条执行路径

计划写完后，不是继续停留在 planning，而是进入明确的执行分流。原文给出两条执行路径：

1. subagent-driven-development

这是原文推荐的默认选项，前提是平台支持 subagent。它的特点是每个任务派生一个新的 subagent，让子代理拿着计划文件和当前任务，在干净上下文里工作。原文还提到该路径带两轮审查：先看是否符合 spec，再看代码质量。它更适合任务较多、上下文容易漂移、且希望提高稳定性的场景。

2. executing-plans

这是在当前会话里串行执行整个计划的方式。它适合没有 subagent 支持的环境，或者任务简单、不想额外绕一层代理调度的场景。它的代价是上下文会持续累积，会话越长越容易受到前序错误尝试和无关上下文干扰。

适用边界与注意事项

AI编程任务细粒度计划拆解并不意味着所有任务都要写成长篇计划，但它要求所有任务都拆到足够细。即使项目很小、改动很轻，计划也可以很短，但不能跳过“明确步骤与验收标准”这件事。它也不负责替代调试流程；如果执行中遇到 bug，应插入系统化调试流程而不是在计划里用模糊修补语句带过。同样，它也不替代测试纪律；示例步骤本身就体现出测试先行和验证驱动的执行方式，与整个工程纪律体系是配套关系。

与相关概念的关系

brainstorming：负责从需求到设计，并产出 spec；细粒度计划拆解以它的产物为输入。
subagent-driven-development：计划完成后的推荐执行路径，适合支持子代理的平台。
executing-plans：计划完成后的串行执行路径，适合不支持子代理的环境。