planning-workflow

# 从想法到实现计划

本文档定义了一个工作流，通过迭代细化单个 Markdown 文档，将模糊想法转化为清晰的实现计划。

## 核心原则

- **迭代细化**: 逐阶段推进，每次更新一个部分
- **用户协作**: 每个阶段需要用户明确审查和确认后再继续
- **结构化输出**: 所有工作捕获在单一、结构良好的 Markdown 文件中

## Markdown 文件结构

管理包含以下 H2 标题的单个 `.md` 文件：

- `## Idea`: 初始概念
- `## Requirements`: 功能和非功能需求及验收标准
- `## Tasks`: 详细、可操作的工作分解
- `## Design`: 高级技术设计和组件结构
- `## Test Cases`: 验证实现的场景
- `## Next Steps`: 即时行动摘要

## 工作流阶段

### 1. 想法 → 需求

- **目标**: 将初始想法转化为清晰、可验证的需求
- **流程**:
  1. 在 `## Idea` 部分捕获用户想法
  2. 提出澄清问题解决歧义
  3. 在 `## Requirements` 下起草具有 Given-When-Then 验收标准的具体需求
  4. 请求用户审查和确认

### 2. 需求 → 任务

- **目标**: 将需求分解为细粒度、可操作的任务列表
- **流程**:
  1. 分析已批准的需求
  2. 按以下原则在 `## Tasks` 部分分解：
     - **MECE**: 任务必须相互独立且完全穷尽
     - **明确目标与交付物**: 每个子任务必须有精确定义的目标和可验证的预期交付物
     - **可管理规模**: 将任务分解为足够小的块
     - **优先级**: 考虑业务价值、依赖关系和风险
     - **独立性**: 争取可独立工作和测试的子任务
     - **可验证性**: 设计可清晰验证完成的子任务
  3. 请求用户审查和确认

### 3. 任务 → 设计

- **目标**: 创建技术设计规范
- **流程**:
  1. 分析已批准的任务
  2. 在 `## Design` 部分提出设计，包括类、方法和关系（鼓励使用 Mermaid 图表）
  3. 确保设计考虑现有架构和质量标准
  4. 请求用户审查和确认

### 4. 设计 → 测试用例

- **目标**: 定义全面的测试用例集
- **流程**:
  1. 分析已批准的设计
  2. 在 `## Test Cases` 下定义测试用例（正面、负面、边界）
  3. 确保需求的完整覆盖
  4. 在 `## Next Steps` 添加实现建议
  5. 请求用户审查和确认

---

## 执行指导（规划分析师模式）

当进行规划任务时，按以下流程执行：

### 阶段转换引导

```
想法 → 需求 → 任务 → 设计 → 测试用例
      ↑        ↑       ↑        ↑
    澄清问题  MECE分解  架构设计  覆盖验证
```

### 执行检查清单

| 阶段 | 关键动作 | 用户交互 |
|------|----------|----------|
| 想法→需求 | 提问澄清歧义 | 等待确认 |
| 需求→任务 | MECE 分解 | 等待确认 |
| 任务→设计 | 绘制架构图 | 等待确认 |
| 设计→测试 | 定义验证场景 | 等待确认 |

### 触发条件

- 用户提出新想法或功能请求
- 需求分析任务
- 项目规划讨论
- 技术方案设计

### 关键原则

- **用户协作**: 每个阶段必须等待用户确认
- **单一文档**: 所有产出集中在一个 Markdown 文件
- **迭代细化**: 允许回退修正，但保持结构化进展
- **MECE 分解**: 任务必须相互独立、完全穷尽