你大概率遇到过这些场景：让AI帮你写个功能，它上来就开干，设计不讨论、测试不写、写完就说搞定了；换个会话接着聊，它把上次的决策忘得一干二净，推翻重来；过了两周想查某个功能为什么这么设计，翻遍聊天记录也找不到。

社区给了两个热门方案：Superpowers说它能管住AI的工程纪律，OpenSpec说它能帮你把变更记录管明白。一个GitHub上9万多Star，一个背靠Y Combinator。

到底行不行？这篇文章把两个框架的原理、用法、适用场景全讲清楚，最后再说说它们能不能一起用。

Superpowers：给AI编码代理装上「工程纪律」

Superpowers是一个专门为AI编程Agent（如Claude Code, Cursor, Codex）设计的开源结构化软件开发工作流与技能框架。它将AI的“Vibe Coding”提升为工程级标准，通过20+个可组合的技能强制AI执行“先思考、再规划、后编码、必验证”的流程，主要用于解决AI自主编程时的逻辑局限和不可靠性。它的作者是Jesse Vincent，这哥们1996年就写了Request Tracker（一个至今还在用的开源工单系统），被知名技术博主Simon Willison评为「最具创造力的AI编码代理用户之一」。

他的思路很直接：AI写代码太快了，快到没纪律。跳过设计、跳过测试、没验证就说做完——这些是人类程序员也知道不该干的事，但AI干起来毫无心理负担。Superpowers的解法是：不让AI直接写代码，而是强制它先设计、再计划、再写代码、再测试、再审查，整个过程由14个叫「Skill」的技能模块驱动。

怎么装Superpowers？一条命令的事

如果你用的是Claude Code，直接在对话里输入：

/plugin install superpowers@claude-plugins-official

装完之后，每次新开会话它会自动加载，不需要你手动做什么。它也支持Cursor、Codex、Gemini CLI等，但效果最好的是Claude Code和Cursor——因为它最核心的能力依赖「子代理派发」，不是所有工具都支持。

它是怎么管住AI的？全靠这套流程

Superpowers把开发流程拆成了固定的几个阶段，每个阶段都有对应的Skill来执行，AI不能跳过任何一个阶段。

第一步：头脑风暴（brainstorming）

你说「帮我加个登录功能」，AI不会直接写代码。它会先问你一堆问题：要支持哪些登录方式？已有用户怎么迁移？安全要求是什么？然后给出2-3种方案让你选。你确认了设计方案之后，它才进入下一步。这里有个门禁：设计没通过，一行代码都不许写。

第二步：拆计划（writing-plans）

把设计方案拆成AI能执行的小步骤，每个步骤控制在2-5分钟。要求很严格：每一步必须写清楚改哪个文件的哪行代码，不能用「类似Task N」这种话糊弄。AI会把这些写成一份计划文档。

第三步：隔离工作（git worktree）

自动创建一个隔离的Git工作树，在独立分支上开发。不会污染你的主分支，出了问题可以直接丢弃。

第四步：子代理执行（subagent-driven-development）

这是Superpowers最核心的设计。计划写好后，主代理（Controller）把任务逐个派给实现者（Implementer）去写代码，写完再派给审查者（Reviewer）去审。关键是：实现者和审查者是两个完全独立的子代理，互不知道对方做了什么，所以审查结果更客观。审查分两轮：先看代码符不符合设计规格，再看代码质量好不好。不通过就打回去重做。

第五步：强制TDD

铁律：没有失败测试就不能写生产代码。如果AI先写了代码再补测试？对不起，删掉重来。这个规则听起来死板，但确实有效——因为AI最擅长的就是跳过测试直接交差。

第六步：验证后才算完

AI不能口头说「我做完了」，必须跑完测试、读完输出、确认结果符合预期，才能声称完成。Superpowers专门做了一个Skill来防止AI「提前交卷」，里面还列举了AI最常见的自我合理化借口（比如「太简单不用测」「我测完再补」），逐条反驳。

