---
title: "OpenSpec + Superpowers 融合方案下线记：2 周 3 次实测 + 3 个测试识别缝合怪 + 加法 vs 减法传播学 + Plan Mode + Superpowers + ASD 最终方案"
source_url: "https://mp.weixin.qq.com/s/tw6nPi8NIYxd55yiPafSig"
ingested: 2026-06-18
sha256: b4988a1a8db9fc849eb0ff7912215ae91a4a5a158aae9cae2bea5da14b36e40f
type: raw
tags: [openspec, superpowers, asd, frankenstein-pattern, three-test-framework, addition-vs-subtraction, plan-mode, propagation-economics, shuge, spec-driven-development, ac-numbering, ac-coverage, drift-check, six-injection-points]
---

# OpenSpec + Superpowers 融合方案下线记

## 导语

上周刷到一篇《OpenSpec + Superpowers + Spec-Kit 终极融合工作流》，收藏过万，评论区一片"先马后看""这才是完全体"。

而我们团队，刚把 OpenSpec + Superpowers 的融合方案下线了——**两周 pilot，三次完整实测之后**。

一边是万人收藏的终极方案，一边是亲手实测后的撤退。这个落差值得认真讲一次：先把这套方案当初为什么成立讲清楚，再讲它为什么没活下来，最后完整交代我们现在跑的方案。

## 一、当时的"完全体"：OpenSpec 管 What，Superpowers 管 How

选这套组合不是跟风，是冲着两个真实痛点去的：

**痛点一（需求层）**：规格散落在聊天记录和过期文档里，代码改了没人改 spec，三个月后没人说得清系统"应该"是什么样。

**痛点二（执行层）**：AI 写代码质量不稳定，有时跳过测试直接给实现，验证全凭 Agent 自己一句"应该没问题"。

**OpenSpec 正面解决痛点一**：核心设计是活基线——规格不是一次性文档，而是一个持续演进的真相源。每次变更以 delta 形式提案，实施完成后归档合并回基线。规格永远反映系统当前状态，每次变更可追溯。

**Superpowers 正面解决痛点二**：核心设计是流程纪律——brainstorming 发散方案、writing-plans 拆任务、TDD 红绿循环强制先写测试、verification 提交前验证、code review 子 Agent 互审。AI 不能跳步骤。

两者看起来完美正交：**一个管 What 的治理，一个管 How 的纪律**。衔接处设计了握手协议——spec 里的每个 Scenario，对应 TDD 里的一个测试函数，归档时回写基线，形成从规格到代码再回到规格的闭环。

融合后的完整流程五个阶段：**首尾治理、中间执行**。

设计评审时，这套方案全票通过。直到开始跑。

## 二、两周实测：1 + 1 < 1

实测暴露的问题不是"不合理"，是处处打架。把两条工具链并排画出来，问题一目了然：

| 冲突 | 现场 | 后果 |
|---|---|---|
| 设计文档归谁管 | OpenSpec 产出 design.md，Superpowers brainstorming 也产出 design doc，内容高度重叠 | 开发者不知以哪份为准 |
| 真相源冲突 | OpenSpec 认 Spec 是 truth，Superpowers 认测试是 truth | 不一致时永远听测试的，spec 沦为没人看的文档 |
| 多层审批互不信任 | review spec → review design → review plan，审的是同一组信息的三种表达 | 时间变长，信心没有增加 |

**回头看，问题出在分工假设本身**——"OpenSpec 管 What，Superpowers 管 How"这份分工协议，是我们一厢情愿画在 PPT 上的，**两个工具谁都没签字**。

### 手工同步 = 不是自动集成

还有一个更直接的信号：**三次实测，0 个 skill 自动触发**，流程全靠人按 checklist 手工驱动——Scenario 名对齐、validate 双跑，所有"握手协议"都靠人肉维护。

> 手工同步 ≠ 自动集成。缝合怪的本质，是让人肉充当工具之间的胶水。
> 胶水是会累的。两周后最先撑不住的不是工具，是当胶水的那个人。

### 1+1 < 1 的总账

两套产物意味着双份 token，三层审批意味着更长的链路，每个需求都要付两个工具的流程开销。问卷里的反馈："OpenSpec 对效率提升不明显，但增加了成本。"

**1 + 1 不仅没到 2，连 1 都没守住——比单用 Superpowers 更慢、更贵。重叠不是双保险，是负资产。**

## 三、能修，但值得修吗

熟悉 Claude Code 的读者已经在心里反驳了：这些打架，工程上全都有解。

- design doc 重叠？写个 skill，让 brainstorming 直接消费 OpenSpec 的 design.md，跳过自家产出
- Scenario 名人肉对齐？加个 hook，强制校验命名、自动双跑 validate
- 多层审批冗余？合并卡点，一次审完三层

