这次要研究的两个框架，分别是 `obra/superpowers` 和 `gsd-build/get-shit-done`。它们都在为 Claude Code 注入技能体系、工作流程与多智能体协作能力，但实现路径截然不同。 简单来说，Superpowers 倾向于将工程纪律内嵌到会话当中，而 GSD 则把交付过程构建为一套完整的运行时系统。 先看各自的定位。Superpowers 的口号是“你的编程智能体拥有了超能力”，GSD 则更直接：“没有企业角色扮演的废话，只管把事做成。” 翻译成工程技术语言： - Superpowers 是一套可组合的 Skill 库，旨在将工程纪律注入 Claude Code - GSD 是一套结合 Meta-Prompting、CLI 与状态机的工程流水线 口号只是表面，真正的差异在设计重心上。Superpowers 偏向 skill-first、prompt-first、行为约束优先；GSD 偏向 workflow-first、runtime-first、状态与工具优先。

1. 系统形态

Superpowers：轻量级的 skill 系统

Superpowers 的结构非常精简：一个 `skills/` 目录，一个 `hooks/session-start` 钩子，外加少量的 `commands/` 和 `agents/`。核心动作是在 SessionStart Hook 里把 `using-superpowers` 这个入口 skill 注入会话，然后由这个入口 skill 去路由到不同的子 skill，例如 brainstorming、writing-plans、test-driven-development、systematic-debugging、subagent-driven-development、verification-before-completion。流程控制权基本写在 skill 文本中，机制上主要还是 skill + hook。

GSD：带状态的 workflow 系统

GSD 可以拆成多个层级：Command Layer（50 个用户入口命令）、Workflow Layer（50 个工作流定义）、Agent Layer（不同角色的智能体）、CLI Tools Layer（`gsd-tools.cjs`、`install.js`），以及 File System State（`.planning/` 目录）。这意味着 GSD 不只是把规则写在 prompt 里，而是将大量确定性逻辑放进了工具层——比如初始化上下文、模型选择、状态更新、模板填充、配置读取、安全验证。 总结一下区别：Superpowers 主要靠 Skill 文本和 Hook 约束行为，GSD 已经把一部分行为直接做成了 CLI 和状态系统。

2. 上下文怎么组织

两套系统都在处理同一个问题：如何把正确的信息，在正确的时机，交给正确的智能体。

Superpowers 的做法：Lazy Loading

Superpowers 的策略比较“省”：常驻层尽量精简，高层规则先放在 `using-superpowers` 里，需要某个 skill 时再按需读取对应的 `SKILL.md`。这里有个细节：它对 YAML frontmatter 里的 `description` 写法要求非常严格，目的是避免模型只看一眼描述就跳过完整 skill。整体策略可以概括为三句话——少给、迟给、只在要用的时候给。

GSD：结构化注入 + 分层传播

GSD 的思路正好相反。它会先思考：当前 workflow 需要什么上下文？当前 phase 需要什么上下文？哪些文件要传给 planner，哪些要传给 verifier？哪些状态要对所有智能体可见？它的上下文链路包括 `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md`、`CONTEXT.md`、`RESEARCH.md`、`PLAN.md` 等，不同角色拿到的内容各不相同。再加上 XML 结构化的 task 定义、JSON 初始化的上下文包，它实际上是把上下文从自然语言对话，变成了可注入、可分发、可追踪的结构化材料。 所以这一层的区别很清晰：Superpowers 在做按需加载，GSD 在做结构化注入。一个偏轻，一个偏重；一个优先控制会话负担，一个优先控制状态传播。

3. 多 Agent 怎么调度

Superpowers：Controller → Implementer → Reviewer

Superpowers 的多智能体模式更接近“评估器-优化器”循环。主控会话做的事情是：读 plan → 抽任务 → 派发实现智能体 → 回收结果 → 再派发 reviewer。实现智能体先做完，再过两轮 review：第一轮 spec compliance review，第二轮 code quality review。有问题就回去修复，再 review。这个模式看的不是智能体数量，而是主控保持干净，实现和搜索过程不污染主上下文，review 是流程中的固定环节而不是最后补一下。用团队协作打个比方：我先给你任务，你执行，我先看你有没有偏离需求，再看代码质量。

GSD：Wa ve 并行 + 多层验证

