为什么要拆成Tasks，为什么不要把一个大而全的Spec/PRD丢给AI

为什么需求文档要先转 Spec、再拆 Task？——从百炼 Chatbot 项目看 AI Coding 的正确姿势

很多人以为 AI Coding 就是"把需求丢给 AI → 出代码"。但真正落过地的人都知道，中间少了两步关键动作。这篇文章用一个真实项目讲清楚这两步是什么、为什么必须做、以及怎么做。

一、需求文档不能直接喂给 AI

"调用百炼实现 Chatbot"——一句话需求，丢给 Claude Code 或 Qoder。

AI 会干什么？它会猜。猜你要什么框架、猜你的 API 怎么设计、猜你的错误码怎么定、猜你的测试写到什么粒度。猜对多少取决于你的 prompt 写得多好，而不是你的需求想得多清楚。

这就是第一个断层：

需求方说的      PM 理解的        AI 需要的
"做个聊天机器人"   "调用百炼 API"    框架？分层？端点？字段？错误码？测试？
   🟢 清晰          🟡 模糊           🔴 AI 在盲猜

AI Coding 不是不干活，而是它需要一份能"编译"的输入。就像编译器需要源代码，而不是产品说明书。Spec 14 文档体系就是把模糊的需求"编译"成 AI 能直接消费的规格。

二、为什么要转 Spec？——三个不可绕过的问题

问题 1：没有 Spec，AI 生成的代码字段名是随机的

两个开发者分别让 AI 生成同一个接口的代码，一个叫 userMessage，一个叫 query_text。联调时发现字段对不上——这就是没有"契约真源"的代价。

Spec 09 的核心价值就一句话：字段名在 09 中冻结。之后所有代码、测试、文档都引用这个字段名，不存在理解偏差。

问题 2：没有 Spec，你不知道 AI 漏了什么

AI 生成了 200 行代码，看起来挺完整的。但你不知道它漏了哪些错误处理、缺了哪些边界条件、少了哪些安全控制。

Spec 05 的验收标准（AC）就是一把尺子：

• AC-001-01：消息非空时返回 AI 回复 → 代码里有吗？
• AC-003-01：Key 无效时返回 401 → 错误处理覆盖了吗？
• AC-003-02：超时返回 504 + traceId → 链路追踪做了吗？

14 篇 Spec 文档的本质不是"文档"，而是可自动化验证的约束清单。

问题 3：没有 Spec，团队之间永远在对齐

PM："我觉得应该支持流式响应"
后端："你没写在 PRD 里啊"
PM："我开会时说了"
后端："我没参会"

Spec 是唯一真源（Single Source of Truth）。04 PRD 里写了流式响应（P1），05 里有 US-004，09 里有 stream: boolean。所有人看同一份文档，不靠记忆、不靠口述。

三、Spec 有了，为什么还要拆 Task？

有了 Spec 之后，一个自然的想法是：把 14 篇 Spec 全部丢给 AI，让它一次性生成所有代码。

这个想法会翻车。原因有三：

1. AI 的上下文窗口是有限的

14 篇 Spec 文档加起来几万字。即使模型能装下，注意力也会稀释——前面的章节细节会被后面的覆盖。一次让 AI 做一件事，质量远高于一次让它做所有事。

2. 不同任务之间有关键依赖

W1 Provider 层（封装百炼 SDK）
    ↓ 必须先做完
W2 Route+Service 层（调用 Provider）
    ↓ 必须先做完
W3 错误处理（包装 Provider 的异常）
    ↓
W5 测试（测试上面所有层）

如果把所有代码都丢给 AI 一次生成，依赖关系会被打乱。Provider 还没定义好，Service 就在调用它了——AI 会假设一些不存在的接口。

3. 不同任务应由不同的人（或 Agent）并行处理

拆成独立 Task 后，可以多人并行+ 多 Agent 并行，而不是排队等一个人写完。

四、怎么拆？——从 Spec 到 WBS 的方法论

关键原则：按工程职责拆，不按功能拆。

❌ 错误拆法（按功能）：

Task 1: 做单轮对话功能
Task 2: 做多轮对话功能
Task 3: 做错误处理功能

这样拆的问题：单轮对话功能跨越了 Provider → Service → Route 三层，一个人要搞定所有层，没法并行。

✅ 正确拆法（按工程职责）：

W1: Provider 层 → 封装百炼 SDK          （负责外部服务对接）
W2: Route + Service 层 → 参数校验+编排   （负责 HTTP 处理）
W3: 错误处理层 → 错误码+降级             （横切关注点）
W4: 流式响应层 → SSE 格式                （P1 增强）
W5: 测试门禁层 → TC + CI                （质量保障）