没错，都能修。**我们当时真的列了这张修补清单。动手之前，先算了三笔账——算完就收手了。**

### 第一笔账：你修补的不是 bug，是世界观

| 工具 | 世界观 |
|---|---|
| OpenSpec | **Spec 是真相源**，代码是它的投影，整套流程围绕"文档的生命周期"转 |
| Superpowers | **测试是真相源**，文档只是脚手架，整套流程围绕"代码的质量纪律"转 |

**"Spec 是真相源"要成立，至少要满足两个条件**：Spec 无歧义，Spec 与代码自动同步。两条都不满足——Spec 是人用自然语言写的，AI 用概率模型解读，中间隔着两层有损翻译；代码改了，Spec 不会自己跟上，反向同步的成本是直接改代码的数倍。

> **今天的 Spec 不是 truth，是 claim**——一份等待验证的主张。真正的 truth 只有一个：跑通测试的代码，pass / fail，没有歧义。

**所以这不是"两个都对、选一个"，是一个成立、一个不成立。**你写的每一个同步 skill，都是在给一个不成立的前提续命。

### 第二笔账：修补的终点，是重写

把同步自动化、产物去重、卡点合并全部做完，回头一看你干了什么？你把 OpenSpec 的功能，用"测试是真相源"的世界观重新实现了一遍。

> **修补的尽头不是融合，是吞并。**既然终点注定只剩一个真相源，为什么不在起点就只留一个工具？

### 第三笔账：就算修成了，方向也是反的

03 篇说过：**模型在变强，正确方向是 more context, less control**。而这台修补完的机器——产物更多、卡点更多、链路更长——每一个零件都在往 control 上加码。你花一个月的工程，得到一台方向反了的完美机器。

> 工程师最危险的时刻，不是解不出问题，而是兴致勃勃地去解一道不该存在的题。
> 所以"打架可以用 skills 解决"这句话，对了一半："能修"回答的是可行性，"该修"回答的是价值。
> 自动化一个不该存在的流程，只会让它更难被删掉。

## 四、真正的问题：为什么缝合怪反而受追捧

方案下线后我一直困惑：这类融合文章的数据为什么那么好？

**点赞数测量的不是工程有效性，是心理有效性。**三个认知陷阱，环环相扣：

### 陷阱一：收藏的是安全感，不是工作流

"全都要"的方案卖的是一种幻觉：每个工具的优点我都不错过。读者点下收藏的那一刻，焦虑已经被治愈了——至于方案能不能跑半年，没人会回来验证。

> 爆款工作流的归宿是收藏夹，不是 CI。"先马后看"的真实含义，是"永远不看"。

### 陷阱二：加法有传播性，减法只有有效性

"我融合了五个工具"是一张可以展示的全家福；"我删到只剩 Plan Mode + 测试"看起来像偷懒。

**但工程里最贵的能力恰恰是做减法**——下线 OpenSpec 之前，我们把它的每项价值都找到了接盘者：

| OpenSpec 原职责 | 接盘者 |
|---|---|
| 意图对齐 | Plan Mode |
| AC（验收标准） | 测试 |
| 变更追溯 | git |
| 活基线 | 测试套件本身 |

> 加法不需要理解，减法需要。传播市场天然奖励加法。Less is more 不涨粉。

### 陷阱三：把"单独有道理"当成"叠加更有道理"

直觉说：OpenSpec 的 delta 回写有道理，Superpowers 的 TDD 有道理，Spec-Kit 的分层也有道理。**全用上，道理最大化。错在算法。**

> **工具的收益是加法，工具间的关联成本是乘法。**两个工具一条人工同步链，五个工具十条。收藏量随工具数线性涨，维护成本随组合数爆炸。

每多缝一个工具，就多一层 control、多一份要同步的真相源。**缝合怪不是先进，是用流程堆叠对冲对模型的不信任——方向反了。**

## 五、三个测试，识别你手里的缝合怪

> **问题从来不是"用了几个工具"，而是工具之间重不重叠、同步靠不靠人肉。组合不是原罪，重叠才是。**

### ① 真相源测试：两个工具对"什么是 truth"的回答一致吗？

OpenSpec 认 Spec，Superpowers 认测试——回答不一致的工具缝在一起，迟早要人来当法官，每次开庭都是认知税。

### ② 同步测试：工具 A 的产物变了，工具 B 自动知道吗？

靠人工对齐的关联是定时炸弹。问自己：需求量翻三倍，同步工作量翻几倍？

### ③ 重叠测试：删掉其中一个工具，有没有另一个工具天然补位？

删掉后另一个工具天然补位，说明两者本来就在干同一件事——留一个就够。

