GSD 完胜 OpenSpec 和 Superpowers？源码拆完发现：三者防御的是 context rot 的三道防线

封面图：context rot 三道防线

有一篇传播挺广的文章，结论是 GSD 完胜 OpenSpec 和 Superpowers，因为它从上下文腐烂层面解决问题。这个结论方向不算错，但读源码读得越细，越觉得这个完胜的叙事把三者的关系过度简化了。

它们不是同一条赛道上的三个选手。更准确的说法是：OpenSpec、Superpowers、GSD 解决的是 context rot 这同一个问题的三个不同症状阶段，存在递进关系。

把三者并列成 GSD 全流程 vs OpenSpec 规范层 vs Superpowers 工作流纪律，会让你误以为只能三选一。实际上很多团队是叠加用的。

这篇文章做的事很简单：对着源码把三个框架各自针对 context rot 的哪一层、用什么机制、付出了什么代价拆一遍。顺手纠正几个被反复转发的、和当前主分支对不上的数字。

1. 先把敌人看清楚：Context Rot 不是模型 bug

三个框架的共同前提，是 transformer 架构有个绕不开的物理限制。GSD 的官方文档 docs/explanation/context-engineering.md 给出的描述是目前看过最直白的：

模型不会报错，它只会慢慢变笨。这是最阴险的地方——你以为它还在正常工作，直到某个瞬间你发现它给出的代码已经偏离了会话开始时的约定。

GSD 文档列出了四种典型表现，这里直接引用：

模型开始和早期已确认的决策自相矛盾代码风格偏离会话开始时定下的约定计划开始忽略早已被埋在历史里的需求模型对 20 轮对话前还正确的文件名、函数签名产生幻觉

文档强调一句关键的话：这不是模型 bug，是 transformer attention 在长序列上的固有属性。

这条前提决定了三个框架的根本差异 - 它们对腐烂发生在哪个层面的诊断不同，所以开的药也不同。

三层防御关系图

图 1：三个框架分别防御 context rot 的三个不同症状层

2. OpenSpec：防的是 AI 该做什么的腐烂

OpenSpec 的诊断最窄，也最准。它认为 context rot 的第一个症状是：AI 把需求在长对话里搞漂移了。

README 里有一句话几乎等于它的产品定位：

解决方案也很直接 - 把需求从易腐烂的对话历史里搬到版本化的文件系统里。docs/overview.md 的原话是：

2.1 核心三件套：spec / change / delta

OpenSpec 的目录结构简洁到几乎是教科书级：

代码语言：markdown

复制

openspec/├── specs/← 当前真相（source of truth）│ └── auth/spec.md└── changes/← 进行中的变更（每个一个文件夹）└── add-2fa/├── proposal.md ← 为什么改、改什么├── design.md ← 怎么改├── tasks.md← 执行清单└── specs/← delta spec：只描述变化└── auth/spec.md

specs/ 是当前真相，changes/ 是进行中的变更。归档时 delta 会自动合并进 specs/，change 文件夹移到 changes/archive/YYYY-MM-DD-xxx/。

这套结构最聪明的设计不在目录本身，而在 delta。

2.2 Delta Spec：只描述变化，不重写

OpenSpec 最值得学的机制是 delta spec - 不重写整个规范，只写增量。三个固定区段：

代码语言：markdown

复制

## ADDED Requirements### Requirement: Two-Factor Authentication（新增的完整需求定义）## MODIFIED Requirements### Requirement: Session ExpirationPreviously: 30 minutes → 改为 15 分钟## REMOVED Requirements### Requirement: Remember MeDeprecated in favor of 2FA

为什么 delta 比完整重写强？docs/concepts.md 给了三条理由，条条都在点子上：

Clarity：审阅时只看 diff，不用脑补对比两份长文档的差异Conflict avoidance：两个 change 可以同时碰同一份 spec，只要改的是不同的 requirementBrownfield fit：适配现有项目，不用先把整个遗留系统文档化才能开始用

Brownfield fit 这条尤其关键。多数规范框架的门槛在于你得先把整个系统写规范才能上手，对存量项目基本是劝退。delta 允许你从一个 change 起步，边做边补。

2.3 OpenSpec 显式不做的事

这点参考文章判断是对的。OpenSpec README 里关于 context engineering 只有一句轻飘飘的 maintain good context hygiene throughout your session。

没有任何机制强制执行。

❌ 不管 context engineering - 它假设主对话能保持清醒❌ 不管执行过程 - apply 命令把任务交给 AI 自由发挥，没有原子提交、没有并行控制❌ 不管代码质量 - v1.x 加了 /opsx:verify，但它检查的是 spec 一致性，不是代码本身的好坏

OpenSpec 假设了一个相对干净、相对短的主对话。一旦对话变长，AI 脑子开始糊，spec 文件再规范，AI 读的时候也读偏。这就是它的天花板。

