规划三阶段

R0 需求精炼

目标：模糊需求 → 可验证规格

操作：

1. 分析用户需求，列出理解到的内容
2. 识别歧义点和缺失信息，主动向用户提问
3. 将需求按优先级分级：
   • MUST: 不做就算失败的核心需求
   • SHOULD: 重要但不阻塞交付的需求
   • COULD: 有最好，没有也行的增强
4. 为每个 MUST 需求写验收标准（怎么验证做完了）

此阶段不写任何代码。

产出格式：

## 需求规格
### MUST
- [ ] 需求 1 — 验收标准：...
- [ ] 需求 2 — 验收标准：...
### SHOULD
- [ ] ...
### COULD
- [ ] ...

门控：[寸止-需求确认]

• 调用 cunzhi MCP 暂停等待用户确认
• cunzhi 不可用时：输出规格后直接问用户 "以上理解是否正确？确认后我继续技术调研"
• 用户确认后 → 如 .ai_state/ 存在，写 state.json {"phase":"R",...} → 进入 R 阶段

R 技术调研

目标：摸清技术可行性

操作：

1. 用 Cursor 代码库搜索，找到项目中的相关实现
2. 识别：
   • 可复用的现有代码（函数、组件、模块）
   • 需要新增的依赖（库名 + 版本）
   • 潜在的技术风险和约束
3. 如果遇到不确定的库 API：
   • 有 context7 skill → 调用查询文档
   • 没有 → 使用 web 搜索或阅读 node_modules/.venv 中的源码
4. 列出技术方案的关键决策点

产出格式：

## 技术调研结果
### 可复用代码
- 文件路径: 用途
### 新增依赖
- 库名@版本: 用途
### 技术风险
- 风险描述: 缓解方案
### 关键决策
- 决策点: 选项 A vs 选项 B (推荐 X，原因)

门控：发现重大技术风险 → 暂停告知用户，等待决策 完成后 → 如 .ai_state/ 存在，写 state.json {"phase":"D",...} → 进入 D 阶段

D 方案定稿

目标：确定最终实现方案

操作：

1. 整合 R0 需求规格和 R 技术调研结果
2. 此阶段不写代码，只输出方案
3. 对方案进行三项审视：
   • 接口最小化: 是否暴露了不必要的接口？能否更简单？
   • 错误处理完整性: 每个外部调用都有错误处理？
   • 有没有更简单的方案: 是否过度设计？
4. 列出本次变更涉及的文件清单

产出格式：

## 实现方案
### 方案概述
（一段话描述核心思路）
### 变更文件清单
- [ ] 新建: path/to/file — 用途
- [ ] 修改: path/to/file — 改什么
### 数据流 / 接口
（如有必要，描述数据流向和接口定义）

门控：[寸止-方案确认]

• 调用 cunzhi MCP 暂停等待用户确认
• cunzhi 不可用时：输出方案后直接问用户 "方案是否可以？确认后我开始排期和编码"
• 用户确认后 → 如 .ai_state/ 存在，写 state.json {"phase":"P",...} → 继续 workflow 编排进入 P/E 阶段