整个流程走下来大概是这个感觉：先想清楚要做什么 → 用户确认 → 开隔离分支 → 拆成小步骤 → 先写测试再写代码 → 独立审查 → 跑测试确认 → 合并或提PR。每一步都有检查点，AI没法偷懒。

Superpowers擅长什么、不擅长什么

它最擅长的事：管住AI的代码质量。强制TDD、独立子代理审查、验证后才算完成——这三个机制组合起来，代码质量确实有保障。Reddit上有人评价：「用了Superpowers之后，每个阶段都得到了适当的关注，不再赶工跳步了。」

它不擅长的事：管理知识和决策记录。设计文档写完就丢在`docs/superpowers/specs/`目录下，没有系统化的维护机制。换个会话，AI不记得上次为什么这么设计。另外，多代理架构的Token消耗是实打实的——有人反馈首周Token用量比预期高了3倍。而且它只能在支持子代理的平台上用（目前主要是Claude Code和Cursor）。

OpenSpec：AI编码的「决策备忘录」

OpenSpec是一款专为AI编码助手（如Cursor, Claude Code）设计的开源规范驱动开发框架。它通过标准化的specs/文件和变更记录，在编码前明确需求，解决AI编程中容易出现的需求混淆、输出不可控问题。它的作者是Tabish Bidiwale，他的公司Fission-AI进了Y Combinator(全球最顶尖的创业加速器和种子期投资机构) 2026冬季批次。Tabish之前在Q-CTRL（一家量子计算公司），经历了从种子轮到1.13亿美元B轮融资的全过程。他发现一个问题：AI编码代理会重现人类团队同样的毛病——上下文对不齐、决策无记录、反复推翻重来。OpenSpec就是为了解决这个问题。

如果说Superpowers是严格的工程经理，OpenSpec更像一个严谨的架构师。它不管代码写得好不好，它管的是「为什么做这个变更」和「系统当前是什么状态」——这些问题在换会话、换人的时候最容易断档。

一条命令装OpenSpec

npm install -g @fission-ai/openspec@latest

需要Node.js >= 20.19.0。安装完成后，在项目根目录运行openspec init，会在项目根目录生成一个openspec/文件夹，里面包含AI代理的行为指引（AGENTS.md）、项目信息（project.md）和配置文件（config.yaml）。它支持25+工具：Claude Code、Cursor、GitHub Copilot、Codex、Windsurf、Gemini CLI……基本你能想到的都支持。

它是怎么把变更管明白的？两个文件夹的秘密

OpenSpec最核心的设计是「双文件夹模型」：

openspec/
  ├── specs/              ← 系统当前的真实状态
  │   ├── auth/spec.md    （按「能力」组织，不是按功能特性）
  │   └── payment/spec.md
  └── changes/            ← 活跃的变更提案
      └── add-oauth/
          ├── proposal.md  （为什么改、改什么）
          ├── design.md    （技术方案）
          ├── tasks.md     （实现清单）
          └── specs/       （增量：ADDED / MODIFIED / REMOVED）

specs/是「系统当前是什么样」的真实记录，按能力（而不是功能特性）组织。当有人问「认证是怎么工作的」，直接查specs/auth/spec.md就行。这些文件跟着Git走，不会因为会话结束而消失。

changes/是「我们要改什么」的工作区。每个变更独立一个文件夹，改完了才合并回specs/。变更之间互不干扰，多个变更可以并行推进。

OpenSpec的工作流用几个命令驱动：

/opsx:explore    → 先随便看看，不急着做决策
/opsx:propose   → 创建变更提案（快速通道，一键生成所有文档）
/opsx:ff        → 快进：一口气生成所有规划文档
/opsx:apply     → 开始写代码，逐个勾选任务
/opsx:verify    → 检查代码实现是否和文档一致
/opsx:archive   → 归档已完成的变更，增量合并到主规格

最常用的路径是propose → ff → apply → archive，但这不是强制的——你可以在apply中途回过头改design，也可以跳过某些步骤。这就是OpenSpec的设计理念：流畅而非僵硬，迭代而非瀑布。

OpenSpec擅长什么、不擅长什么

