ai vibecoding workflow 实践

ai vibecoding 开发模式

1. 根据需求 先开发前端 ，mock接口 给出api端点 然后喂给后端生成
   必须要严格检查数据库 字段是否完全准确，必须要检查后端暴露接口以及response字段是否完全一致
   优点：能最快看到效果
   缺点：前后端联调要对齐，一定要对齐不然后续要出问题
   2. 前后端一起 同步开发
      优点：适合联调一些小功能，或者bug涉及前后端联调的修复
      缺点：需要将前后端放到同一个目录下管理，git容易混乱
   3. 先开发后端 然后导出swagger api 再进行前端开发
      优点：专注于后端实现，完全依赖于后端，逻辑重心在后端会更多，可以完成核心逻辑后再聚焦样式体验
      缺点：看不到实时效果，容易背离需求

开发场景

1. 从0到1构建
2. 已有系统新增模块
   1. 独立小需求
   2. 大需求 关联多个模块
3. bug修复
4. 功能变更，删除
5. 简单的一些逻辑处理或者修改一些与功能无关的系统信息

工作流框架选型实践

openspec 实践过程

codex gpt5.5/5.4 + openspec /spec driven的 工作流 以spec为核心,在开发的时候会先和用户约定好具体细节

最基本的 整个流程大概是先 opsx/propsal 先提案，然后codex会在openspec 文件夹下添加对应的change，并创建四个工件 propsal.md (why 为什么改动) /speecs/xxx.md (what 改动的场景 用例对应delt change) design.md (how 具体的设计实现技术层面) task.md(plan todo计划，基于前面的拆解出来的任务)

当然如果一开始没有思路 可以用 opsx/explore 先和ai探讨，然后引导创建propsal

生成完工件artifacts一定要仔细检查 具体实现细节是否和你的想法和spec一致，这里体现的就是你对项目技术的实现是什么完全清楚，如果是小白可能看都看不懂，所以vibe并不能替代人类决定，人类的经验和技术沉淀越深驾驭ai才能越强

如果有差别请你立刻提出,这个时候ai会帮你立刻修改对应的artifacts。记住一定要仔细审核，就像平时进行代码评审，需求评审一样认真。不过有些细节当时确时没看出来，也没事那就只能后面返工咯。

确认好后进行opsx/apply 对应change就可以等他实现了，可以加上适当按情况使用subagent来进行任务执行效果更好（毕竟全新上下文），通常情况下验证会写在task里，所以task完成了验证也完成

这个时候进行人工验收，如果有问题就增加delt change在这个change下，ai会继续修改artifacts然后修改或增加任务，依次循环上面步骤直到你满意为止。

这个时候你就可以进行 opsx/archive 进行归档，归档后的change 通常不能变更，意味着这次已经完成，加入后面同一个模块需求变更就需要重新新建change(如果没有change 归档还可以通过delt change来变更)

以上工作流是默认的工作流，他会一次性生成四个工件，其实openspec 也可以调整细粒度的工作流来进行更精确的需求确认生成
/opsx:explore -> /opsx:new (只创建change文件夹不写artifacts)-> /opsx:continue (一步步完成四个artifacts 与你确认)-> /opsx:apply->/opsx:archive

另外如果以上4个工件不满足需求可以自定义custom工作流 https://github.com/studyzy/OpenSpec-cn/blob/main/docs/customization.md

openspec 的问题 和优化

从整个交互流程我们会发现，openspec 会进行特别多的文件创建而且也没有任何git管理,实现细节也是根据定义好的模版prompt来生成的，验证有的时候也写的不够全。这会带来很多问题，比如一些功能写错了不能回退版本，需求一句话说不清楚，实现因为审核不仔细写了很多屎山代码，中途发生变更需求未能同步到changes文档，验证不全面等等。我们可以通过AGENTS.md 和 添加skills来解决一些问题

以下是一些简单的实践解决办法

1. git 管理 流程 在AGENTS.md 写好约束 只能在master 分支提change，然后必须使用 feat，fix，chore等修改分支上进行 apply（不允许master分支修改）。实现好后需要验证是否全部完成并且提交合并到master。完成了才能在master分支归档，归档后自动触发推送到远程分支。
2. 沉淀skill只要对话发生需求变更立即（sync）同步change下文档发送变更
3. 沉淀skill 定义验证的模板 （比如lint 检查，静态检查，单元测试，模拟点击，接口测试等，前后端联调测试等）
4. 在openspec 的系统配置文件写清楚 技术栈细节。尤其是在design 注入实现细节方法。
5. AGENTS.md 我们要定义好需求粒度，比如遇到涉及多处改动的大模块需求 要严格要求用户提供PRD文档和视觉图等才能生成工件或者apply，小的需求可以一句话进行描述。openspec里的specs可以是说是非常重要，但是小需求能讲清楚的也没必要花时间在PRD文档上，所以需要先断定一下需求的复杂程度。
6. 并行开发，当多个模块之间相互影响较少，可以使用多个subagent创建worktree 进行开发apply实现

