克劳德代码两大工程化方案排行榜：超级能力与GSD深度测评推荐

2026-06-16阅读 0热度 0

Claude

这次要分析的两套框架，分别是 `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，涵盖了 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 的多智能体模式更接近“评估器-优化器”循环。主控会话的工作流程是：读取计划 → 拆解任务 → 分配实现智能体 → 回收结果 → 再分配审核智能体。实现智能体完成后，会经历两轮 review：第一轮是 spec compliance review，第二轮是 code quality review。发现问题则回退修改，再 review。这一模式的关键不在于智能体的数量，而在于主控保持干净，实现与搜索过程不污染主上下文，review 作为流程中的固定环节而非事后补丁。用团队协作打个比方：我先给你任务，你做完，我先检查是否偏离需求，再检查代码质量。

GSD：Wave 并行 + 多层验证

GSD 的执行并非“一个 controller 盯一个 implementer”，而是先做依赖分析，然后按 wave 分组，同一 wave 并行执行，wave 结束后统一进行验证。验证流水线包括：Plan Checker（执行前审查计划）、Executor Verify（执行中按 task 自带的 verify 进行）、Verifier（执行后反向验证 goals 是否真正交付）、UAT（人工确认）。此外还采用 `--no-verify` commit 避免并行时 hook 互相抢锁，wave 结束后统一跑 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 层会更有用。