「分页查询」引发的三重暴击
2026 年 3 月，我给我的一个后端项目加了一个需求：给用户管理模块加「分页查询」。不改数据库、不改实体类，就加一个 Controller 方法和对应的 Service 逻辑。需求本身简单到不值一提。

但我故意跑了三遍。

第一遍：只用 OpenSpec。

我写下 /opsx:propose，让它生成 proposal、specs、design、tasks。四个工件出来后我扫了一眼——规格写得漂亮，page 参数的范围、size 的上限、空结果的返回格式，都用 SHALL/MUST 标得清清楚楚。然后我执行 /opsx:apply，让它开始实现。

代码写完了。跑起来没问题。但我 review 的时候发现——它顺手「优化」了旁边的 UserService.getUserById() 方法，加了一个缓存逻辑。我从来没让它做这个。

它没有恶意。它只是在执行的时候看到那个方法，觉得「顺手优化一下很合理」。但这一顺手，改了一个不在本次变更范围内的文件 ——在真实项目里，这可能意味着你今晚要加班修一个跟分页毫无关系的 bug。

第二遍：只用 Superpowers。

因为 TDD 铁律的存在，这次每个任务都有测试先跑——没有失败测试，不准写生产代码。Review Gate 层层把关。

但问题出在更早的阶段。Superpowers 的 brainstorming 做需求澄清的时候，我问它「分页要处理哪些边界情况」。它列了几个，比如 page 从 1 开始还是从 0 开始、size 的上限是多少。但它没有给我一个结构化的 spec。执行过程中，AI 自己做了几个关于边界行为的决定——比如 page=0 时返回空数组，而不是返回 400 错误。这些决定分散在各个子代理的会话里，没有汇总。等 code-review 发现这个问题的时候，测试已经写了、代码已经改了，回头的成本远高于第一次就写对。

第三遍：用 spec-superflow。

bridge-contract 在规划阶段就锁死了 Scope Fence：「只改 UserController / UserService / UserListDTO，不准动 UserEntity」。Non-Goals 里写着：「不做全文搜索，不优化 N+1 查询」。Test Obligations 列了六条，包括「page=0 返回 400」「size=-1 返回 400」「空结果返回 200 + 空数组」。

然后 build-executor 拿着这份契约逐条比对执行。AI 想顺手改 UserEntity？Guard 拦住了。Review Gate 发现分页逻辑跟 Test Obligations 不一致？打回去重写。

三遍跑完，同一个需求，三种结局。

第一种，代码能跑但有 side effect。第二种，测试覆盖但边界行为不一致。第三种，跟 spec 对齐。

这不是 magic。这是我在 OpenSpec（5.8 万星）和 Superpowers（24 万星）之间找到的那条裂缝——然后把它焊上了。

三种工作流对比：只用OpenSpec vs 只用Superpowers vs 用spec-superflow

二、两个顶级框架，各自解决了一半
要理解 spec-superflow 做了什么，我们得先搞清楚这两个框架各自擅长什么——以及各自由什么「边界」决定了它们只能走到哪。

OpenSpec：规划做到极致，但到执行为止
OpenSpec 由 Fission AI 开源（MIT 协议，GitHub 58,030 星，截至 2026 年 7 月最新版 v1.5.0），是目前最成熟的 AI-native 规划引擎。它的核心是一个围绕「工件」（artifacts）构建的工作流：

/opsx:explore → 把模糊想法变成结构化的 change 定义
/opsx:propose → 生成 proposal.md + specs/ 目录，用 SHALL/MUST/Given-When-Then 锁定行为
/opsx:apply → 生成 design.md + tasks.md，推到可执行状态
/opsx:sync → 把 delta spec（增量变更）合并回主 spec
/opsx:archive → 变更完成，归档
这套工件依赖链设计得非常漂亮——proposal 定义意图，specs 锁定行为，design 画架构，tasks 拆执行步骤。支持 25+ 个 AI 编码平台（Claude Code、Cursor、Copilot、Codex、Gemini CLI、Windsurf 等），内置 Zod Schema 验证引擎，delta spec 用 ADDED/MODIFIED/REMOVED/RENAMED 四个标记做增量变更而不动已有规格。

但 OpenSpec 的设计哲学是「做好一件事」。它把需求定义到 tasks.md，就停了。 怎么执行、按什么纪律执行、谁来保证代码不偏离 spec——它有意不碰。

