前言在 AI 辅助编程也就是很多人说的Vibe Coding大行其道的今天开发者经常会遇到一个很微妙的崩溃瞬间AI 确实能秒写代码。但是它太急于交差了。需求还没问清楚它已经开始改文件测试还没补它已经说“已完成”上下文一长它就开始自由发挥甚至把不存在的 API、目录和业务规则写得像真的一样。所以AI 编程的瓶颈早就不是“它能不能写出来”而是它能不能按工程纪律写对、测过、交付清楚。为了把 AI 从“手速极快的实习生”训练成“靠谱的高级工程师”开源社区逐渐形成了 AI 编程的“三件套”思路OpenSpec先把需求变成规格解决“做什么”的问题。Superpowers把工程方法变成技能解决“怎么做”的问题。gstack把审查、QA、发布变成团队流程解决“怎么交付”的问题。本文会从概念、安装、实战流程、避坑和技术分享考点五个角度完整讲清这三个工具如何串成一套 AI 驱动开发工作流。⚡ 快速参考适用场景使用 Claude Code、Cursor、Codex、OpenCode 等 AI 编程助手做真实项目开发希望减少 AI 乱写、漏测、假完成。核心结论OpenSpec 管需求规格Superpowers 管开发纪律gstack 管交付验证三者不是互相替代而是上下游协作。最短工作流OpenSpec 提案-Superpowers 计划与 TDD-gstack Review/QA/Ship。常用命令# OpenSpecnpminstall-gfission-ai/openspeclatest openspec init# gstackgitclone --single-branch--depth1https://github.com/garrytan/gstack.git ~/gstackcd~/gstack./setup避坑提醒不要把这三件套理解成“多装几个插件”。真正有价值的是背后的工作流规格先行、测试先行、验证先行。 学习目标说清 OpenSpec、Superpowers、gstack 各自解决什么问题。能把三者串成一套真实项目中的 AI 编程流程。理解 AI 编程里的 SDD、TDD、上下文工程、交付验证到底怎么落地。避开 AI 编程中最常见的“需求没锁定、代码没测试、交付没验证”三类坑。一、为什么 AI 编程需要“三件套”1.1 Vibe Coding 的效率幻觉Vibe Coding 的体验很爽你描述一句需求AI 读仓库、改代码、跑命令、给总结。但真实项目里问题通常不在“AI 不会写代码”而在下面这些地方问题表现后果需求模糊你说“加一个暗黑模式”AI 立刻开写没有确认系统偏好、用户持久化、默认策略执行失控AI 一次改很多文件你很难审查 diff也很难定位回归测试缺失AI 写完功能就总结完成边界条件、回归测试、UI 状态都没覆盖上下文漂移对话一长AI 开始忘记原始约束代码越写越偏甚至生成不存在的接口交付假完成AI 说“已修复”但没有真实浏览器验证上线后才发现控制台报错、表单不可用这就是 AI 编程最常见的误区把 AI 当成“代码生成器”而不是“需要流程约束的执行者”。1.2 三件套分别解决什么可以把 AI 编程三件套理解成一个虚拟研发团队层级工具核心问题类比角色规格层OpenSpec做什么产品经理 架构记录员执行层Superpowers怎么做高级工程师 TDD 教练交付层gstack怎么确认能交付Reviewer QA Release Engineer它们不是三选一而是接力关系OpenSpec 先把模糊需求沉淀成可审查的规格文档。Superpowers 约束 AI 按计划、测试、调试、审查的纪律执行。gstack 在交付前补上代码审查、真实浏览器 QA、安全和发布检查。1.3 一图理解三层关系二、OpenSpec规格层先管“做什么”2.1 OpenSpec 是什么OpenSpec 是一个面向 AI 编程的轻量级Spec-Driven Development规格驱动开发工具。它的核心思想非常简单先写规格再写代码。在传统开发里需求可能散落在聊天记录、Issue、脑子里。AI 一旦进入长对话很容易丢失上下文。OpenSpec 的做法是把一次需求变更拆成结构化文档通常包括文档作用解决的问题proposal.md为什么要做、要改什么防止需求目标漂移design.md技术方案、边界、数据流防止 AI 直接乱改架构tasks.md可执行任务清单防止任务过大、改动失控specs/长期规格资产防止项目知识只存在聊天里这类文档可以进 Git可以被 Review也可以在未来继续被 AI 读取。2.2 OpenSpec 解决的核心痛点OpenSpec 主要解决三个问题需求从口头变成资产不再只靠一句 Prompt 驱动 AI而是把需求变成可版本管理的文档。AI 在正确轨道上工作AI 每一步都围绕 proposal、design、tasks 执行不容易偏题。复杂需求可拆解、可审查大任务先拆成多个小任务人可以先审规格再让 AI 动手。2.3 OpenSpec 基本安装OpenSpec 可以通过 npm 全局安装npminstall-gfission-ai/openspeclatest进入项目根目录后初始化cdyour-project openspec init初始化后项目里会生成openspec/相关目录用来存放变更提案、设计文档、任务清单和规格文件。常见工作方式如下/opsx:explore /opsx:propose add-dark-mode /opsx:apply /opsx:archive说明/opsx:explore在不急着实现前先和 AI 一起探索需求。/opsx:propose把需求写成提案、设计和任务。/opsx:apply按任务清单实现。/opsx:archive完成后归档变更更新长期规格。不同 AI 编程助手对斜杠命令的集成方式可能不同实际以 OpenSpec 官方文档和你使用的宿主工具为准。2.4 示例用 OpenSpec 锁定暗黑模式需求不要这样写给应用加一个暗黑模式。更推荐这样开始/opsx:propose add-dark-mode 目标给应用添加暗黑模式。 要求 1. 支持跟随系统偏好。 2. 支持用户手动切换 light / dark / system。 3. 用户选择需要持久化。 4. 首屏加载时不能闪白。 5. 补充单元测试和至少一个端到端验证场景。这样 AI 不会马上乱改而是先生成规格文档让你审查openspec/ changes/ add-dark-mode/ proposal.md design.md tasks.md你确认规格没问题再进入实现阶段。三、Superpowers执行层管“怎么做”3.1 Superpowers 是什么Superpowers 可以理解为一套给 AI 编程助手使用的工程技能库。它不是单纯增加几个 Prompt而是把软件工程里的最佳实践变成 AI 必须遵守的工作方式例如头脑风暴前先澄清问题。写代码前先写计划。修 bug 前先做系统化调查。实现功能前优先采用 TDD。完成后主动请求代码审查。声称完成前必须运行验证命令。这正好补上了 AI 最容易偷懒的地方。3.2 Superpowers 解决的核心痛点AI 写代码经常像一个兴奋的新同事“我懂了我马上改。”但高级工程师不会这么做。高级工程师会先问需求边界是什么有没有现有模式可以复用哪些测试能证明它真的工作如果失败怎么定位根因这次改动会不会影响别的模块Superpowers 的价值就是把这套纪律固定下来。能力对应工程实践价值brainstorming需求澄清避免没想清就开写writing-plans实施计划把大任务拆成小步骤test-driven-developmentTDD先证明问题再实现systematic-debugging系统化调试避免拍脑袋修 bugrequesting-code-review代码审查完成前自查风险verification-before-completion完成前验证防止“嘴上通过”3.3 Superpowers 的典型安装方式Superpowers 通常作为技能目录安装到 AI 助手的技能路径中。以 Claude Code 为例常见安装方式类似gitclone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers如果你使用的是 Cursor、Codex、OpenCode、Trae 等其他工具需要根据它们各自的 Skills 或 Rules 目录调整安装位置。例如Claude Code: ~/.claude/skills/ Codex: ~/.codex/skills/ Cursor: 以官方 Skills / Rules 支持为准 Trae: 以官方 Skills / Rules 支持为准重点不是路径本身而是让 AI 编程助手能在合适场景自动加载这些技能。3.4 Superpowers 如何约束 AI 编码假设 OpenSpec 已经生成了任务1. 添加主题状态模型 2. 实现 light / dark / system 三种模式 3. 持久化用户选择 4. 避免首屏闪烁 5. 补充测试Superpowers 介入后AI 不应该直接写一大坨代码而应该按工程节奏执行需求澄清 - 实施计划 - 写失败测试 - 最小实现 - 测试通过 - 重构 - 验证 - 审查用 TDD 表达就是Red先写失败测试证明当前功能不存在或行为不符合预期 Green写最少代码让测试通过 Refactor在测试保护下清理结构 Verify运行完整验证命令确认没有回归3.5 一个好用的手动触发方式如果你的 AI 助手支持斜杠命令或技能命令可以在复杂任务前明确要求使用 Superpowers 的 brainstorming 和 writing-plans。 先澄清需求再写计划。 计划通过后用 TDD 实现不要跳过测试。 完成前运行验证命令并给出验证结果。这句话的本质不是“念咒”而是把 AI 的行为从“生成答案”切换成“执行工程流程”。四、gstack交付层管“怎么交付”4.1 gstack 是什么gstack 是 Garry Tan 开源的一套 AI 编程技能和工作流集合。它的定位很直接把 AI 编程助手组织成一个虚拟工程团队。在 gstack 里你可以使用不同技能完成不同交付动作例如命令角色作用/office-hours产品/创业顾问澄清产品想法/plan-ceo-reviewCEO 视角挑战范围和价值/plan-eng-review工程经理审查架构和风险/review高级工程师代码审查找 bug 和回归风险/qaQA 负责人打开真实浏览器做交互测试/cso安全负责人做安全审计/ship发布工程师发布前检查如果说 Superpowers 强调“编码过程的纪律”那么 gstack 更强调“交付前的完整把关”。4.2 gstack 解决的核心痛点很多 AI 编程失败不是失败在写代码而是失败在最后 20%没有认真审 diff。没有跑真实页面。没有检查控制台报错。没有考虑安全边界。没有发布前清单。gstack 把这些动作显式化。尤其是/qa这类能力价值很高让 AI 不只是在文本里说“页面应该能用”而是打开真实浏览器点击、输入、检查状态和报错。这对于前端页面、后台管理系统、登录注册、表单提交、支付流程等场景尤其重要。4.3 gstack 基本安装gstack 支持多种 AI 编程助手。通用安装方式gitclone --single-branch--depth1https://github.com/garrytan/gstack.git ~/gstackcd~/gstack./setup如果需要指定宿主可以使用./setup--hostcodex ./setup--hostcursor ./setup--hostopencode如果你使用 Claude Code也可以安装到 Claude 的技能目录gitclone --single-branch--depth1https://github.com/garrytan/gstack.git ~/.claude/skills/gstackcd~/.claude/skills/gstack./setup安装完成后可以在支持的 AI 编程助手中使用对应技能例如/review /qa https://staging.example.com /ship4.4 gstack 在工作流中的位置gstack 不应该只在“代码写完之后”才出现。更好的方式是分阶段使用渲染错误:Mermaid 渲染失败: Lexical error on line 2. Unrecognized text. ... -- B[/office-hours] B -- C[/plan- -----------------------^不过在本文这套三件套工作流里可以简单理解为OpenSpec 负责把需求变成规格。Superpowers 负责按纪律实现。gstack 负责交付前多角色检查。五、三件套如何串联一套黄金工作流5.1 总体流程把三件套串起来后一个比较稳的 AI 编程流程如下gstackSuperpowersOpenSpec开发者gstackSuperpowersOpenSpec开发者描述需求生成 proposal/design/tasks人工审查并确认进入任务执行计划、TDD、调试、验证提交可审查变更review、qa、ship输出交付结论和风险一句话总结OpenSpec 让 AI 别跑偏Superpowers 让 AI 别偷懒gstack 让 AI 别假完成。5.2 Step 1用 OpenSpec 锁定需求以“添加暗黑模式”为例先不要直接让 AI 改代码。输入/opsx:propose add-dark-mode 给应用添加暗黑模式 1. 支持 light、dark、system 三种模式。 2. system 模式跟随操作系统偏好。 3. 用户手动选择需要持久化。 4. 首屏加载不能出现明显闪烁。 5. 需要补充测试和验证步骤。OpenSpec 生成文档后你先 Reviewproposal.md目标是否清楚 design.md方案是否合理 tasks.md任务是否足够小确认无误后再执行/opsx:apply5.3 Step 2用 Superpowers 保障实现质量进入编码阶段后明确要求 AI 使用工程纪律请按 Superpowers 工作流执行 1. 先读取 OpenSpec 生成的 tasks.md。 2. 为每个任务写一个小计划。 3. 使用 TDD先补失败测试再写实现。 4. 每完成一个任务运行相关测试。 5. 完成后运行完整验证命令。一个理想的执行记录应该像这样[Plan] 本次实现拆成 4 个小步骤 [Red] 新增 theme preference 测试当前失败 [Green] 实现 useThemePreference让测试通过 [Refactor] 抽离 localStorage 访问函数 [Verify] npm test 通过npm run lint 通过如果测试失败不要让 AI 猜。要求它进入系统化调试不要直接修。 先复现失败列出观察结果再提出 2-3 个可能原因。 确认根因后再修改。5.4 Step 3用 gstack 做交付把关实现完成后不要直接合并。先让 gstack 做代码审查/review重点看是否有潜在 bug。是否破坏现有行为。是否缺测试。是否有安全风险。是否有明显 AI 生成的冗余代码。如果是前端功能再做真实 QA/qa http://localhost:3000让 AI 打开浏览器实际验证默认主题是否正确。切换 light / dark / system 是否生效。刷新后用户选择是否保留。控制台是否有报错。页面是否出现闪烁。最后进入发布检查/ship这一步通常会检查测试、diff、文档、版本、变更说明等。六、完整实战案例给应用添加暗黑模式下面用一个简化案例把三件套串起来。6.1 需求输入原始需求给应用加一个暗黑模式。这句话太模糊需要改写成可执行需求目标给应用添加暗黑模式。 功能要求 1. 支持 light / dark / system 三种主题。 2. 默认使用 system。 3. 用户手动选择后写入 localStorage。 4. 页面刷新后恢复用户选择。 5. 首屏渲染时尽量避免主题闪烁。 质量要求 1. 补充单元测试。 2. 补充至少一个浏览器验证场景。 3. 不引入新的 UI 框架。 4. 遵循现有项目的组件和样式约定。6.2 OpenSpec 阶段输入/opsx:propose add-dark-mode期望生成openspec/changes/add-dark-mode/ proposal.md design.md tasks.md人工审查重点文件审查点proposal.md是否说明为什么要做、用户价值是什么design.md主题状态放在哪里、如何避免闪烁、如何持久化tasks.md是否拆成可独立验证的小任务如果tasks.md里出现类似“实现暗黑模式全部功能”这种大任务要继续拆。更好的任务清单1. 新增主题偏好类型和存储工具函数。 2. 新增 ThemeProvider支持 light / dark / system。 3. 新增主题切换 UI。 4. 添加首屏主题初始化脚本。 5. 补充单元测试。 6. 补充浏览器 QA 验证步骤。6.3 Superpowers 阶段让 AI 按 TDD 执行读取 openspec/changes/add-dark-mode/tasks.md。 请使用 TDD 实现。 每次只处理一个任务 1. 先写测试。 2. 再写最少实现。 3. 测试通过后再重构。 4. 每完成一个任务汇报 diff 和验证结果。理想的验证命令可能是npmtestnpmrun lintnpmrun typecheck如果项目是后端服务可能是mvntest如果是 Python 项目可能是pytest ruff check.关键点验证命令必须来自项目本身而不是 AI 临时编出来。6.4 gstack 阶段代码实现后/review让 AI 重点检查请重点看 1. 首屏主题闪烁风险。 2. localStorage 不可用时的降级。 3. system 模式监听 prefers-color-scheme 变化是否正确清理。 4. 测试是否覆盖 light / dark / system。 5. 是否有无关 refactor。如果是 Web 应用/qa http://localhost:3000QA 检查清单1. 首次访问默认跟随系统。 2. 切换 dark 后页面立即变化。 3. 刷新后仍保持 dark。 4. 切换 system 后跟随系统偏好。 5. 控制台无报错。 6. 关键页面视觉没有明显错位。准备发布/ship发布前确认1. 测试通过。 2. lint/typecheck 通过。 3. 代码审查问题已处理。 4. QA 问题已处理。 5. changelog 或发布说明已更新。七、三件套不是银弹它们各自的边界7.1 OpenSpec 的边界OpenSpec 能帮你沉淀规格但不能替你判断业务价值。如果一开始的方向就是错的规格写得再漂亮也没用。适合 OpenSpec 的场景新功能开发。架构调整。多模块变更。团队需要审查需求和技术方案。不一定需要 OpenSpec 的场景修一个错别字。改一行配置。临时验证一个小实验。7.2 Superpowers 的边界Superpowers 能约束 AI 的执行过程但它依赖项目本身有基本工程基础。如果项目没有测试、没有 lint、没有清晰模块边界AI 也很难凭空变出稳定流程。所以使用 Superpowers 前最好先补齐项目启动命令。测试命令。lint/typecheck 命令。目录说明。编码规范。这些可以写到AGENTS.md CLAUDE.md README.md7.3 gstack 的边界gstack 能做审查、QA、安全和发布检查但它不是替代人工负责。尤其是涉及支付、权限、隐私、生产数据的变更。涉及数据库迁移的变更。涉及安全策略的变更。涉及公司合规和发布流程的变更。这些仍然需要人来最终决策。八、场景应用场景 1个人开发者做独立项目需求一个人维护项目想快速迭代但怕 AI 改乱代码。推荐流程OpenSpec 写清每个功能变更 Superpowers 约束 AI 按 TDD 实现 gstack 在发布前做 /review 和 /qa收益每个功能都有规格记录。改动更容易回看。不容易出现“AI 说完成但页面打不开”。场景 2团队协作开发需求多人参与同一个仓库希望 AI 输出可审查、可追踪。推荐流程OpenSpec 作为需求和技术方案入口 AGENTS.md 写团队编码规范和测试命令 Superpowers 负责执行纪律 gstack /review 作为 PR 前置自查收益AI 不再只听某一次聊天上下文。团队可以 Review 规格和任务。PR 质量更稳定。场景 3遗留系统重构需求老项目复杂不敢让 AI 大范围乱改。推荐流程OpenSpec 先限定重构范围 Superpowers 要求小步 TDD gstack 做风险审查和回归 QA特别注意每次只改一个模块。每次只做一个明确目标。不要让 AI 顺手“优化全项目”。九、开发避坑总结9.1 典型坑 1装了工具但还是一句话让 AI 开写错误方式帮我把系统优化一下。正确方式先用 OpenSpec 生成变更提案。 不要写代码。 我确认 proposal、design、tasks 后再进入实现。9.2 典型坑 2把 OpenSpec 当文档生成器OpenSpec 的重点不是“多生成几份 Markdown”而是让规格成为开发入口。真正的流程应该是需求 - 规格 - 审查 - 任务 - 实现 - 归档如果规格写完没人看、没人审、实现时也不读那就失去了意义。9.3 典型坑 3AI 写完测试但没有运行很多 AI 会说我已经添加了测试。但“添加测试”和“测试通过”不是一回事。你应该要求请运行项目测试命令并贴出关键结果。 如果测试失败不要跳过先定位根因。9.4 典型坑 4gstack QA 没有真实环境/qa需要能访问你的应用页面。如果本地服务没启动、登录态没有准备、测试账号不可用QA 结果就会受限。建议提前准备1. 本地启动命令 2. 测试账号 3. 需要验证的 URL 4. 核心路径检查清单9.5 典型坑 5多个工具职责混乱不要让三个工具互相抢活。更清晰的职责分工是阶段主工具人的职责需求阶段OpenSpec判断需求是否值得做编码阶段Superpowers审查计划和测试交付阶段gstack决定是否合并和发布十、总结AI 编程的未来不是“AI 替代开发者”而是“开发者带着 AI 组成更高效的研发系统”。在这个系统里开发者负责判断、取舍、审查和最终责任。AI 负责执行、验证、整理和重复性工作。工具负责把流程固化下来减少 AI 的随意发挥。OpenSpec、Superpowers、gstack 分别补齐了 AI 编程中最关键的三块短板OpenSpec 让 AI 理解你要什么。Superpowers 让 AI 按工程纪律去做。gstack 让 AI 在交付前接受审查和验证。当你愿意花时间把需求想清楚把任务拆清楚把测试和 QA 跑清楚AI 就不再只是“写得快”而是开始接近一个真正可靠的工程协作者。这也是 AI 编程从玩具走向生产力的分水岭不是让 AI 更自由而是给 AI 更好的工程约束。参考链接OpenSpec npm 包https://www.npmjs.com/package/fission-ai/openspecOpenSpec GitHubhttps://github.com/Fission-AI/OpenSpecSuperpowers GitHubhttps://github.com/obra/superpowersgstack GitHubhttps://github.com/garrytan/gstack本文为MY_TEUCK原创实战学习笔记持续更新Java后端与AI应用领域干货问题欢迎评论区交流。