dev-workflow

1# 开发流程五步法
2 
3需求理解 → 方案设计 → 代码实现 → 代码审查 → Bug 修复
4 
5## Step 1：识别当前步骤
6 
7根据用户需求选择对应 reference 文件执行：
8 
9| 步骤 | 文件 | 触发关键词 |
10|------|------|-----------|
11| 需求理解 | [requirement.md](reference/requirement.md) | 需求分析、理解需求、整理需求、帮我梳理 |
12| 方案设计 | [design.md](reference/design.md) | 方案设计、技术设计、架构设计、怎么实现 |
13| 代码实现 | [implementation.md](reference/implementation.md) | 代码实现、开始写代码、帮我实现、写一下 |
14| 代码审查 | [review.md](reference/review.md) | 代码审查、Review、检查代码、看看有没有问题 |
15| Bug 修复 | [bug-fix.md](reference/bug-fix.md) | bug、报错、崩溃、异常、不工作、出错了、测试失败 |
16 
17## Step 2：执行、输出与落盘
18 
19读取对应 reference 中的完整流程，按步骤执行，输出符合该阶段要求的交付物。
20 
21**自动落盘（默认必须写入）：**
22 
23- **需求理解**：`docs/<feature>/01-需求理解.md`
24- **方案设计**：`docs/<feature>/02-方案设计.md`
25 
26**可选落盘（默认不写，仅当用户明确要求时才写入）：**
27 
28- **代码审查**：`docs/<feature>/03-代码审查.md`
29- **Bug 修复**：`docs/<feature>/04-bug修复.md`
30 
31落盘规则：
32 
33- 目录为当前工作目录 `docs/` 下，不存在则创建
34- **按功能划分子目录**：能识别出功能（如登录、测试、部署等）就必须写入 `docs/<feature>/`，即使只有一个功能也不写入根目录；涉及多个功能时各建子目录，同一功能的全部文档归入同一子目录
35- 无法识别功能或跨功能全局性内容（如整体架构设计）：写入 `docs/通用/`
36- `<feature>` 使用稳定标识（建议用功能英文名或代码目录名/包名，如 `login`、`deploy`，避免同义词混用）
37- **演进式更新（不追加）**：主文件永远是最新完整版，结构为 `# 文档标题` → `## 修订记录`（表格：版本 | 日期 | 摘要）→ 本次完整正文
38- **首次写入**：创建文件，修订记录写入 `v1 | YYYY-MM-DD HH:mm | 初版`
39- **再次写入**：先将旧文件整体移入 `docs/<feature>/archive/<原文件名>-v<N>-<YYYYMMDD>.md`（同日多次归档加时分后缀），再重写主文件，修订记录表新增一行（版本号递增，摘要为一句话变更概括）
40- 若用户明确指定了其他文件路径，优先按用户指定路径写入
41- 可选维护 `docs/功能索引.md` 记录功能名与文档路径映射
42 
43## 注意事项
44 
45- 每步完成后提示用户进入下一阶段
46- 上游缺失时：提示用户先完成前置步骤，或简要收集关键信息后继续