MumuSpec-写了Spec之后还要拆解为Tasks

在 MumuSpec 十四文档体系里，12 回答"什么时候能向业务演示什么"和"开发要拆哪几包活"。里程碑按可演示价值切，WBS 按工程职责切——一条 REQ 到 TC 的全链路，一张表看完。

一、一个让所有 Leader 头疼的问题

项目启动会上，老板问："什么时候能看东西？"

开发说："大概两个月吧。"

老板追问："一个月能看什么？一个半月呢？"

开发沉默了。

两个月后，交付了一堆功能。老板问："这个功能不是我想要的，那个功能怎么还没做？"

开发委屈："需求变了好几轮，我们已经很努力了。"

这就是缺一份实施计划的典型症状：

• 排期模糊："大概两个月"——没有里程碑，没有可演示增量
• 职责不清："这个谁做？"——没有 WBS 拆分，没有 DoD 定义
• 追踪断链："这条需求现在什么状态？"——没有 REQ→S→W→TC 的映射表

在 MumuSpec 体系里，12 实施计划与里程碑就是来解决这个问题的。

二、12 是什么，不是什么

它是

• 可演示增量的时间轴。不是"接口写好了"，而是"能给业务看什么"。
• 工程职责的任务清单。按路由、存储、Agent、前端拆分，不是按功能模块拆。
• 需求到测试的全链路地图。一行看完一条需求什么时候演示、谁来做、怎么验。
• 依赖与风险的提前预判。S1→S2→S3 的依赖链，风险识别与应对预案。

它不是

• 不是项目甘特图（那是 PM 工具的事）
• 不是每日站会记录（那是敏捷仪式的事）
• 不是资源预算表（那是项目管理的事）
• 不是需求优先级排序（那在 03 立项提案和 04 PRD）

一层管一层，不混层。12 只回答两个问题：① 什么时候能演示什么？② 开发要拆哪几包活？

三、12 在 MumuSpec 体系里站在哪个位置

十四份文档有一条明确的主链：

Proposal(03-04) → Spec(05-06-07) → Design(08-09-10-11) → Plan(12) → Test(13) → Trace(14)

12 属于 Plan 阶段，是承上启下的关键枢纽。

它的上下游关系：

一条需求落到 12，才算"可排期"。PM 的 REQ-001 说"问答返回正确结果"，业务侧这条需求写在 05。但它真正变成可排期的输入，是在 12 定义了"S2 问答核心里程碑，主要 WBS 是 W1 路由+W3 Agent，验证 TC-M01-001"之后。

四、为什么 12 是 AI Coding 时代的"加速器"

这是很多团队的真实困境：

"我们让 AI 生成代码，但不知道先生成什么、后生成什么。结果前端等后端，后端等数据模型，大家都卡着。"

原因很简单：AI 需要明确的优先级和依赖关系，才能高效协作。

12 的价值在于：

4.1 按"可演示增量"切，而不是按"技术完成度"切

错误的切法：

• 第 1 周：写数据库
• 第 2 周：写后端接口
• 第 3 周：写前端页面
• 第 4 周：联调

正确的切法（12 的方式）：

• S1 会话管理：会话 CRUD API + 前端侧栏 → 业务能看到"创建会话"
• S2 问答核心：问答提交 + LLM 调用 + 结果展示 → 业务能看到"提问-回答"
• S3 历史记录：问答记录查询 + 会话状态 → 业务能看到"历史对话"
• S4 发布准备：性能优化 + 错误处理 + 测试门禁 → 达到发布标准

每一个 S，都能给业务演示一个完整价值。不是"数据库写好了"（业务看不懂），而是"你能创建会话了"（业务能感知）。

4.2 WBS 按工程职责切，而不是按功能切

按功能切的问题：

• "A 同学做会话管理"——他既要写路由，又要写存储，还要联调前端
• "B 同学做问答核心"——同上，全栈包干

结果是：每个人的工作互相依赖，无法并行，Code Review 也没人懂。

按工程职责切（12 的方式）：

• W1 路由实现：端点注册、参数校验 → 贯穿 S1-S4
• W2 存储层：数据 CRUD、模型映射 → S1-S2
• W3 Agent 编排：LLM 调用、降级策略 → S2-S3
• W4 前端视图：页面组件、交互逻辑 → S1-S4

每个 W 可跨多个 S 迭代推进，不同 W 可并行开发。W1 和 W2 可以同时进行，W3 等 W2 完成后接入，W4 按 S1-S4 逐步填充界面。

4.3 一条表看完需求全链路

老板问"REQ-001 什么时候能看？"——答"S2"。问"谁负责？"——答"W1 路由+W3 Agent"。问"怎么算通过？"——答"TC-M01-001"。

