OpenSpec+Superpowers+GStack：AI编程全流程自动化实战指南

AI编程进入工程化串联时代

单个AI编程工具的能力早已不是瓶颈。真正卡住效率的地方在于——怎么把多个工具串成一条线，从需求写完到代码发布，中间不断档、不掉链子。

今天拆解的方案由三个工具组成：OpenSpec 管需求、Superpowers 管质量、GStack 管全流程。三者各司其职，在同一个 Claude Code 会话里共存、自动衔接，做到"敲一条斜杠命令，后面全自动跑完"的工程化AI编程体验。

这里提到的 Claude Code 是 Anthropic 推出的终端原生 AI 编程代理，它直接运行在开发者的命令行环境中，能够读写文件、执行 shell 命令、管理 Git 操作。与 IDE 插件形态的 GitHub Copilot 不同，Claude Code 以 Agent 模式运行，具备自主规划和多步执行能力。三个工具能在同一个会话中共存，关键在于 Claude Code 的 Slash Command 和 Custom Instruction 机制——每个工具通过独立的配置文件注入自己的行为规则和可用命令，Claude Code 的上下文窗口同时加载这些规则，根据用户输入的斜杠命令动态激活对应工具的逻辑。这种架构类似于 Unix 哲学中的管道组合——每个工具做好一件事，通过标准接口串联。

三个工具各管什么

OpenSpec：动手写代码前，先把需求锁死

OpenSpec 的核心机制是 DAG 产物依赖图——在写第一行代码之前，就把需求彻底对齐。

DAG（Directed Acyclic Graph，有向无环图）是计算机科学中一种经典的数据结构，广泛应用于任务调度、编译依赖分析和工作流编排等场景。在 OpenSpec 的语境中，DAG 产物依赖图意味着四份需求文件之间存在严格的先后依赖关系：Proposal 是 Specs 的输入，Specs 是 Design 的输入，Design 是 Tasks 的输入——形成一条单向链路，不允许出现循环依赖。这种设计借鉴了构建工具（如 Make、Bazel）的依赖解析思想：只有上游产物通过验证，下游产物才能开始生成，从根本上杜绝了"需求还没定清楚就开始画架构图"的常见工程混乱。

OpenSpec 会依次产出四份关键文件：

• Proposal：功能提案，说清楚要做什么、为什么做
• Specs：需求规格说明，定义验收标准
• Design：设计方案，明确技术选型和架构
• Tasks：任务拆解，把大需求拆成可执行的小步骤

这四份文件就是后续所有环节的"唯一真相源"（Single Source of Truth）。需求没对齐就不动手，这是工程化AI编程的第一道防线。

Superpowers：写代码的过程中，把质量卡住

Superpowers 的核心武器是 HLAT JT + TDD 铁律。TDD（Test-Driven Development，测试驱动开发）是 Kent Beck 在 2003 年系统化提出的软件开发方法论，核心循环是"红-绿-重构"：先写一个会失败的测试（红），再写最少量的代码让测试通过（绿），最后重构代码消除重复。

HLAT JT 是 Superpowers 框架中对 TDD 的工程化强化实现——HLAT 代表 High-Level Acceptance Test（高层验收测试），JT 代表 Journey Test（旅程测试），两者结合确保不仅单元逻辑正确，用户完整操作路径也被覆盖。

Superpowers 通过 Hard Gate 机制自动拦截低质量代码——每段业务逻辑必须先写测试，测试跑不过就不能往下走。Hard Gate 类似于 CI/CD 管线中的 Quality Gate（如 SonarQube 的质量阈值），但它直接嵌入到 AI 编码会话中，在代码生成的瞬间就进行拦截，而非等到代码提交后才检查。

TDD 铁律只有三个明确的例外：

1. 一次性原型代码
2. 自动生成的代码
3. 配置文件

除此之外，铁律没有打折空间。所有规则存放在 .clrmd 和 Skill 文件里，与其他工具的状态完全隔离，互不干扰。

GStack：代码写完之后，把发布全包了

GStack 负责从计划到发布的全流程管理，核心是 Browse 引擎 + 七阶段 Sprint 管线。

GStack 的 Browse 引擎是一个内置的无头浏览器控制层，底层基于 Playwright 和 Chromium 实现自动化浏览器操作。Playwright 是微软开源的端到端测试框架，支持 Chromium、Firefox 和 WebKit 三大浏览器引擎，能够模拟真实用户的点击、输入、导航等操作。七阶段 Sprint 管线借鉴了敏捷开发中 Sprint 的概念，但将其细化为七个离散的自动化阶段。传统敏捷 Sprint 依赖人工站会和看板追踪，而 GStack 将每个阶段的准入和准出条件编码为可执行规则，实现了从计划到发布的全自动流转。这种设计思路与 GitOps 理念一脉相承——用声明式配置和自动化管线取代手动操作，确保每次发布都是可重复、可审计的。

GStack 覆盖了计划评审、代码审查、QA验收、版本发布的完整链路，所有状态存放在独立的 gstack/ 目录中。

四个自动衔接点：串联的核心机制

三个工具不是"你干完我再干"的接力赛，而是在同一个 Claude Code 会话里自动触发、互相衔接。这是整套方案最精妙的地方。

衔接点一：OpenSpec 产物 → GStack 评审输入

OpenSpec 生成的 Proposal、Specs、Design、Tasks 四份文件，直接喂给 GStack 的 Auto Plan 模块。GStack 会从四个维度做评审：CEO视角看商业价值、工程视角看技术可行性、设计视角看用户体验、DX视角看开发者友好度。

