Claude Code 的 Superpowers 插件：真正有效的结构化工作流

Superpowers 插件 在五个月内获得了 107,000 个 GitHub star。它有 8,600 个 fork。它于 2025年10月推出，已经成为 GitHub 上增长最快的开发者工具仓库之一。比大多数成熟框架更快。比大多数设计系统更快。比几乎所有没有大公司营销预算支持的东西都快。

superpower claude-code

这并非偶然。它发生在工具以有效的方式解决开发者问题时。

无纪律的 AI 编码是慢的。这就是问题所在。我知道这听起来 backwards。但我在构建 Ding 时艰难地学到了这一点。

Ding 是我长期以来一直相信的一个项目。它是一个无状态告警守护进程，我相信它在可观测性领域有很强的用例，我在那里工作了多年。总体思路是有吸引力且可靠的。执行一直是个挑战。

过去一年半我一直在构建我的宠物想法，解构它，然后用每一波新的 AI 代理从头重建它。每次有新的模型或工具发布，Ding 就成为我的测试。它很难。它需要架构决策、并发处理、配置设计。那种能暴露代理是思考还是只是打字快的东西。

代理一直在变得更好。但我从未见过任何东西能像 Superpowers 那样干净地构建 Ding。

没有工作流的 Claude 会在你第一个模糊描述上狂奔，自信地朝着错误的方向构建，让你陷入三小时的拆解中。速度和浪费都在扩展。

如果这个问题在团队层面听起来很熟悉： Builder.io 是一个代理开发平台，运行并行 AI 代理，内置结构化审查门控。云容器，无需本地设置，免费开始。如果你想让整个团队而不仅仅是个人 Claude Code 会话拥有这种纪律，值得一看。

Superpowers 修复了这一点。它是一个 Claude Code 插件，在编写任何代码之前强制执行结构化工作流。先头脑风暴。隔离你的分支。编写详细计划。然后执行。每一步都门控下一步。

以下是使用它的体验，以及它仍然存在的粗糙边缘。

---

Superpowers 插件如何工作

Superpowers 是由 Jesse Vincent 和 Prime Radiant 团队构建的 Claude Code 插件。它提供了一系列技能：带有指令、检查清单和流程图的 markdown 文件，Claude 在采取行动之前阅读。插件是容器。技能是它提供的工作流。

强制序列是四个步骤：

1. 头脑风暴：在有人类批准的设计文档之前不编写代码
2. Git worktree：隔离分支，这样 main 分支永远不会被触碰
3. 编写计划：将工作分解为 2-5 分钟任务的文档，包含确切的文件路径、确切的命令和完整代码
4. 执行：子代理实现每个任务；每个任务后两阶段审查

把它想象成雇佣承包商。其他所有 AI 编码工具都交给 Claude 一个模糊的简报和一套钥匙。Superpowers 是合同审查、蓝图签字和打卡清单。在任何人触碰墙壁之前。

在你安装它之前，你可能认为这听起来很慢。其实不然。原因如下。

---

为什么在编写代码之前头脑风暴阶段是强制的

头脑风暴阶段是强制的，因为它在实施开始之前解决重要的架构决策。规范锁定的每个决策（冷却行为、热重载语义、范围外边界）在纸上做出比在代码中撤销更便宜。这是防止最多返工的门控，也是最容易被忽视为开销的。

在 Ding v1 实现触及单个 Go 文件之前，头脑风暴会议产生了一份 424 行的规范文档。一份详细的设计，在实施开始之前解决了每个重要的架构决策。

其中三个决策如果在构建中期出错会很昂贵：

按标签集冷却，而不是按规则冷却。 规范锁定 cpu_spike 对 host=web-01 触发不会阻止它对 host=web-02 触发。这是多主机告警工具的正确行为。它也不是明显的第一个实现。没有规范，冷却追踪器几乎肯定会按规则键入，然后在第一个真正的多主机用例出现时需要重构。

stdout 内置通知器。 规范将 stdout 定义为你可以在规则中直接引用的特殊通知器名称，而无需在 notifiers: 映射中声明它。简单的决策，最小配置少六行，在设计文档中做出。没有它，计划会从开始搭建完整的 StdoutNotifier 声明。

