Vibe Coding 开发流程：一套可照着执行的 AI 项目开发使用说明书

Vibe Coding 标准开发流程：一套可照着执行的 AI 项目开发 SOP

适用场景：Claude Code + Superpowers Skills、Codex CLI、Cursor、Gemini CLI，以及其他 AI 编程工具。
核心目标：让 AI 项目开发从“想到哪写到哪”，变成“按阶段推进、按文档验收、按 Git 留痕、按测试闭环”。

很多人用 AI 写代码时，最大的问题不是 AI 不够强，而是流程太松散：

• 需求还没想清楚，就开始让 AI 写代码；
• 文档没有沉淀，后续上下文很快丢失；
• 前后端接口没有约定，联调阶段反复返工；
• 没有阶段验收，项目越做越乱；
• 没有测试和 Git 节点，出了问题很难回滚。

这篇文档整理了一套Vibe Coding 标准开发流程。可以作为以后每个 AI 编程项目的执行 SOP。

你可以把它理解为一套项目推进清单：每个阶段都有明确的目标、输入、推荐 Skills、执行步骤、交付物、完成标准和注意事项。做完一个阶段，验收通过，再进入下一个阶段。

一、这套流程适合谁？

如果你正在使用以下工具做项目开发，这套流程都适用：

• Claude Code + Superpowers Skills
• Codex CLI / Codex App
• Cursor
• Gemini CLI
• 其他支持文件读写、代码生成、测试执行的 AI 编程工具

其中，Claude Code + Superpowers Skills是最推荐的组合，因为 Skills 可以把“需求分析、计划编写、调试、测试、Code Review”等动作拆成稳定流程，减少 AI 随机发挥。

二、核心原则

1. Documentation First：先文档，后实现

不要一上来就写代码。先让 AI 和你一起产出 PRD、架构设计、数据库设计、API 文档等关键材料。

文档不是形式主义，而是 AI 项目的长期上下文。

2. Stage Gate：阶段门禁

每个阶段都有完成标准。没有完成标准，就不要进入下一阶段。

例如：PRD 没确认，不做原型；API 没稳定，不做前端联调；测试没通过，不进入发布。

3. Git Driven：每阶段都提交

每完成一个阶段，就提交一次 Git Commit。

这样可以保证项目过程可追溯、可回滚、可协作。

4. Test Driven：关键逻辑用测试闭环

后端接口、核心业务逻辑、前端关键流程，都应该有测试覆盖。

AI 写代码速度很快，但测试可以帮你判断它是否真的写对。

5. Skills Driven：不同阶段调用不同 Skills

不要让一个通用 Prompt 贯穿全项目。不同阶段应该使用不同的 Skills 或工作模式：

• 需求阶段用 brainstorming；
• 计划阶段用 writing-plans；
• 执行阶段用 executing-plans 或 subagent-driven-development；
• 调试阶段用 systematic-debugging；
• 测试阶段用 test-driven-development；
• 评审阶段用 requesting-code-review / receiving-code-review。

三、整体流程图

如果 CSDN 的 Mermaid 渲染不稳定，可以直接看下面这张总览表。

四、阶段总览表

五、推荐 Skills 功能速查

下面这张表可以作为以后做 Vibe Coding 项目时的 Skills 选择指南。

如果某个工具环境里没有对应 Skill，也可以把“功能说明”和“典型产出”改写成 Prompt，让 AI 按同样的工作方式执行。

建议记住一个简单规则：

想清楚需求：brainstorming 写执行计划：writing-plans 按计划执行：executing-plans / subagent-driven-development 写测试闭环：test-driven-development 修复杂问题：systematic-debugging 发布前审查：requesting-code-review + receiving-code-review + finishing-a-development-branch

六、Stage 0：项目初始化

阶段目标

建立项目的基础结构、协作规范和 AI 上下文文件，为后续阶段提供稳定起点。

前置输入

• 项目名称
• 项目大致方向
• 技术栈初步想法
• 目标运行环境

推荐 Skills

• using-superpowers
• brainstorming

执行步骤