这种四维度评审机制借鉴了产品管理领域的多角色评审实践。在传统软件公司中，一个功能提案通常需要经过产品委员会、技术评审会、设计评审和开发者体验审查等多轮人工评审，往往耗时数天甚至数周。GStack 将这四个维度编码为自动化评审规则：CEO视角评估 ROI（投资回报率）和战略对齐度；工程视角评估技术债务、性能影响和可维护性；设计视角评估交互一致性和可用性；DX视角评估 API 设计、文档完整性和开发者上手成本。这种思路与 Amazon 的"六页纸备忘录"文化异曲同工——在动手之前，强制从多个角度审视决策的合理性。

衔接点二：Superpowers Hard Gate → 编码阶段自动拦截

一旦进入编码阶段，Superpowers 的 Hard Gate 自动激活。任何不符合质量标准的代码提交都会被拦下来，必须修正后才能继续。

衔接点三：TDD 铁律 → GStack Review 自动生效

Superpowers 的 TDD 铁律保证了每段代码都有测试覆盖。这意味着 GStack 做 Code Review 时，有了可靠的质量底线——不是靠人肉检查，而是靠测试结果说话。

衔接点四：GStack SHIP → OpenSpec Archive 归档闭环

发布完成后，GStack 的 SHIP 命令会自动触发 OpenSpec 的 Archive 操作，把本次迭代的 Delta 规范合入主规范，完成从需求到发布再到归档的完整闭环。

一个功能从想法到上线的七步流程

理解了串联机制，来看一个功能的完整生命周期：

步骤	具体动作	负责工具
1	生成需求产物（Proposal → Specs → Design → Tasks）	OpenSpec
2	Auto Plan 读取产物，执行四维度评审	GStack
3	TDD 铁律自动生效，先写测试再写代码	Superpowers
4	Review 审查代码，扫描 Diff 定位问题	GStack
5	QA 用 Playwright + Chromium 做真实浏览器验收	GStack
6	SHIP 自动执行版本升级、生成 Changelog、创建 PR 推送	GStack
7	Archive 归档，Delta 规范合入主规范	OpenSpec

关键不在于"做了哪些事"，而在于每一步如何自动触发下一步。你只需要输入对应的斜杠命令，工具之间的衔接全部自动完成。

避坑指南：三条必须遵守的铁律

三个工具协作时，职责边界必须划清楚。以下是实际使用中最容易踩的三个坑。

铁律一：不要设置重复门禁

Superpowers 的 Hard Gate 已经负责设计审批，就别再用 GStack 的 Plan Design Review 重复审查同一份设计文档。双重门禁不会让质量更高，只会让流程更慢。这个问题在软件工程中被称为"过度流程化"（Process Bloat），它会显著增加每次迭代的周期时间，而不会带来对等的质量收益。

铁律二：Specs 是唯一的需求真相源

OpenSpec 的 Specs 文件定义"做什么"，GStack 的设计文档描述"怎么做"。两者不能混为一谈——需求变更改 Specs，实现方案调整改 GStack 设计文档。搞混了就会出现需求和实现对不上的问题。这一原则与领域驱动设计（DDD）中"通用语言"的理念一致：团队必须对核心概念有唯一且一致的定义，否则沟通成本会随着项目规模指数级增长。

铁律三：SHIP 是唯一的发布出口

GStack 的 SHIP 命令是唯一合法的发布通道。OpenSpec 的 Archive 只是收尾归档，不是发布操作。所有发布必须走 SHIP，确保版本号递增、Changelog 生成、PR 创建等环节一个不落。这种"单一发布通道"的设计遵循了持续交付（Continuous Delivery）的核心原则——发布流程必须是可重复的、自动化的、可审计的，任何绕过标准管线的"热修复"或"手动部署"都是潜在的风险源。

核心设计哲学：三套状态互不干扰

这套AI编程自动化方案能稳定跑通，根本原因在于状态隔离：

• OpenSpec 的产物存在 openspec/ 目录
• Superpowers 的规则存在 .clrmd 和 Skill 文件里
• GStack 的状态存在 gstack/ 目录

状态隔离是分布式系统和微服务架构中的核心设计原则。在微服务架构中，每个服务拥有独立的数据存储，避免共享数据库带来的耦合问题。这三套独立目录结构本质上是将这一原则应用到了 AI 编程工具链中。状态隔离带来三个关键好处：一是故障隔离——某个工具的配置出错不会污染其他工具的运行状态；二是独立演进——每个工具可以独立升级版本而不影响其他工具；三是可调试性——出现问题时可以精确定位到具体工具的状态目录进行排查。这与 Twelve-Factor App 方法论中"严格分离配置与代码"的理念高度一致。

三套状态互不干扰，三个工具在同一个 Claude Code 会话里共存。各自的命令和技能全部可用，但管的层次泾渭分明：

• OpenSpec：写代码前，把需求锁住
• Superpowers：写代码时，把质量卡住
• GStack：写完代码后，把发布包了

这种分层架构让每个工具只专注自己最擅长的环节，通过四个自动衔接点实现无缝串联，最终形成一条完整的AI编程自动化流水线。

总结：让专精工具自动协作

工程化AI编程的核心思路不是找一个"什么都能干"的万能工具，而是让多个专精工具在同一个工作流里自动协作。

OpenSpec + Superpowers + GStack 这套组合的价值可以用一句话概括：需求有锁、质量有卡、发布有包，三道防线自动生效。

对于追求代码质量和交付效率的开发团队来说，这套基于 Claude Code 的AI编程工具链方案，值得花时间认真研究和落地实践。