| name | requirement-discussion |
| description | 需求讨论工作流。引导用户描述需求,使用 Critical Thinking 讨论,拆解功能,生成需求文档。在"/requirement"、"/需求讨论"、"讨论需求"时使用。 |
需求讨论工作流
定位
开发流程第一阶段:需求理解与拆解
核心目标:把需求说清楚,拆解清晰
关键约束
- ❌ 不讨论技术实现:这是需求阶段,不涉及代码
- ❌ 不一味讨好:发现问题要指出
- ✅ 聚焦"做什么":而非"怎么做"
- ✅ 可验证:每个功能都有明确的验收标准
工作流程
1. 启动阶段
询问用户:
- 这是新功能还是迭代优化?
- 功能的名称/代号是什么?
如果是迭代,先读取已有需求文档:docs/requirements/feature-xxx.md
2. 讨论阶段
引导用户描述:
追问用户场景:
- 用户在什么情况下会用这个功能?
- 用户期望的操作流程是什么?
- 有没有类似的产品/功能可以参考?
Critical Thinking:
- 指出需求中的矛盾点
- 质疑不合理的假设
- 提出潜在的风险和边界情况
- 建议更好的方案(如果有)
联网调研(必要时):
3. 收敛阶段
总结讨论要点:
拆解功能列表:
- 每个功能用一句话描述
- 功能之间的优先级
- 哪些是 MVP,哪些是后续迭代
明确验收标准:
生成需求文档:
- 保存到
docs/requirements/feature-xxx.md
交付物格式
# [Feature 名称] 需求文档
> 创建日期:YYYY-MM-DD
> 状态:草稿 / 已确认
## 背景
为什么要做这个功能?解决什么问题?
## 用户场景
### 场景1:[场景名称]
- **用户**:[谁]
- **情境**:[在什么情况下]
- **需求**:[需要什么]
- **期望**:[期望的结果]
### 场景2:[场景名称]
...
## 功能列表
### MVP(必须实现)
- [ ] F1: [功能描述]
- [ ] F2: [功能描述]
### 后续迭代(可选)
- [ ] F3: [功能描述]
## 验收标准
| 功能 | 验收条件 |
|-----|---------|
| F1 | AC1: ... |
| F2 | AC2: ... |
## 非功能需求
- **性能**:[要求]
- **兼容性**:[要求]
- **安全**:[要求]
## 待澄清问题
- [ ] Q1: [问题描述]
- [ ] Q2: [问题描述]
## 讨论记录
### YYYY-MM-DD
- 讨论要点1
- 讨论要点2
- 决定:xxx
讨论风格示例
用户:我想做一个用户登录功能
Agent:好的,我来帮你梳理登录功能的需求。先问几个问题:
1. **登录方式**:支持哪些?
- 手机号 + 验证码?
- 邮箱 + 密码?
- 第三方登录(微信/Google)?
2. **用户场景**:
- 新用户注册和老用户登录是同一个入口吗?
- 用户忘记密码怎么处理?
3. **安全考虑**:
- 需要图形验证码吗?
- 登录失败次数限制?
另外,你提到"登录功能",是只做登录,还是整个用户体系(注册 + 登录 + 个人信息管理)?
---
用户:先做手机号登录,注册和登录合一
Agent:明白。手机号登录 + 注册登录合一,这是比较主流的方案。
我再确认几点:
1. **验证码**:短信验证码还是语音验证码?验证码有效期多久?
2. **新用户处理**:首次登录自动创建账号,还是需要补充信息(如昵称)?
3. **登录态**:token 有效期多久?支持多设备同时登录吗?
还有一个潜在问题:如果用户换了手机号怎么办?需要考虑账号绑定/解绑的场景吗?
流转条件
需求文档经用户确认后,可进入下一阶段:开发计划
确认方式:
- 用户明确表示"需求确认"
- 或用户说"可以开始做了"
- 或用户触发
/dev-plan
注意事项
- 不要急于收敛:充分讨论比快速产出更重要
- 记录讨论过程:重要的讨论点要记录在文档中
- 保持开放:用户可能在讨论中改变想法,这是正常的
- 适时总结:讨论一段时间后主动总结,避免发散太远