1. 创建 Git 仓库。
2. 初始化README.md。
3. 创建CLAUDE.md或同类 AI 项目记忆文件。
4. 创建docs/目录，用于保存 PRD、架构、API、测试报告等文档。
5. 创建基础目录，例如frontend/、backend/、scripts/、tests/。
6. 确认技术栈，例如前端框架、后端语言、数据库、缓存、部署方式。
7. 记录阶段状态和下一步待办。

推荐 Prompt

请帮我初始化这个 Vibe Coding 项目的开发规范。 项目信息： - 项目名称： - 项目类型： - 目标用户： - 计划技术栈： 请输出： 1. README.md 初稿 2. CLAUDE.md 项目记忆文件 3. 推荐目录结构 4. 后续开发阶段清单 5. Stage 0 完成检查清单

交付物

README.md CLAUDE.md docs/ frontend/ backend/ Git 初始化记录

完成标准

• 项目目录已经创建。
• README 能说明项目是什么。
• AI 项目记忆文件已经包含技术栈、目录约定和工作流。
• Git 仓库可以正常提交。
• 下一阶段的需求分析已有明确入口。

注意事项

不要把CLAUDE.md当成摆设。每完成一个阶段，都应该更新其中的当前进度、交付物、待办事项和关键决策。

七、Stage 1：需求分析（PRD）

阶段目标

把模糊想法整理成可执行的产品需求文档，明确要做什么、不做什么、先做什么。

前置输入

• 项目想法
• 目标用户
• 核心使用场景
• 初步功能列表

推荐 Skills

• brainstorming
• verification-before-completion

执行步骤

1. 使用brainstorming和 AI 讨论需求边界。
2. 明确目标用户、核心场景、业务流程和 MVP 范围。
3. 输出 PRD 初稿。
4. 使用verification-before-completion检查遗漏功能、边界条件和异常流程。
5. 根据检查结果修订 PRD。
6. 将 PRD 保存到docs/01-PRD.md。

推荐 Prompt

请基于以下项目描述，帮我输出一份完整 PRD。 项目描述： 【在这里填写项目背景和想法】 PRD 需要包含： 1. 项目背景 2. 目标用户 3. 用户痛点 4. 核心功能模块 5. 页面流程 6. 非功能需求 7. MVP 范围 8. 暂不实现的功能 9. 边界场景和异常流程 10. Stage 1 完成检查清单

交付物

docs/01-PRD.md

完成标准

• 功能范围清晰。
• MVP 边界明确。
• 页面流程和用户路径可描述。
• 异常流程和边界条件已经列出。
• 后续原型设计可以直接基于 PRD 展开。

注意事项

PRD 未确认前，不要直接写代码。AI 编程最常见的返工，通常都来自需求阶段没有说清楚。

八、Stage 2：产品原型设计

阶段目标

基于 PRD 设计页面结构、用户流程和关键交互，让开发前先看见产品形态。

前置输入

• docs/01-PRD.md
• MVP 功能范围
• 用户路径

推荐 Skills

• executing-plans
• using-git-worktrees

执行步骤

1. 根据 PRD 梳理页面清单。
2. 为每个页面定义核心功能和入口出口。
3. 设计用户流程，例如登录、创建、编辑、提交、查询、管理等路径。
4. 输出 Wireframe 或低保真原型。
5. 如果需要写原型代码，建议放到独立分支或 worktree，避免污染主分支。
6. 评审原型是否覆盖 PRD 中的主流程和异常流程。

推荐 Prompt

请根据以下 PRD，设计产品原型方案。 输入： - PRD 内容： 【粘贴 docs/01-PRD.md】 请输出： 1. 页面清单 2. 页面之间的跳转关系 3. 每个页面的核心区域 4. 关键用户流程 5. Wireframe 文本草图 6. 原型开发建议 7. Stage 2 完成检查清单

交付物

页面结构说明 页面流程图 Wireframe Prototype

完成标准

• PRD 中的核心功能都能在页面中找到对应入口。
• 页面流程能支撑完整 MVP。
• 关键异常状态有展示方案。
• 前端架构设计可以基于原型继续推进。

注意事项

原型阶段不要过早追求视觉细节。此阶段的重点是流程正确、信息结构正确、主路径可走通。

