Superpowers vs OpenSpec vs GSD 深度阅读总结

基于: 15+ 篇文章深度阅读 整理时间: 2026-03-20

一、三个工具各解决什么问题？

Superpowers：解决"AI 太冲动"

核心问题：AI 编码助手像一个"热情的实习生"——你说要一个功能，它立刻开始写代码。不问需求、不写规范、不写测试、不问架构。代码能跑，但品味缺失。

创始人 Jesse Vincent 的洞察：

"大多数开发者安装 Claude Code，打一个提示词，拿到代码。代码通常还行，有时甚至很好。但总觉得哪里不对——Agent 先写实现后写测试，猜测架构而不是提问，修症状而不是根因。它工作很快，但像一个跳过无聊环节的热情实习生。"

解决方案：不是建新模型或新工具，而是给现有 Agent 一套必须遵守的纪律。一个 skill 就是一个 markdown 文件，描述"什么时候触发、遵循什么步骤、验证什么结果"。Agent 不能选择跳过——框架让它们变成强制执行。

OpenSpec：解决"AI 猜错需求"

核心问题：AI 编码助手最大的问题不是写不了代码，而是写出来的不是你想要的。你说"加个暗黑模式"，它改了 CSS 变量、加了切换按钮、还重构了布局——而你只是想换个颜色 token。下一个对话，上下文没了，AI 又从头猜。

解决方案：在 AI 写代码之前，先生成规范文档。人类和 AI 对齐"做什么"和"怎么做"，然后按规范实现。规范文件存在代码库中，用 Git 管理，上下文不会在对话之间消失。

GSD：解决"上下文腐烂"

核心问题：这是 AI 编码的头号失败点。

上下文使用率	质量表现
0-30%	峰值质量，工作彻底
30-50%	还行，但开始偷懒
50-70%	偷工减料，遗漏需求
70%+	幻觉、遗忘上下文

"每个人用 AI 编码都经历过：一切顺利，Claude 写出完美代码，然后突然在 50% 上下文处，事情开始崩塌。代码变粗糙，需求被遗忘，Claude 开始'更简洁'（翻译：偷工减料）。这就是上下文腐烂。"

解决方案：不再把单个聊天线程当构建系统。把工作拆成小的、可检查的计划，每个计划在全新的上下文窗口中运行，每个任务做原子级 git commit。

二、三者的工作方式有何根本不同？

Superpowers：纪律型（方法论驱动）

设计哲学：30 年软件开发方法论浓缩成 Agent 可执行的规则。

独特机制：

强制 TDD：写了代码没先写测试？删掉，重来。不能保留为"参考"
子代理驱动开发：每个任务由独立子代理执行，执行后自动做两阶段审查（规范合规 + 代码质量）
Spec Review 循环（v5.0 新增）：规划完成后启动对抗性审查，找出计划中的 TBD 和遗漏
模型降级策略：有了详细计划后，可以用 Claude Haiku（便宜模型）实现，Opus 只用于规划
视觉头脑风暴（v5.0 新增）：支持在浏览器中展示设计稿

Jesse Vincent 的金句：

"实现计划要清晰到能让一个热情的、品味差的、没有判断力、没有项目上下文、还讨厌写测试的初级工程师来执行。"

实际效果：

测试覆盖率从 0-30% 跳到 85-95%
chardet 库用 Superpowers 方法论发布 7.0.0 版本：41 倍性能提升，96.8% 准确率

OpenSpec：契约型（规范驱动）

设计哲学："结构先于代码"，brownfield-first（先服务现有项目）。

独特机制：

变更管理：每个功能/改动独立文件夹，包含 proposal + specs + design + tasks
增量修改格式：用 ADDED/MODIFIED/REMOVED 标记变更，不需要重写整个规范
快速归档：完成后归档，规范沉淀为项目文档
仪表盘：实时可视化跟踪

Redreamality 的深度分析：

"当上下文使用超过 40%，AI 性能显著退化——之前的需求细节被遗忘或篡改。OpenSpec 的核心价值在于'先建后改'策略，专门为改造现有项目设计。"

GSD：工程型（上下文工程驱动）

设计哲学：不要跟上下文腐烂硬刚，直接重置。

独特机制：

波次并行执行：任务按依赖关系分波（Wave），独立的任务在全新的 200K 上下文中并行执行
目标反向规划：不问"怎么做"，问"什么必须为真？"，然后倒推任务
XML 原子计划：计划是严格的 XML 结构，告诉执行者精确的文件路径和验证步骤
HANDOFF.json：跨会话交接文件，可以随时中断和恢复
Nyquist 验证层：确保写代码之前有测试反馈循环
自动偏差处理：执行中出错时，Agent 有明确的偏差规则，不会自作主张

创始人的态度：

"其他规范驱动工具——BMAD、SpecKit——都把事情搞得比需要复杂得多。冲刺仪式、故事点、利益相关者同步、回顾会、Jira 工作流……我不需要这些。"

三、三者对比矩阵

