124 lines
2.9 KiB
Markdown
124 lines
2.9 KiB
Markdown
|
---
|
|||
|
|
name: dev-plan
|
|||
|
|
description: 开发流程 - 步骤分解阶段，将设计拆解为可验证的实施步骤
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 步骤分解
|
|||
|
|
|
|||
|
|
> 开发流程第三阶段：将设计拆解为可验证的实施步骤，每步提供验收标准。
|
|||
|
|
|
|||
|
|
## 调用方式
|
|||
|
|
|
|||
|
|
`/dev-plan`，也可说"分解步骤"或"制定开发计划"。
|
|||
|
|
|
|||
|
|
## 产出目录
|
|||
|
|
|
|||
|
|
`docs/plans/`
|
|||
|
|
|
|||
|
|
## 执行流程
|
|||
|
|
|
|||
|
|
### Checklist
|
|||
|
|
|
|||
|
|
- [ ] 前置检查：读取需求和设计文档
|
|||
|
|
- [ ] 分析设计，识别实现步骤
|
|||
|
|
- [ ] 定义每个步骤的验收标准
|
|||
|
|
- [ ] 展示完整步骤列表
|
|||
|
|
- [ ] 用户确认并保存
|
|||
|
|
|
|||
|
|
### 1. 前置检查
|
|||
|
|
|
|||
|
|
- 读取 `docs/requirements/` 和 `docs/design/`
|
|||
|
|
- 如果任一目录为空，提示用户先完成对应阶段（可选择跳过）
|
|||
|
|
- 展示需求和设计摘要，确认分解范围
|
|||
|
|
|
|||
|
|
### 2. 分析设计，识别步骤
|
|||
|
|
|
|||
|
|
基于设计文档的模块划分和架构，将实现工作拆解为步骤。
|
|||
|
|
|
|||
|
|
**拆解原则：**
|
|||
|
|
- 每个步骤必须**可独立验证**
|
|||
|
|
- 步骤粒度：一个步骤应能在一次开发会话中完成
|
|||
|
|
- 优先按依赖关系排序：基础模块先于上层模块
|
|||
|
|
- 同一模块的相关任务归为同一步骤
|
|||
|
|
|
|||
|
|
### 3. 定义验收标准
|
|||
|
|
|
|||
|
|
为每个步骤定义验收标准。
|
|||
|
|
|
|||
|
|
**验收标准要求：**
|
|||
|
|
- **可客观判断**：能通过命令执行、文件检查或视觉确认
|
|||
|
|
- **具体明确**：不使用"基本完成"、"大致可用"等模糊描述
|
|||
|
|
- **可演示**：每个步骤完成后都能展示具体成果
|
|||
|
|
|
|||
|
|
**好的验收标准示例：**
|
|||
|
|
```
|
|||
|
|
- [ ] 执行 `npm run build` 无错误
|
|||
|
|
- [ ] 访问 /api/users 返回 200 和用户列表 JSON
|
|||
|
|
- [ ] 用户可以点击"添加"按钮并在列表中看到新条目
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**不好的验收标准示例：**
|
|||
|
|
```
|
|||
|
|
- [ ] 基本功能可用
|
|||
|
|
- [ ] 接口设计完成
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4. 展示步骤列表
|
|||
|
|
|
|||
|
|
按以下格式展示完整计划：
|
|||
|
|
|
|||
|
|
```markdown
|
|||
|
|
# 实施计划：<项目名称>
|
|||
|
|
|
|||
|
|
> 创建日期：YYYY-MM-DD
|
|||
|
|
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
|
|||
|
|
> 对应设计：docs/design/YYYY-MM-DD-xxx.md
|
|||
|
|
> 状态：待执行
|
|||
|
|
|
|||
|
|
## 步骤概览
|
|||
|
|
|
|||
|
|
| # | 步骤名称 | 依赖 | 状态 |
|
|||
|
|
|---|---------|------|------|
|
|||
|
|
| 1 | xxx | 无 | 待执行 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 步骤 N：<标题>
|
|||
|
|
|
|||
|
|
**目标**：一句话描述
|
|||
|
|
|
|||
|
|
**具体任务**：
|
|||
|
|
- [ ] 任务项 1
|
|||
|
|
- [ ] 任务项 2
|
|||
|
|
|
|||
|
|
**验收标准**：
|
|||
|
|
- [ ] 标准 1（可验证描述）
|
|||
|
|
- [ ] 标准 2
|
|||
|
|
|
|||
|
|
**涉及文件**：
|
|||
|
|
- src/xxx.ts（新建/修改）
|
|||
|
|
|
|||
|
|
**预估复杂度**：低/中/高
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 依赖关系图
|
|||
|
|
|
|||
|
|
步骤 1 → 步骤 2, 3 → 步骤 4
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 5. 用户确认
|
|||
|
|
|
|||
|
|
- 展示完整步骤列表
|
|||
|
|
- 询问是否需要调整（合并、拆分、重排序）
|
|||
|
|
- 修改后循环展示直到用户确认
|
|||
|
|
- 保存为 `docs/plans/YYYY-MM-DD-<项目名>.md`
|
|||
|
|
- 提示下一步可调用 `/dev-develop` 开始开发
|
|||
|
|
|
|||
|
|
## 关键行为
|
|||
|
|
|
|||
|
|
- 验收标准是步骤分解的核心，必须可验证
|
|||
|
|
- 步骤之间依赖关系必须明确，无循环依赖
|
|||
|
|
- 不遗漏设计文档中的任何模块或接口
|
|||
|
|
- 步骤数量适中（通常 3-10 个），避免过度拆分
|