九、Stage 3：数据库与系统架构设计

阶段目标

完成系统的核心技术设计，包括数据库、后端架构、前端架构和关键基础设施。

前置输入

• PRD
• 产品原型
• 技术栈选择
• 业务实体和核心流程

推荐 Skills

• dispatching-parallel-agents

执行步骤

1. 将架构设计拆成三个方向并行推进：数据库设计、后端架构、前端架构。
2. 数据库方向输出 ER 图、表结构、索引设计和初始化 SQL。
3. 后端方向输出模块划分、目录结构、权限、缓存、日志、异常处理和部署方案。
4. 前端方向输出页面结构、组件划分、路由、状态管理和接口调用规划。
5. 汇总三个方向，检查边界是否一致。
6. 保存架构文档和数据库脚本。

推荐 Prompt

请根据 PRD 和产品原型，帮我完成系统架构设计。 输入： - PRD： 【粘贴 PRD】 - 产品原型： 【粘贴页面结构和流程】 - 技术栈： 【填写技术栈】 请分别输出： 1. 数据库设计：ER 图、表结构、索引、SQL 2. 后端架构：目录结构、模块划分、权限、缓存、日志、异常处理、部署方案 3. 前端架构：页面结构、组件划分、路由、状态管理、接口规划 4. 架构风险点 5. Stage 3 完成检查清单

交付物

docs/02-Database.md docs/03-Architecture.md docs/database.sql

完成标准

• 核心业务实体已经建模。
• 表结构和业务流程对应。
• 后端模块边界清楚。
• 前端页面、组件、状态和接口关系清楚。
• 架构文档能指导后续工程开发。

注意事项

数据库设计和架构设计不要完全交给 AI 一次生成后就直接使用。至少要人工检查实体关系、权限边界、索引合理性和扩展风险。

十、Stage 4：后端工程开发

阶段目标

根据 PRD、数据库设计和架构设计，快速生成标准后端工程骨架，并逐步补充业务逻辑。

前置输入

• PRD
• 数据库设计
• 系统架构设计
• 技术栈和后端框架

推荐 Skills

• subagent-driven-development

执行步骤

1. 先生成后端基础工程目录。
2. 创建 Controller、Service、Repository、Entity、DTO 等分层结构。
3. 添加统一配置、异常处理、中间件、日志和权限基础能力。
4. 按模块逐步补充业务代码。
5. 每完成一个模块，执行基础运行检查。
6. 更新项目文档和 Git Commit。

推荐 Prompt

请根据以下文档生成后端工程骨架。 输入： - PRD： 【粘贴 PRD】 - 数据库设计： 【粘贴数据库文档】 - 系统架构： 【粘贴架构文档】 - 后端技术栈： 【填写框架和数据库】 请输出： 1. 后端目录结构 2. Controller / Service / Repository / Entity / DTO 划分 3. 配置文件设计 4. 统一异常处理 5. 权限和中间件设计 6. 模块开发顺序 7. Stage 4 完成检查清单

交付物

backend/ 后端工程目录 基础配置 核心模块代码

完成标准

• 后端项目可以启动。
• 目录结构符合架构文档。
• 核心模块已经有清晰分层。
• 基础异常、日志、权限或中间件框架已经建立。
• 可以进入后端测试阶段。

注意事项

建议先生成脚手架，再补业务逻辑。不要让 AI 一次性生成大量业务代码，否则排查成本会变高。

十一、Stage 5：后端测试（TDD）

阶段目标

通过测试保证后端接口和核心业务逻辑稳定。

前置输入

• 后端工程
• PRD
• 数据库设计
• API 初步约定

推荐 Skills

• test-driven-development

执行步骤

1. 为核心业务接口编写测试计划。
2. 先写失败测试，明确期望行为。
3. 运行测试，确认失败原因符合预期。
4. 实现最小业务代码，让测试通过。
5. 补充异常场景和边界条件测试。
6. 重构代码并保持测试通过。
7. 输出测试报告。

推荐 Prompt