openspec 像拆得更细的每一步工作流方法，我们需要自己组装使用这些工作流步骤来完成迭代开发，适合前端需求或者前后端的联调小需求

superpowers 实践过程

superpowers 结合claude code 使用 搭配 gpt5.5 和 claude sonnet 4.6 均有不错效果,后续如果考虑成本可尝试 deepseek v4pro

superpowers 的设计 理念就是 一组skills 包，其中比较重要的是 brainstorming,subagent-driven-development,test-driven-development,writing-plans,using-superpowers。只需要了解这些skill的作用和其他skill得关联，claudecode 会自己视情况自己调用。
using-superpowers
作为主控制层调度和协调各个 skill 的使用，实现端到端的高效开发流程。 调用 Brainstorming 生成方案、触发 Writing Plans 制定计划、启动 Subagent-Driven Development 执行任务、并确保 TDD 测试贯穿全过程，实现闭环反馈与优化。
Brainstorming
在项目启动或需求澄清阶段快速生成创意、方案和任务思路。 为 Writing Plans 提供初步内容和方向，确保计划覆盖多种可能性；同时为 Subagent-Driven Development 提供多种实现策略供子代理选择。通常会在superpowers 文件夹下生成一个specs文档。
Writing Plans
根据需求和目标形成结构化计划，包括任务拆分、优先级和执行顺序。
整合 Brainstorming 的创意和策略，为 Subagent-Driven Development 提供清晰执行路径，同时为 TDD 指明测试范围和目标。通常会在superpowers 文件下写对应spec 得具体tdd plan计划
Subagent-Driven Development
会自动创建worktree，将主任务拆解成子任务（claudecode内部维护），由不同子 Agent 并行执行，实现模块化和高效开发。 依赖 Brainstorming 生成的方案思路来拆解任务，并与 Test-Driven Development 协作确保每个子任务质量，同时反馈给 Using Superpowers 的主流程进行进度跟踪。每个子任务Task完成此模式都会开启两个子review agent 进行审查，一个审查specs是否符合预期，一个审查code 的quality。不满足要求就会重新进行Task任务。
Test-Driven Development (TDD)
在编码前先定义测试用例，引导开发保证功能正确性，减少返工。
与 Subagent-Driven Development 紧密配合，每个子 Agent 在实现功能implement 阶段使用TDD进行开发，首先依具需求写最小失败测试用例并且失败，失败后进行最小实现再次跑用例能够通过，再不断优化架构实现方法达到最优通过测试的开发方案代码。通过TDD的流程进行的代码实现会严格按照需求出发，不断迭代优化，而不是靠猜测。生成的测试结果可反馈给 Brainstorming 或 Writing Plans 用于优化方案。

superpowers 通常整个工作流都比较重，然后设计思路基本上涵盖了整个开发流程的git版本控制，spec驱动，然后还引入了实现阶段的TDD驱动，基本上不需要额外自定义规则，可以开箱即用。比较适合后端大模块的从0到1的构建，或者是项目架构重构这些复杂任务。唯一的缺点可能就是非常耗token,一个大任务基本上会花2-3h，差不多5000万token。而openspecs 大概只会花500万-1000万token完成一次change 实现。

工作流选型

不要轻易尝试再一个agent如codex 混用 superpowers 和 openspecs，可能会造成混乱，最好是就是ClaudeCode 搭配SuperPowers ，Codex 搭配OpenSpecs。当然反过来也行，这个没有试过。
综合上面说的场景

1. 对于一个新项目，从0到1构建脚手架，建议使用ClaudeCode 搭配SuperPowers
2. 对于新的大模块增加，或者涉及关联已有模块的修改建议使用ClaudeCode 搭配SuperPowers
3. 对于整体后端架构要进行重构，建议使用ClaudeCode 搭配SuperPowers
4. 对于小需求，临时需求，建议使用Codex 搭配OpenSpecs
5. 对于样式修改，前端需求，建议使用Codex 搭配OpenSpecs
6. 对于bug 修复，建议使用Codex 搭配OpenSpecs
   另外如果处于成本考虑，在模型选型上，可以在Openspecs 和 Superpowers 进行change 工件文档书写和头脑风暴、writing plans使用较贵的模型如gpt 5.5 和opus 4.7。而再实现阶段使用Glm5或者deepseekv4pro 等国产模型进行苦力输出。

后续工作

从需求到代码的设计实现的流程已经完成，后续目标会继续探索功能测试自动化工作流的实现