第一个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 的场景。它有一套非常漂亮的工件依赖图。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全靠手动判断手动切换手动归档。用了一段时间我就烦了——这哪是提效这是给自己加了个「流程管理员」的活。所以我决定把两者焊死让状态机自动驱动流转。做法是三步——去重叠、留异同、加独创。
4万星和5.7万星的两个框架，我焊在一起后它们封神了
第一个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 的场景。它有一套非常漂亮的工件依赖图。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全靠手动判断手动切换手动归档。用了一段时间我就烦了——这哪是提效这是给自己加了个「流程管理员」的活。所以我决定把两者焊死让状态机自动驱动流转。做法是三步——去重叠、留异同、加独创。
