Vibe Coding 工作流模板
一套结构化的 AI 辅助开发工作流,将完整开发过程拆分为 4 个阶段,逐层递进、模块解耦、减少上下文压力。
Prompt 模板
每个阶段的 prompt 统一使用以下格式:
markdown
## [阶段名称]
- **目标**:一句话描述这个阶段要达成什么
- **输入**:列出所有输入文件/信息
- **输出**:明确产物路径和格式
- **步骤**:有序的执行步骤
- **约束**:不可猜测、必须提问等规则
- **完成标准**:什么情况下视为完成
- **回退条件**:什么情况下需要回退修改
阶段一:确定需求
- 目标:通过与 AI 对话,逐步确认并生成需求文档
- 输入:用户口头描述 + 项目技术栈信息
- 输出 :
doc/requirement.md - 步骤 :
- 描述项目背景和目标
- AI 通过提问确认不明确的需求细节
- 确认后生成结构化需求文档
- 约束 :
- 不猜测用户意图,任何不明确的地方必须提问
- 用户不熟悉的技术领域,AI 需给出选项供选择
- 完成标准:用户确认需求文档内容无误
- 回退条件:用户发现遗漏需求或需求变更时,回到本阶段修改
示例 Prompt
markdown
目标:
我希望用 react 开发一个 cf 类型的 web 游戏,现在帮我完成需求文档。
输入:
当前文件夹是一个 react cli 创建的项目,可以使用 antd、three.js 等相关库实现。
输出:
请在 doc 文件夹下生成需求文档 requirement.md。
步骤:
1. 我不太了解 three.js 相关库等知识。
2. 请使用提问等方式和我确认需求。
3. 不要猜测我的意图,任何不明确的地方都必须向我提问。
完成标准:
我确认需求文档内容完整且准确。
回退条件:
如果后续设计阶段发现需求遗漏,回到本阶段补充。
阶段二:方案设计
- 目标:基于需求文档,生成模块化的详细设计文档
- 输入 :
doc/requirement.md - 输出 :
doc/design.md - 步骤 :
- 阅读需求文档,按功能划分模块
- 为每个模块编写详细设计(接口、数据结构、交互流程)
- 确保模块间松耦合,可独立测试
- 约束 :
- 不猜测意图,不明确的地方必须提问
- 模块间通过明确接口通信,避免隐式依赖
- 完成标准:每个模块有清晰的职责边界、接口定义和数据流描述
- 回退条件:设计评审发现与需求不一致时,回到需求阶段修改
建议
⚠️ 如果方案设计占用的上下文较多,建议新开一个会话处理,在 prompt 中明确引用需求文档路径。后续实现也是如此。
示例 Prompt
markdown
目标:
根据需求文档生成详细的设计文档。
输入:
需求文档 doc/requirement.md。
输出:
在 doc 文件夹下生成详细的设计文档 design.md。
步骤:
1. 根据需求文档的内容,按模块编写详细设计文档。
2. 模块与模块之间尽量保持相互独立,可以独立进行测试。
3. 不要猜测我的意图,任何不明确的地方都必须向我提问。
完成标准:
每个模块有明确的接口定义、数据结构和交互流程图。
回退条件:
如果设计与需求冲突,回到需求阶段确认后修改。
阶段三:划分任务
- 目标:将设计文档拆解为最小可执行任务,按模块管理
- 输入 :
doc/requirement.md+doc/design.md - 输出 :
doc/tasks/{module-name}.md(每个模块一个文件)doc/tasks/progress.md(总体进度 checklist)
- 步骤 :
- 按模块拆分任务,每个任务应可在单次会话内完成
- 标注任务间的依赖关系和执行优先级
- 生成总体进度文件,用 checklist 跟踪完成状态
- 约束 :
- 每个任务应足够小,避免单次会话上下文溢出
- 任务描述应包含足够上下文,使新会话无需阅读全部历史
- 完成标准:所有模块的任务已拆分,进度文件可追踪
- 回退条件:实现过程中发现任务粒度不合适,回到本阶段调整
示例 Prompt
markdown
目标:
为每个模块划分最小可执行任务。
输入:
需求文档 doc/requirement.md。
详细设计文档 doc/design.md。
输出:
- 任务列表:doc/tasks/{module-name}.md(每个模块对应一个)
- 总体进度:doc/tasks/progress.md
步骤:
1. 根据需求文档和设计文档,为每个模块生成 vibe coding 用的最小任务。
2. 每个模块对应一个 {module-name}.md。
3. 在 progress.md 中用 checklist 表示子任务完成状态。
4. 标注任务优先级和依赖关系。
完成标准:
- 每个任务可在单次 AI 会话中完成
- progress.md 覆盖所有任务且依赖关系清晰
progress.md 建议格式
markdown
## 总体进度
### 模块 A
- [x] 任务 1 - 基础数据结构定义 (P0, 无依赖)
- [ ] 任务 2 - 核心逻辑实现 (P0, 依赖任务1)
- [ ] 任务 3 - 单元测试 (P1, 依赖任务2)
### 模块 B
- [ ] 任务 1 - 接口定义 (P0, 无依赖)
- [ ] 任务 2 - UI 组件实现 (P1, 依赖模块A任务2)
阶段四:实现需求
- 目标:生成 vibeCoding 起始 Prompt,用主 Agent + 子 Agent 模式自动实现代码
- 输入 :
doc/requirement.md+doc/design.md+doc/tasks/ - 输出 :
doc/prompt.md+ 实际代码产物 - 步骤 :
- 阅读所有输入,生成
doc/prompt.md作为主 Agent 的起始 Prompt - 主 Agent 跟踪整体进度,按依赖顺序调度子任务
- 子 Agent 实现每个模块并完成测试
- 主 Agent 验证集成,更新
progress.md
- 阅读所有输入,生成
- 约束 :
- UI 组件使用快照测试,业务逻辑必须有单元测试
- 每个子 Agent 会话应自包含,不依赖其他会话的上下文
- 生成 prompt 过程中如有不明确之处必须提问
- 完成标准:所有任务完成、测试通过、progress.md 全部打勾
- 回退条件:集成测试失败时,定位到具体模块回退修改
示例 Prompt
markdown
目标:
生成 vibeCoding 的 prompt。
输入:
需求文档 doc/requirement.md。
详细设计文档 doc/design.md。
任务划分 doc/tasks。
输出:
doc/prompt.md
步骤:
1. 阅读输入信息,了解当前要实现的工程,生成 doc/prompt.md 作为 vibeCoding 的起始 Prompt。
2. 主 Agent 用来跟踪整体进度。
3. 主 Agent 生成子 Agent,实现每一个模块并完成测试,整个过程不会有人工参与。
4. UI 组件用快照测试,业务逻辑必须有单元测试。
5. 生成 prompt 过程中,如果有任何不明确的地方都必须向我提问。
完成标准:
- prompt.md 可直接交给 AI 执行,无需额外人工补充信息
- 包含清晰的 Agent 调度策略和验收标准
最佳实践
上下文管理
- 每个阶段建议新开会话,通过文件路径引用上一阶段产物
- 避免单次会话承载过多信息导致质量下降
- 任务描述应自包含,新会话仅需读取对应的任务文件即可开始工作
质量保障
- UI 组件:快照测试 / E2E 测试
- 业务逻辑:必须有单元测试
- 集成验证:主 Agent 在所有子任务完成后执行集成检查
常见陷阱
| 陷阱 | 解决方案 |
|---|---|
| 需求模糊导致后续返工 | 阶段一充分提问,不跳过确认环节 |
| 模块耦合导致无法独立测试 | 阶段二严格定义接口,禁止隐式依赖 |
| 任务粒度过大,单次会话无法完成 | 阶段三确保每个任务可在 1 次会话内完成 |
| 子 Agent 缺少上下文 | 任务文件应包含完整的接口定义和依赖说明 |
| 跳过测试导致集成失败 | 约束中明确测试要求,主 Agent 验证测试覆盖率 |
文件结构参考
ruby
project/
├── doc/
│ ├── requirement.md # 需求文档
│ ├── design.md # 详细设计文档
│ ├── prompt.md # vibeCoding 起始 Prompt
│ └── tasks/
│ ├── module-a.md # 模块 A 任务列表
│ ├── module-b.md # 模块 B 任务列表
│ └── progress.md # 总体进度追踪
├── src/ # 源代码