不用再翻 PRD、翻 UserStory、翻测试用例——一张表全有。

五、12 长什么样：以投研问答助手为例

用真实的模板结构说明。完整模板见 Spec模板-投研助手/12-实施计划与里程碑.md，这里摘核心几块：

5.1 里程碑（S1～S4）

切分原则：每刀切出一个可演示的用户价值。

每个 S 的交付要点，业务都能看懂并演示。不是"存储层完成"，而是"会话可创建删除"。

5.2 WBS 任务拆分

拆分原则：按工程职责切，不按功能切。

每个 W 的 DoD 都指向 Spec文档——不是"代码写完"，而是"对齐 09 端点与错误码"。

5.3 S × W 对应矩阵

读法：●= 主要推进，○= 少量涉及，—= 不涉及

这张矩阵回答了"每个阶段各条线在做什么"。一眼看出 S2 是核心攻坚期（W1/W2/W3/W4/W6 都在推进），S4 是收口期（主要是优化和门禁）。

5.4 REQ → S → W → TC 总对应表

一行看完一条需求的全链路。

14 追溯矩阵直接从这张表生成——REQ 到 US 到 S 到 W 到 TC，全链路不断链。

5.5 依赖与风险

依赖链：

S1 会话管理 → S2 问答核心（必须先有会话才能提问）→ S3 历史与状态 → S4 发布准备

风险不是事后补救，是提前识别并写入 12。每个风险标注影响范围和应对预案，对应到具体 WBS 任务。

六、写 12 的三个实用原则

原则 1：里程碑按"可演示价值"切，不是按"技术完成度"切

错误示范：

• ❌ "第 1 周：数据库设计完成"
• ❌ "第 2 周：后端接口完成"
• ❌ "第 3 周：前端页面完成"

正确示范：

• ✅ S1：用户能创建、查看、删除会话
• ✅ S2：用户能提问并得到回答
• ✅ S3：用户能查看历史问答记录
• ✅ S4：系统达到性能指标和测试门禁

判断标准：每个 S 结束，能不能给业务演示并收集反馈？能，就是按价值切；不能，就是按技术切。

原则 2：WBS 按工程职责切，不是按功能模块切

错误示范：

• ❌ "A 同学负责会话管理"（全栈包干）
• ❌ "B 同学负责问答核心"（全栈包干）

正确示范：

• ✅ W1 路由：所有端点注册和参数校验（贯穿 S1-S4）
• ✅ W2 存储：所有数据 CRUD 和模型映射（S1-S2）
• ✅ W3 Agent：所有 LLM 调用和降级策略（S2-S3）
• ✅ W4 前端：所有页面组件和交互（贯穿 S1-S4）

判断标准：不同 W 能不能并行开发？能，就是按职责切；不能，就是按功能切。

原则 3：每个 W 的 DoD 必须指向 Spec 文档

错误示范：

• ❌ "代码写完"
• ❌ "功能实现"
• ❌ "测试通过"

正确示范：

• ✅ "对齐 09端点与错误码"
• ✅ "对齐 10数据模型"
• ✅ "对齐 06FSD 交互规范"
• ✅ "对齐 13测试策略 P0 用例"

判断标准：DoD 能不能被客观验证？能指向具体 Spec 章节，就能验证；模糊描述，就不能验证。

七、12 的常见问题与解法

八、12 的六阶段速记

帮你理解 14 份 Spec 文档的关系：

12 是把 What 和 How 变成 When 的关键一步。没有 12，前面的 Spec 再完善也不知道什么时候交付；没有 12，后面的 Test 再严谨也不知道什么时候开始测。

在 MumuSpec 十四文档体系里，12 通常只有 3-4 页 markdown。但它是从"纸上谈兵"到"真正交付"的转折点：

• 05 PRD 定义了需求，但 12 定义了什么时候交付这些需求
• 09 API 定义了接口，但 12 定义了什么时候实现这些接口
• 13 测试定义了用例，但 12 定义了什么时候执行这些用例
• 14 RTM 定义了追踪，但 12 提供了REQ→S→W→TC的映射关系

12 写的质量，直接决定了项目的可控性和交付的可预期性。

写 12 不需要复杂的项目管理工具，一个 markdown 文件 + 四张表就够了：

1. 里程碑表：S1-S4，按可演示价值切
2. WBS任务表：W1-W6，按工程职责切
3. S×W 对应矩阵：●○—，看清并行关系
4. REQ→S→W→TC总对应表：一行看完全链路

关键是：把它当交付地图写，而不是当排期表写。

排期表回答"什么时候做完"，交付地图回答"什么时候能向业务演示什么价值"。前者是技术视角，后者是业务视角。12 必须是业务视角。