最近有篇文章影响不小，核心观点是GSD完胜OpenSpec和Superpowers，理由是从根源上解决了上下文腐烂问题。这个判断方向没错，但老实说，当你顺着源码把三个框架的细节都啃一遍之后，就会发现“完胜”这个词，把三者之间的关系想得过于简单了。
它们根本不是同一条赛道上的选手。更准确地说，OpenSpec、Superpowers和GSD解决的是“上下文腐烂”这同一个病症的三个不同阶段。这更像是一种递进关系，而不是谁替代谁的零和博弈。
如果你把这三种方案并列，当成是GSD全流程 vs. OpenSpec规范层 vs. Superpowers工作流纪律，很容易掉入“只能选一个”的陷阱。而现实是，很多团队会根据自己的痛点，把它们叠加起来使用。
这篇文章要做的事很直接：翻开源码，看看这三个框架各自针对上下文腐烂的哪一层、用了什么机制、付出了什么代价。顺便，修正几个被反复引用但跟当前主分支对不上号的数字。
1. 先把敌人看清楚：Context Rot 不是模型 bug
这三个框架之所以能摆在同一个桌面上讨论，是因为它们都直面Transformer架构一个无法回避的物理限制。GSD官方文档里 docs/explanation/context-engineering.md 的描述，是我见过最直白的一种：
模型不会给你报错，它只会慢慢变笨。这才是最阴险的地方——你以为它还在正常工作，直到某个瞬间，你突然发现它产出的代码，已经和会话开始时约定好的东西完全不是一回事了。
GSD文档列出了四种典型表现，这里直接引用：
- 模型开始和早期已经确认的决策自相矛盾
- 代码风格偏离会话开始时定下的约定
- 计划开始忽略早已被埋在历史里的需求
- 模型对20轮对话前还正确的文件名、函数签名产生幻觉
文档里有一句关键的话：这不是模型的bug，是Transformer的注意力机制在长序列上的固有属性。
这个前提，决定了三个框架的根本差异。因为对“腐烂发生在哪一层”的诊断不同，它们开的药方自然也不同。
图1：三个框架分别防御context rot的三个不同症状层
2. OpenSpec：防的是“AI该做什么”的腐烂
OpenSpec的诊断最窄，但也最准。它认为上下文腐烂的第一个症状是：AI在长对话里把需求搞漂移了。
它的README里有一句话，几乎就是它的产品定位：
AI has an unfortunate tendency to drift from the spec in long conversations.
解决方案也很直接——把需求从容易腐烂的对话历史中搬出来，放到版本化的文件系统里。docs/overview.md 的原话是：
By keeping the specification in a version-controlled directory, we ensure the AI always reads the latest agreement, not an interpretation of a conversation from forty messages ago.
2.1 核心三件套：spec / change / delta
OpenSpec的目录结构简洁到堪称教科书级别：
openspec/
├── specs/
│ └── auth/spec.md
└── changes/
└── add-2fa/
├── proposal.md
├── design.md
├── tasks.md
└── specs/
└── auth/spec.md
specs/ 是当前的事实标准，changes/ 用于存放进行中的变更。归档时，delta 会自动合并进 specs/，而 change 文件夹则被移到 changes/archive/YYYY-MM-DD-xxx/。
这套结构最聪明的点，不在于目录本身，而在于那个“delta”。
2.2 Delta Spec：只描述变化，不重写
OpenSpec最值得学习的机制是delta spec——不重写整个规范，只写增量。它有三个固定的区段：
## ADDED Requirements
### Requirement: Two-Factor Authentication（新增的完整需求定义）
## MODIFIED Requirements
### Requirement: Session Expiration
Previously: 30 minutes → 改为 15 分钟
## REMOVED Requirements
### Requirement: Remember Me
Deprecated in fa vor of 2FA
为什么delta比完整重写强？docs/concepts.md 给了三条理由，每条都切中要害：
- 清晰度：审阅时只看diff，不用脑补对比两份长文档的差异。
- 避免冲突：两个change可以同时修改同一份spec，只要改的是不同的requirement。
- 适配存量项目：不用先把整个遗留系统文档化就能直接用，门槛低。
最后这点特别关键。很多规范框架的门槛在于，得先把整个系统写成规范才能上手，对存量项目基本是劝退。而delta允许你从一个change起步，边做边补。
2.3 OpenSpec 显式不做的事
那篇参考文章在这个问题上的判断是对的。OpenSpec的README里关于上下文工程，只有一句轻飘飘的 maintain good context hygiene throughout your session。
没有任何机制强制执行。
- 它不管上下文工程——它假设主对话能保持清醒。
- 它不管执行过程——
apply命令把任务交给AI自由发挥，没有原子提交，没有并行控制。 - 它不管代码质量——v1.x 虽然加了
/opsx:verify，但检查的是spec一致性，不是代码本身的好坏。
OpenSpec假设了一个相对干净、相对短的主对话。一旦对话变长，AI脑子开始糊，spec文件再规范，AI在读的时候也会读偏。这就是它的天花板。
3. Superpowers：防的是“AI怎么做”的腐烂
Superpowers的诊断比OpenSpec宽一层。它认为上下文腐烂的第二个症状是：AI在长对话里跳过TDD、不做code review、直接动手改代码——也就是流程纪律的退化。
解决方案是一组能自动触发的skill，把好习惯变成条件反射，让模型想偷懒都不行。
3.1 自动触发机制：1% 可能性就要 invoke
触发规则写在 skills/using-superpowers/SKILL.md 里，话说得极硬：
A skill check must occur before any response or action. If you think there is more than 1% chance a skill may be relevant, you MUST invoke it.
注意，是“在任何回应或行动之前”。连“我需要先了解一下上下文”这种借口都不行——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 里有一段硬门禁，明确禁止在用户批准设计前动手：
Do NOT begin writing code until the user has approved the design plan and given explicit permission to proceed.
这种硬门禁，GSD也没有。GSD有plan-checker，但不强制TDD。这是两个框架的哲学差异：Superpowers相信纪律内化为反射，GSD相信结构隔离腐烂。
3.3 Superpowers 也玩 subagent，只是不如 GSD 结构化
参考文章说Superpowers不管上下文工程，这个论断部分错误。看源码就知道：
skills/subagent-driven-development/SKILL.md 写得很清楚：
If a task can benefit from a fresh context, dispatch a sub-agent to work in isolation.
skills/dispatching-parallel-agents/SKILL.md 也支持并行：
For independent chunks of work, dispatch multiple agents in parallel to sa ve time.
所以准确的说法是：
| 维度 | Superpowers 的 subagent | GSD 的 subagent |
|---|---|---|
| 触发方式 | 模型/用户 ad-hoc 判断 | orchestrator 自动调度 |
| 依赖分析 | 没有，手动写3个dispatch调用 | PLAN.md 声明，自动wa ve划分 |
| 并发协调 | 没有，靠模型自觉 | STATE.md.lock 原子锁 & per-wa ve 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 的核心原话：
You minimize context rot by never ha ving a long conversation in the first place.
4.1 Orchestrator → Fresh-context Agent
每个GSD workflow的固定形状（来自 multi-agent-orchestration.md）：
Orchestrator (workflow .md file)
│
├── Load context (gsd-tools.cjs init )
├── Resolve model (gsd-tools.cjs resolve-model )
├── 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故意做得很薄——文档原话是：
The orchestrator is a lightweight router. It does not execute work.
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 Wa ve Execution：结构化并行的核心
GSD把任务按依赖关系分成多个wa ve，同一wa ve内的任务并行执行，wa ve之间串行等待：
Plan 01 (no deps) ─┐
Plan 02 (no deps) ─┤── Wa ve 1 (parallel)
Plan 03 (depends: 01) ─┤── Wa ve 2 (waits for Wa ve 1)
Plan 04 (depends: 02) ─┘
Plan 05 (depends: 03, 04) ─── Wa ve 3
图2：GSD的依赖波次调度模型——同一波次并行执行，波次之间串行等待
两个并发安全机制，都经过源码核对：
STATE.md.lock原子锁——用O_EXCL创建，防止两个agent同时读写状态文件导致数据丢失；过期锁（>10秒）自动清理。- Per-wa ve hook run——同一波次的executor都用
--no-verify提交，跳过pre-commit hook（避免cargo.lock这类锁冲突），整个波次结束后orchestrator跑一次hook。
这两条是Superpowers没有的。Superpowers的并行靠模型自觉，遇到cargo.lock这种共享资源就只能赌运气。
4.4 .planning/：跨会话记忆
GSD用文件系统做跨上下文的记忆。核心目录结构：
.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 明确列了四项代价，写文章时必须诚实转述：
- 协调开销——每个agent spawn是一次往返（格式化prompt、传上下文、等1-5分钟、解析结果），简单任务比单agent慢。
- 执行不透明——subagent运行时对父会话不可见，没有实时进度流，调试困难。
- 上下文拼接成本——给每个agent装配正确上下文需要orchestrator自己消耗token。
- 模型成本放大——5个Opus tier agent并行比1个贵5倍（虽然有
model_profiles让便宜agent干轻活）。
正因为这些代价，GSD自己提供了 /gsd-quick 和 /gsd-fast 两条跳过完整阶段循环的命令。context-engineering.md 自己说：
For simple, well-understood tasks, don't use the full GSD suite. Use
/gsd-quickand move on.
意思是：小任务别用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，模型自觉 | wa ve 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自己文档里说的：
Most users will only need about 10% of what GSD offers.
这句话挺诚实。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表里那些各自不可替代的设计。