3. Superpowers：防的是 AI 怎么做事的腐烂

Superpowers 的诊断比 OpenSpec 宽一层。它认为 context rot 的第二个症状是：AI 在长对话里跳过 TDD、不做 code review、直接动手改代码——也就是流程纪律退化。

解决方案是一组自动触发的 skill，把好习惯变成条件反射，让模型想偷懒都不行。

3.1 自动触发机制：1% 可能性就要 invoke

触发规则写在 skills/using-superpowers/SKILL.md 里，话说得极硬：

注意是 before any response or action。连我需要先了解一下上下文这种借口都不行 - skill check 必须发生在 clarifying question 之前。

using-superpowers 里那张 Red Flags 表特别值得读，它其实就是防止模型自我开脱的心理防线：

Thought	Reality
This is just a simple question	Questions are tasks. Check for skills.
I need more context first	Skill check comes BEFORE clarifying questions.
The skill is overkill	Simple things become complex. Use it.
I remember this skill	Skills evolve. Read current version.

每一条都在堵模型可能用来跳过 skill的借口。这种设计只有真正见过模型偷懒的人才能写得出来。

3.2 不是 7 个 skill，是 14 个

参考文章和一些二次传播的博文只提了 Superpowers 的 7 步核心流程。实际上 skills/ 目录里有 14 个 skill，7 步只是 happy path 的子集：

测试：test-driven-development调试：systematic-debugging、verification-before-completion协作：brainstorming、writing-plans、executing-plans、dispatching-parallel-agents、requesting-code-review、receiving-code-review、using-git-worktrees、finishing-a-development-branch、subagent-driven-development元：writing-skills、using-superpowers

每个 skill 都是流程纪律的一个齿轮。TDD skill 强制先写测试再写代码；brainstorming 里有一段硬门禁，明确禁止在用户批准设计前动手：

这种硬门禁 GSD 也没有。GSD 有 plan-checker 但不强制 TDD。这是两个框架的哲学差异：Superpowers 信纪律内化为反射，GSD 信用结构隔离腐烂。

3.3 Superpowers 也玩 subagent，只是不如 GSD 结构化

参考文章说 Superpowers 不管上下文工程，这个论断部分错误。看源码就知道：

skills/subagent-driven-development/SKILL.md 写得很清楚：

skills/dispatching-parallel-agents/SKILL.md 也支持并行：

所以准确的说法是：

维度	Superpowers 的 subagent	GSD 的 subagent
触发方式	模型/用户 ad-hoc 判断	orchestrator 自动调度
依赖分析	没有，手动写 3 个 dispatch 调用	PLAN.md 声明，自动 wave 划分
并发协调	没有，靠模型自觉	STATE.md.lock 原子锁 per-wave hook
隔离目的	保留主会话上下文用于协调	从根上防止任务级腐烂

两者都隔离上下文，但定位不同。Superpowers 的隔离是战术性的（这个大任务派出去做，免得污染主会话）；GSD 的隔离是结构性的（默认所有任务都不在主会话发生）。

3.4 Superpowers 不管的事

❌ 不管跨会话状态 - 没有 .planning/ 这种持久化目录，/clear 之后必须从头加载❌ 不管结构化并行 - 并行是 ad-hoc 的❌ 不管 spec 演进 - brainstorming 产出的是 docs/superpowers/specs/ 下的设计文档，但没有 delta 合并机制

4. GSD：防的是 AI 脑子本身的腐烂

GSD 的诊断最深。它认为前面两个框架都在治标 - OpenSpec 防需求漂移、Superpowers 防流程退化。

但只要对话够长，AI 的脑子本身就会因为注意力稀释而变笨。spec 再清楚它也读偏，纪律再严它也执行不到位。

GSD 的解决方案是最激进的：不试图让 AI 在长对话里保持清醒，直接放弃长对话。

docs/explanation/context-engineering.md 的核心原话：

4.1 Orchestrator → Fresh-context Agent

每个 GSD workflow 的固定形状（来自 multi-agent-orchestration.md）：

代码语言：markdown

复制

