AI 任务分解全景：从用户故事到并行执行的艺术

简单任务：AI 表现
- "写一个冒泡排序"      → 完美
- "创建一个 React 组件"  → 很好
- "写一个用户登录 API"   → 较好

复杂任务：AI 表现
- "搭建一个电商后端"     → 到处是坑
- "重构整个认证模块"     → 上下文丢失
- "实现微服务架构"      → 完全失控

Level 1: Mega Plan（项目级）
   └── 输出：mega-plan.json + design_doc.json
   └── 作用：把"做一个电商系统"变成"auth模块 + API模块 + 数据库模块"

Level 2: Feature（功能级）
   └── 输出：PRD + Design Doc
   └── 作用：把"auth模块"变成"JWT认证 + 密码哈希 + Session管理"

Level 3: Story（故事级）
   └── 输出：具体可执行的任务
   └── 作用：把"JWT认证"变成"写 auth 中间件 + 写测试 + 写文档"

项目目标
   ↓ Level 1: Mega Plan
功能模块 1  ← →  功能模块 2  ← →  功能模块 3
   ↓ Level 2              ↓ Level 2              ↓ Level 2
PRD + Design         PRD + Design           PRD + Design
   ↓ Level 3              ↓ Level 3              ↓ Level 3
可执行任务           可执行任务              可执行任务
   ↓ (并行)                ↓ (并行)                ↓ (并行)
Agent A 执行        Agent B 执行           Agent C 执行
   ↓                                               ↓
质量门（DoR/DoD/测试覆盖率/lint）← 汇总

传统方式：
  AI 记住所有上下文 → 对话变长 → 上下文压缩 → 设计决策丢失

Plan Cascade 方式：
  设计文档持久化 → 即使上下文压缩，设计文档还在 → AI 随时可以重新理解项目

Feature PRD:
├── 背景与目标
├── 用户故事（User Stories）
├── 功能范围（In Scope / Out of Scope）
├── 验收标准（Acceptance Criteria）
├── 非功能性需求（性能、安全、可扩展性）
└── 依赖项（Dependencies）

Design Doc:
├── 技术选型
├── 架构图
├── API 设计
├── 数据模型
├── 错误处理策略
└── 监控与可观测性

Phase 1: Decompose
  Opus 4.6 分析代码库 + 任务 → 生成依赖图

Phase 2: Execute
  Wave 1: [create routes] + [add middleware]  ← 并行（无依赖）
  Wave 2: [write tests]                        ← 等待 Wave 1
  Wave 3: [code review]                        ← 等待 Wave 2

Phase 2.5: Quality Gate
  Opus 4.6 审核所有 Agent 输出 → 打分 + 通过/不通过

文件锁: {auth.ts -> Agent 1}
       {middleware.ts -> Agent 2}
       {test_auth.ts -> Agent 3}

Who：谁会用这个功能？
What：这个功能具体做什么？
Why：为什么要做？（解决什么问题）
Where：在什么场景下使用？
When：什么时候需要？
How：怎么验证做对了？

识别标准：
- 模块有清晰的边界
- 模块可以被独立测试
- 模块之间有明确的接口定义

例如：
  电商系统 → auth模块 + product模块 + order模块 + payment模块

格式：作为[角色]，我希望[功能]，以便[收益]

例如：
  故事1：作为用户，我希望用手机号登录，以便不需要记住密码
  故事2：作为用户，我希望30天内自动登录，以便不需要每次都输入验证码
  故事3：作为管理员，我希望强制登出功能，以便在安全事件时保护用户

故事1分解：
  [ ] 实现手机号 + 验证码登录 API
  [ ] 集成短信网关（Mock for 开发）
  [ ] 验证码有效期 5 分钟逻辑
  [ ] 同一手机号 60 秒内不能重复发送
  [ ] 登录日志记录
  [ ] 单元测试（覆盖率 > 80%）

并行判断规则：
✓ 两个任务修改不同的文件 → 可以并行
✓ 两个任务修改同一文件的不同区域 → 可能可以，需要文件锁
✗ 任务B依赖任务A的输出 → 必须串行
✗ 两个任务修改同一文件的同一区域 → 不能并行

Definition of Ready (DoR)：
  □ 需求清晰，验收标准明确
  □ 没有模糊的术语
  □ 估算工作量 < 2 天

Definition of Done (DoD)：
  □ 代码符合规范，通过 lint
  □ 有单元测试，覆盖率达标
  □ 有基本的集成测试
  □ 文档已更新

作为需求分析专家，分析以下功能需求：

【需求描述】
{输入需求}

请输出：
1. 背景理解：这个需求要解决什么问题？
2. 关键干系人：谁会使用这个功能？谁会受到影响？
3. 核心用户故事（3-5条）
4. 可能的边界情况（Edge Cases）
5. 需要澄清的问题（如果有）
6. 验收标准草稿

作为任务分解专家，将以下功能分解成可执行的任务列表：

【功能描述】
{输入功能}

请输出：
1. 功能模块划分（Level 1）
2. 每个模块的用户故事（Level 2）
3. 每个故事的技术任务（Level 3）
4. 依赖关系图（哪些任务可以并行？）
5. 优先级排序
6. 估算工作量（每个任务）

作为代码评审专家，检查以下实现是否满足需求：

【原始需求】
{需求描述}

【实现内容】
{代码或设计文档}

请输出：
1. 是否满足所有验收标准？
2. 是否有遗漏的边界情况？
3. 是否有安全隐患？
4. 是否有可改进的地方？
5. 综合评分（1-10）和建议

第一代：单 Agent 执行
  Claude Code 单一会话 → 上下文有限

第二代：任务分解 + 并行
  Plan Cascade / Claude Swarm → 突破上下文限制

第三代（预测）：自动分解 + 自主执行
  AI 自动理解需求 → 自动分解 → 自动执行 → 自动验证