请基于以下后端模块，帮我设计 TDD 测试方案。 输入： - 模块名称： - 接口列表： - 业务规则： - 异常场景： 请输出： 1. 测试用例清单 2. 正常流程测试 3. 异常流程测试 4. 边界条件测试 5. Mock 数据设计 6. 覆盖率建议 7. Stage 5 完成检查清单

交付物

Test Plan Unit Test Integration Test Coverage Report

完成标准

• 核心业务接口有测试覆盖。
• 正常流程和异常流程都经过验证。
• 测试可以在本地稳定运行。
• 修复代码后没有破坏已有测试。

注意事项

测试不是最后补文档。TDD 的价值在于先明确行为，再让 AI 实现代码。

十二、Stage 6：API 文档

阶段目标

生成标准接口文档，让前端开发和联调有明确契约。

前置输入

• 后端路由
• DTO
• Response 结构
• 权限规则
• 错误码

推荐 Skills

• executing-plans

执行步骤

1. 扫描后端 Router、Controller、DTO 和 Response。
2. 统一接口路径、请求参数、响应格式和错误码。
3. 生成 Markdown API 文档。
4. 如项目支持，生成 Swagger 或 OpenAPI。
5. 让前端依据 API 文档确认字段、状态码和异常响应。
6. 将 API 文档纳入 Git 版本管理。

推荐 Prompt

请根据以下后端接口代码或路由定义，生成标准 API 文档。 输入： - Router / Controller： 【粘贴代码或路由】 - DTO： 【粘贴 DTO】 - Response： 【粘贴响应结构】 请输出： 1. 接口列表 2. 请求方法和路径 3. 请求参数 4. 响应字段 5. 错误码 6. 鉴权要求 7. Swagger / OpenAPI 建议 8. Stage 6 完成检查清单

交付物

docs/04-API.md Swagger OpenAPI

完成标准

• 每个接口都有请求和响应说明。
• 字段类型明确。
• 错误码和异常响应明确。
• 前端可以不读后端代码，仅凭 API 文档进行开发。

注意事项

API 文档是前后端契约。后端代码变更后，要同步更新 API 文档，否则联调阶段会大量返工。

十三、Stage 7：前端开发

阶段目标

根据 PRD、产品原型、API 文档和前端架构，实现前端页面和交互流程。

前置输入

• PRD
• 产品原型
• API 文档
• 前端架构设计

推荐 Skills

• subagent-driven-development

执行步骤

1. 初始化前端工程。
2. 根据页面结构创建路由。
3. 根据组件划分实现基础组件。
4. 封装 API 请求层。
5. 实现状态管理。
6. 按页面逐步开发主流程。
7. 接入 Mock API 或真实 API。
8. 更新前端说明文档。

推荐 Prompt

请根据以下材料生成前端开发计划并实现页面。 输入： - PRD： 【粘贴 PRD】 - 产品原型： 【粘贴页面说明】 - API 文档： 【粘贴 API】 - 前端架构： 【粘贴前端架构】 请输出： 1. 前端目录结构 2. 路由设计 3. 组件划分 4. 状态管理方案 5. API 请求封装 6. 页面开发顺序 7. Stage 7 完成检查清单

交付物

frontend/ 页面 组件 状态管理 请求封装 路由配置

完成标准

• 核心页面已经实现。
• 主流程可以操作。
• API 请求层已封装。
• 页面状态、加载态、空状态和错误态有基本处理。
• 可以进入前端测试阶段。

注意事项

不要把 API 调用散落在每个组件里。建议统一封装请求层，降低后续接口调整成本。

十四、Stage 8：前端测试

阶段目标

验证页面渲染、交互行为、接口调用和异常状态，保证前端主流程可用。

前置输入

• 前端工程
• API 文档
• Mock 数据
• 产品原型

推荐 Skills

• test-driven-development

执行步骤

1. 编写页面渲染测试。
2. 编写组件交互测试。
3. 使用 Mock API 验证接口调用。
4. 覆盖登录、权限、表单、空状态、错误页面等关键场景。
5. 运行测试并修复失败项。
6. 输出前端测试报告。

推荐 Prompt

请为以下前端页面设计测试方案。 输入： - 页面名称： - 页面功能： - 组件列表： - API 调用： - 异常场景： 请输出： 1. 页面渲染测试 2. 组件交互测试 3. Mock API 测试 4. 权限和登录测试 5. 表单校验测试 6. 异常页面测试 7. Stage 8 完成检查清单