Orchestrator (workflow .md file)│├── Load context (gsd-tools.cjs init <workflow>)├── Resolve model (gsd-tools.cjs resolve-model <agent-name>)├── Spawn specialised agent│ ├── Agent definition (agents/*.md)│ ├── Context payload (init JSON)│ ├── Model assignment│ └── Tool permissions├── Collect result└── Update state (gsd-tools.cjs state update)

关键设计是 orchestrator 故意做得很薄 - 文档原话是：

orchestrator 只负责路由。这样它的上下文增长很慢，即便发生腐烂，也只影响轻量级的路由层，不污染实际干活的地方。

4.2 34 个 Agent 的实际分工

参考文章整理过 agent 分类表，对照源码基本一致。但数字本身要纠一下：参考文章说 33 个 agent，实际 ls agents/ 是 34 个；说 86 个 command，实际 commands/gsd/ 是 70 个；说 142 项功能，实际 FEATURES.md 章节标题约 44 项核心（加 v1.27 扩展）。

这些数字大概率引自旧版本或二次传播时走样，不必纠缠。但写作时还是用源码实测数字更稳。

类别	Agent	并行模式
Researchers	project-researcher / phase-researcher / ui-researcher / advisor-researcher	4 路并行（stack/features/architecture/pitfalls）
Synthesiser	research-synthesizer	串行，等研究员完成
Planners	planner / roadmapper	串行
Checkers	plan-checker / integration-checker / ui-checker / nyquist-auditor	串行，最多 3 轮修订
Executor	executor	波次内并行，波次间串行
Verifier	verifier	串行
Mapper	codebase-mapper	4 路并行
Auditor	ui-auditor / security-auditor	串行

注意 executor 那一行：波次内并行，波次间串行。这就是 GSD 和 Superpowers 在并行调度上最核心的机制差异。

4.3 Wave Execution：结构化并行的核心

GSD 把任务按依赖关系分成多个 wave，同一 wave 内的任务并行执行，wave 之间串行等待：

代码语言：markdown

复制

Plan 01 (no deps) ─┐Plan 02 (no deps) ─┤── Wave 1 (parallel)Plan 03 (depends: 01) ─┤── Wave 2 (waits for Wave 1)Plan 04 (depends: 02) ─┘Plan 05 (depends: 03, 04) ─── Wave 3

Wave Execution 并行模型

图 2：GSD 的依赖波次调度模型——同一波次并行执行，波次之间串行等待

两个并发安全机制，都经过源码核对：

STATE.md.lock 原子锁 - 用 O_EXCL 创建，防止两个 agent 同时读改写状态文件导致数据丢失；过期锁（>10 秒）自动清理Per-wave hook run - 同一波次的 executor 都用 --no-verify 提交，跳过 pre-commit hook（避免 cargo lock 这类锁冲突），整个波次结束后 orchestrator 跑一次 hook

这两条是 Superpowers 没有的。Superpowers 的并行靠模型自觉，遇到 cargo lock 这种共享资源就只能赌运气。

4.4 .planning/：跨会话记忆

GSD 用文件系统做跨上下文的记忆。核心目录结构：

代码语言：markdown

复制

.planning/├── PROJECT.md # 项目愿景├── REQUIREMENTS.md# 分级需求（v1/v2/不做）├── ROADMAP.md # 阶段分解├── STATE.md # 当前位置（spine）├── config.json└── phases/└── {phase-name}/├── CONTEXT.md # 讨论阶段决策├── RESEARCH.md# 调研产出├── PLAN.md# 执行计划（XML 任务描述）├── SUMMARY.md # 执行结果└── VERIFICATION.md# 验证报告

STATE.md 是导航层，任何 workflow 启动第一步就是读它定位当前位置。

最巧妙的是 continue-here.md 机制 - 当 orchestrator 自己的上下文也快满时，把进度写到这个文件，下次开新会话从断点继续，orchestrator 又是全新的。

这种会话级断点续传是 Superpowers 没有的能力（OpenSpec 的 changes/archive/ 只持久化 spec 本身，不持久化"做到哪一步"的执行状态）。它让 GSD 可以横跨多个会话甚至多个工作日推进同一个项目。

4.5 GSD 自己承认的代价

GSD 文档没有把这套方案吹成银弹。multi-agent-orchestration.md 的 §Trade-offs 明确列了四项代价，写文章时必须诚实转述：

Coordination overhead - 每个 agent spawn 是一次往返（格式化 prompt、传上下文、等 1-5 分钟、解析结果），简单任务比单 agent 慢Opacity during execution - subagent 运行时对父会话不可见，没有实时进度流，调试困难Context stitching cost - 给每个 agent 装配正确上下文需要 orchestrator 自己花钱Model cost amplification - 5 个 Opus tier agent 并行比 1 个贵 5 倍（虽然有 model_profiles 让便宜 agent 干轻活）

正因为这些代价，GSD 自己提供了 /gsd-quick 和 /gsd-fast 两条跳过完整阶段循环的命令。context-engineering.md 自己说：

意思是：小任务别用 GSD 全套。这是 GSD 自己说的，不是反对者在诋毁它。

5. 三者对比：源码数字版

维度	OpenSpec	Superpowers	GSD
诊断的腐烂层	需求/契约腐烂	流程纪律腐烂	注意力本身腐烂
核心机制	spec / change / delta	14 个自动触发 skill	orchestrator fresh-context subagent
持久化	specs/ changes/	无跨会话状态	.planning/ STATE.md continue-here.md
并行调度	无	ad-hoc，模型自觉	wave execution 原子锁
硬门禁	无	brainstorming 设计批准、TDD	plan-checker 修订（不强制 TDD）
数字规模（源码实测）	5 个核心命令	14 个 skill	34 agent / 70 command / 95 workflow
学习成本	最低	中等	最高
适合项目规模	小到中	中	中到大

这张表传达的核心信息是：三个框架的强项几乎不重叠。实际项目里所以经常看到组合用法——OpenSpec 管 spec 演进，Superpowers 管执行纪律，GSD 管跨会话大项目。代价是维护成本叠加，三者在不同层面重复处理同一个根因。

6. 几处需要温和纠正的说法

写这一节不是要打脸参考文章，主要是源码数字和文章里的数字确实对不上，读源码的人会有困惑。

流传说法	源码核对
GSD 有 33 个专用 Agent	ls agents/ 实测 34 个
GSD 有 86 个命令	commands/gsd/ 实测 70 个
GSD 有 142 项功能	FEATURES.md 章节标题约 44 项核心 v1.27 扩展
Superpowers 不管上下文工程	部分错误 - subagent-driven-development 和 dispatching-parallel-agents 都讲 fresh context，只是不如 GSD 结构化
Superpowers 子 agent 串行无波次	准确，但 dispatching-parallel-agents 支持手动并行
Improve & Repeat 博客实测称 GSD 是唯一产出可用应用的框架	单一样本，不构成统计结论

最后一条多说两句。那篇博客的实测是有价值的，但它测的是用三个框架分别从零搭一个应用这种特定场景。

GSD 在这种从零开始 多文件 需要完整流程的场景下确实优势明显。但这不等于 GSD 在所有场景都比另外两个强 - 改一个 API、加一个按钮这种小活，GSD 自己都建议你用 /gsd-quick。

数字本身的偏差不关键，关键是从这些数字推导出的GSD 完胜叙事会误导选型。

7. 三个框架的理想用户画像

基于源码、而不是基于想象：

OpenSpec 的理想用户 - 你已经有完整的开发流程（自己的 TDD、自己的 code review、自己的 CI），只是缺一个和 AI 对需求的方式。OpenSpec 是最薄的一层，不侵入你现有的工作流。

你的痛点是 AI 改着改着就忘了最初要它做什么，不是 AI 脑子变笨。

Superpowers 的理想用户 - 你想要的是装上插件就能用的纪律。TDD、code review、worktree 这些好习惯你认同但经常偷懒不做，Superpowers 用自动触发强迫你做。你的痛点不在需求漂移这一层，而是 AI 一激动就跳过测试直接写代码，写完才发现方向错了。

GSD 的理想用户 - 你在做真的大型项目 - 多文件、多会话、跨天推进。你愿意接受仪式化流程和 5 倍的 model 成本，换取 AI 不会在第 5 个文件时开始腐烂。

你的痛点是前两个框架都解决不了的：注意力稀释。

大多数人不需要 GSD 的全部能力。这话不是我说的，是 GSD 自己文档里说的：

这句话挺诚实。GSD 的 95 个 workflow、34 个 agent，对绝大多数日常任务是过度工程。

但用到的那个十分之一 - 通常是 orchestrator fresh-context subagent .planning/ 持久化 - 确实解决了 AI 聊久了就变笨这个其他框架都碰不到的、也最让人头疼的问题。

总结

把三个框架放在一起看，能看出 AI 编程工具在 2025-2026 这一年的演进逻辑：大家在和同一个敌人打仗，只是防线设在不同纵深。

OpenSpec 把防线设在最外层，防需求从源头漂移。Superpowers 往里一层，管执行纪律在长对话里退化。GSD 最激进，直接防模型的注意力本身被噪声稀释。

三者不是替代关系，更像洋葱。你可以只用 OpenSpec 解决需求对齐；需求对齐搞定后，发现执行纪律还是飘，就再叠 Superpowers；如果连跨会话推进大项目都成问题，那再往上叠 GSD。叠得越多，防御越厚，但维护成本也越高。

选哪个（或叠哪几个），取决于你的 context rot 主要发生在哪一层。

如果你的 AI 主要症状是忘了最初要做什么，用 OpenSpec 就够了，不必上 GSD。如果连 AI 第 3 个文件就开始忘事都成了常态，那 GSD 确实是目前的唯一解——但要准备好为那个十分之一的能力，接受整套仪式化的代价。

参考文章的GSD 完胜叙事，方向上不算错 - GSD 的覆盖面确实最广。但把它理解成另外两个可以被 GSD 替代，就错过了 OpenSpec 的 delta spec 和 Superpowers 的 Red Flags 表里那些各自不可替代的设计。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！