Vibecoding Plan

---
description: "VibeCoding 规划三阶段：需求精炼(R0)、技术调研(R)、方案定稿(D)。由 vibecoding-workflow 编排调度进入。也可在用户明确要求'分析需求''调研方案''设计架构'时独立触发。仅在 workflow 指示进入 R0、R 或 D 阶段时使用。"
name: VibeCoding Plan
---

# 规划三阶段

## R0 需求精炼

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

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

此阶段不写任何代码。

产出格式：
```markdown
## 需求规格
### 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. 列出技术方案的关键决策点

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

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

## D 方案定稿

目标：确定最终实现方案

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

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

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