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。

三、整体流程图

#mermaid-svg-l3I9EpaqASaaQ1Kj{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-l3I9EpaqASaaQ1Kj .error-icon{fill:#552222;}#mermaid-svg-l3I9EpaqASaaQ1Kj .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-l3I9EpaqASaaQ1Kj .marker{fill:#333333;stroke:#333333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .marker.cross{stroke:#333333;}#mermaid-svg-l3I9EpaqASaaQ1Kj svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-l3I9EpaqASaaQ1Kj p{margin:0;}#mermaid-svg-l3I9EpaqASaaQ1Kj .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster-label text{fill:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster-label span{color:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster-label span p{background-color:transparent;}#mermaid-svg-l3I9EpaqASaaQ1Kj .label text,#mermaid-svg-l3I9EpaqASaaQ1Kj span{fill:#333;color:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .node rect,#mermaid-svg-l3I9EpaqASaaQ1Kj .node circle,#mermaid-svg-l3I9EpaqASaaQ1Kj .node ellipse,#mermaid-svg-l3I9EpaqASaaQ1Kj .node polygon,#mermaid-svg-l3I9EpaqASaaQ1Kj .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .rough-node .label text,#mermaid-svg-l3I9EpaqASaaQ1Kj .node .label text,#mermaid-svg-l3I9EpaqASaaQ1Kj .image-shape .label,#mermaid-svg-l3I9EpaqASaaQ1Kj .icon-shape .label{text-anchor:middle;}#mermaid-svg-l3I9EpaqASaaQ1Kj .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .rough-node .label,#mermaid-svg-l3I9EpaqASaaQ1Kj .node .label,#mermaid-svg-l3I9EpaqASaaQ1Kj .image-shape .label,#mermaid-svg-l3I9EpaqASaaQ1Kj .icon-shape .label{text-align:center;}#mermaid-svg-l3I9EpaqASaaQ1Kj .node.clickable{cursor:pointer;}#mermaid-svg-l3I9EpaqASaaQ1Kj .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .arrowheadPath{fill:#333333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-l3I9EpaqASaaQ1Kj .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-l3I9EpaqASaaQ1Kj .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-l3I9EpaqASaaQ1Kj .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster text{fill:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj .cluster span{color:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-l3I9EpaqASaaQ1Kj .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-l3I9EpaqASaaQ1Kj rect.text{fill:none;stroke-width:0;}#mermaid-svg-l3I9EpaqASaaQ1Kj .icon-shape,#mermaid-svg-l3I9EpaqASaaQ1Kj .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-l3I9EpaqASaaQ1Kj .icon-shape p,#mermaid-svg-l3I9EpaqASaaQ1Kj .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-l3I9EpaqASaaQ1Kj .icon-shape .label rect,#mermaid-svg-l3I9EpaqASaaQ1Kj .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-l3I9EpaqASaaQ1Kj .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-l3I9EpaqASaaQ1Kj .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-l3I9EpaqASaaQ1Kj :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Stage 0 项目初始化
Stage 1 需求分析 PRD
Stage 2 产品原型设计
Stage 3 数据库与系统架构
Stage 4 后端工程开发
Stage 5 后端 TDD 测试
Stage 6 API 文档
Stage 7 前端开发
Stage 8 前端测试
Stage 9 前后端联调
Stage 10 Code Review 与发布

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

四、阶段总览表

阶段	阶段目标	推荐 Skills	核心交付物	通过标准
Stage 0	初始化项目规范和目录	using-superpowers、brainstorming	README、CLAUDE.md、项目目录	项目结构清晰，可开始需求分析
Stage 1	输出 PRD	brainstorming、verification-before-completion	`docs/01-PRD.md`	MVP、功能、边界、异常流程明确
Stage 2	设计产品原型	executing-plans、using-git-worktrees	页面流程、Wireframe、Prototype	页面结构可指导开发
Stage 3	完成数据库和系统架构	dispatching-parallel-agents	Database、Architecture、SQL	前后端和数据结构边界清楚
Stage 4	生成后端工程骨架	subagent-driven-development	`backend/`	后端目录、模块、基础配置完成
Stage 5	后端测试闭环	test-driven-development	Test Plan、Unit Test、Integration Test	核心接口测试通过
Stage 6	生成 API 文档	executing-plans	`API.md`、OpenAPI、Swagger	前端可按文档开发
Stage 7	开发前端工程	subagent-driven-development	页面、组件、状态、路由	页面能调用接口并完成主流程
Stage 8	前端测试	test-driven-development	Frontend Test Report	页面、表单、权限、异常状态通过
Stage 9	前后端联调	systematic-debugging	Bug Report、Regression Test	联调问题修复并验证
Stage 10	评审和发布	requesting-code-review、receiving-code-review、finishing-a-development-branch	PR、Release Note、Tag	Review 完成，版本可发布

五、推荐 Skills 功能速查

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

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