GSD 的执行不是“一个 controller 盯一个 implementer”，而是先做依赖分析，再按 wa ve 分组，同一 wa ve 并行执行，wa ve 结束后统一过验证。验证管线包括：Plan Checker（执行前看计划）、Executor Verify（执行中按 task 自带的 verify）、Verifier（执行后反推 goals 是否真的交付）、UAT（人工确认）。再加上 `--no-verify` commit 避免并行时 hook 互相抢锁，wa ve 结束后统一跑 pre-commit，`STATE.md` 更新带文件锁，以及 Node Repair 自动重试。这里处理的已经不是“多叫几个智能体一起干活”，而是并行系统的协调成本。 所以多 Agent 在两边不是同一个概念：Superpowers 是 review-driven 的多 Agent，GSD 是 pipeline-driven 的多 Agent。

4. 质量怎么兜底

Superpowers：TDD 放在前面

Superpowers 把 TDD 放得非常靠前。它不是“建议你写测试”，而是直接把 TDD 写成铁律。而且不是口号式的，连常见借口都预判好了：太简单不需要测试、先写代码再补测试、这是 UI 不好测、赶时间……还有一条更严格的要求：如果你已经先写了代码，再想起要 TDD，正确动作是删掉已写的代码，从测试开始。你可以不喜欢这套要求，但方向很清楚。

GSD 的质量保障是多层自动验证

GSD 没有把 TDD 当铁律。它更像是在构建一层又一层的验证面：plan 先检查，task 执行时自带 verify，phase 结束后再有 verifier，还要 UAT。再加上 Nyquist Validation、`gsd-nyquist-auditor`、Node Repair、`gsd-debugger`。它要解决的问题也很直接：如果智能体不是严格按 TDD 走，系统还能靠什么办法兜住质量。 所以两边的差异是：Superpowers 把质量前置到每一步，GSD 把质量铺成一条多层验证管线。一个更“严”，一个更“厚”。

5. 状态存在哪里

Superpowers 基本是无持久状态的

Superpowers 当然不是完全没有状态——它有当前上下文窗口、git 历史、spec 和 plan 文档。但它没有一套像 `.planning/STATE.md` 这样的统一状态机。连续性更依赖当前对话、git 和文档文件。好处是系统简单，没有状态同步问题，没有状态损坏和恢复复杂度。代价是长任务的 pause/resume 没那么强，跨 session 的连续性主要靠外部文档。

GSD：把状态做成文件系统里的活态记忆

GSD 在这件事上走得非常彻底。`.planning/` 那棵目录树就是这套系统的心脏：`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md`、`HANDOFF.json`、`config.json`、`phases/`、`research/`、`debug/`、`threads/`……尤其是 `STATE.md` 和 `HANDOFF.json`。这套状态层解决了：当前做到哪了，做过什么决策，卡在哪，下一轮怎么接着干。 这一组对比可以归结为：Superpowers 更偏向“无持久状态的工程纪律系统”，GSD 更偏向“带持久化状态机的交付系统”。这不是表层差异，而是系统边界的差异。

6. Hook、配置和安全

Hooks

Superpowers 的 hook 比较克制，主要动作还是 SessionStart：把入口 skill 注入会话。GSD 则已经把 hook 用成了一层功能面：`statusline`、`context-monitor`、`check-update`、`prompt-guard`、`workflow-guard`。尤其是 `context-monitor` 和 `prompt-guard`，这已经不是补一点提示词，而是在做运行时防护和可观测性。

配置

Superpowers 基本是零配置取向，主要行为定义都在 skill 文本里。GSD 则已经有完整的配置矩阵：per-agent 模型配置、workflow 开关、discuss mode、parallelization、git branching strategy、全局 defaults。这说明它已经把“工作流怎么跑”当成系统配置问题来处理。

安全

Superpowers 的安全更多还是依赖 skill 约束和最小权限原则。GSD 则已经明显做成了多层防御：路径遍历防护、prompt injection 检测、shell 参数清洗、安全 JSON 解析、CI 里的注入扫描。这三块放在一起看，GSD 更像一个完整系统，Superpowers 这边则是轻、可组合、低摩擦。

怎么选

做选型时，可以先记住这两句话：Superpowers 是工程纪律优先，GSD 是端到端自动化优先。 如果你平时更接近这种方式——已有代码库、增量开发、很在乎 TDD、想让智能体更守规矩、不想引入太重的系统——那 Superpowers 用起来会更顺手。 如果你更接近这种方式——新项目多、想把从 idea 到 QA 的链路系统化、需要持久状态、需要跨 session 连续性、需要并行和多阶段调度——那 GSD 可能更适合你。 最后可以压成这条边界：Superpowers 主要解决会话内的工程纪律，GSD 主要解决跨阶段的交付组织。如果你手里已经有代码库，想先把智能体的行为拉回规范，Superpowers 更容易接进去。如果你要的是从需求、计划、执行、验证到交付的一整条链路，GSD 的状态层和 workflow 层会更有用。