每个 WBS 任务同时出现在多个里程碑中（用 S×W 矩阵管理）：

S1 对话   S2 完善   S3 增强
W1 Provider  ●        ○        —
W2 Route/Ser ●        ○        —
W3 错误处理   —        ●        —
W4 流式      —        —        ●
W5 测试门禁   ○        ●        ○
**● 主要推进，○ 少量涉及，— 不涉及。**这样 PM 一看就知道：S1 后 Provider 和 Route 层就完成了，S2 补上错误处理和测试，S3 再上流式。

五、拆完怎么发布？

任务拆好了，接下来要做的就是把这些任务"搬运"到工程管理系统里。先搞清楚两个概念：

MCP 是什么？

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 AI 能直接调用外部工具 API。Claude Code 通过 MCP Server 可以直接操作 Jira——创建 Issue、查询 Sprint、更新状态，全程不需要打开浏览器。

Skill 是什么？

Skill 是 Claude Code 内的"专家指令集"。mumu-spec-tasks这个 Skill 专门负责：读取 12-实施计划 → 解析 WBS → 格式化任务描述 → 输出创建命令。它知道 Spec 的结构、DoD 的格式、TC 的关联方式。

该用哪个？两个都用。

Skill 负责"怎么描述这个任务"     MCP 负责"怎么调用 Jira API"
        │                              │
        └──────────┬───────────────────┘
                   ▼
        完整格式化的 Jira Issue，一键创建

为什么不能只用 MCP？MCP 只是管道。它不知道 Spec 是什么、WBS 是什么、DoD 格式该长什么样。这些"领域知识"都在 Skill 里。

为什么不能只用 Skill？Skill 能整理出完美的任务描述，但它没办法替你点 Jira 的"创建"按钮。

Jira 和 Teambition 都能通过 MCP 打通

MCP 是一个通用协议标准，任何提供 HTTP API 的服务都可以封装一个 MCP Server。Jira 和 Teambition 都有成熟的 REST API，技术上都能通过 MCP 直接调用。

配置好 MCP Server 后，Claude Code 可以直接调用这些 API 创建 Issue/Task，不需要打开网页、不需要手动填表单。

务实方案：三层发布，适配不同团队

99% 的团队应该从 🥉 开始。不需要配置任何东西，打开 Spec Console，点击复制，贴到 Jira 里就行了。5 个 Task，不到 3 分钟。

对于配置了 MCP Server 的团队，Claude Code 可以直接调用 Jira API 或 Teambition API 创建 Issue，全程零手动。

六、完整流程：从一句话到 Jira Backlog

⏱ 0:00  需求："调用百炼实现 Chatbot"
         ↓
⏱ 2:00  Run mumu-spec-init → 14 篇骨架
⏱ 5:00  Run mumu-spec-r1 → 03 立项提案 + 04 PRD
⏱ 8:00  Run mumu-spec-r2 → 05 用户故事 + 09 API 契约（字段冻结）
⏱ 12:00 Run mumu-spec-r3 → 08 架构 + 10 数据 + 06 FSD + 07 NFR + 11 安全
⏱ 15:00 Run mumu-spec-r4 → 12 计划 + 13 测试 + 14 追溯矩阵
         ↓
⏱ 17:00 打开 Spec Console → 扫描检查 → 评分 92/100
⏱ 18:00 进入「📋 任务」标签 → 确认 WBS 拆分
⏱ 19:00 依次点击「📋 Jira MCP」→ 粘贴 → 5 个 Issue 创建完成
         ↓
⏱ 21:00 进入「📜 版本」标签 → 查看完整变更时间线
⏱ 22:00 导出 HTML 报告 → 打印 PDF → 归档

22 分钟，从一句话到 5 个可追溯的 Jira Issue，附带完整的质量评分和版本记录。

七、总结：三层递进，缺一不可

需求文档（模糊）──→ Spec 文档（精确）──→ Task 列表（可执行）
   输入层             规格层               任务层
   "做个聊天机器人"    09 API 契约          W1 Provider
                      字段名已冻结           DoD: 09 §3
                      AC 可测试             TC: TC-001

为什么不能跳过 Spec？

因为 AI 需要精确输入，Spec 就是那层翻译。

为什么不能一次性交给 AI？

因为上下文太大、依赖关系复杂、需要并行处理。

为什么要 MCP发布？

因为手动搬运 5 个 Task 到 Jira 是纯机械劳动，AI 最适合干这个。

三层都做完，你得到的不是一堆代码，而是一条可追溯、可量化、可自动化的工程管线。