morning-start 需求拆解
将模糊、宏大的需求转化为一连串具体、可执行、可验证的小任务。
核心框架：三步递进
澄清需求 → 拆解需求 → 验证需求
第一步：澄清需求
目标：确保完全理解需求本质，而非表面方案。
1.1 统一语言
与业务方对齐关键术语：
- 确认核心实体的属性（如"订单"包含：订单号、商品、总价、状态）
- 确认业务规则和边界条件
1.2 挖掘真实动机（5W2H法）
| 维度 | 问题 |
|---|---|
| Why | 为什么做？解决什么问题？ |
| Who | 谁会用？直接/间接用户？ |
| What | 核心问题是什么？ |
| Where | 在哪里用？环境特点？ |
| When | 什么时候用？频率？ |
| How | 期望怎么做？ |
1.3 定义具体目标
将模糊目标转化为可量化指标：
| 模糊目标 | 具体目标 |
|---|---|
| 提升点单效率 | 平均每单点单时间缩短至1分钟以内，错误率降低到5%以下 |
第二步：拆解需求
目标：将需求分层拆解为可开发的用户故事和具体任务。
层级1：特性 → 用户故事
按核心流程或功能模块拆分，用户故事格式：
"作为<角色>，我想要<活动>，以便于<商业价值>"
层级2：用户故事 → 任务
将每个用户故事拆分为具体技术任务：
| 任务类型 | 示例 |
|---|---|
| 前端任务 | UI设计、组件开发、交互实现 |
| 后端任务 | 数据模型、API接口、业务逻辑 |
| 测试任务 | 测试用例编写、功能验证 |
拆解技巧
- 按工作流拆分：如"点单 → 支付 → 出餐"
- 按功能模块拆分：如"商品管理"、"订单管理"、"会员管理"
- 按技术架构拆分：前端界面、后端逻辑、数据库设计
- 按操作类型拆分：增、删、改、查
第三步：验证需求
目标：与需求方确认理解一致，避免后续返工。
3.1 定义验收标准（DoD）
使用 Given-When-Then 格式：
Given 前置条件
When 操作行为
Then 预期结果
示例：
- Given 店员已选择了一杯"珍珠奶茶"
- When 店员增加了"珍珠"配料并选择"无糖"
- Then 系统应显示"珍珠奶茶(无糖, +珍珠)"，总价增加1元
3.2 反向串讲
拿着原型图或流程图，让需求方扮演用户模拟操作，提前发现理解偏差。
3.3 例外情况测试
主动思考异常流程：
- 顾客在支付前想取消订单怎么办？
- 某个配料卖完了，界面如何显示？
- 打印小票时没纸了，系统如何提示？
使用场景
当用户提供模糊需求时，主动调用此skill进行需求拆解：
- 用户说"帮我做一个商城系统"
- 用户说"需要一个项目管理工具"
- 用户说"开发一个社交App"
- 用户的需求过于笼统，需要具体化
输出格式
完成拆解后，输出以下结构化内容：
## 需求澄清
- 核心目标：...
- 关键术语：...
- 5W2H分析：...
## 拆解结果
### 特性1：...
- 用户故事：...
- 任务列表：...
### 特性2：...
...
## 验收标准
- 用户故事1的DoD：...
- 用户故事2的DoD：...
...