第一个AI 在「要构建什么」还没想清楚的时候就开始写代码。你跟它讨论需求聊了三轮它突然来一句「我来帮你实现吧」然后一顿输出写完一看方向跑偏了。代码能跑但不是你想要的。删了重来token 已经烧掉了。第二个规划倒是写了但实现的时候还是漂移。代码和 spec 各走各的路到最后 review 的时候才发现对不上。为了解决这两个问题我分别找到了两个框架。OpenSpecGitHub 5.7 万星Fission AI 开源的 spec-driven 规划引擎。规划能力极强proposal 到 specs 到 design 到 tasks每一步都有 schema 验证delta spec 做增量变更支持 25 个 AI 编码平台。说实话在「让 AI 想清楚再动手」这件事上目前没看到比它更成熟的方案。SuperpowersGitHub 24 万星obra 做的执行纪律框架。TDD 铁律、Review Gate、Subagent-Driven Development、系统性调试四层质量门禁层层设卡。在「逼着 AI 按规矩做」这件事上它是绝对的行业标杆。两个框架都很强我两个都在用。但用了一段时间之后一个新的痛点浮出水面——我得手动判断现在该用哪个框架。需求模糊的时候用 OpenSpec 探索规划写完了要切到 Superpowers 执行中间还得手动管理状态转换、手动归档、手动检查 spec 有没有漂移。两个框架各自没有对接粘合剂是我自己脑子里的流程。太累了。所以我写了 spec-superflow一个把两者焊在一起的插件。核心思路说出来其实不复杂——用一张「执行契约」把规划和执行连起来然后让状态机自动驱动流转。今天拆开来聊聊这个设计思路。OpenSpec5.7 万星的规划标杆先聊 OpenSpec。这是 Fission AI 开源的 AI-native 规划引擎MIT 协议目前 v1.4.1GitHub 5.7 万星。它要解决的问题很直接——AI 编码助手在需求只存在于聊天记录的时候行为是不可预测的。你今天跟 AI 说「加个暗色模式」它记住了。明天你改了主意说「先别做暗色模式把性能优化搞一下」它可能还记得昨天那个暗色模式的上下文写着写着又跑回去了。OpenSpec 的解法是加一层轻量协议在写代码之前先把变更该做什么记下来。不是写那种 50 页的 PRD而是一个结构化的 spec用 SHALL 和 MUST 这种确定性词汇描述需求配上 Given/When/Then 的场景。OpenSpec 工件依赖图它有一套非常漂亮的工件依赖图。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 的定位是「规划引擎」它把规划做到了极致但从规划到落地这段路它有意不碰。它的设计哲学是「做好一件事」——把需求定义清楚然后交给执行层。这不是缺陷是边界。只是这个边界意味着用户需要自己去找一个靠谱的执行层框架来对接。Superpowers24 万星的执行圣经再说 Superpowers。这是 obraPrime Radiant做的一套软件开发方法论打包成可组合的 AI agent skills目前 v6.0.3GitHub 24 万星。24 万星什么概念这是 AI 编码工具生态里星标最高的框架之一。它不是某个特定功能做得好而是整个「AI 该怎么写代码」的方法论被社区认可了。如果说 OpenSpec 是个冷静的参谋Superpowers 就是个铁血教官。它的核心不是「帮你想清楚」而是「逼着你按规矩来」。每个 skill 都是强制性的。它甚至有一张「Red Flags」表列出了 AI 可能用来跳过流程的借口——「这个改动太小了不需要测试」「用户赶时间先跳过 review」——然后逐条告诉你为什么这些借口不成立。我第一次看到这张表的时候笑了因为它列的每条借口我都见过AI 确实就是这么偷懒的。TDD 在这里是铁律没有失败测试就不准写生产代码。不是建议是强制。AI 要是违反了这条规则要求它把写的代码全部删掉从 failing test 重新开始。这个设计太狠了但也太对了。AI 最难拒绝的就是「我先写个大概能跑的版本再补测试」这种诱惑Superpowers 直接把这扇门焊死了。Review Gate 层层设卡——spec 写完先自审每个任务完成后审查整个分支完成后审查交付前最终验证。四层 gate任何一层没通过都不能往下走。SDDSubagent-Driven Development更是杀手级能力。每个任务分发给一个独立的子代理去执行上下文隔离文件交接。子代理不会被其他任务的上下文污染完成后还有双裁决审查——既查 spec 合规性又查代码质量。v6.0 的评测数据显示这套机制让 token 消耗砍了约 50%速度翻了一倍。不过Superpowers 的定位是「执行纪律」它在规划层提供的是 brainstorming——更像设计讨论不是正式的 spec。没有 SHALL/MUST 这种确定性需求描述没有 delta spec 增量管理没有 spec 之间的拓扑依赖。同样这不是缺陷是边界——它专注于把「做」这件事做到极致。只是规划层需要一个更正式的引擎来补位。spec-superflow让两个框架自动协作现在该说 spec-superflow 了。这是我自己开源的 Claude Code 插件v0.2.0MIT 协议。你可能想两个框架同时装上不就行了问题在于粘合剂得你自己做。OpenSpec 的 explore 和 Superpowers 的 brainstorming 都在做需求梳理同时用哪个OpenSpec 的 propose 和 Superpowers 的 writing-plans 都在做计划生成听谁的规划完了谁触发执行执行到一半发现 spec 要改谁来回滚归档的时候谁来同步 delta spec全靠手动判断手动切换手动归档。用了一段时间我就烦了——这哪是提效这是给自己加了个「流程管理员」的活。所以我决定把两者焊死让状态机自动驱动流转。做法是三步——去重叠、留异同、加独创。spec-superflow 整合策略流程图去重叠把功能重复的合并掉brainstorming 融入 spec-explorer因为探索需求本身就是头脑风暴的落地形态writing-plans 融入 spec-forger规格锻造的过程就是写计划的过程executing-plans 并入 execution-governor执行和治理本来就不该分开archive 和 finishing 并入 closure-archivist收尾归档一气呵成。留异同两边各自独有的东西全部保留。systematic-debugger 是 Superpowers 的精华之一专门处理 bug 的OpenSpec 没有对应物保留。spec-syncer 是 OpenSpec 的 delta spec 同步机制Superpowers 没有保留。code-reviewer 同理。加独创这是最关键的部分。新增了三个组件bridge-contract解析引擎自动从规划工件提取执行契约、workflow-orchestrator内容级状态检测不只是看文件存不存在、还有一个覆盖全流程的七状态机。这三个新增组件里面bridge-contract 是核心创新。单独拆出来说。执行契约让规划变成可验证的东西bridge-contract 是整个 spec-superflow 的设计重心。它生成的 execution-contract.md 不是第五个规划文档而是一份可验证的执行契约。为什么需要这个东西因为我发现前面说的那两个失败模式根源在于规划和执行之间缺少一个「锚点」。OpenSpec 的 spec 是参考材料AI 执行的时候可能看也可能不看。Superpowers 的 skill 是行为准则但它不知道具体该验证什么。execution-contract 就是那个锚点它从 OpenSpec 的四个规划工件proposal、specs、design、tasks里自动提取关键约束形成一份执行必须对标的契约。提取什么六样东西。Intent Lock锁定变更意图防止执行过程中目标漂移。Scope Fence圈定变更范围明确什么该改什么不该改。Non-Goals列出明确不做的东西这个很重要AI 最容易「顺手」做 spec 之外的事情。Test Obligations测试义务哪些场景必须有测试覆盖。Review Gates审查节点执行到哪一步需要暂停等人 review。Rewind Triggers回滚触发条件出现什么情况必须停下来重新评估。然后做覆盖检查每个 spec 里的 SHALL 和 MUST 需求都必须在契约中有对应的条目。如果某条需求在契约里找不到映射说明规划层和执行层之间有缝隙要么补契约要么回头补规划。契约生成后唯一的人工门禁就是用户审批。审批通过了execution-governor 才能启动执行。这个设计是有意的机器可以生成规划机器可以执行代码但「确认这个规划值得执行」这个判断必须是人来做。execution-contract 数据流图来看一段实际的 contract 片段。假设我们在做一个「给用户管理模块加分页」的变更Intent Lock实现用户管理列表的分页查询功能支持按创建时间排序。Scope FenceIn Scopesrc/modules/user/user.controller.ts— 新增分页参数解析src/modules/user/user.service.ts— 分页查询逻辑src/modules/user/dto/user-list.dto.ts— 新增分页 DTOOut of Scope用户详情接口不动不做前端分页组件Non-Goals不引入 Elasticsearch不做全文搜索不优化现有的 N1 查询留给下个变更Test Obligations默认分页参数page1, size20单元测试非法分页参数page0, size-1边界测试空结果集返回格式测试Review GatesGate 1: DTO 和 Service 层完成后review 分页逻辑Gate 2: Controller 层完成后review 参数绑定Rewind Triggers如果分页查询导致已有接口响应时间 500ms暂停评估是否需要加索引如果发现需要改动 user.entity.ts暂停——可能超出 scope这就是契约的样子。不长但每一条都对应着执行时的检查点。AI 在写代码的时候execution-governor 会拿着这份契约逐条比对。Scope Fence 之外的文件不许碰。Non-Goals 里提到的事情不准顺手做。Rewind Trigger 触发了暂停等人来决定。Claude Code 安装/plugin marketplace add MageByte-Zero/spec-superflow/plugin install spec-superflowspec-superflow启动工作流使用 workflow-orchestrator 开始七状态机一条路走到黑的流程spec-superflow 的完整工作流用七个状态描述exploring → specifying → bridging → approved → executing → debugging → closing。每个状态对应一到两个 skill。exploring 阶段用 spec-explorer 梳理需求specifying 阶段用 spec-forger 生成规划工件bridging 阶段用 bridge-contract 生成执行契约approved 是人工审批的暂停点executing 阶段用 execution-governor 管控实施debugging 阶段交给 systematic-debugger 处理异常closing 阶段由 closure-archivist 完成归档。workflow-orchestrator 是入口。你说「开始」或者「继续」它检测当前状态决定下一步该调用哪个 skill。这里有个设计细节值得说说它不是简单地检查某个文件存不存在来判断状态而是读文件内容分析里面写了什么。比如它不会只看「design.md 存在吗」而是看「design.md 里面的内容是否覆盖了 specs 里提到的所有关键技术决策」。这个内容级检测的设计是因为我踩过坑。早期版本用文件存在性检查结果 AI 生成了一个空的 design.md 占位状态机就以为规划完成了直接往下走。后来改成内容级检测才把这类问题堵住。