Vibe Coding 全流程开发工作流

本 skill 把 "vibe coding" 范式落到一个可执行的 6 阶段闭环： 需求理解 → 方案设计(Plan) → 编码实现 → 测试验证 → Code Review → 提交部署。

核心理念：

人定方向 + AI 执行 + 人 Review，失去 Review 环节就是灾难
意图大于细节：用户描述"要什么"，你负责"怎么做"
小步前进 + 节点 Review：每阶段交付物先让用户/自己确认，再进入下一阶段
subagent 并行加速：把独立可拆的子任务（代码探索、多模块阅读、独立 Review）委托给 subagent，主线程只做编排和决策

何时使用本 skill

应触发：

"帮我开发一个 XX 功能 / 接口 / 模块"
"新增 XX 业务 / 端到端做一个 XX"
"从零搭一个 XX"
任何需要跨多文件、跨多阶段（设计+编码+测试）的开发任务

不触发：

单行/单段修改（直接改即可）
纯 Bug 定位（用 systematic-debugging）
单纯读代码 / 改注释 / 重命名
用户明确说"先别走流程，就快速改一下"

全流程总览

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ 1. 需求理解   │ → │ 2. Plan 设计  │ → │ 3. 编码实现   │
│ 拆解+提疑问   │   │ 2-3 方案+推荐 │   │ 小步多文件    │
└──────────────┘   └──────────────┘   └──────────────┘
                                              ↓
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ 6. 提交部署   │ ← │ 5. Code Review│ ← │ 4. 测试验证   │
│ commit/PR    │   │ 自查+第二意见 │   │ 写+跑+自修复  │
└──────────────┘   └──────────────┘   └──────────────┘

每阶段都有明确的"交付物"和"用户确认点"，不要把所有阶段一口气跑完。

第 1 阶段：需求理解

目标：把用户一句话需求转成结构化的 "做什么 + 不做什么 + 验收标准"。

动作：

复述需求：用一段话回述你理解的需求
列出至少 3 个主动提问，覆盖：边界场景、数据规模、错误处理、与现有模块的关系
给出初步验收标准（功能可见的"做到什么程度"）

何时跳过：用户需求已经写得很完整（含输入、输出、边界、约束），可以直接进入 Plan 阶段，但仍需复述确认。

交付物示例：

我理解的需求：实现「用户登录次数统计」接口，按用户聚合最近 N 天的登录次数。

需要先确认：
1. N 是固定 7 天还是参数可配？
2. 是否包含失败登录？
3. 性能要求？（万级用户/百万级日志）
验收标准：
- GET /api/users/{id}/login-stats?days=7 返回 {userId, days, count}
- 单元测试覆盖：正常、用户不存在、days 越界

第 2 阶段：Plan（方案设计）

强制要求：复杂任务（跨 ≥2 文件 / 新建模块 / 涉及 schema 变更）必须先 Plan，给出 2-3 种方案 + 推荐 + 文件清单，待用户确认后再进入编码。

Plan 输出模板：

## 方案 A：<一句话总结>
- 实现思路：...
- 优点 / 缺点
- 影响文件清单

## 方案 B：<一句话总结>
- 同上

## 推荐：方案 A，原因 ...

## 文件改动清单
- 新建：src/.../OrderLoginStatsService.java
- 修改：src/.../UserController.java（+1 接口）
- 测试：test/.../OrderLoginStatsServiceTest.java

subagent 委托点：如果项目庞大，可派 subagent 并行探索代码现状（见 references/subagent-strategy.md 的"代码探索"章节），主线程拿到结论再拟方案。

用户确认点：方案给出后必须等用户拍板（"按方案 A 走"），不要自作主张直接编码。

第 3 阶段：编码实现

原则：

按 Plan 中的文件清单逐个落地，每个文件改完简要说明改了什么
复用现有工具/常量，不自行新建重复抽象
代码必须加注释（CLAUDE.md 要求），注释只写 WHY 和约束，不写 WHAT
不引入未约定的依赖

何时用 subagent：

独立模块的并行编码（如前后端解耦，可让两个 subagent 同时做）
大量重复模板代码生成（如 N 个 DTO）

详见 references/subagent-strategy.md。

输出节奏：每完成一个文件简要汇报，避免一次性堆几百行 diff。

第 4 阶段：测试验证

强制要求：每个新增/修改的核心逻辑必须配套测试。CLAUDE.md 规则："写完代码只测试，无需编译"。

测试编写要求：

覆盖：正常路径 + 至少 2 个边界场景（null、空、越界、并发等）
使用项目现有测试框架（先看 pom.xml / package.json 确认）
命名规范遵循项目现状（如 method_scene_expected）

