wenjunduan 规划三阶段
R0 需求精炼
目标：模糊需求 → 可验证规格
操作：
- 分析用户需求，列出理解到的内容
- 识别歧义点和缺失信息，主动向用户提问
- 将需求按优先级分级：
- MUST: 不做就算失败的核心需求
- SHOULD: 重要但不阻塞交付的需求
- COULD: 有最好，没有也行的增强
- 为每个 MUST 需求写验收标准（怎么验证做完了）
此阶段不写任何代码。
产出格式：
## 需求规格
### MUST
- [ ] 需求 1 — 验收标准：...
- [ ] 需求 2 — 验收标准：...
### SHOULD
- [ ] ...
### COULD
- [ ] ...
门控：[寸止-需求确认]
- 调用 cunzhi MCP 暂停等待用户确认
- cunzhi 不可用时：输出规格后直接问用户 "以上理解是否正确？确认后我继续技术调研"
- 用户确认后 → 如 .ai_state/ 存在，写 state.json
{"phase":"R",...}→ 进入 R 阶段
R 技术调研
目标：摸清技术可行性
操作：
- 用 Cursor 代码库搜索，找到项目中的相关实现
- 识别：
- 可复用的现有代码（函数、组件、模块）
- 需要新增的依赖（库名 + 版本）
- 潜在的技术风险和约束
- 如果遇到不确定的库 API：
- 有 context7 skill → 调用查询文档
- 没有 → 使用 web 搜索或阅读 node_modules/.venv 中的源码
- 列出技术方案的关键决策点
产出格式：
## 技术调研结果
### 可复用代码
- 文件路径: 用途
### 新增依赖
- 库名@版本: 用途
### 技术风险
- 风险描述: 缓解方案
### 关键决策
- 决策点: 选项 A vs 选项 B (推荐 X，原因)
门控：发现重大技术风险 → 暂停告知用户，等待决策
完成后 → 如 .ai_state/ 存在，写 state.json {"phase":"D",...} → 进入 D 阶段
D 方案定稿
目标：确定最终实现方案
操作：
- 整合 R0 需求规格和 R 技术调研结果
- 此阶段不写代码，只输出方案
- 对方案进行三项审视：
- 接口最小化: 是否暴露了不必要的接口？能否更简单？
- 错误处理完整性: 每个外部调用都有错误处理？
- 有没有更简单的方案: 是否过度设计？
- 列出本次变更涉及的文件清单
产出格式：
## 实现方案
### 方案概述
（一段话描述核心思路）
### 变更文件清单
- [ ] 新建: path/to/file — 用途
- [ ] 修改: path/to/file — 改什么
### 数据流 / 接口
（如有必要，描述数据流向和接口定义）
门控：[寸止-方案确认]
- 调用 cunzhi MCP 暂停等待用户确认
- cunzhi 不可用时：输出方案后直接问用户 "方案是否可以？确认后我开始排期和编码"
- 用户确认后 → 如 .ai_state/ 存在，写 state.json
{"phase":"P",...}→ 继续 workflow 编排进入 P/E 阶段