AI 编程黄金搭档：Superpowers Skills × OpenSpec 实战指南

大家想学习更多AI知识，可以收藏下面两个网站：
GPTBUYS、ZeoAPI

在 AI 编程进入“人人都能生成代码”的阶段后，工程团队真正缺的已经不是“会不会写代码”，而是“能不能稳定地产出可验证、可演进、可协作的结果”。这也是为什么越来越多工程师开始从“Prompt 技巧”转向“工作流设计”。

如果你只让 AI 直接开写，通常会遇到几个典型问题：需求理解漂移、上下文混乱、代码能跑但难维护、改动大时难以评审。而 Superpowers Skills 和 OpenSpec 恰好分别解决这两类问题：前者负责把 AI 拉回资深工程师式的工作链路，后者负责把“先对齐规格、再做实现”的过程落到项目资产中。两者组合起来，就是很适合真实工程项目的 AI 编程“黄金搭档”。

摘要

摘要：本文从工程落地角度，讲清楚为什么要把 Superpowers Skills 与 OpenSpec 组合使用，以及如何把它们接入一个实际项目流程。

本文核心观点很简单：

• Superpowers Skills 更像 AI 编程的“操作系统级工作流约束”，强调先澄清目标、再产出规格、再制定计划、最后执行实现。[1][2][6]
• OpenSpec 更像“规格驱动开发”的项目资产管理工具，适合把 proposal、design、tasks、spec delta 这些内容沉淀到仓库里，形成团队可追踪的单一事实源（single source of truth）。[3][7]
• 两者组合后，可以形成一条非常清晰的链路：
  需求澄清 → brainstorming → 规格变更提案 → design/tasks → 计划编写 → 实现与验证 → commit/归档
• 这套方式尤其适合：
  • 中大型需求
  • brownfield 老项目改造
  • 多人协作、需要 PR 评审的团队
  • 对可追溯性和质量要求较高的项目

下面直接进入工程视角的实战拆解。

为什么说它们是“黄金搭档”

摘要：Superpowers 解决“AI 应该怎么工作”，OpenSpec 解决“规格如何沉淀并驱动实现”。

先分别看两者的定位。

Superpowers 官方中文站把它定义为“让 Claude Code 像资深工程师一样工作”的技能体系，并给出典型三步路径：安装、实战流程、Skill 全览。[1] GitHub 官方仓库进一步明确，它不是零散提示词，而是一个建立在可组合 skills 之上的完整 AI 编程工作流，核心理念是：

1. 先澄清目标
2. 再产出规格
3. 再制定实现计划
4. 最后执行代码实现
5. 并用测试和证据验证结果 [2]

这意味着 Superpowers 的价值不只是“多了几个命令”，而是它主动约束 AI 不要过早编码。官方 brainstorming skill 文档甚至明确规定：头脑风暴之后的唯一下一步是 writing-plans，而不是直接实现。[6]

再看 OpenSpec。官方仓库将它定义为面向 AI 编程助手的 Spec-driven development（SDD） 工具。[3] 它强调在较大改动前，先提交 change proposal，然后再推进设计与实现；同时建议在更干净的上下文中进行规划与实现，以提升质量。[3] 这和很多工程团队已有的“先方案后编码”原则高度一致，只是 OpenSpec 把它标准化了。

所以从职责分工上看：

• Superpowers：负责驱动 AI 的行为顺序与方法论
• OpenSpec：负责管理规格资产与变更闭环

一个偏“行为编排”，一个偏“规格资产化”。这正是它们能互补的关键。

工程化工作流：从 brainstorming 到 spec 再到 commit

摘要：落地时不要把它们当成两个独立工具，而要当成一条连续的交付流水线。

依据官方资料，可以把这条链路拆成 6 个阶段。

1）需求澄清与头脑风暴

Superpowers 首页展示的实战流程里，明确包含从 /brainstorming 到写代码再到 /commit 的工作链路。[1]
而 brainstorming skill 文档进一步说明，这一步的目的不是“快速生成代码”，而是探索问题空间、识别约束、确认边界，并根据问题类型判断该用浏览器还是终端。[6]

这一步最重要的产出不是代码，而是：

• 问题定义
• 成功标准
• 已知约束
• 候选方案
• 待确认风险

2）规格提案

当需求不是一次性小修，而是涉及模块变更、接口调整、流程重构时，OpenSpec 的建议是：先提交 change proposal，再开始实现。[3]

这个阶段适合沉淀：

• 为什么要改
• 改什么
• 不改什么
• 影响范围
• 回滚与兼容策略

3）设计与任务拆解