Skill	核心功能	适用阶段	典型产出	使用注意
`using-superpowers`	加载 Superpowers 工作方式，提醒 AI 优先使用合适的 Skills，而不是直接自由发挥。	Stage 0、每次新会话开始	技能调用意识、项目工作约束	适合放在项目初始化和长期协作规范里，保证 AI 每次开工先检查流程。
`brainstorming`	通过提问、澄清、方案对比，把模糊想法变成明确设计或需求。	Stage 0、Stage 1	项目方向、PRD、设计方案、范围边界	不要急着让 AI 写代码；先用它把需求、目标用户、MVP 和边界条件问清楚。
`writing-plans`	把已确认的设计或需求拆成可执行的实现计划。	PRD 后、架构后、复杂功能开发前	Implementation Plan、任务拆分、文件改动清单	适合在"已经知道要做什么，但还没开始写代码"时使用。
`executing-plans`	按计划逐步执行任务，并在执行过程中做检查和汇报。	Stage 2、Stage 6、计划落地阶段	原型、API 文档、按计划完成的实现结果	前提是已经有清晰计划；不要拿它替代需求分析。
`using-git-worktrees`	创建隔离工作区或分支，避免原型、实验代码污染主分支。	Stage 2、并行实验、风险较高的改动	独立 worktree、隔离分支	做原型、重构、实验方案时很有用，尤其适合不确定的探索。
`dispatching-parallel-agents`	把相互独立的任务分派给多个 Agent 并行推进。	Stage 3	数据库设计、后端架构、前端架构并行产出	只适合边界清楚的并行任务；不要把强依赖的任务硬拆开。
`subagent-driven-development`	将开发任务拆给子 Agent 实现，再由主 Agent 汇总和审查。	Stage 4、Stage 7	后端模块、前端页面、组件、业务代码	适合工程量较大的开发阶段；每个子任务都要有明确输入和验收标准。
`test-driven-development`	按 TDD 思路先写测试，再实现代码，再重构。	Stage 5、Stage 8	单元测试、集成测试、Mock 测试、覆盖率报告	适合接口、核心业务逻辑、表单、权限等高风险区域。
`verification-before-completion`	在阶段结束前检查是否遗漏需求、边界、异常流程或交付物。	Stage 1、每个阶段收尾	检查清单、遗漏项、修订建议	很适合做 Stage Gate，确认当前阶段真的可以进入下一阶段。
`systematic-debugging`	使用系统化方式复现问题、定位根因、验证修复。	Stage 9、Bug 修复阶段	Bug Report、Root Cause、Regression Test	遇到联调问题时先复现和定位，不要凭感觉让 AI 乱改代码。
`requesting-code-review`	发起代码评审，让 AI 从 bug、风险、测试缺口、架构问题等角度检查代码。	Stage 10	Code Review Report	发布前必须使用，重点检查权限、安全、数据一致性和异常处理。
`receiving-code-review`	根据评审意见逐条修复，并确认每个问题都有处理结果。	Stage 10	Review Fix Commit、修复说明	不要只挑简单意见改；高风险问题要优先处理并补测试。
`finishing-a-development-branch`	完成分支收尾，包括测试、合并、发布准备和版本记录。	Stage 10	PR、Release Note、Tag、部署说明	用于正式发布前的最后检查，保证分支不是"写完就扔"。

建议记住一个简单规则：

text 复制代码

想清楚需求：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 上下文文件，为后续阶段提供稳定起点。

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

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

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

docs/01-PRD.md

完成标准

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

注意事项

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

八、Stage 2：产品原型设计

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

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

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

十、Stage 4：后端工程开发

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

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

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

Test Plan
Unit Test
Integration Test
Coverage Report

完成标准

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

注意事项

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

十二、Stage 6：API 文档

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

docs/04-API.md
Swagger
OpenAPI

完成标准

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

注意事项

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

十三、Stage 7：前端开发

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

十四、Stage 8：前端测试

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

十五、Stage 9：前后端联调

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

十六、Stage 10：Code Review 与发布

阶段目标

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

前置输入

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

执行步骤

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

交付物

text 复制代码

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

完成标准

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

注意事项

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

十七、每阶段 Git Commit 建议

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

text 复制代码

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 可以拆为：

text 复制代码

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

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

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

建议记录：

text 复制代码

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

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

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

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

markdown 复制代码

# 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

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

text 复制代码

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

二十一、总结

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

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

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

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

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

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

一、这套流程适合谁？

二、核心原则

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

2. Stage Gate：阶段门禁

3. Git Driven：每阶段都提交

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

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

三、整体流程图

四、阶段总览表

五、推荐 Skills 功能速查

六、Stage 0：项目初始化

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

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

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

八、Stage 2：产品原型设计

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

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

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

十、Stage 4：后端工程开发

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

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

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

十二、Stage 6：API 文档

阶段目标

前置输入

推荐 Skills

执行步骤

推荐 Prompt

交付物

完成标准

注意事项

十三、Stage 7：前端开发

阶段目标

前置输入

推荐 Skills

执行步骤