交付物

Frontend Test Report 页面测试 组件测试 Mock API 测试

完成标准

• 核心页面可以稳定渲染。
• 关键交互有测试覆盖。
• API 成功和失败状态都经过验证。
• 登录、权限和表单流程可用。

注意事项

前端测试不要只测“页面能不能打开”。真正重要的是用户能否完成关键任务，以及异常状态是否可恢复。

十五、Stage 9：前后端联调

阶段目标

修复前后端集成过程中的问题，让系统主流程完整跑通。

前置输入

• 后端服务
• 前端工程
• API 文档
• 测试数据
• 环境配置

推荐 Skills

• systematic-debugging

执行步骤

1. 启动前端和后端服务。
2. 按用户主流程逐步验证。
3. 记录所有联调问题。
4. 对每个问题定位根因，例如 Token、权限、参数、接口、Redis、数据库、缓存或第三方接口。
5. 修复后补充回归测试。
6. 输出 Bug Report 和联调完成报告。

推荐 Prompt

请使用系统化调试方式，帮我分析以下前后端联调问题。 问题描述： 【填写现象】 已知信息： - 前端请求： - 后端日志： - API 文档： - 数据库状态： - 环境配置： 请输出： 1. 可能原因列表 2. 最小复现步骤 3. 根因判断 4. 修复方案 5. 回归测试建议 6. Stage 9 完成检查清单

交付物

Bug Report Root Cause Regression Test 联调完成报告

完成标准

• 用户主流程可以完整跑通。
• 已知联调问题全部有处理结论。
• 修复项有回归测试或验证记录。
• 前后端接口契约已经同步。

注意事项

联调时不要凭感觉改代码。先复现，再定位根因，再修复，再回归验证。

十六、Stage 10：Code Review 与发布

阶段目标

完成代码评审、修复评审问题，并发布可追溯版本。

前置输入

• 已完成联调的代码
• 测试报告
• API 文档
• 部署说明
• Git 分支

推荐 Skills

• requesting-code-review
• receiving-code-review
• finishing-a-development-branch

执行步骤

1. 使用requesting-code-review发起代码评审。
2. 让 AI 或团队成员检查 bug、风险、测试缺口和架构问题。
3. 使用receiving-code-review逐条处理评审意见。
4. 重新运行测试和关键流程验证。
5. 合并分支。
6. 生成 Release Note。
7. 创建 Tag 或发布版本。
8. 更新部署文档和项目状态。

推荐 Prompt

请对当前项目进行发布前 Code Review。 请重点检查： 1. 是否存在明显 bug 2. 是否有安全风险 3. 是否有接口兼容问题 4. 是否有未覆盖测试的关键逻辑 5. 是否有部署风险 6. 是否有文档缺失 请按严重程度输出问题，并给出修复建议。

交付物

Code Review Report Review Fix Commit Release Note PR Tag 部署文档

完成标准

• Code Review 问题已经处理。
• 测试通过。
• Release Note 已生成。
• 版本号或 Tag 已创建。
• 部署步骤清晰。

注意事项

不要跳过 Code Review。AI 写出来的代码也需要评审，尤其是权限、安全、数据一致性和异常处理部分。

十七、每阶段 Git Commit 建议

建议每完成一个阶段提交一次，Commit Message 可以参考：

chore: initialize project structure docs: add project PRD docs: add product prototype docs: add database and architecture design feat: scaffold backend project test: add backend api tests docs: add api documentation feat: implement frontend pages test: add frontend tests fix: resolve integration issues chore: prepare release

如果某个阶段内容较多，可以拆成多个小提交。例如 Stage 3 可以拆为：

docs: add database design docs: add backend architecture docs: add frontend architecture

十八、每个阶段都要更新 CLAUDE.md

如果你使用 Claude Code 或其他支持项目记忆的 AI 编程工具，建议每个阶段结束时都更新一次CLAUDE.md。

建议记录：

当前阶段： 已完成内容： 核心交付物： 关键决策： Git Commit： 待办事项： 下一阶段入口：