这不是缺陷，是边界。Fission AI 团队选择在规划层做到极致，不越界去管执行。这个选择本身是对的——做一件事比做两件事更可能做好。问题是，你作为使用者，规划做到 tasks.md，下一步谁接手？

Superpowers：执行纪律做到极致，但规划偏弱
Superpowers 由 obra（Jesse Vincent）主导（GitHub 242,711 星，截至 2026 年 7 月最新版 v6.1.0），是 AI 编码工具生态里星标最高的执行纪律框架。14 个 skill 全是 Markdown prompt，零依赖注入，靠自然语言强制执行纪律。

它的四层质量门禁是真正的「硬」约束：

TDD 铁律：NO PRODUCTION CODE WITHOUT FAILING TEST——不是建议，是强制。Red Flags 表里列出了 AI 会用哪些借口跳过测试（「这个太简单了」「我先写个原型」），然后逐条反驳。Meincke 等人 2025 年的研究数据显示，这种反合理化设计让合规率从 33% 提升到了 72%（N=28,000 次会话）。
Review Gate 四层设卡：自审 → 任务审 → 分支审 → 交付审——每一层查不同的东西，不是同一批人看四遍。
SDD（Subagent-Driven Development）：每个任务独立子代理执行，上下文隔离，token 消耗约砍掉一半。
系统性调试：四阶段根因分析——Root Cause → Pattern → Hypothesis → Implementation——不是「试一下能不能跑」。
但 Superpowers 的规划能力靠的是 brainstorming。这是一场设计讨论，不是正式 spec。没有 SHALL/MUST 的确定性需求描述，没有 delta spec 增量管理，没有工件依赖拓扑。它告诉你「先想清楚」，但「想清楚」的标准是自己定的。

如果两个都装呢？
我试过。三个月的真实体验是——

需求模糊的时候，OpenSpec 的 explore 和 Superpowers 的 brainstorming 都在做需求梳理。同时开两个，哪个为准？
规划写完了，OpenSpec 的 propose 和 Superpowers 的 writing-plans 都在做计划生成。听谁的？
规划完了谁触发执行？手动切换。
执行到一半发现 spec 要改，谁来回滚？手动判断。
归档的时候谁来同步 delta spec？手动归档。
我用两个框架，却给自己加了一份「流程管理员」的工作。这份工作的内容就是：判断、切换、手动拼接。每一处拼接点都是一个潜在的漂移入口——因为我也是人，我也会漏。

2026 年的生态也印证了这一点。社区里出现了好几个试图桥接 OpenSpec 和 Superpowers 的项目——spec-driven-tdd（4 阶段 skill-pack）、sddflow（npm 编排器）、Astrolabe（28 平台+CodeGraph）、Comet（29 平台+阶段守护脚本）、easyflow（8 阶段+治理层）。这些项目都在解决同一个问题：两个框架各自优秀，但接不上。

它们共同的问题在于桥接方式——用 skill 注入、配置文件、Shell 脚本把两个框架「拼」在一起。这就像用胶带把两个引擎绑在一起——看起来是一辆车，但引擎之间没有传动轴。

我需要的不只是「同时安装」。我需要一个传动轴。

OpenSpec 与 Superpowers 的边界和重叠区域

三、传动轴是怎么造出来的
spec-superflow 的方法不是「两边都装」，而是「去重叠、留异同、加独创」。这三步背后各有一个设计决策，让我一个一个说。

第一步：去重叠
OpenSpec 和 Superpowers 在四个能力上有重叠——需求探索、规划生成、代码审查、验证归档。你不能让两个引擎同时输出同一件事，结果一定会冲突。

我的做法是：每种能力只保留一个引擎，选最强的一方。

去重叠的四个决策点——explore/propose/review/archive 各自选了哪一方