测试执行：

跑一遍测试，失败的自己修，循环到通过
测试跑通后再进入 Review，不要带着红色测试做 Review

何时用 subagent：测试代码与实现代码独立时，可派 subagent 并行编写测试。

第 5 阶段：Code Review

两步走：

5.1 自 Review（必做）

对刚才所有改动按以下维度自查并打分（1-5）：

维度	检查点
正确性	是否实现了需求？是否处理了 Plan 中列的边界？
可读性	命名、结构、注释是否清晰？
性能	是否有 N+1、死循环、不必要的全量加载？
安全	SQL 注入、XSS、敏感信息、权限校验？
测试覆盖	关键分支是否被测试到？

输出 Top 3 必须修复的问题，并立刻修复。详见 references/review-checklist.md。

subagent 委托点：可派一个 subagent 独立 review（不告诉它实现细节，只给 diff + 需求），降低"自己 review 自己"的盲区。

5.2 提示用户做第二意见

完成自 Review 后，告诉用户：

建议切换到 Codex 做第二意见 review，命令参考：
codex
> review 当前 git diff，重点关注安全/性能/异常处理

不要在 skill 内自动调 codex（依赖外部环境，不可控）。

第 6 阶段：提交部署

遵守 CLAUDE.md 规则：

✅ 用当前分支，不新建分支
✅ commit message 用英文
✅ 提交前必须用户确认
✅ 不批量删除文件/文件夹（需用户确认）
❌ 不要主动 push 或建 PR，除非用户明确要求

commit message 风格：参考最近 3-5 条 git log，匹配项目现有风格。

输出格式：先列出"将要提交的文件清单 + 拟用 commit message"，等用户回 "go" 再执行 git add + git commit。

subagent 使用策略（关键加速器）

详细策略见 references/subagent-strategy.md，这里给出决策速查：

场景	是否派 subagent	类型
大型项目代码探索	✅ 派	Explore
同时阅读 5+ 文件理解架构	✅ 派	general-purpose
独立模块并行编码（如前/后端）	✅ 派	general-purpose（多个并行）
独立 Code Review（盲审）	✅ 派	code-improvement-scanner
单文件读取 / 已知路径修改	❌ 直接做	-
短链 grep 查找	❌ 直接做	-
需要用户决策的环节	❌ 主线程做	-

核心原则：独立、无共享状态、≥2 个任务时才派 subagent。一旦派出，要在同一个 message 里并行派多个，不要串行。

提示词模板速查

8 个核心动作的提示词模板见 references/prompt-templates.md，包括：

提示词三段式（背景/任务/约束）
代码阅读模板（项目级/单文件/调用链）
新功能 Plan-Code-Test 模板
Debug 现场报告模板
重构（提取/模式/性能）模板
测试用例模板
文档/注释模板
Code Review 维度评分模板

使用方式：当你需要在某个阶段给出标准化产物时，去 references/prompt-templates.md 里抓模板填空。

全流程节奏检查表（TodoList 建议）

进入本 skill 后，立刻把以下任务写入宿主提供的任务计划工具（Claude Code 使用 TodoWrite，Codex 使用 update_plan），逐项推进：

☐ 第 1 阶段：复述需求 + 提问 + 验收标准
☐ 第 2 阶段：Plan（2-3 方案 + 推荐 + 文件清单）→ 等用户确认
☐ 第 3 阶段：编码实现（逐文件落地）
☐ 第 4 阶段：测试编写 + 跑通
☐ 第 5 阶段：自 Review + 修复 + 提示外部 Codex
☐ 第 6 阶段：列提交清单 + commit message → 等用户确认 → 执行

每完成一项立刻标完成，不要批量改状态。

边界与例外

不适合本流程：MVP 之外的高并发架构改造、安全敏感模块、跨团队/跨系统接口设计 —— 这些需要更重的设计评审，本 skill 是"开发执行"层，不是"架构评审"层
何时主动退出本流程：当你发现需求实际上极简（10 行代码以内），明确告诉用户"这个不用走完整流程，直接改了"，并退出
遇到阻塞：在任一阶段卡住（依赖缺失、Plan 找不到合理方案），明确停下来问用户，不要硬猜

参考资源

references/prompt-templates.md —— 8 个动作的提示词模板
references/subagent-strategy.md —— subagent 委托策略与示例
references/review-checklist.md —— Code Review 维度清单与高频问题

code-vibe-workflow

SKILL.md.claude/skills/code-vibe-workflow/SKILL.md