维度	Superpowers	OpenSpec	GSD
核心定位	工程纪律	需求对齐	上下文管理
解决的核心痛点	AI 太冲动	AI 猜错需求	AI 失忆
设计哲学	强制方法论	轻量契约	上下文工程
安装复杂度	中	低（5分钟）	低
学习曲线	中	低	中
Token 消耗	较高	低	高（5-10x）
TDD 强制	✅ 最严格	❌	❌（但有验证层）
上下文腐烂处理	靠子代理隔离	靠规范文件	✅ 波次管理，最系统
增量修改	中	✅ 最佳	中
自主开发时长	数小时	需人工驱动	✅ 数小时
可中断恢复	部分	❌	✅ HANDOFF.json
并行执行	❌	❌	✅ 波次并行
测试覆盖率提升	85-95%	—	—
适合谁	追求代码质量	追求需求对齐	追求交付速度
不适合谁	快速原型	TDD 严格要求者	Token 预算有限者

四、社区真实反馈

Superpowers 的反馈

正面：

"Superpowers 把 Claude Code 从快速打字员变成了有纪律的工程伙伴"
"test coverage 从 0-30% 跳到 85-95%"
"Claude 写了代码没测试？Superpowers 自动删掉重来" — 不是建议，是强制执行

争议：

有人把 Superpowers 的 brainstorm 和 planning 技能嫁接到其他框架上，说明技能可拆分使用
Claude Opus 4.5 开始会在计划和规范中留 TBD，所以 v5.0 加了对抗性审查循环

OpenSpec 的反馈

正面：

"OpenSpec 解决 AI 编码助手最大的问题：写出来的不是你想要的"
"brownfield-first 策略很实用，不像其他工具只适合从零开始"
"5 分钟就能装好，上手极快"

争议（来自 Reddit 讨论）：

"规范会过时，你需要更新它们"
"规范用人类语言写，第 1 个规范和第 50 个规范可能互相矛盾"
"LLM 是非确定性的，你不可能永远强制执行规范"
有人提到德语词 "Verschlimmbesserung"（越改越糟）：我们是否在试图把事情变好时反而变糟了？

GSD 的反馈（Hacker News 460 分/251 评论）

正面：

"GSD 让 Claude Code 在整个项目期间保持峰值质量"
"结构化 AI 开发系统让交付周期快 40-60%"
"它不是魔法，只是非常好的上下文工程，包裹在一个不碍事的工作流里"

争议：

"Token 消耗是普通模式的 10 倍，没有明显的收益提升"
"最终我发现 Plan mode 就够了，我更喜欢自己引导 Claude Code"
"这些框架适合不想手动引导 Claude 的人，但我更喜欢掌控权"
"适合 fire-and-forget 任务，特别是涉及研究的任务"

五、怎么选？最终建议

场景 A：你追求代码质量，不想花时间返工

→ Superpowers

强制 TDD，代码质量有保障
测试覆盖率 85-95%
适合有工程素养的个人开发者

场景 B：你的项目已经有代码，需求经常变

→ OpenSpec

5 分钟上手，零学习成本
增量修改支持最好
规范即文档，Git 沉淀

场景 C：你想让 AI 跑几小时不管它

→ GSD

波次管理解决上下文腐烂
可中断恢复，灵活度高
并行执行效率高

场景 D：全都要

→ Superpowers + OpenSpec

OpenSpec 管需求（proposal → archive）
Superpowers 管纪律（brainstorm → TDD → review）
社区有现成的组合教程和 vk-workflow-kit 工具

六、参考文章（按工具分类）

本文档基于 2026 年 3 月 15+ 篇文章深度阅读整理，所有引用均来自公开资料。

Superpowers vs OpenSpec vs GSD 深度阅读总结 ​

一、三个工具各解决什么问题？ ​

Superpowers：解决"AI 太冲动" ​

OpenSpec：解决"AI 猜错需求" ​

GSD：解决"上下文腐烂" ​

二、三者的工作方式有何根本不同？ ​

Superpowers：纪律型（方法论驱动） ​

OpenSpec：契约型（规范驱动） ​

GSD：工程型（上下文工程驱动） ​

三、三者对比矩阵 ​

四、社区真实反馈 ​

Superpowers 的反馈 ​

OpenSpec 的反馈 ​

GSD 的反馈（Hacker News 460 分/251 评论） ​

五、怎么选？最终建议 ​

场景 A：你追求代码质量，不想花时间返工 ​

场景 B：你的项目已经有代码，需求经常变 ​

场景 C：你想让 AI 跑几小时不管它 ​

场景 D：全都要 ​

六、参考文章（按工具分类） ​

Superpowers ​

OpenSpec ​

GSD ​

Superpowers vs OpenSpec vs GSD 深度阅读总结

一、三个工具各解决什么问题？

Superpowers：解决"AI 太冲动"

OpenSpec：解决"AI 猜错需求"

GSD：解决"上下文腐烂"

二、三者的工作方式有何根本不同？

Superpowers：纪律型（方法论驱动）

OpenSpec：契约型（规范驱动）

GSD：工程型（上下文工程驱动）

三、三者对比矩阵

四、社区真实反馈

Superpowers 的反馈

OpenSpec 的反馈

GSD 的反馈（Hacker News 460 分/251 评论）

五、怎么选？最终建议

场景 A：你追求代码质量，不想花时间返工

场景 B：你的项目已经有代码，需求经常变

场景 C：你想让 AI 跑几小时不管它

场景 D：全都要

六、参考文章（按工具分类）

Superpowers

OpenSpec

GSD