AI Vibe-Coding 工作流方法codegraph / GSD / Superpowers / OpenDesign 六层分工实战写给「用 AI 写代码Vibe Coding却总觉得 AI 越写越乱」的开发者。本文介绍一套把代码认知、需求发散、方案收敛、计划执行、视觉设计拆开分工的工作流每个环节用专门的工具环环相扣。旧项目二开、新项目开发都覆盖适合 Claude Code / Cursor 等 AI 编码工具的使用者参考。声明文中工具均为开源项目内容为作者个人实践总结非官方教程命令与产物路径可能随版本更新以各工具官方文档为准。目录一、这套方法解决什么痛点二、工具栈总览六层分工三、核心心法为什么是这么个顺序四、旧项目 / 二次开发完整流程五、新项目完整流程六、决策矩阵什么情况用什么七、避坑清单八、串起来一个典型工作日九、总结一、这套方法解决什么痛点用 AI 写代码vibe coding最难受的三件事痛点具体表现根因AI 不认得你的代码二开项目里 AI 张口就是通用套路写出来的风格跟项目对不上甚至改崩AI 对代码的理解是零散的grep 翻文件抓不住调用关系和既定约定需求没对齐就动手脑子里还是模糊想法AI 已经咔咔写代码写完发现不是你要的返工需求没经过「发散」你的 A 被 AI 理解成了 A’聊得越久质量越差对话一长AI 忘了早期约定代码风格漂移、自相矛盾上下文腐化Context Corruption窗口有限早期约束被新内容淹没这套方法的核心思路把「代码认知」「需求发散」「方案收敛」「计划执行」「视觉设计」拆成独立环节每个环节用专门的工具环环相扣。二、工具栈总览六层分工环节工具解决什么关键动作产物① 代码认知codegraphAI 不认得代码构建知识图谱统一检索入口SQLite 图谱 CLAUDE.md 检索规则② 项目骨架gsd-core项目状态不落盘初始化把项目知识沉淀到.planning/PROJECT / REQUIREMENTS / ROADMAP / codebase 地图③ 需求发散superpowers brainstorming想法模糊、没对齐一次只问一个问题多轮挖掘设计文档docs/superpowers/specs/…-design.md④ 方案收敛superpowers writing-plans知道做什么、不知道怎么落地拆成任务级实现计划含完整代码的实现计划docs/superpowers/plans/…md⑤ 计划执行superpowers 自带执行单功能gsd-core多阶段执行期上下文腐化满血子代理 原子提交 阶段验收一次次的原子 commit .planning/状态⑥ 视觉设计opendesignUI 说不清、样式难统一自然语言直接出可运行 HTML 原型可运行的 HTML 原型 / 导出工程文件一句话总结这套打法先让 AI 认得代码①再让项目状态落盘②新需求先发散到清晰③、再收敛成计划④、交给满血执行⑤页面的「脸」用专门工具先长出来⑥。三、核心心法为什么是这么个顺序下面四个原理是后面所有流程的「为什么」。记不住流程没关系记住这四个原理自己就能推导出该用什么工具。原理 1先认知后动手 —— ① 永远在最前面老项目里 AI 返工的最大原因不是它笨是它不认得你的代码。用 grep 翻文件的方式AI 只能看到零散片段抓不住「这个函数被谁调用」「改这里波及哪里」「项目既定约定是什么」。codegraph 把符号、调用边、波及范围建成可查询的知识图谱一次查询就能拿到某函数的完整源码 调用链 改动影响面。在CLAUDE.md里写明「本仓库代码检索一律用 codegraph」是把这件事制度化——每个新会话的 AI 一进场就知道用正确的方式理解代码检索口径不漂移、不退回 grep。为什么不先建图就开干因为后面所有步骤——brainstorming 要读现有代码、写计划要引用现有符号、执行要改现有文件——全都建立在「AI 真认得代码」这个地基上。地基不牢后面每一步都在猜。原理 2发散 → 收敛先设计后实现 —— ③ ④ 是最该花时间的环节「AI 直接写代码」之所以容易翻车是因为需求没有经历过发散。brainstorming 通过一次只问一个问题把模糊念头展开成完整的需求图景发散再收敛成一份带边界、带取舍、带验收标准的设计文档收敛。brainstorming 的产物是设计文档spec回答「做什么 / 为什么」存到docs/superpowers/specs/…-design.md。它有硬门禁——你批准设计之前禁止写任何代码设计写完还要你审阅过 spec 文件才进入计划阶段。三道门设计批准 → 文档审阅 → 计划执行选择保证每一步都经你确认。收敛之后还有一道闸writing-plans把设计拆成任务级实现计划回答「怎么做」。任务小到「2-5 分钟一个动作」每个动作都带真实代码、真实路径不允许占位符TBD / TODO 即计划失败。⚠️ 别误会 writing-plans「会写代码」它的产出物仍然是计划文档只是把完整代码测试代码 实现代码 提交命令预写在计划里。「写进计划」≠「写进仓库」——真正的代码落地发生在执行阶段由执行器按计划逐任务改真实文件。计划里代码越完整执行器越不需要猜。为什么不能跳过设计直接让 AI 写「边想边写」是最贵的路径。返工 重来成本翻倍「想清楚再写」只有一次成本。设计文档和计划文件是「记忆外置」。隔一周回来AI 读文件就能接着干不需要你重新讲一遍需求这也是对抗上下文腐化的关键。多轮挖掘是在挖「你以为的需求」和「真正的需求」之间的裂缝。越简单的需求越要确认——简单需求里藏着的想当然最多。原理 3执行走「满血状态 落盘」—— 但先想清楚走哪条执行路线规划做得再好直接在长会话里让 AI 一口气写一大段代码上下文腐化又悄悄发生。所以执行阶段必须是「满血 落盘」全新上下文执行器、小块原子提交、状态落盘。但这里其实有两条路线别默认只走一条执行路线适用场景多给的保障superpowers 自带执行subagent-driven-development/executing-plans单次功能交付每个任务全新子代理 任务间 review轻量gsd-core 执行/gsd-progress --do路由多阶段项目 / 需要「证明做对了」阶段目标验证goal-backward、需求可追溯、合并后全量测试、跨阶段回归、UAT 人工验收、STATE/ROADMAP 全程跟踪关键差别一句话superpowers 执行做到「功能能跑了」gsd-core 执行做到「证明阶段目标真的达成了、没弄坏别的东西」。判断很简单这个工作是「单次功能」→ superpowers 自带执行就够再小可走/gsd-fast、/gsd-quick是「多阶段项目」且需要验证 回归保护 → 才上 gsd-core。原理 4视觉单独成环 —— ⑥ opendesignUI 是「说出来最费劲、看才看得明白」的东西。让 AI 在代码里直接抠样式既慢又难统一。opendesign 用自然语言直接产出可运行的 HTML 原型网页、仪表盘、PPT、PDF、HTML 视频内置 150 套大厂设计系统用DESIGN.md约束视觉风格保证整套界面风格统一。先出原型、用眼睛确认「长这样」再进执行比在代码里来回调样式快一个数量级。四、旧项目 / 二次开发完整流程二开最怕 AI 不认代码所以第一条线是「建认知」→「初始化」→「发散收敛」→「执行」。第 0 步codegraph 建图 CLAUDE.md 定规则建认知codegraph init # 在项目根目录启用索引生成 .codegraph/然后在项目的CLAUDE.md里写明本仓库代码检索一律使用 codegraphcodegraph_explore/codegraph explore禁止直接全库 grep。为什么这就是原理 1 的落地。图谱是后面所有步骤的「真相源」规则写进 CLAUDE.md 是让每个新会话的 AI 都照此检索口径统一。第 1 步gsd-core 初始化项目让 GSD 懂你的项目/gsd-onboard # 1. 检查仓库状态安全地告诉你先干嘛 /gsd-map-codebase # 2. 派子代理并行读代码生成代码地图到 .planning/codebase/ /gsd-new-project # 3. 初始化项目这里只描述你要『新增』的功能别把整个项目重新讲一遍为什么技术栈、目录结构、代码规范、报错格式、测试习惯全被记进代码地图。之后 GSD 提的问题、写的计划全都基于你项目的真实情况不用你一遍遍解释。⚠️ codegraph 和 gsd-map-codebase 不重复是互补的两层gsd-map-codebase 地图册宏观综述技术栈/架构/目录/约定人读文档一次性快照服务规划阶段codegraph 实时 GPS符号级精确函数实现/调用链/改动影响半径机器读图谱随编码自动同步服务日常对话。一句话想了解项目全景看代码地图想定位具体代码用 codegraph。前者进规划后者进对话。第 2 步新需求 → brainstorming 发散 →涉及页面先 opendesign→ writing-plans 收敛这是「返工率」的分水岭也是最值得花时间的一步无界面需求 1. 用 brainstormingAI 一次问一个问题多轮挖掘直到需求清晰 → 产出设计文档 docs/superpowers/specs/YYYY-MM-DD-主题-design.md 涉及页面 / UI 需求插入一步 2. 用 opendesign自然语言描述 → 产出可运行 HTML 原型DESIGN.md 锁风格 → 把原型/导出工程文件并进设计文档作为「长这样」的证据 3. 用 writing-plans把设计文档拆成任务级实现计划 → 产出实现计划 docs/superpowers/plans/YYYY-MM-DD-功能.md → 计划里每个任务带真实代码、真实路径、验收标准不允许占位符为什么是这个顺序原理 2 的落地先发散brainstorming 把「模糊想法」挖成「清晰需求」避免 AI 理解成 A’。中间插视觉UI 用语言说不清opendesign 出原型最快让人确认。再收敛writing-plans 把「做什么」变成「怎么一步步做」并自动做覆盖度检查设计里的每条要求都能指到某个任务。第 3 步执行计划满血执行 落盘—— 单功能走轻的多阶段走 GSD# 路线 A单次功能 → superpowers 自带执行轻 writing-plans 写完计划会给你执行选择 → subagent-driven-development逐任务派子代理推荐 → executing-plans内联执行带检查点 # 路线 B多阶段 / 要验证 → gsd-core重 /gsd-progress --do 把 docs/superpowers/plans/…md 的计划落地执行 # 描述意图GSD 会智能路由到合适的命令可自定义 /gsd-do 快捷指令为什么原理 3 的落地。gsd-core 把「执行计划」这个意图交给执行体系全新上下文子代理 原子提交 阶段验收/gsd-verify-work→/gsd-ship。执行期上下文不腐化中断能续上每步能回退。但如果这只是个一次性的单功能superpowers 自带的执行就够——别为一个功能背上整套阶段验证的税。页面优化 / 开发专项opendesign 设计先行需要做页面官网、H5、仪表盘、网页游戏官网、游戏 UI 原型时别直接在代码里调样式1. opendesign自然语言描述 → 产出可运行 HTML 原型 2. 用眼睛确认「长这样」→ 满意后导出真实工程文件 3. 把原型/工程文件喂给执行体系做集成落地为什么单独拎出来页面设计是「视觉验证」环节。先出原型用眼睛确认再进代码避免在代码里来回调样式的时间黑洞。原型可丢 Git 版本管理风格由 DESIGN.md 统一约束。五、新项目完整流程新项目起点明确重点是「能不能省掉发散」。有完整 PRD / 需求文档直接 gsd-core 全流程/gsd-new-project # 初始化有 PRD 就喂给它不用从零问 /gsd-discuss-phase 1 # 讨论有 PRD 可跳过 /gsd-plan-phase 1 --prd docs/xxx.md # 规划规划器直接从 PRD 提取决策 /gsd-execute-phase 1 # 执行原子提交 阶段校验 /gsd-verify-work 1 /gsd-ship 1 # 验收 → 发布 # 之后循环 讨论→规划→执行→验收→发布直到整个项目完成为什么可以直接跑PRD 本身就是「发散 收敛」过的产物——需求、边界、验收标准已经写清楚了不需要再 brainstorm 一遍。GSD 能从 PRD 直接提取决策跳过讨论直接规划。后续功能扩展 / 优化回到发散收敛那条链新功能是新的创意工作要重新发散收敛brainstorming发散新需求→ [涉及页面则 opendesign 出原型] → writing-plans收敛成计划→ 执行单功能走 superpowers 自带执行多阶段走 gsd-core为什么新增功能 ≠ 走老路。功能扩展同样面临「想法模糊」的问题直接让 AI 加功能 又一次「边想边写」的返工风险。六、决策矩阵什么情况用什么场景用什么一句话进老项目先摸清代码codegraph init CLAUDE.md 定规则建认知地基老项目初始化/gsd-onboard→/gsd-map-codebase→/gsd-new-project让 GSD 懂你的项目新需求想法模糊brainstorming多轮挖掘到清晰需求涉及页面先 opendesign先出可运行原型有了设计要实施writing-plans拆成任务级计划执行计划单功能superpowers 自带执行轻量不必上 GSD执行计划多阶段/要验证/gsd-progress --do路由到 GSD 满血执行 验证新项目 完整 PRDgsd-core 全流程--prd直接跑跳过发散页面单独优化 / 开发opendesign → 喂给执行体系集成视觉先行后续功能扩展 / 优化brainstorming → writing-plans → 执行单功能自带/多阶段 gsd-core重新发散收敛临时小需求/gsd-quick//gsd-fast不需要完整流程出 bug/gsd-debug系统化调试七、避坑清单别让 AI 直接全库 grep老项目先进 codegraph检索口径统一CLAUDE.md 写死规则。别跳过 brainstorming越简单的需求越要确认——简单需求里藏着的想当然最多。别让设计/计划留占位符TBD、TODO、「适当处理错误」都是计划失败的信号writing-plans 要求每个任务都有真实内容。别在一个长会话里让 AI 写太多代码交给执行体系单功能用 superpowers 自带执行多阶段用 gsd-core防上下文腐化。别让 UI 直接在代码里调先 opendesign 出原型用眼睛确认长相再进代码。别忘了 CLAUDE.md 里写 codegraph 规则不写规则下个会话的 AI 又会用老办法检索。新项目有 PRD 就别重复发散PRD 已经是收敛过的产物直接--prd喂给 GSD。八、串起来一个典型工作日早上进老项目先看一眼状态 /gsd-progress # 我在哪、下一步干什么 接了个新二开需求要加个功能 新页面 codegraph explore 相关模块调用链 # ① 先建认知随手查 brainstorming # ③ 发散多轮挖掘到需求清晰产出设计文档 opendesign # ⑥ 涉及页面出 HTML 原型确认「长这样」 writing-plans # ④ 收敛拆成任务级实现计划 /gsd-progress --do 执行这个计划 # ⑤ 满血执行 原子提交 验收 新项目有完整 PRD /gsd-new-project → /gsd-plan-phase 1 --prd docs/xxx.md → … → /gsd-ship 1 下午突发的临时小改动 /gsd-quick 改个错别字 # 小任务不需要完整流程 /gsd-debug 用户点保存没反应 # 出 bug系统化排查九、总结这套方法的本质是三句话先认知再动手codegraph——AI 必须真认得你的代码先设计再实现brainstorming → writing-plans——需求不发散返工是必然满血执行 状态落盘superpowers 自带执行 / gsd-core——让质量不取决于你们聊了多久单功能走轻的多阶段走重的。工具会更新命令会变但这三个原理不会过时。用的时候想「我在哪个环节、要解决什么问题」比硬记命令更靠谱。如果你也在用 AI 写代码、想让 AI 从「乱写」变成「按套路好好写」这套分层打法可以直接照搬。工具怎么搭配、顺序怎么排欢迎在评论区交流你的实践文中涉及工具codegraph / GSD Core / Superpowers / OpenDesign均为开源项目内容为作者个人实践总结非官方教程部分命令与技能如 brainstorming、writing-plans来自第三方技能集安装方式与完整命令请查阅对应项目的官方说明。命令与产物路径可能随版本更新请以各工具官方文档为准。