当 OpenSpec 遇见 Superpowers：打造 AI 编程的「规范-执行-验证」闭环
如何让 AI 编程助手既能「想清楚」又能「做对事」？本文分享一个将需求规范与执行纪律完美结合的实践方案。
1. 引言
在使用 AI 编程助手时，你是否遇到过这些困扰：
-
需求在对话中越聊越偏，最终实现与初衷南辕北辙
-
代码写完了才发现设计有漏洞，返工成本高昂
-
AI 写的代码质量参差不齐，有时优秀有时糟糕
-
缺乏可追溯性，不知道为什么做了某个决定
这些问题的本质是：需求标准化与执行标准化的缺失。
本文将介绍两个工具——OpenSpec 和 Superpowers，以及如何将它们结合起来，形成「规范—执行—验证」的完整闭环。
2. 两个工具的核心价值
2.1 OpenSpec：需求标准化
OpenSpec 是一个规范驱动的开发工具，核心理念是「先想清楚，再动手」。
它的核心流程是：
bashproposal → specs → design → tasks → implement → archive
每个变更都有独立的文件夹，包含：
-
proposal.md：为什么做，做什么
-
specs/：需求规格和场景
-
design.md：技术设计
-
tasks.md：实现任务列表
2.2 Superpowers：执行标准化
Superpowers 是一套执行纪律工具集，核心理念是「按规矩办事」。
它的核心能力包括：
-
brainstorming：设计澄清，避免想当然
-
TDD：测试驱动开发，保证代码质量
-
code-review：代码审查，及时发现问题
-
subagent-driven-development：子代理执行，保持上下文清洁
3. 为什么需要结合？
单独使用时，各自都有局限：
| 工具 | 优势 | 局限 |
|---|---|---|
| OpenSpec | 规范清晰、可追溯 | 执行过程缺乏约束，质量不稳定 |
| Superpowers | 执行纪律强、质量高 | 缺乏需求规范的输入来源 |
结合后，OpenSpec 提供「做什么」的定义，Superpowers 保证「怎么做好」的执行。
4. 协同链路命令总览
这是整个协同方案的核心——一张完整的命令流程图，展示了 OpenSpec 命令与 Superpowers 技能如何协同工作。
4.1 全流程一览
bash┌─────────────────────────────────────────────────────────────────┐
│ 阶段 OpenSpec 命令 Superpowers 技能 │
├─────────────────────────────────────────────────────────────────┤
│ 规划阶段 │
│ ─────────────────────────────────────────────────────────────│
│ 探索想法 /opsx:explore │
│ 创建变更 /opsx:propose → brainstorming (嵌入)│
│ → 生成规范文档 │
│ → design.md/specs/ │
│ → tasks.md (简洁) │
├─────────────────────────────────────────────────────────────────┤
│ 执行阶段 │
│ ─────────────────────────────────────────────────────────────│
│ 开始实现 /opsx:apply → 生成 plan.md (详细) │
│ [每个任务] → TDD: RED→GREEN→REFACTOR │
│ [复杂任务] → subagent-driven-dev │
│ [功能单元完成] → requesting-code-review │
│ (规范合规+代码质量) │
├─────────────────────────────────────────────────────────────────┤
│ 收尾阶段 │
│ ─────────────────────────────────────────────────────────────│
│ 验证实现 /opsx:verify │
│ 分支处理 → finishing-a-dev-branch│
│ 归档变更 /opsx:archive │
└─────────────────────────────────────────────────────────────────┘
4.2 规划阶段详解
命令入口：/opsx:explore 或 /opsx:propose
1. 轻量探索 — /opsx:explore
用于需求不清晰时的前期调研：
bash用户: /opsx:explore 如何实现用户认证？
AI: 让我帮你调研一下...
[分析现有代码库]
[比较不同认证方案]
我发现你的项目目前使用 session 认证。
对于用户认证，有几个方向：
1. 扩展现有 session 方案
2. 引入 JWT 无状态认证
3. 集成第三方 OAuth 登录
你想深入了解哪个方向？
特点：不产生正式文档，纯对话探索。
2. 正式创建变更 — /opsx:propose
当想法明确后，创建正式的规范文档：
bash用户: /opsx:propose add-jwt-auth
AI: 创建变更 add-jwt-auth...
[触发 brainstorming 技能]
→ 探索项目上下文
→ 提问澄清需求
→ 提出 2-3 个方案
→ 分段展示设计，逐段确认
[写入规范文档]
✓ proposal.md — 变更意图、范围、方法
✓ specs/auth/ — 需求规格和场景
✓ design.md — 架构、组件、数据流
✓ tasks.md — 高层任务列表
规范文档已创建，运行 /opsx:apply 开始实现。
关键设计：brainstorming 的输出直接写入 OpenSpec 的规范文档结构，避免产物分散。
4.3 执行阶段详解
命令入口：/opsx:apply
1. 生成详细计划
启动时自动生成详细的 plan.md：
bash用户: /opsx:apply add-jwt-auth
AI: 读取规范文档...
[调用 writing-plans 技能]
→ 读取 tasks.md 和 specs/
→ 每个任务拆解为 TDD 子任务
→ 生成完整的实现计划
✓ 生成 plan.md
- Task 1.1: Create JWT utilities (5 steps)
- Task 1.2: Add auth middleware (5 steps)
- Task 2.1: Implement login endpoint (5 steps)
...
2. TDD 循环执行
每个任务都遵循严格的 TDD 流程：
bash执行 Task 1.1: Create JWT utilities
Step 1: 写失败的测试
────────────────────────────────────
[编写测试代码]
测试文件: tests/utils/jwt.test.ts
Step 2: 运行测试，确认失败
────────────────────────────────────
$ npm test tests/utils/jwt.test.ts
✗ FAIL: generateToken is not defined
✓ 测试正确地失败了
Step 3: 编写最小实现
────────────────────────────────────
[编写刚好能让测试通过的代码]
Step 4: 运行测试，确认通过
────────────────────────────────────
$ npm test tests/utils/jwt.test.ts
✓ PASS: all tests passed
Step 5: 提交代码
────────────────────────────────────
$ git commit -m "feat: add JWT token generation"
3. 功能单元审查
每个功能单元完成后，自动触发代码审查：
bashTask 1.1 完成，开始代码审查...
[规范合规性审查]
✓ 实现了 specs 中定义的 JWT 生成功能
✓ 支持 24 小时过期时间
⚠ 缺少 specs 中提到的 refresh token 支持
[代码质量审查]
✓ 测试覆盖率 100%
✓ 代码结构清晰
⚠ Magic number: 过期时间应提取为常量
审查结果: 2 个问题需要修复
→ 插入新任务: Fix: Add refresh token support (Important)
→ 插入新任务: Fix: Extract expiry constant (Minor)
4. 复杂度自适应执行
简单任务和复杂任务采用不同执行模式：
| 任务类型 | 判断标准 | 执行模式 |
|---|---|---|
| 简单 | 1-2 文件，逻辑清晰 | 单代理执行 |
| 复杂 | 3+ 文件，跨模块，状态管理 | 子代理执行 |
AI 自动判断，用户无需关心内部细节。
4.4 收尾阶段详解
1. 变更验证 — /opsx:verify
对所有实现进行完整性、正确性、一致性检查：
bash用户: /opsx:verify add-jwt-auth
AI: 验证变更 add-jwt-auth...
完整性检查
────────────────────────────────────
✓ 所有 12 个任务已完成
✓ 所有需求都有对应实现
⚠ 场景「Token 过期处理」缺少测试覆盖
正确性检查
────────────────────────────────────
✓ 实现符合 specs 定义的意图
✓ 边界情况已处理
✓ 错误状态符合定义
一致性检查
────────────────────────────────────
✓ 架构设计与 design.md 一致
✓ 命名规范统一
验证结果: 1 个警告，建议补充测试
2. 归档变更 — /opsx:archive
完成分支决策、规范同步、变更归档：
bash用户: /opsx:archive add-jwt-auth
AI: 准备归档...
[finishing-a-development-branch]
────────────────────────────────────
✓ 所有测试通过
✓ 代码审查问题已处理
分支处理选项:
1. 合并到 main
2. 创建 PR
3. 保持分支
4. 放弃变更
你的选择？→ 2
[创建 Pull Request]
────────────────────────────────────
✓ 推送到远程
✓ 创建 PR #42
[同步规范]
────────────────────────────────────
✓ 合并 specs/ 到主规范目录
[归档]
────────────────────────────────────
✓ 移动到 openspec/changes/archive/2026-06-05-add-jwt-auth/
变更已归档，可以开始下一个变更。
4.5 命令速查表
| 命令 | 阶段 | 触发的 Superpowers 技能 | 主要产出 |
|---|---|---|---|
/opsx:explore | 规划 | — | 调研结论（无文档） |
/opsx:propose | 规划 | brainstorming | proposal.md, specs/, design.md, tasks.md |
/opsx:apply | 执行 | writing-plans, TDD, code-review | plan.md, 实现代码, 测试 |
/opsx:verify | 收尾 | — | 验证报告 |
/opsx:archive | 收尾 | finishing-a-dev-branch | 归档目录, PR/merge |
4.6 完整工作流示例
一个真实的开发流程：
bashDay 1: 需求探索
──────────────────────────────────────────────────
/opsx:explore
→ 调研用户认证方案
→ 确定 JWT 方向
Day 1: 规范制定
──────────────────────────────────────────────────
/opsx:propose add-jwt-auth
→ brainstorming 澄清设计
→ 创建规范文档
→ 用户确认
Day 2-3: 实现执行
──────────────────────────────────────────────────
/opsx:apply
→ 生成详细计划
→ Task 1.1: JWT 工具函数 (TDD + 审查)
→ Task 1.2: 认证中间件 (TDD + 审查)
→ Task 2.1: 登录接口 (TDD + 审查)
→ Task 2.2: 登出接口 (TDD + 审查)
→ Task 3.1: Token 刷新 (TDD + 审查)
Day 3: 验证归档
──────────────────────────────────────────────────
/opsx:verify
→ 发现 1 个警告，补充测试
→ 再次验证通过
/opsx:archive
→ 创建 PR
→ 同步规范
→ 归档完成
5. 核心设计决策
在协同链路设计中，有几个关键决策值得分享：
5.1 1. Brainstorming 嵌入时机
决策：在 /opsx:propose 内部嵌入 brainstorming，而不是作为独立前置步骤。
原因：
-
避免产物分散（brainstorming 输出直接写入 OpenSpec 规范文档）
-
保持流程连贯性
-
减少用户操作步骤
5.2 2. TDD 子任务展开
决策：每个高层任务拆解为 TDD 子任务，显式追踪。
原因：
-
让测试驱动过程可追踪、可验证
-
避免跳过测试直接写代码
-
便于暂停恢复时定位进度
5.3 3. 代码审查粒度
决策：功能单元粒度审查（如「1.1 Create ThemeContext」），而非每个子任务或整个变更。
原因：
-
子任务粒度太细，审查过于频繁
-
变更粒度太粗，问题累积后修复成本高
-
功能单元是一个平衡点
5.4 4. Minor 问题处理
决策：Minor 问题记录在 tasks.md 末尾，不阻塞进度。
原因：
-
避免小问题打断开发节奏
-
保持问题可追溯
-
归档前统一决定是否处理
6. 实际效果
这套协同链路带来的改变：
6.1 Before（无协同）
-
需求在对话中飘移
-
代码质量不稳定
-
缺乏可追溯性
-
问题后置发现
6.2 After（有协同）
-
需求文档化、可追溯
-
TDD 保证代码质量
-
审查及时发现问题
-
规范与实现一致
7. 如何使用
这套协同技能已打包为 openspec-integration skill，下载后存放在 ~/.claude/skills/openspec-integration/。
7.1 手动触发
bash/skill:openspec-integration
7.2 快速上手
bash# 1. 探索想法
/opsx:explore
# 2. 创建变更（内含 brainstorming）
/opsx:propose add-user-auth
# 3. 执行实现（自动 TDD + 代码审查）
/opsx:apply
# 4. 验证实现
/opsx:verify
# 5. 归档完成
/opsx:archive
8. 一键安装：openspec-integration Skill
为了方便使用，我们将这套协同方案打包成了一个独立的 skill——openspec-integration。
8.1 什么是 Skill？
Skill 是 Claude Code 的能力扩展机制。通过安装 skill，Claude 可以自动获得特定领域的知识和工作流程。
8.2 安装方式
skill 文件位于 ~/.claude/skills/openspec-integration/，包含：
bashopenspec-integration/
├── SKILL.md # 主入口，定义触发条件
├── flows/
│ ├── propose-flow.md # /opsx:propose 详细流程
│ ├── apply-flow.md # /opsx:apply 详细流程
│ ├── verify-flow.md # /opsx:verify 详细流程
│ └── archive-flow.md # 归档流程
└── templates/
├── tasks-with-tdd.md # TDD 任务模板
├── plan-template.md # 详细计划模板
└── review-feedback.md # 审查反馈模板
8.3 触发方式
手动触发：
bash/skill:openspec-integration
8.4 立即开始
安装后，你可以立即开始使用：
bash# 第一个变更
/openspec-integration my-first-feature
# 按提示完成设计和实现
# 享受规范驱动的开发体验！
9. 总结
规范和执行是软件开发的两个支柱。OpenSpec 解决了「想清楚」的问题，Superpowers 解决了「做对事」的问题。
两者的结合，形成了完整的「规范—执行—验证」闭环：
bash需求标准化 → 执行标准化 → 验证标准化
↑ │
└──────────────────────────────┘
持续改进
这正是 AI 时代的软件开发所需要的方法论——让 AI 既有清晰的规范指引，又有严格的执行纪律。
通过 openspec-integration skill，这套方法论已经变成了一键可用的工具。希望它能帮助你更好地与 AI 协作，写出更高质量的代码。
10. 参考资料
11. 技能下载
链接: https://pan.baidu.com/s/1FGzcUaNUOajPg_GBIQNBYg?pwd=zgyx 提取码: zgyx
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
4
0- 0
已为社区贡献1条内容
所有评论(0)