这样做的好处是：即使中途换会话、换模型、换工具，项目上下文也不会完全丢失。

十九、Vibe Coding 项目执行检查清单

下面这份清单可以在每个新项目开工时复制使用。

# Vibe Coding 项目执行检查清单 ## Stage 0：项目初始化 - [ ] 创建 Git 仓库 - [ ] 初始化 README.md - [ ] 初始化 CLAUDE.md - [ ] 创建 docs/ 目录 - [ ] 创建 frontend/ 和 backend/ 目录 - [ ] 确认技术栈 - [ ] 提交 Git Commit ## Stage 1：需求分析 PRD - [ ] 使用 brainstorming 分析需求 - [ ] 输出 docs/01-PRD.md - [ ] 明确 MVP 范围 - [ ] 检查异常流程和边界问题 - [ ] 使用 verification-before-completion 复查 - [ ] 提交 Git Commit ## Stage 2：产品原型设计 - [ ] 输出页面清单 - [ ] 输出页面流程 - [ ] 输出 Wireframe 或 Prototype - [ ] 检查是否覆盖 PRD 主流程 - [ ] 提交 Git Commit ## Stage 3：数据库与系统架构 - [ ] 输出数据库设计 - [ ] 输出 database.sql - [ ] 输出后端架构设计 - [ ] 输出前端架构设计 - [ ] 检查实体、接口、页面是否一致 - [ ] 提交 Git Commit ## Stage 4：后端工程开发 - [ ] 生成后端工程骨架 - [ ] 创建 Controller / Service / Repository / Entity / DTO - [ ] 添加配置、异常、日志、权限基础能力 - [ ] 后端项目可以启动 - [ ] 提交 Git Commit ## Stage 5：后端测试 - [ ] 编写测试计划 - [ ] 编写单元测试 - [ ] 编写集成测试 - [ ] 覆盖正常流程和异常流程 - [ ] 测试通过 - [ ] 提交 Git Commit ## Stage 6：API 文档 - [ ] 扫描 Router / DTO / Response - [ ] 输出 docs/04-API.md - [ ] 生成 Swagger 或 OpenAPI - [ ] 前端确认接口契约 - [ ] 提交 Git Commit ## Stage 7：前端开发 - [ ] 初始化前端工程 - [ ] 创建路由 - [ ] 创建组件 - [ ] 封装 API 请求 - [ ] 实现状态管理 - [ ] 主流程页面可操作 - [ ] 提交 Git Commit ## Stage 8：前端测试 - [ ] 编写页面测试 - [ ] 编写组件测试 - [ ] 编写 Mock API 测试 - [ ] 覆盖登录、权限、表单、异常页面 - [ ] 测试通过 - [ ] 提交 Git Commit ## Stage 9：前后端联调 - [ ] 启动前后端服务 - [ ] 跑通用户主流程 - [ ] 记录联调问题 - [ ] 定位 Root Cause - [ ] 修复并添加回归测试 - [ ] 输出联调完成报告 - [ ] 提交 Git Commit ## Stage 10：Code Review 与发布 - [ ] 发起 Code Review - [ ] 修复评审问题 - [ ] 重新运行测试 - [ ] 生成 Release Note - [ ] 创建 PR / Tag / Release - [ ] 更新部署文档 - [ ] 提交 Git Commit

二十、一句话记住整个流程

初始化 ↓ 需求 PRD ↓ 产品原型 ↓ 数据库 + 架构 ↓ 后端开发 ↓ 后端测试 ↓ API 文档 ↓ 前端开发 ↓ 前端测试 ↓ 前后端联调 ↓ Code Review ↓ 发布

二十一、总结

Vibe Coding 的重点不是“让 AI 多写代码”，而是“让 AI 在正确的流程里写代码”。

真正稳定的 AI 项目开发，应该做到：

• 每个阶段有文档；
• 每个阶段有交付物；
• 每个阶段有完成标准；
• 每个阶段有 Git 记录；
• 关键逻辑有测试；
• 发布前有 Review。

按照这套 Workflow 执行，AI 编程会从一次性的代码生成，变成可持续推进、可复盘、可协作的工程流程。