OpenSpec 社区实践里，proposal、design、tasks、spec delta、archive 构成了完整循环。[7]
而 Superpowers 则在 brainstorming 之后接 writing-plans，强调把模糊目标转成可执行计划。[6]

这里建议把两者结合：

• OpenSpec 负责落盘设计文档与任务清单
• Superpowers 负责把设计继续转成有顺序的执行计划

4）实现与验证

Superpowers 仓库强调“测试优先”“系统化胜过拍脑袋”“用证据验证结果”。[2]
这意味着实现阶段不要只追求“生成代码”，而要同时生成：

• 测试
• 验证步骤
• 证据输出
• 变更说明

5）提交与归档

Superpowers 流程中包含 /commit。[1]
OpenSpec 侧则有 archive 这样的闭环动作，用于在变更完成后归档 proposal/design/tasks 过程资产。[7]

6）复盘与沉淀

这是很多团队最容易忽略的一步。
如果某个需求最终落地很好，应该把这次实践固化为：

• 可复用 prompt/命令模版
• 标准目录结构
• 任务拆解模板
• 回归测试模板

这样第二次、第三次接入时，AI 才能真正从“会生成”升级为“会稳定交付”。

安装与目录落盘：先把基础设施搭起来

摘要：工具真正能用，关键在安装方式、升级路径和文件落盘位置是否统一。

Superpowers Skills 的接入要点

官方市场仓库给出的安装路径是：

1. 先添加 marketplace
2. 再执行 /plugin install superpowers@superpowers-marketplace [5]

官方市场 README 还说明，核心插件提供 20+ battle-tested skills，并暴露如 /brainstorm、/write-plan、/execute-plan 等命令，同时支持 Skills-search 工具与 SessionStart context injection。[5]

这几点很重要，因为它说明 Superpowers 不只是命令清单，还会在会话初始化时注入工作流上下文，让 AI 从一开始就处于“工程化模式”。

Superpowers 的目录变化

根据 release notes，近期 spec 和 plan 的默认保存目录 已重构到：

• docs/superpowers/specs
• docs/superpowers/plans [4]

这对团队协作非常关键。因为目录一旦稳定，后续就可以：

• 做 PR 模板链接
• 做 CI 校验
• 做文档索引
• 做自动归档脚本

OpenSpec 的安装与更新

官方仓库给出的 CLI 更新方式是：

• npm install -g @fission-ai/openspec@latest
• 项目内执行 openspec update [3]

同时官方明确建议：OpenSpec 更适合高推理模型，并且要尽量保持干净上下文。[3]
这意味着一个实战建议：规划阶段和实现阶段最好分会话处理。规划会话专注 proposal/design/tasks，实现会话专注代码、测试和验证，避免上下文污染。

Key Comparison Table

摘要：下面用工程决策表把两者在真实项目中的分工和取舍讲清楚。

Dimension	Superpowers Skills	OpenSpec	实战建议
核心定位	AI 编程工作流与技能体系，强调先澄清、后计划、再实现 [1][2]	面向 AI 助手的规格驱动开发工具，强调 proposal/design/tasks 闭环 [3]	两者不要二选一，应该组合使用
主要解决问题	防止 AI 过早写代码，提供结构化执行流程 [2][6]	把需求、设计、任务和变更沉淀为项目资产 [3][7]	Superpowers 管“行为”，OpenSpec 管“文档资产”
最佳使用时机	会话开始、需求分析、计划编写、执行实现 [1][5]	大改动前、需求冻结前、设计评审前 [3]	小改动偏 Superpowers，大改动必须加 OpenSpec
典型产物	brainstorming 结果、plan、执行步骤、commit 流程 [1][5]	proposal、design、tasks、spec delta、archive [3][7]	计划与规格文档都要入库
对上下文的要求	通过 skills 和 SessionStart 注入工作上下文 [5]	推荐保持干净上下文，尤其是规划与实现分离 [3]	规划和编码分两个会话最稳
适用项目类型	从日常开发到多阶段实现都适用 [1][2]	更适合中大型变更、brownfield 改造 [3][7]	老项目改造优先采用组合流
落盘目录与可追踪性	默认可落到 docs/superpowers/specs 与 docs/superpowers/plans [4]	以规格文件和变更记录为核心 [3][7]	统一目录后再接 CI/评审流程

一套可复制的实战打法：中型需求怎么跑

摘要：下面给出一套适合真实项目的“最小可用组合流程”，重点是步骤清楚、产物可追踪。

假设你要做一个“用户资料页支持头像上传与裁剪”的需求，涉及前端 UI、后端上传接口、对象存储配置和权限校验。这个需求已经超出“直接让 AI 写个组件”的范畴，更适合走组合流程。

