从想法到实现计划

本文档定义了一个工作流，通过迭代细化单个 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分解  架构设计  覆盖验证

执行检查清单

触发条件

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

关键原则

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