全部教程Claude Code Vibe Coding 工作流：从规范到落地

Claude Code Vibe Coding 工作流：从规范到落地

我是 Quentin，OpenClaw 拼车的维护者。这篇是我整理的一套 Claude Code Vibe Coding 工作流——从需求到代码的完整闭环，参考了 Kiro 的规范驱动开发理念。

「Vibe Coding」最早来自 Andrej Karpathy 那条火出圈的推文，意思是「跟着感觉写」——你不再亲手敲每行代码，而是和 AI 持续对话，逐步逼近想要的东西。听起来很美，但实际跑起来的人都知道：没有结构的 vibe coding 会变成一团乱麻。代码是写出来了，但你说不清它的需求是什么、设计长啥样、为什么这么实现。

这篇分享我吸收的一套规范驱动 + Vibe Coding 混合的流程：保留 vibe coding 的快感和速度，但用结构化命令把每一步的产出固化下来，前后衔接、逻辑一致、可追溯。

拼车前置：完整跑一次 Vibe Coding 工作流（spec → design → task → execute）大约消耗 5~15 万 token。OpenClaw 拼车一行接通 Max 20× 配额：

curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x

一、为什么需要工作流？

直接给 Claude Code 一句「帮我实现用户认证系统」会发生什么？

  • 它会立刻开干，写出一堆代码
  • 你看着代码觉得「好像不对」，但说不清哪里不对
  • 改两轮之后整个文件已经面目全非，你不敢回滚
  • 最后变成「能跑就行」，质量全靠运气

问题不在 Claude Code，问题在你没有把需求拆清楚。当输入是模糊的、跳跃的、缺约束的，输出也只会是模糊的、跳跃的、缺约束的。

Vibe Coding 工作流的核心思路：把需求 → 设计 → 任务 → 执行的过程显式化，每一步都有明确的输出物（spec / design / task / code），前一步的输出是后一步的输入。这样：

  • 中途回看时知道「为什么要这样做」
  • 出错时能快速定位是哪一层出了问题
  • 团队 review 时可以单独评审需求或设计，而不是混在代码里
  • 改需求时知道要回退到哪一步重做

二、规范驱动开发的五个阶段

灵感来自 Kiro 项目，每一阶段都对应一个自定义斜杠命令：

/kiro:spec    [feature]      → 创建需求文档和验收标准
/kiro:design  [feature]      → 制定架构设计和组件规划
/kiro:task    [feature]      → 生成具体的实施任务清单
/kiro:execute [task]         → 执行具体的开发任务
/kiro:vibe    [question]     → 快速开发问答支持

这个流程的妙处在于：每一步都有明确的输出，前一步的结果会成为下一步的输入，形成完整的闭环。

阶段 1：spec — 需求是什么

/kiro:spec 用户认证系统 会让 Claude 产出：

  • 用户故事（User stories）
  • 验收标准（Acceptance criteria）
  • 边界条件
  • 非功能性需求（性能、安全、合规）
  • 不在范围内的事项（明确「不做什么」）

输出存到 .kiro/specs/<feature>/spec.md。

关键：这一步不写代码、不画架构，只把需求说清楚。Claude 会反问你不清晰的地方——比如「忘记密码功能要不要？」、「OAuth 第三方登录支持哪些？」、「session 时长？」。

阶段 2：design — 架构和组件

/kiro:design 用户认证系统 基于上一步的 spec 产出：

  • 模块划分（auth-service / token-store / session-manager）
  • 数据模型（User / Session / Credential）
  • API 接口（POST /login / GET /me / DELETE /session）
  • 数据流图（登录、注销、刷新 token）
  • 关键依赖（数据库、Redis、邮件服务）
  • 安全考量（密码哈希算法、防爆破、CSRF、XSS）

输出存到 .kiro/specs/<feature>/design.md。

这一步还不写代码，但已经把「怎么做」说清楚了。如果到这一步发现设计有问题，回去改 spec 比改完代码再回滚便宜得多。

阶段 3：task — 任务拆解