能力 OpenSpec Superpowers spec-superflow 的选择 理由
需求探索 /opsx:explore（结构化的 change 定义） brainstorming（设计讨论，一次一个问题） 融合增强：取 OpenSpec 的结构化输出 + Superpowers 的「一次只问一个问题」的提问法 结构化的探索才有可追溯性；但一次把所有追问全抛出来会让用户窒息
规划生成 /opsx:propose + /opsx:apply（4 工件 + Schema 验证） writing-plans（Markdown 计划） 取 OpenSpec：4 工件 + Schema 引擎实时验证 我需要的是确定性的需求描述，不是自然语言的计划文档
代码审查 — code-reviewer（三级问题分级） 取 Superpowers：结构化审查 OpenSpec 没有审查能力，Superpowers 有
调试 — systematic-debugging（四阶段根因分析） 取 Superpowers：四阶段调试 OpenSpec 没有调试能力
Delta 同步 /opsx:sync（增量合并+冲突检测） — 取 OpenSpec：增量 spec 管理 Superpowers 没有 spec 版本管理
执行管控 — TDD + SDD + Review Gate 取 Superpowers：三重纪律 OpenSpec 只到 tasks.md 为止
第二步：留异同——把不一样的保留下来，因为它们解决不同的问题
有些能力两边根本没有重叠，各自是唯一的。这些要全部保留：

OpenSpec 的 Schema 验证引擎：用 Zod 做类型定义，写 proposal/specs/design/tasks 的时候实时检查格式和完整性。没有这个，规划工件的质量取决于写 prompt 的人——同一个 prompt，三分钟后的 AI 可能产出不同的结构。
OpenSpec 的 Delta Spec：ADDED/MODIFIED/REMOVED/RENAMED 四个标记，增量更新 spec 而不动已有内容。棕地项目的命——你不能每次都重写整个 spec。
Superpowers 的 TDD 铁律：不是「建议写测试」，是「没有失败测试就不准写生产代码」。Red Flags 表 + 反合理化设计让 AI 无法绕过去。
Superpowers 的 SDD：每个任务独立子代理，token 消耗砍半，速度翻倍。
Superpowers 的 验证前完成铁律：NO COMPLETION CLAIMS WITHOUT FRESH EVIDENCE——不许说「完成了」，必须先跑测试、读输出、确认通过。
第三步：加独创——bridge-contract
去掉了重叠，保留了异同。但到现在为止，spec-superflow 还是两个引擎的复刻——它们都还在，只是不冲突了。

真正的创新在第三步：bridge-contract 执行契约。

这是 spec-superflow 里最核心的一行代码——不是比喻，真的是一份叫 execution-contract.md 的文件。它是由 contract-builder 里的解析引擎自动从 OpenSpec 的四个规划工件里提取出来的：

proposal.md ──→ Intent Lock（变更意图）
specs/ ──→ Approved Behavior（审批通过的行为规格）
design.md ──→ Design Constraints（设计约束）
tasks.md ──→ Task Batches（任务批次）
然后自动补上两份「执行纪律层」的信息：

Test Obligations：哪些场景必须有测试覆盖——从 specs 的 Given-When-Then 场景里自动提取
Review Gates：执行到哪一步需要暂停等人审查——根据变更复杂度自动设定
最终生成一份可检查、可验证的执行契约。

bridge-contract 六要素：Intent Lock / Scope Fence / Non-Goals / Test Obligations / Review Gates / Rewind Triggers

这六样东西不是让人「感觉更安心」的修辞。每一条都是可程序化检查的：

Intent Lock 锁定了变更意图——执行过程中如果 AI 的行为偏离了初始意图，Guard 系统会拦截
Scope Fence 圈定了文件范围——明确哪些文件可以改、哪些不能碰
Non-Goals 列出了明确不做的事——这是给 AI 设的「护栏」，防止它顺手做额外的事
Test Obligations 列出了必须覆盖的场景——不是「建议测一下」，是「以下场景都有失败测试」
Review Gates 标出了人机交互点——到这几步，暂停，等人确认
Rewind Triggers 设了回滚条件——出现这些情况（如 Scope Fence 被突破、Test Obligations 未覆盖），自动停下，回到 bridging 状态重新评估
关键是：这份契约唯一的「人工准入」就是你在 bridging 状态结束时的审批。 审批之后，整个 execution 阶段不需要你再当「流程管理员」——execution-governor 拿着契约逐条比对，Guard 系统做五维检查（工件存在、Schema 有效、契约新鲜、任务完成、测试通过），检测到违规就自动拦截。

这就是传动轴。它把 OpenSpec 的「想清楚」和 Superpowers 的「做对」之间的手工作业，变成了一份自动执行的合同。

而驱动整个流程的，是一个 8 状态机。

8 状态机完整流转：exploring→specifying→bridging→approved-for-build→executing⇄debugging→closing→abandoned + syncing