第一步：用 Superpowers 做问题澄清

目标不是写代码，而是先输出：

• 用户故事
• 非功能要求
• 接口约束
• 存储策略
• 兼容性与回滚点

这里要特别注意官方 skill 文档的约束：brainstorming 后不要直接进入实现。[6]

第二步：用 OpenSpec 建 proposal

把下面问题写清楚：

• 这个改动为什么必要
• 现有方案有哪些不足
• 本次要影响哪些模块
• 是否涉及数据库、接口、权限、前端路由
• 验收标准是什么

第三步：生成 design 和 tasks

设计文档建议至少覆盖：

• 前端交互流程
• 上传接口定义
• 文件命名与存储策略
• 裁剪参数格式
• 权限控制点
• 失败补偿机制

任务拆解建议按“可验证单元”来分，而不是按文件名来分。比如：

1. 前端上传组件骨架
2. 图片裁剪交互
3. 后端上传签名接口
4. 对象存储适配
5. 用户资料更新接口
6. 集成测试与回归

第四步：回到 Superpowers 写执行计划

这一步适合把 OpenSpec 的 tasks 继续编排成：

• 先做哪些基础设施
• 哪些步骤要先写测试
• 哪些步骤可以并行
• 哪些步骤必须人工确认

第五步：执行、验证、提交

这里不要只让 AI 输出代码，要同时要求：

• 单元测试/接口测试
• 手动验证清单
• 变更说明
• commit message 草案

这才是真正工程可用的交付单元。

代码块注释规范

摘要：AI 生成代码很快，但如果没有统一注释规则，后续评审和维护成本会迅速上升。

下面给出 4 条实用规则，适合写进团队规范。

规则 1：代码块开头先写“目的注释”

每个代码块最上方先用 1 行注释说明用途，比如“初始化 OpenSpec 并同步项目模板”“根据任务清单生成执行计划”。
这样读者不需要先读命令本身，就知道这段代码是干什么的。

规则 2：关键步骤只注释“为什么”，少注释“显而易见的是什么”

例如：

• 好注释：# 保持 proposal 先于实现，避免直接改代码导致评审缺失
• 差注释：# 执行 npm install

注释重点应该放在工程意图，而不是逐词翻译命令。

规则 3：对有副作用的命令必须标注影响范围

凡是会修改仓库、覆盖配置、提交代码、更新 CLI 的命令，都要说明副作用，例如：

• 是否会修改全局环境
• 是否会改写本地模板
• 是否会新增目录或文件

规则 4：一段代码块不要混合太多目标

安装、规划、执行、提交尽量拆成不同代码块。
每段代码块只表达一个阶段动作，这样更利于 CSDN 读者复制执行，也利于团队文档维护。

实战代码示例

摘要：下面给出一个可直接参考的接入与执行示例，重点展示“规格先行”和“计划驱动实现”的组合方式。

# 目的：安装/更新 OpenSpec CLI，并在当前项目同步最新模板
# 关键点：全局安装 CLI，项目内再执行 update，保证团队模板一致
npm install -g @fission-ai/openspec@latest

# 进入你的项目目录
cd your-project

# 同步项目内 OpenSpec 模板与配置
openspec update

# 建议：执行后把生成/更新的规格文件一并纳入版本控制
git status

# 目的：用 Superpowers 的工作链路驱动一次中型需求实现
# 关键点：先 brainstorming，再 write-plan，最后 execute/commit；不要跳步直接写代码

# Step 1：澄清需求与边界，产出方案讨论结果
/brainstorming

# Step 2：基于已确认的需求写实现计划
/write-plan

# Step 3：按计划执行实现，并补齐测试与验证证据
/execute-plan

# Step 4：完成后整理提交
/commit

<!-- 目的：示例一个 OpenSpec proposal 骨架 -->
<!-- 关键点：先对齐意图、影响范围和验收标准，再进入设计与编码 -->

# Change Proposal: avatar-upload-and-crop

## Why
> 摘要：本节给出关键结论、核心步骤和可执行建议。

用户资料页当前仅支持文本资料编辑，不支持头像上传与裁剪，影响资料完整度与体验。

## Scope
> 摘要：本节给出关键结论、核心步骤和可执行建议。

- 前端：资料页头像上传与裁剪交互
- 后端：上传签名接口、头像更新接口
- 基础设施：对象存储配置与访问权限

## Non-Goals
> 摘要：本节给出关键结论、核心步骤和可执行建议。

- 不做相册管理
- 不做批量图片处理
- 不做历史头像版本回滚

## Acceptance Criteria
> 摘要：本节给出关键结论、核心步骤和可执行建议。