/kiro:task 用户认证系统 把设计拆成具体任务：

- [ ] T1：创建 User 数据模型（schema、迁移）
- [ ] T2：实现密码哈希工具（argon2id）
- [ ] T3：实现 /login 接口
- [ ] T4：实现 session 存储（Redis）
- [ ] T5：实现 /me 接口
- [ ] T6：实现 /logout 接口
- [ ] T7：写 E2E 测试
- [ ] T8：写文档

每个任务有：

  • 简短描述
  • 依赖（T3 依赖 T1 + T2）
  • 预估复杂度（1~5 分）
  • 验收标准（通过哪些测试就算完成）

输出存到 .kiro/specs/<feature>/tasks.md。

阶段 4：execute — 开始干活

/kiro:execute 用户认证系统 实现 /login 接口 会：

  1. 读取 spec、design、tasks
  2. 找到对应任务（T3）
  3. 实现代码
  4. 写单元测试
  5. 跑测试验证
  6. 把任务在 tasks.md 标记为完成

每次只执行一个任务，跑完就停。这样进度可控、回滚方便。

阶段 5：vibe — 快速问答

/kiro:vibe 这里用 JWT 还是 session token 是给「中途突然想问点什么」用的快速通道。不写文档、不改代码，只快速解答。

它和直接问 Claude 的区别在于：vibe 命令会自动加载当前 feature 的 spec/design 上下文，所以回答会贴合你的项目语境，不会给那种「教科书答案」。

三、增强分析能力的命令

除了开发主流程，几个增强思考的命令也很有用：

/think-harder      [problem]          → 深度分析问题
/think-ultra       [complex problem]  → 超级综合分析（多角度交叉）
/reflection                           → 分析和改进当前指令
/reflection-harder                    → 全面会话分析和学习
/eureka            [breakthrough]     → 项目成果复盘

/think-harder 适合卡壳时

写到一半发现「这里好像走错了路」，又说不清哪里错。/think-harder 这个 session 实现有什么问题 会让 Claude 跳出当前实现，从架构、安全、性能、可维护性多个角度做评估。

/reflection 适合每天结束时

每天最后跑一次 /reflection，让 Claude 总结：

  • 今天做了什么
  • 哪些做得好
  • 哪些可以改进
  • 是否需要更新 CLAUDE.md 里的项目记忆

这是把经验沉淀回项目知识库的关键动作。

四、GitHub 深度集成

对开源 / 团队开发，GitHub 集成是必不可少的：

/gh:review-pr  [PR_NUMBER]    → 全面的 PR 审查和评论
/gh:fix-issue  [issue-number] → 完整的问题解决工作流

/gh:review-pr 123 实战

跑这条命令，Claude 会：

  1. 用 gh 拉取 PR diff
  2. 读取相关文件的完整上下文
  3. 分析变更：bug、安全、性能、风格
  4. 在发布评论前征求你的意见——你可以增删修改
  5. 确认后用 gh pr review 发布到 GitHub

特别好的一点是「先征求意见再发布」——避免 AI 评论太啰嗦或者跑偏。

/gh:fix-issue 456 闭环

收到一个 issue，Claude 会：

  1. 拉取 issue 描述和评论
  2. 在仓库里搜索相关代码
  3. 复现问题（如果 issue 有复现步骤）
  4. 设计修复方案，问你确认
  5. 实现修复 + 测试
  6. 提 PR 并自动关联 issue

整个流程从「issue 进来」到「PR 出去」，一条命令搞定。

五、Claude Code 自身管理

/cc:create-command [name] [description]  → 创建新的 Claude Code 命令

这条命令很元——它让你用 Claude Code 创建 Claude Code 自定义命令。

例：

/cc:create-command deploy 部署当前项目到生产环境，跑测试、build、推镜像、滚动更新

它会：

  1. 在 .claude/commands/deploy.md 创建文件
  2. 写入合适的 prompt 模板
  3. 询问是否要 $ARGUMENTS 参数
  4. 询问是否要锁定特定工具集