热重载语义。 规范定义了在引擎交换之前正在进行的评估完成（交换时写锁，评估期间读锁）。做错这一点会产生一个几乎不可能重现和调试的数据竞争。它在规范中正确决定，在第一次通过时正确实现。

头脑风暴还产生了一个清晰的范围外列表：复合条件（AND、OR）、原生 PagerDuty 支持、失败 webhook 的重试逻辑。每次在执行过程中出现”添加…会很自然”的冲动时，答案就在规范中。无需讨论，无漂移。

这些问题感觉慢。它们让三天的工作保持在正轨上。

---

Superpowers 计划包含什么

Superpowers 计划包含完整、可运行的代码。没有伪代码。每个任务指定确切的文件路径、终端命令、完整的失败测试、最小实现和 git 提交消息。计划足够详细，没有项目背景的人也能正确实现它。

大多数计划都很模糊。“向配置解析器添加验证”可能意味着十几种不同的事情。

Superpowers 计划格式不同。编写计划技能产生带有完整代码的计划。对于 Ding v1 配置验证任务，计划包含完整的失败测试：

func TestConfig_UnknownNotifier(t *testing.T) {
    cfg := &Config{...}
    err := cfg.Validate()
    assert.ErrorContains(t, err, `rule "cpu_spike": alert references unknown notifier "nonexistent"`)
}

连同确切的 go test 命令、预期输出（“FAIL — Validate not defined”）、完整的 Validate() 实现、验证它通过的命令和 git 提交消息。

v1 计划涵盖了整个项目的 17 个文件，在顶部的文件表中映射，准确显示每个文件负责什么。实现产生了 26 个顺序提交，每个对应一个计划任务。

这种具体的计划也是可审查的。计划编写后，规范合规子代理审查了它，发现 BenchmarkEngineSwap 与规范的 EngineReinit 术语不匹配。一个会在产生混乱基准结果之前被修复的命名不一致。在执行开始之前修复。

计划应该足够详细，你可以把它交给没有项目背景的人并得到正确的输出。模糊的指令会变成 bug。

---

Superpowers 插件的局限性

Superpowers 插件有两个主要局限性：它无法处理环境调试（无法提前计划的特定平台问题），以及计划继承规范错误。如果设计文档错误，计划会在同一方向上错误。两者都需要在工作流之外解决。

工作流是为功能开发构建的。环境救火超出其范围。

环境调试不在计划中。 Ding 基准套件是为通用 Unix 环境计划的。在 macOS 上运行它触发了初始实现后的 10 个单独修复提交：

• date +%s%N 在 macOS BSD date 上不存在。每个延迟和启动脚本都使用纳秒时间戳。它们都需要一个可移植的 ns_now() 函数。
• eval "$start_cmd" & 后跟 kill $! 在 bash 保持子 shell 包装器时无法可靠地杀死目标。$! 是子 shell 的 PID，不是 Ding 的 PID。Ding 作为孤儿继续运行，持有端口，导致下一次启动尝试失败。通过添加 pkill -9 -f "ding serve" 来捕获孤儿进程来修复。
• docker run -d 在 stdout 上返回容器 ID，但 $! 是 docker CLI 进程的 PID。十个连续的 Prometheus 容器启动失败，因为第一个容器从未停止。

这些都无法提前计划。macOS shell 行为不是你可以从规范中推理的东西。调试本质上是迭代的：运行、观察失败、形成假设、测试它、发现不同的失败。

当环境与你对抗时，走出计划工作流。修复环境。然后回来。计划用于构建功能。在工作流之外修复环境，然后返回。

计划继承规范错误。 计划是从规范生成的。如果规范错误，计划会在同一方式上错误。

基准规范是从阅读 Ding 文档和示例配置编写的。示例配置中的配置看起来像这样：

rules:
  - name: high_cpu
    metric: cpu_usage
    condition: value > 95
    alert:
      type: webhook
      url: http://localhost:9998/

但实际的配置解析器需要一个单独的 notifiers: 映射：