- 用户可上传 png/jpg/webp
- 支持裁剪后提交
- 上传失败时可重试
- 更新成功后资料页实时展示新头像

常见问题与排错

摘要：组合使用时，问题通常不在“工具装不上”，而在“流程顺序错了”或“上下文污染了”。

1）AI 一上来就开始写代码，怎么办？

先检查是否跳过了 brainstorming / proposal 阶段。Superpowers 官方方法明确强调先澄清、再规格、再计划。[2][6]
处理方法：重开会话，先做需求收敛，再进入计划。

2）OpenSpec 文档写了，但实现时还是跑偏？

通常是 proposal、design、tasks 没有形成单一事实源。
处理方法：在实现前明确“本次只以 proposal + design + tasks 为准”，并将变更补回 spec delta。[7]

3）上下文越聊越乱，后面质量明显下降？

OpenSpec 官方建议保持干净上下文，尤其适合高推理模型。[3]
处理方法：把“规划”和“实现”拆成两个会话，中间只传递已确认的文档资产。

4）团队里有人只想直接让 AI 改代码，不想写规格？

对于小修小补可以简化，但只要是跨模块变更、接口变更、数据结构调整，就应该先有 proposal。[3]
否则后续 PR 评审和回归验证成本会更高。

5）Superpowers 的 spec/plan 文件找不到了？

注意新版目录已经调整到 docs/superpowers/specs 和 docs/superpowers/plans。[4]
处理方法：优先检查新目录，并更新团队文档与脚本路径。

适合什么团队，什么时候值得引入

摘要：不是所有项目都要上完整流程，但一旦达到中等复杂度，这套方法的收益会迅速放大。

我更建议以下场景优先引入：

适合优先引入的场景

• 老项目功能扩展，存在历史包袱
• API、数据库、权限链路同时变更
• 团队需要 PR 评审、测试回归、文档留痕
• AI 参与开发，但希望输出可审查、可追踪

可以简化使用的场景

• 单文件小改动
• 文案、样式、轻量配置调整
• 已有明确实现路径的机械性改动

一个很实用的判断标准是：
如果这个需求需要你在评审会上讲 5 分钟以上，那它通常就值得先走 OpenSpec；如果它还需要 AI 分阶段执行，那就再叠加 Superpowers。

结语：先把“能生成代码”升级成“能稳定交付”

摘要：真正高价值的 AI 编程，不是多快写出第一版，而是多稳地完成从需求到提交的整个工程闭环。

Superpowers Skills 和 OpenSpec 组合起来，最有价值的地方不在于“多了两个流行工具”，而在于它们把很多资深工程师本来就在做、但没有显式固化的工作方式，变成了 AI 可遵循的流程：

• 先澄清
• 先对齐规格
• 先拆计划
• 再实现
• 再验证
• 最后归档

如果你准备在团队内落地，我建议下一步按下面顺序推进：

1. 先选一个 中等复杂度需求 做试点
2. 用 Superpowers 固化 brainstorming → plan → execute → commit 的节奏
3. 用 OpenSpec 固化 proposal → design → tasks → archive 的资产闭环
4. 把目录、模板、PR 检查项统一进仓库
5. 试跑 2~3 个需求后，再做团队规范沉淀

这样你获得的就不只是“AI 帮你写代码”，而是一套更稳定的 AI 工程交付流水线。

CSDN 发布建议（标签与专栏）

摘要：发布到 CSDN 时，标签与专栏要围绕“AI 编程 + 工程实践 + 规格驱动”三个核心关键词组织。

标签建议：AI编程、Claude Code、Superpowers、OpenSpec、规格驱动开发、软件工程、提示工程、研发效能

专栏建议：AI 工程化实践、智能编码工作流、Spec-Driven Development 实战、研发效能与自动化

参考资料

1. Superpowers Skill（官方中文站）
   https://superpowers-skills.com/zh-cn/index.html

2. GitHub - obra/superpowers: An agentic skills framework & software development methodology that works.
   https://github.com/obra/superpowers

3. GitHub - Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistants.
   https://github.com/Fission-AI/OpenSpec

4. superpowers/RELEASE-NOTES.md at main · obra/superpowers
   https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md

5. GitHub - obra/superpowers-marketplace: Curated Claude Code plugin marketplace
   https://github.com/obra/superpowers-marketplace

6. superpowers/skills/brainstorming/SKILL.md at main · obra/superpowers
   https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md

7. openspec.md · GitHub Gist
   https://gist.github.com/Darkflib/c7f25b41054a04a5835052e5a21cdf82

8. GitHub - spenceriam/OpenSpecification: Nano web inspired version of Kiro IDE’s Spec Mode
   https://github.com/spenceriam/OpenSpecification