OpenSpec + Superpowers + gstack 完整工作流指南
一、整体定位
这三套体系并不是互相替代，而是互补关系。
可以理解为：
OpenSpec = 项目规格层（长期上下文）
Superpowers = 开发执行层（高质量编码）
gstack = AI团队层（PM/QA/Review/发布）
完整关系：
gstack(产品/架构/QA/发布)↓OpenSpec(spec / design / task)↓Superpowers(编码 / TDD / Debug)
适合：
- Go + Gin
- Java Spring
- Node.js
- 前后端分离
- 中大型项目
- 多模块系统
- 长期维护项目
- AI协作开发
二、推荐项目结构
project/
├── backend/
├── frontend/
├── openspec/
│ ├── specs/
│ ├── changes/
│ └── archive/
├── .claude/
│ ├── skills/
│ └── agents/
├── docs/
└── scripts/
三、三者职责详解
| 工具 | 核心职责 | 解决的问题 |
|---|---|---|
| OpenSpec | 管需求/设计/spec | AI上下文丢失 |
| Superpowers | 管开发/TDD/Debug | AI代码质量低 |
| gstack | 管团队/QA/发布 | AI工程流程混乱 |
四、OpenSpec 工作流
OpenSpec 核心思想：
先写规格
再写代码
即：
Proposal
→ Design
→ Tasks
→ Implement
→ Archive
五、OpenSpec 目录结构
1. specs/
当前系统正式规格。
例如：
openspec/specs/
├── article/
├── category/
├── auth/
└── user/
用于：
- 当前线上系统能力
- AI长期记忆
- 新人阅读
- 系统文档化
2. changes/
每次开发需求。
例如：
openspec/changes/add-homepage-category/
内部：
proposal.md
design.md
tasks.md
specs/
3. archive/
完成后的需求归档。
例如：
openspec/archive/2026-05-add-homepage-category/
六、OpenSpec 完整开发流程
假设需求：
新增首页分类聚合接口
Step 1：创建变更
/opsx:new homepage-category-system
生成：
openspec/changes/homepage-category-system/
Step 2：生成 proposal
# Proposal目标：新增首页分类聚合接口。需求：- 首页区域化展示
- 一级分类聚合
- 二级三级分类支持
- 最新文章推荐
- 浏览量排序
Proposal 主要回答：
为什么做
Step 3：生成 design
# Design接口：GET /v1/home/index数据库：category
article
article_view_log缓存：Redis 5分钟缓存
Design 主要回答：
怎么做
Step 4：生成 tasks
# Tasks- [ ] 分类查询
- [ ] 文章聚合
- [ ] DTO设计
- [ ] Redis缓存
- [ ] 浏览量统计
- [ ] 单元测试
Tasks 主要回答：
拆成哪些步骤
Step 5：开始开发
此时再交给：
Superpowers
开发。
Step 6：完成归档
/opsx:archive
需求会进入：
archive/
系统 spec 更新。
七、Superpowers 工作流
Superpowers 本质：
AI开发技能库
目标：
让 AI 像高级工程师一样开发
八、Superpowers 常用技能
| Skill | 作用 |
|---|---|
| brainstorming | 需求分析 |
| executing-plans | 按计划开发 |
| test-driven-development | TDD开发 |
| systematic-debugging | 系统化Debug |
| code-review | 自动Review |
| verification-before-completion | 完成前验证 |
九、Superpowers 推荐开发流程
完整流程：
brainstorming↓
executing-plans↓
TDD↓
debugging↓
review↓
verification
十、Superpowers 实战流程
需求：
实现文章详情接口
Step 1：brainstorming
输入：
使用 brainstorming 设计文章详情接口
AI 会分析：
- 路由设计
- DTO结构
- DAO层
- 缓存策略
- SEO字段
- 浏览量统计
- 错误处理
输出类似：
handler
↓
biz
↓
dao
↓
model
Step 2：executing-plans
输入：
使用 executing-plans 实现文章详情接口
AI 会：
先列步骤
再逐步实现
例如：
1. 创建DTO
2. 编写路由
3. 编写biz
4. 编写dao
5. 编写缓存
6. 编写日志
7. 编写测试
Step 3：TDD
输入：
使用 test-driven-development 开发
AI 流程：
先测试
→ 再实现
→ 再验证
例如：
测试：
- id不存在
- id非法
- 文章已删除
- 正常返回
Step 4：systematic-debugging
当出现：
panic
SQL错误
缓存问题
使用：
使用 systematic-debugging 分析问题
AI 会：
定位问题
分析原因
给出修复步骤
Step 5：verification-before-completion
最后：
使用 verification-before-completion
AI 会检查：
- 是否遗漏
- 是否有边界问题
- 是否有panic
- 是否有SQL风险
- 是否有context问题
- 是否有缓存问题
十一、gstack 工作流
gstack 核心：
AI 软件团队
不是单纯代码生成。
而是：
PM
Architect
QA
Security
Review
Release
全流程。
十二、gstack 常见 Agent
| Agent | 职责 |
|---|---|
| PM Agent | 产品需求 |
| Architect Agent | 架构设计 |
| QA Agent | 质量检查 |
| Review Agent | Code Review |
| Security Agent | 安全审计 |
| Ship Agent | 发布检查 |
十三、gstack 完整流程
完整：
PM
↓
Architect
↓
Coder
↓
QA
↓
Review
↓
Security
↓
Ship
十四、gstack 实战流程
Step 1：PM 阶段
/office-hours
AI 会像产品经理一样提问：
1. 首页有哪些区域？
2. 分类是否支持三级？
3. 是否需要SEO？
4. 是否需要Redis？
5. 是否记录访问日志？
6. 是否需要推荐系统？
最终生成：
PRD
需求文档
技术方向
Step 2：Architect 阶段
/architect
AI 会设计：
接口
数据库
缓存
索引
模块拆分
例如：
GET /v1/article/:id
以及：
article(category_id, publish_time)
联合索引建议。
Step 3：Coder 阶段
交给：
Superpowers
开发。
Step 4：QA 阶段
/qa
AI 会检查：
- 参数校验
- SQL注入
- panic风险
- nil风险
- 缓存穿透
- context超时
- goroutine风险
- 事务问题
例如：
发现问题：
1. 缺少context timeout
2. category查询存在N+1
3. 缺少Redis异常处理
Step 5：Review 阶段
/review
AI 会检查：
- 架构是否合理
- biz是否过大
- handler是否写业务
- DAO是否耦合
- DTO是否混乱
- 命名是否规范
例如：
建议：
1. article handler 过重
2. service拆分不足
3. repository层可抽象
Step 6：Security 阶段
/security
检查：
- SQL注入
- XSS
- 文件上传漏洞
- JWT问题
- Redis风险
- 权限问题
Step 7：Ship 阶段
/ship
AI 会检查：
- 是否可以上线
- 是否有高风险改动
- 是否缺少测试
- 是否需要灰度
- 是否需要回滚方案
十五、推荐的真实开发工作流
这是目前最推荐的组合。
需求开发流程
1. gstack PM分析需求↓
2. OpenSpec 固化spec↓
3. Architect设计架构↓
4. Superpowers 开发↓
5. QA自动检查↓
6. Review自动Review↓
7. Security安全审计↓
8. Ship上线检查↓
9. OpenSpec archive归档
十六、Go + Gin 推荐最佳实践
非常适合：
handler
↓
biz/service
↓
dao/repository
↓
model
十七、AI 最容易犯的问题
1. handler写业务
错误：
handler里直接写SQL
正确：
handler
↓
biz
↓
dao
2. context不透传
错误：
func GetArticle(id int)
正确：
func GetArticle(ctx context.Context, id int)
3. N+1 查询
错误：
循环查数据库
Review 和 QA 会重点检查。
4. 缺少事务
例如：
文章 + 日志
未使用事务。
5. 错误处理不完整
AI 很容易漏：
if err != nil
十八、最推荐的组合
小项目
推荐：
Superpowers
原因：
- 最轻量
- 开发效率高
- 不复杂
中大型项目（推荐）
推荐：
OpenSpec + Superpowers
原因：
OpenSpec 负责长期上下文
Superpowers 负责高质量开发
这是目前最稳定组合。
创业级项目
推荐：
OpenSpec + Superpowers + gstack
适合：
- AI团队协作
- 自动QA
- 自动Review
- 自动发布
- 多Agent协同
十九、推荐的实际使用方式
建议：
OpenSpec：必须长期使用
Superpowers：日常开发主力
gstack：大需求时开启
二十、最终建议
对于 Go 后端开发：
最推荐：
OpenSpec + Superpowers
等项目复杂后：
再接入：
gstack
因为：
gstack 更偏工程团队化
学习成本更高
Token消耗更大
而：
OpenSpec + Superpowers
已经足够覆盖：
- 需求管理
- 长期上下文
- TDD
- Debug
- QA
- Review
- 高质量开发