**三个测试全过才叫集成，过不了就是缝合。**

## 六、正确的路径：不是缝合，是渐进式

工具链的问题从来不是"选哪个工具"，而是"用什么结构组织工具"。缝合和渐进式，是两种相反的拓扑：

### 缝合（串联）

每个需求都要穿过所有工具，成本是所有工具之和——每一环都在加 token、加审批、加同步，轻需求也被迫为重流程买单。

### 渐进式（分流）

先按场景分档，每个需求只走最匹配的那条路径，成本只有单条路径。

> 串联的成本随工具数叠加，分流的成本随场景精准匹配。
> 不同场景用不同的工具，而不是所有场景用所有的工具。

### 6.1 主干：按需求分档，知识闭环

| 需求类型 | 路径 |
|---|---|
| **重需求** | 走 Superpowers 全套 — 留下它，正是因为它的世界观赢了（测试是真相源，流程是质量纪律） |
| **中轻需求** | 降级 Plan Mode — 先出计划、人确认、再执行。**Plan Mode 本身就是轻量 Spec**，不要把"没有独立 spec 文件"当成"没做 spec 驱动" |
| **所有需求** | 共享地基：CLAUDE.md + 知识库 |

### 6.2 增强层：ASD，左端补 Context，右端补 Eval

流程有了，但 Superpowers 和 Plan Mode 不天然解决两个问题：**上下文从哪来，验证凭什么独立。**这就是 ASD（Agent-Spec-Driven）增强层的全部使命：

> 在 Intent → Spec 补 Context（让 AI 少猜），在 Spec → Code 补 Eval（让 AI 不能自证正确）。

ASD 不改 Superpowers 一行源码，通过 CLAUDE.md 的 `@import` 侧面注入六个点：

| # | 注入位置 | Superpowers 默认 | ASD 覆写 |
|---|---|---|---|
| ① | brainstorming | 只看代码和文档 | 检索知识库，注入领域铁律和踩坑记录 |
| ② | brainstorming | spec 格式自由 | 强制模板 + AC 全局编号 |
| ③ | writing-plans | task 按功能拆 | 每个 task 标注关联 AC 编号 |
| ④ | TDD | 测试命名自由 | 测试函数嵌入 AC：TestAC01_余额扣减 |
| ⑤ | verification | Agent 自己跑测试自评 | **外部闸门管道替换自评** — 考生不能批改自己的试卷 |
| ⑥ | finishing | 测试过了就交付 | ac-coverage / drift-check 全量校验 |

**贯穿全程的那条线**：AC 编号从 spec → task → 测试函数名 → 覆盖率校验，一路自动追溯。这正是当年 OpenSpec + Superpowers 要靠人肉维护的"Scenario 名对齐"——**同一个需求，从人肉胶水变成了机器纪律**。

### 6.3 验证管道：独立闸门，不许自证

前四步是本来就该跑的 build / lint / test；最后两步是 ASD 独有的——**AC 覆盖率**（每条验收标准都有对应测试吗）和**漂移检测**（代码还和 spec 一致吗）。失败自动重试，三次不过升级人工。

### 6.4 自检：用三个测试扫一遍自己

| 测试 | OpenSpec + Superpowers（融合失败） | Plan Mode + Superpowers + ASD（最终方案） |
|---|---|---|
| **真相源** | Spec 和测试两个 truth，打架 | 唯一 truth = 测试；spec 审完即冻结，活基线是测试套件 |
| **同步** | Scenario 名人肉对齐 | AC 编号机器贯穿，ac-coverage 自动校验 |
| **重叠** | design.md 与 design doc 80% 重叠 | 零重叠：Plan Mode 管轻流程，Superpowers 管重流程，ASD 只补两者都没有的 Context 和 Eval |

> 缝合是两个完整方案抢同一块地盘；集成是每个组件补别人没有的能力。

## 七、收束：好的工具链是删出来的

> 回到那篇万人收藏的融合文章。我不怀疑作者的诚意，每个工具他可能都真的研究过。**但研究过五个工具和用一套流程交付过半年，是两种完全不同的知识。**
> 前者的产出是全家福，后者的产出是伤疤。这个系列写的全是伤疤。
> 好的工具链不是收集出来的，是删出来的。每个留下来的组件，都应该有一个"别人补不了位"的理由。
> 删完之后剩下的工具，也不该缝回一条更长的流水线，而是排成几条深浅不同的车道——场景决定走哪条，而不是每条都走一遍。

做个小实验：拿三个测试扫一遍你现在的工作流——有没有哪个工具，删掉之后另一个会天然补位？

#OpenSpec #Superpowers #ASD #缝合怪 #减法 #Spec驱动开发