4万星和5.7万星的两个框架，我焊在一起后它们封神了
第一个，AI 在「要构建什么」还没想清楚的时候就开始写代码。你跟它讨论需求，聊了三轮，它突然来一句「我来帮你实现吧」，然后一顿输出，写完一看，方向跑偏了。代码能跑，但不是你想要的。删了重来，token 已经烧掉了。
第二个，规划倒是写了，但实现的时候还是漂移。代码和 spec 各走各的路，到最后 review 的时候才发现对不上。
为了解决这两个问题，我分别找到了两个框架。
OpenSpec，GitHub 5.7 万星，Fission AI 开源的 spec-driven 规划引擎。规划能力极强，proposal 到 specs 到 design 到 tasks，每一步都有 schema 验证，delta spec 做增量变更，支持 25+ 个 AI 编码平台。说实话，在「让 AI 想清楚再动手」这件事上，目前没看到比它更成熟的方案。
Superpowers，GitHub 24 万星，obra 做的执行纪律框架。TDD 铁律、Review Gate、Subagent-Driven Development、系统性调试，四层质量门禁层层设卡。在「逼着 AI 按规矩做」这件事上，它是绝对的行业标杆。
两个框架都很强，我两个都在用。但用了一段时间之后，一个新的痛点浮出水面——
我得手动判断现在该用哪个框架。
需求模糊的时候用 OpenSpec 探索，规划写完了要切到 Superpowers 执行，中间还得手动管理状态转换、手动归档、手动检查 spec 有没有漂移。两个框架各自没有对接，粘合剂是我自己脑子里的流程。
太累了。
所以我写了 spec-superflow，一个把两者焊在一起的插件。核心思路说出来其实不复杂——用一张「执行契约」把规划和执行连起来，然后让状态机自动驱动流转。
今天拆开来聊聊这个设计思路。
OpenSpec，5.7 万星的规划标杆
先聊 OpenSpec。这是 Fission AI 开源的 AI-native 规划引擎，MIT 协议，目前 v1.4.1，GitHub 5.7 万星。
它要解决的问题很直接——AI 编码助手在需求只存在于聊天记录的时候，行为是不可预测的。你今天跟 AI 说「加个暗色模式」，它记住了。明天你改了主意说「先别做暗色模式，把性能优化搞一下」，它可能还记得昨天那个暗色模式的上下文，写着写着又跑回去了。
OpenSpec 的解法是加一层轻量协议，在写代码之前先把变更该做什么记下来。不是写那种 50 页的 PRD，而是一个结构化的 spec，用 SHALL 和 MUST 这种确定性词汇描述需求，配上 Given/When/Then 的场景。
它有一套非常漂亮的工件依赖图。proposal 定义变更意图，specs 描述具体需求，design 给出技术方案，tasks 拆分成可执行步骤，最后才是 implement。每个工件都有 schema 定义，靠一个 YAML 引擎做拓扑排序，前置工件没就绪，后续的自然等着。依赖关系是「使能」而不是「卡死」——你随时可以回去修改前面的工件，这在「流动不僵化」这个设计理念下非常实用。
几个核心命令，/opsx:explore探索需求，/opsx:propose生成 proposal，/opsx:apply往下游推进，/opsx:sync同步 delta spec 到主 spec，/opsx:archive归档已完成的变更。支持 25+ 个 AI 编码平台，Claude Code、Cursor、Codex、Gemini CLI 全覆盖。
有个设计我特别欣赏——delta spec。棕地项目最怕改一处要重写整份 spec。OpenSpec 用 ADDED/MODIFIED/REMOVED 三个标记描述增量变更，不动已有 spec，只描述差异。这让它在存量代码场景下极其好用。
不过，OpenSpec 的定位是「规划引擎」，它把规划做到了极致，但从规划到落地这段路，它有意不碰。它的设计哲学是「做好一件事」——把需求定义清楚，然后交给执行层。这不是缺陷，是边界。
只是这个边界意味着，用户需要自己去找一个靠谱的执行层框架来对接。
Superpowers，24 万星的执行圣经
再说 Superpowers。这是 obra（Prime Radiant）做的一套软件开发方法论，打包成可组合的 AI agent skills，目前 v6.0.3，GitHub 24 万星。
24 万星什么概念？这是 AI 编码工具生态里星标最高的框架之一。它不是某个特定功能做得好，而是整个「AI 该怎么写代码」的方法论被社区认可了。
如果说 OpenSpec 是个冷静的参谋，Superpowers 就是个铁血教官。它的核心不是「帮你想清楚」，而是「逼着你按规矩来」。
每个 skill 都是强制性的。它甚至有一张「Red Flags」表，列出了 AI 可能用来跳过流程的借口——「这个改动太小了不需要测试」「用户赶时间先跳过 review」——然后逐条告诉你为什么这些借口不成立。我第一次看到这张表的时候笑了，因为它列的每条借口我都见过，AI 确实就是这么偷懒的。
TDD 在这里是铁律，没有失败测试就不准写生产代码。不是建议，是强制。AI 要是违反了这条，规则要求它把写的代码全部删掉，从 failing test 重新开始。这个设计太狠了，但也太对了。AI 最难拒绝的就是「我先写个大概能跑的版本再补测试」这种诱惑，Superpowers 直接把这扇门焊死了。
Review Gate 层层设卡——spec 写完先自审，每个任务完成后审查，整个分支完成后审查，交付前最终验证。四层 gate，任何一层没通过都不能往下走。
SDD（Subagent-Driven Development）更是杀手级能力。每个任务分发给一个独立的子代理去执行，上下文隔离，文件交接。子代理不会被其他任务的上下文污染，完成后还有双裁决审查——既查 spec 合规性，又查代码质量。v6.0 的评测数据显示，这套机制让 token 消耗砍了约 50%，速度翻了一倍。
不过，Superpowers 的定位是「执行纪律」，它在规划层提供的是 brainstorming——更像设计讨论，不是正式的 spec。没有 SHALL/MUST 这种确定性需求描述，没有 delta spec 增量管理，没有 spec 之间的拓扑依赖。同样，这不是缺陷，是边界——它专注于把「做」这件事做到极致。
只是，规划层需要一个更正式的引擎来补位。
spec-superflow，让两个框架自动协作
现在该说 spec-superflow 了。这是我自己开源的 Claude Code 插件，v0.2.0，MIT 协议。
你可能想，两个框架同时装上不就行了？
问题在于，粘合剂得你自己做。OpenSpec 的 explore 和 Superpowers 的 brainstorming 都在做需求梳理，同时用哪个？OpenSpec 的 propose 和 Superpowers 的 writing-plans 都在做计划生成，听谁的？规划完了谁触发执行？执行到一半发现 spec 要改谁来回滚？归档的时候谁来同步 delta spec？
全靠手动判断，手动切换，手动归档。用了一段时间我就烦了——这哪是提效，这是给自己加了个「流程管理员」的活。
所以我决定把两者焊死，让状态机自动驱动流转。做法是三步——去重叠、留异同、加独创。