开发流程五步法

需求理解 → 方案设计 → 代码实现 → 代码审查 → Bug 修复

使用时机

• 用户描述新功能/项目想法，需要需求分析
• 用户提到「方案设计」「架构设计」「怎么实现」
• 用户提到「代码实现」「开始写代码」「帮我实现」
• 用户提到「代码审查」「Review」「检查代码」「看看有没有问题」
• 用户提到「bug」「报错」「崩溃」「异常」「不工作」「出错了」「测试失败」

Step 1：识别当前步骤

根据用户需求选择对应 reference 文件执行：

步骤	文件	触发关键词
需求理解	requirement.md	需求分析、理解需求、整理需求、帮我梳理
方案设计	design.md	方案设计、技术设计、架构设计、怎么实现
代码实现	implementation.md	代码实现、开始写代码、帮我实现、写一下
代码审查	review.md	代码审查、Review、检查代码、看看有没有问题
Bug 修复	bug-fix.md	bug、报错、崩溃、异常、不工作、出错了、测试失败

Step 2：收集输入

• 需求理解：从用户描述或对话中提取功能想法、约束条件
• 方案设计：确认已有需求文档，或简要收集关键信息
• 代码实现：确认已有技术方案，或根据需求快速拟定实现思路
• 代码审查：明确审查范围（哪些文件/模块）
• Bug 修复：确认错误信息、复现步骤、环境信息

Step 3：执行、输出与自动落盘

读取对应 reference 中的完整流程，按步骤执行，输出符合该阶段要求的交付物。

其中以下步骤必须自动写入文档：

• 需求理解：
  • 单模块/未指定模块：将最终需求文档追加写入当前工作目录的 docs/需求理解.md
  • 多模块且已识别模块名：将最终需求文档追加写入 docs/<module>/需求理解.md
• 方案设计：
  • 单模块/未指定模块：将最终方案文档追加写入当前工作目录的 docs/方案设计.md
  • 多模块且已识别模块名：将最终方案文档追加写入 docs/<module>/方案设计.md
• 代码审查：
  • 单模块/未指定模块：将最终审查报告追加写入当前工作目录的 docs/代码审查.md
  • 多模块且已识别模块名：将最终审查报告追加写入 docs/<module>/代码审查.md

落盘规则：

• 默认目录为当前工作目录 docs/，若不存在则创建后再写入
• 多模块项目优先使用 docs/<module>/ 分目录；若无法确定模块则回退到 docs/ 根目录
• <module> 使用稳定标识（建议用目录名/包名，避免同义词）
• 文件不存在则创建，存在则追加，不覆盖历史内容
• 每次新增内容前写入时间标题：## YYYY-MM-DD HH:mm
• 标题后粘贴本次完整输出正文，末尾加分隔线 ---
• 若用户明确指定了其他文件路径，优先按用户指定路径写入
• 可选维护 docs/模块索引.md 记录模块名与文档路径映射，便于检索与归档

注意事项

• 流程串联：需求理解 → 方案设计 → 代码实现 → 代码审查 → Bug 修复；每步完成后提示用户进入下一阶段

• 上游缺失时：提示用户先完成前置步骤，或简要收集关键信息后继续

• 需求理解、方案设计与代码审查阶段默认必须自动落盘（追加写入），不要覆盖历史记录