它最擅长的事：跨会话的知识持久化和变更审计。每次会话结束后，规格文档还在；两周后想查某个功能为什么这么设计，翻changes/目录就能找到完整的决策链（提案→设计→规格→任务）。在需要合规审计的场景下（金融、医疗等），这个能力是不可替代的。

它不擅长的事：管代码质量。OpenSpec不强制TDD，不做独立代码审查，不自动创建隔离分支。它假设你的团队有足够的自律来写测试和审代码。另外，它是单代理模式——不像Superpowers那样可以长时间自主工作。社区里也有人提到一些实际问题：AI可能为一个30分钟的功能生成800多行Markdown（规格膨胀）；如果你在工作流之外直接改了代码，规格和代码就会脱节（规格漂移）；AI有时候会无视自己写的规格（这时候/opsx:verify能帮上忙）。

横向对比：两个框架到底在解决什么问题

说白了，Superpowers解决的是「代码写得对不对」，OpenSpec解决的是「为什么做这个变更」。一个是执行层面的问题，一个是知识和决策层面的问题。

怎么选？一条决策线就够：

1. 你用的平台支持子代理派发吗？不支持→OpenSpec是唯一选择

2. 从零开始的新项目？→Superpowers更合适

3. 团队要求严格的TDD？→Superpowers（它强制你做）

4. 需要长期维护规格文档和变更审计？→OpenSpec（它有知识库）

5. Token预算紧张？→OpenSpec（单代理，消耗低）

如果你是一个小团队在做新项目，用的是Claude Code，Token预算宽裕，Superpowers能让你的代码质量从一开始就很高。如果你是在一个已有代码库上持续迭代，团队有10人以上，还有合规审计的需求，OpenSpec更对路。

两个一起用行不行？行，但要分清谁管什么

它们不是竞争关系。一个管「为什么做」，一个管「做得对不对」，天然互补。最自然的结合方式是三段式分工：

第一段：用OpenSpec想清楚要做什么

/opsx:explore了解现状，/opsx:propose写提案，/opsx:ff一口气生成proposal、design、specs、tasks这些文档。

第二段：切换到Superpowers保证执行质量

参考OpenSpec产出的proposal和design进入brainstorming，开worktree隔离分支，把OpenSpec的tasks.md拆成更细的2-5分钟步骤，然后子代理驱动执行——强制TDD、独立代码审查、验证通过才算完。

第三段：回到OpenSpec收尾

/opsx:verify验证实现是否和规格文档一致，/opsx:archive归档变更，把增量规格合并到主规格库。

简单说就是：OpenSpec管「做什么」和「为什么做」，Superpowers管「怎么做」和「做得对不对」。三段走完，既保证了代码质量，又留下了完整的决策记录。

不过结合使用有几个现实问题要考虑。首先是Token成本——OpenSpec本身很省，但叠加Superpowers的多代理架构后，Token消耗大概是单独用OpenSpec的4-6倍。其次是流程重叠——两者的「需求探索」和「设计」阶段有重叠，需要明确用OpenSpec的explore来主导需求探索，用Superpowers来主导代码执行。最后是平台要求——结合使用的前提是你的平台必须支持子代理派发，目前主要是Claude Code和Cursor。

我的建议

如果是新项目+Claude Code+Token预算宽裕，直接上Superpowers，从第一天起代码质量就有保障。如果是已有项目+合规要求+团队人多，OpenSpec更实用，变更记录和知识库在大型项目中价值很大。如果两者都想要，三段式分工是可行方案，但要接受更高的Token消耗。

最后一个提醒：别过度使用。修个小bug、改个配置、做个快速原型，不需要上SDD工作流。杀鸡用牛刀只会浪费时间。这两个框架解决的是「AI编码缺乏系统性」的问题，不是所有场景都需要系统化。

不知道大家实际用下来感受如何？我目前两个都在试，Superpowers写新项目确实舒服，OpenSpec管变更记录也省心，但结合使用的Token消耗确实肉疼。欢迎评论区聊聊你的经验。