notifiers:
  bench-wh:
    type: webhook
    url: http://localhost:9998/
 
rules:
  - name: high_cpu
    metric: cpu_usage
    condition: value > 95
    alert:
      - notifier: bench-wh

每个基准脚本都在同一方式上错误。当测试运行时，所有 100 个延迟样本都超时了，因为 Ding 在启动时拒绝了配置。规范合规审查在某人注意到测试失败后才标记它。

在与现有代码交互之前，对规范进行快速健全性检查。直接阅读验证函数——它们捕获示例文件跳过的东西。

---

使用 Superpowers 之前你应该知道什么

在使用 Superpowers 之前，内化三个不可协商的事项：规范是所有决策的真相来源，每个计划任务在实施代码之前需要一个失败测试，任务复选框是你的会话恢复机制。跳过其中任何一个都会破坏工作流防止漂移和返工的能力。

规范是后续一切的真相来源。 每个”这对吗？“问题都通过阅读规范来解决。当 Ding v1 期间范围蔓延出现时（“在这里添加 AND 条件会很自然”），答案是立即的：复合条件列在”范围外（v1）“下。无需讨论。无漂移。

计划需要在代码之前先有测试。 编写计划技能围绕 TDD 构建：编写失败测试，验证它失败，编写最小实现，验证它通过，提交。这个顺序很重要。当你阅读技能生成的计划时，检查每个任务在实施步骤之前是否有测试步骤。如果没有，计划不完整。

在执行时勾选任务。 计划文档是你的会话死亡时的恢复机制。（更多关于 Claude Code 会话管理的内容见 50 个 Claude Code 技巧和最佳实践。）计划为每个步骤都有复选框。标记它们是状态日志，不是形式。在 Ding 工作中，git 提交日志起到了这个功能，因为每个完成的任务在会话结束之前都已提交。但在任务部分完成时会话死亡的会话中，计划中未勾选的复选框是下一个会话知道在哪里恢复的唯一方式。

---

Superpowers 的核心模型

Superpowers 是一个纪律执行插件。它强制执行流程严谨性。它通过防止昂贵错误并使工作可恢复、可审查和可纠正来使整体流程更快。

三个硬门控：

你不能构建尚未设计的东西。 头脑风暴门控是硬的。跳过它，你会实现错误的东西。在 Ding 项目中，头脑风暴在实施开始之前决定了按标签集冷却、热重载互斥语义和 stdout 内置通知器。在实施中期做错这些需要大量返工。

你不能执行尚未计划的东西。 计划门控是硬的。跳过它，子代理会漂移。Ding v1 计划指定了 17 个文件和 26 个任务。基准计划指定了 13 个文件和 22 个任务。子代理毫无歧义地遵循这些计划。

你不能发布尚未审查的东西。 审查门控是硬的。跳过它，bug 会溜过。规范合规审查在基准脚本中捕获了配置格式错误，在它成为数小时调试谜团之前。

系统对其差距是诚实的。环境调试、灾难性中断的会话恢复，以及通过审查的规范错误，因为规范本身对代码行为的理解是错误的。走出去，修复问题，回来。工作流为你保留位置。

---

开始使用 Superpowers

/plugin install superpowers@claude-plugins-official

开始一个新的 Claude Code 会话。描述你想构建的东西。不要尝试手动触发技能。它们自动激活。如果你想验证安装，说”我想为这个项目构建一个新功能”，观察头脑风暴技能在 Claude 询问澄清问题之前激活。

在 GitHub 上找到 Ding 项目——规范、计划和基准结果都在仓库中。

• 源码： github.com/obra/superpowers (MIT)
• Discord： discord.gg/Jd8Vphy9jq
• 构建者： Jesse Vincent 和 Prime Radiant 团队

在 Builder.io，我们一直在 Fusion 内部构建类似的结构化工作流。规范优先的工作流是快速 AI 开发与昂贵返工的区别。如果你正在尝试 Superpowers 或结构化 Claude Code 工作流，我很乐意听听进展如何。

---

原文链接：https://www.builder.io/blog/claude-code-superpowers-plugin