下次直接 /deploy 就能用。

六、快速安装

如果你想直接用一套整理好的配置：

# 1. 备份原有配置
mv ~/.claude ~/.claude.bak
 
# 2. 克隆配置仓库（推荐 feiskyer/claude-code-settings 或类似的开源配置集）
git clone https://github.com/feiskyer/claude-code-settings.git ~/.claude
 
# 3. （可选）安装 GitHub Copilot API 代理，复用 Copilot 订阅作为模型提供者
npm install -g copilot-api
copilot-api auth
 
# 4. 后台运行（用 tmux 比较稳）
tmux new-session -d -s copilot 'copilot-api start'

注意：上面那套示例使用 GitHub Copilot 作为模型提供者，通过 copilot-api 代理实现。如果你已经在用 OpenClaw 拼车，保留拼车的 settings.json 配置即可，不要被仓库里的 settings 覆盖。删除或合并 ~/.claude/settings.json 中的认证段。

七、实战示例：开发一个用户认证功能

把上面的命令串起来，假设要从零做用户认证：

# 第一步：定义需求
/kiro:spec 用户认证系统
 
# Claude 会反问你：
# - 支持哪些登录方式？（密码 / OAuth / Magic link）
# - session 时长多久？
# - 需不需要 2FA？
# 你回答完，它产出 spec.md
 
# 第二步：设计架构
/kiro:design 用户认证系统
 
# 它读取上一步的 spec.md，产出 design.md
# - 模块划分
# - 数据模型
# - API 设计
# - 安全方案
 
# 第三步：拆解任务
/kiro:task 用户认证系统
 
# 产出 tasks.md，列出所有要做的事
 
# 第四步：逐个执行
/kiro:execute 用户认证系统 实现用户注册接口
/kiro:execute 用户认证系统 实现登录接口
/kiro:execute 用户认证系统 实现 session 管理
# ... 一个个跑下去
 
# 中途有疑问
/kiro:vibe JWT 的 secret 应该多长？

每一步都会产生详细的文档和代码，前后一致、逻辑清晰。

实际上，如果你保持在 /kiro:spec 开始的会话中没有退出，后面几个命令都不需要你主动执行——Claude 会自动提示你「需求已确认，要不要进入设计阶段？」、「设计已完成，要不要拆任务？」。整个流程像顺水推舟。

八、代码审核场景

GitHub 项目的 PR 审核：

/gh:review-pr 123

Claude Code 会：

  1. 自动拉取 PR 内容
  2. 进行全面分析
  3. 给出具体的改进建议
  4. 在发布 PR 评论前征求你的意见（同意 / 要求修改）
  5. 你拍板后再实际发到 GitHub

避免了「AI 自动审完一堆没用的废话」这种尴尬场景。

九、最佳实践总结

跑了几个月这套流程，我提炼出几条心得：

  1. 不要跳步。看似「直接 execute 就好」其实最慢——回头返工的代价远大于先做规划。
  2. spec 要写「不做什么」。比写「要做什么」还重要——明确边界能防止 Claude 自由发挥过度。
  3. design 阶段强制评审。设计文档比代码 diff 更容易让人发现问题。
  4. execute 单任务粒度。一次只做一件事，跑完测试再做下一件。出问题只回滚一个任务，不会一夜回到解放前。
  5. 每天 reflection。把当天的经验沉淀到 CLAUDE.md，下次跑同类任务速度翻倍。
  6. 不要害怕 vibe。流程是骨架，vibe 是血肉。卡壳了就用 /kiro:vibe 快速问，别死守流程。

十、立即开始

完整跑通一次这套工作流，你会发现 AI 编程突然「不那么野了」——既保留了快感，又保留了工程性。

curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x

把第一个真实需求丢进 /kiro:spec，按流程走完一遍，体会一下「有结构的 vibe coding」是什么感觉。

更多文档见 https://cp.bizq.net。

相关文章

Claude Code Subagents 进化指南：从牛马到老板苏格拉底式 AI Coding：模糊提问的力量