编程 Superpowers 深度拆解：123K Star 的 AI 编程工作流引擎，如何用流程约束让 AI 从写代码的猴子变成做工程的搭档

2026-05-03 11:57:40 +0800 CST views 5

Superpowers 深度拆解：123K Star 的 AI 编程工作流引擎，如何用「流程约束」让 AI 从「写代码的猴子」变成「做工程的搭档」

当你让 AI 写代码，它刷刷刷一顿输出，跑起来发现这也没考虑、那也有 bug——然后你回头收拾烂摊子。这不是 AI 不行，是你没给它装上「工程大脑」。Superpowers 用 15 个可组合的技能、一套强制工作流管道和 subagent 驱动架构，把 Claude Code 从「代码生成器」训练成「软件工程师」。本文从架构设计到代码实战，逐层拆解这个 GitHub 123K Star 的现象级项目。

一、为什么 AI 编程助手需要「上工程课」

1.1 从「能写代码」到「会做工程」的鸿沟

2025 年底到 2026 年初，AI 编程助手的能力已经发生了质变。Claude Code、Cursor、Copilot、Gemini CLI 这些工具，让一个中级程序员的生产力翻了 3-5 倍——前提是，你知道怎么用它们。

但现实往往是这样的：

你：帮我给这个 API 加个缓存
AI：好的，我直接在 controller 里加个 Redis 缓存...
[5 分钟后]
你：等等，你没做缓存失效策略？没考虑并发？没写测试？
AI：抱歉，我来补一下...
[又 5 分钟后]
你：这测试也太空了吧，缓存击穿场景呢？
AI：我再改改...

问题出在哪？大模型有足够的能力写出好代码，但它缺乏工程纪律。它倾向于：

直接动手：收到需求不澄清，上来就写代码
跳过测试：先实现再说，测试是「可选的」
忽略设计：不考虑架构，直接堆代码
自我合理化：「为了节省时间我直接实现了」、「这个场景不太可能发生」

这些行为不是 bug，而是大模型的默认工作模式——它被训练来「快速给出答案」，而不是「按流程交付工程」。

1.2 提示词工程的困境

传统做法是用精心设计的提示词来约束 AI：

## 开发规范
- 先写测试，再写实现
- 遵循 TDD 的 RED-GREEN-REFACTOR 循环
- 不要跳过设计阶段
- 提交前做代码审查

问题是：

不可复用：每个项目都要重新写一遍提示词
不可组合：提示词之间没有结构化关系，容易冲突
不可验证：你不知道 AI 是真的遵守了规则，还是嘴上说遵守
上下文衰减：对话越长，AI 越容易「忘记」最初的约束

1.3 Superpowers 的核心洞察：Process over Prompt

Superpowers 的核心理念只有一句话：

Process over Prompt — 流程大于提示词

它不是给你一个更好的提示词模板，而是给 AI 装上一套可组合的工程工作流引擎。关键区别在于：

维度	传统提示词	Superpowers
约束方式	文本建议	强制门控
复用性	复制粘贴	技能组合
验证	人工检查	自动审查
流程	隐含在提示词中	显式定义在技能中
上下文管理	靠模型自觉	subagent 隔离

二、Superpowers 全景：从一句话需求到可审计交付

2.1 它是什么，它不是什么

它是什么：

一套零运行时依赖的指令架构（核心全部由 Markdown + Shell 构成）
一个可组合的技能引擎，15 个技能覆盖开发全生命周期
一个跨平台工作流框架，支持 Claude Code、Cursor、Copilot、Gemini CLI、Codex、OpenCode
一个 subagent 驱动的工程流水线

它不是什么：

不是新的 IDE
不是新的模型
不是单纯的提示词模板
不是一个代码生成插件

它更接近于：一层覆盖在 AI 编码助手之上的「工程管理系统」。

2.2 五层架构总览

Superpowers 的架构可以分为五层，从下到上：

┌─────────────────────────────────────────────┐
│  第五层：测试基础设施                         │
│  把提示词工程当代码来测                       │
├─────────────────────────────────────────────┤
│  第四层：Agent 定义                          │
│  可复用的角色（code-reviewer 等）              │
├─────────────────────────────────────────────┤
│  第三层：开发工作流管道                        │
│  brainstorm → plan → subagent → TDD → review │
├─────────────────────────────────────────────┤
│  第二层：技能引擎                             │
│  SKILL.md + 刚性/弹性分类 + 工具映射           │
├─────────────────────────────────────────────┤
│  第一层：平台适配与会话注入                    │
│  SessionStart Hook + 备选注入路径              │
└─────────────────────────────────────────────┘

接下来我们逐层拆解。

三、第一层：平台适配与会话注入——如何让每个平台都「听话」

3.1 核心问题

Superpowers 的野心是「全平台统一行为」，但现实世界各 AI IDE/CLI 的插件体系完全不同：

Claude Code 有 Hook 系统
Cursor 有插件市场
Copilot CLI 有扩展机制
Gemini CLI 有 @-include
Codex 有技能发现

Superpowers 需要在所有这些平台上，每次新会话开始时，自动注入 using-superpowers 这个总控技能。

3.2 SessionStart Hook：最关键的入口

SessionStart 是最核心的注入时机，它在以下场景触发：

新开一个 AI 会话
执行 /clear 或 /compact 等重置上下文的指令

钩子脚本 hooks/session-start 的工作流程：

#!/bin/bash
# 简化的 session-start 逻辑

# 1. 读取 using-superpowers 技能内容
SKILL_CONTENT=$(cat skills/using-superpowers/SKILL.md)

# 2. 检测当前平台
if [ -n "$CURSOR_PLUGIN_ROOT" ]; then
    # Cursor 平台
    echo "{\"additional_context\": \"$SKILL_CONTENT\"}"
elif [ -n "$CLAUDE_PLUGIN_ROOT" ] && [ -z "$COPILOT_CLI" ]; then
    # Claude Code 平台
    echo "{\"hookSpecificOutput\": {\"additionalContext\": \"$SKILL_CONTENT\"}}"
else
    # Copilot / 其他平台
    echo "{\"additionalContext\": \"$SKILL_CONTENT\"}"
fi

不同平台的输出格式：

平台	环境变量检测	输出 JSON 字段
Cursor	`CURSOR_PLUGIN_ROOT`	`{ "additional_context": "..." }`
Claude Code	`CLAUDE_PLUGIN_ROOT` 且非 `COPILOT_CLI`	`{ "hookSpecificOutput": { "additionalContext": "..." } }`
Copilot/其他	`COPILOT_CLI` 或默认	`{ "additionalContext": "..." }`

钩子配置通过 hooks/hooks.json 和 hooks/hooks-cursor.json 分别注册。

3.3 备选注入路径

有些平台不支持 Session Hook，Superpowers 为它们准备了替代方案：

Gemini CLI — 通过 GEMINI.md 中的 @-include 指令：

# GEMINI.md
@include skills/using-superpowers/SKILL.md
@include references/gemini-tools.md

Codex — 利用原生技能发现机制，创建符号链接：

ln -s /path/to/superpowers/skills ~/.agents/skills/superpowers

OpenCode — 基于 Bun 的插件，在 config 钩子中注册技能，通过 experimental.chat.system.transform 注入引导上下文。

所有路径最终指向同一个事实：using-superpowers 是整个系统行为的唯一入口，如果这个技能没被注入，Superpowers 就不存在。

3.4 设计启示

这一层的设计启示很清晰：

统一入口：不管多少个平台，核心注入内容只有一个 using-superpowers
适配器模式：不同平台用不同的「插头」，但插的都是同一个「电源」
零运行时：注入过程只需要 Shell 脚本和 JSON，不需要 Node.js / Python 运行时

四、第二层：技能引擎——「技能即行为代码」

4.1 SKILL.md 的解剖

如果说 Hook 负责「把 Superpowers 带进房间」，那技能引擎就负责「规定 AI 在房间里该怎么表现」。

每个技能都是一个独立的 SKILL.md 文件，结构由 writing-skills 元技能规定。一个典型的 SKILL.md 长这样：

---
name: test-driven-development
description: >-
  Enforces RED-GREEN-REFACTOR TDD cycle. Activates during implementation.
  Write failing test first, watch it fail, write minimal code, watch it pass,
  then refactor. Deletes code written before tests.
---

# Test-Driven Development

## Scope Gate
This skill is active during implementation phases only.
It should NOT be re-activated in subagent contexts where
the parent workflow already manages TDD.

## Instruction Priority
User instructions > This skill > Default system prompt

## Checklist
- [ ] Write a failing test that describes the desired behavior
- [ ] Run the test and confirm it fails (RED)
- [ ] Write the minimal implementation to make the test pass
- [ ] Run the test and confirm it passes (GREEN)
- [ ] Refactor if needed while keeping tests green (REFACTOR)
- [ ] Commit the change

## Flow (DOT)
digraph TDD {
    RED -> GREEN -> REFACTOR -> RED;
}

## Danger Signals
| Excuse | Counter |
|--------|---------|
| "To save time, I will implement first" | Violates TDD sequence requirement |
| "This is too simple to need a test" | Every behavior deserves a test |
| "I will add tests after" | Post-hoc tests verify implementation, not behavior |

## Hard Gate
- MUST NOT proceed to next task until current test cycle is complete
- MUST NOT write implementation before failing test exists
- MUST delete any code written before its test

4.2 关键组件解析

YAML 前置数据（Frontmatter）：定义 name 和 description，驱动平台解析和自动激活匹配。description 不仅是文案，更是自动激活触发器——平台用它做语义匹配，当用户请求看起来有 1% 相关时，也会倾向于调用对应技能。

作用域门控（Scope Gate）：防止 subagent 再次触发同一流程技能，避免递归与重复。这在 subagent 驱动开发中尤其重要——否则每个子任务都会重新触发整个头脑风暴流程。

指令优先级（Instruction Priority）：明确「用户 > 技能 > 默认系统提示词」的层级关系。如果你在自己的配置中定义了约束，它可以覆盖甚至部分禁用 Superpowers 的行为。

检查清单（Checklist）：可转化为 Todo/Task 的步骤列表，构成操作的主干。每个步骤都是「可验证」的。

危险信号表（Danger Signals）：这是 Superpowers 最精妙的设计之一。它提前写好「模型常用借口」及其反驳。比如：

模型的借口	反制策略
「为了节省时间我直接实现了」	违反了 TDD 的顺序要求
「这个太简单不需要测试」	每个行为都值得测试
「我之后再补测试」	事后测试验证的是实现，不是行为
「这个场景不太可能发生」	YAGNI 不等于忽略边界条件

硬性门控（Hard Gate）：不是「建议先做 A 再做 B」，而是明写「如果未完成 A 的清单，则拒绝执行 B」。

4.3 刚性技能 vs 弹性技能

Superpowers 把技能分成两大类：

刚性技能：必须严格遵守，任何偏离都被视为流程失败。典型如：

test-driven-development：必须先写失败测试
systematic-debugging：必须按四阶段根因分析
verification-before-completion：必须验证后才能声明完成

弹性技能：提供原则与步骤，但允许根据上下文调整。典型如：

brainstorming：可以在「列举方案→比较→选择」的框架内灵活取舍
writing-plans：可以调整任务粒度

用一个对比来感受：

# 刚性技能：TDD — 必须按顺序执行
- [ ] 写失败测试 → 运行确认失败 → 写最小实现 → 运行确认通过 → 重构

# 弹性技能：头脑风暴 — 框架内灵活
- [ ] 理解目标 → 列举方案 → 比较 → 选择
  （每个步骤的深度和形式可以调整）

4.4 工具映射：跨平台复用的关键

技能内部使用的工具名称以 Claude Code 为「母语」（如 Skill、TodoWrite、Task）。在其他平台上，通过映射文件做名称转换：

# references/copilot-tools.md
| Claude Code Tool | Copilot CLI Tool |
|-----------------|-----------------|
| Skill           | skill           |
| TodoWrite       | todo            |
| Task            | task            |

同理还有 references/codex-tools.md、references/gemini-tools.md。同一个技能文件可以在多平台直接复用，这是 Superpowers 能够跨平台工作的基础。

五、第三层：开发工作流管道——从「一句话需求」到「可审计交付」

这是 Superpowers 的灵魂。它把「帮我做个功能」拆解成一条可验证的工程流水线。

5.1 完整工作流

用户需求 → brainstorming → 设计方案确认
                         ↓
                    using-git-worktrees → 创建隔离分支
                         ↓
                    writing-plans → 任务拆解
                         ↓
                    subagent-driven-development → 逐任务执行
                         ↓
                    test-driven-development → TDD 嵌入
                         ↓
                    requesting-code-review → 代码审查
                         ↓
                    finishing-a-development-branch → 合并/PR

每个环节都是硬性门控：未完成当前技能的检查清单，或用户没有明确确认输出，都不能进入下一阶段。

5.2 brainstorming：苏格拉底式设计澄清

这是第一个触发的技能。当 AI 检测到你想要构建什么时，它不会直接开始写代码，而是：

提出澄清性问题：你真正想做什么？目标用户是谁？核心约束是什么？
列举多种方案：给出至少 2-3 种实现路径
比较权衡：分析每种方案的利弊
分段展示设计：把设计方案分成小段落，每段都短到你真的能读完

# brainstorming 技能的关键规则

## Hard Gate
- MUST NOT begin any implementation work before design is approved
- MUST present design in sections short enough to be read and digested
- MUST explore at least 2 alternatives before recommending one
- User MUST explicitly approve the design before proceeding

实际对话示例：

你：我想给这个 API 加个缓存层

Superpowers AI：好的，在开始之前我想澄清几个问题：

1. 缓存的场景是什么？（读多写少？还是读写均衡？）
2. 一致性要求如何？（强一致？最终一致？）
3. 缓存失效策略偏好？（TTL？事件驱动？手动？）

根据你的回答，这里有几种方案：

**方案 A：Redis + TTL 过期**
- 优点：实现简单，运维成熟
- 缺点：存在缓存与数据库不一致窗口

**方案 B：Redis + Canal 监听 binlog 主动失效**
- 优点：一致性更好
- 缺点：引入 Canal 组件，架构复杂度增加

**方案 C：本地缓存 + Redis 二级缓存**
- 优点：延迟最低
- 缺点：一致性最难保证

你倾向哪种方案？

5.3 writing-plans：给「热情但缺乏判断力的初级工程师」写计划

设计确认后，AI 会编写一份实施计划。README 里有一段非常精准的描述：

After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow.

这既是对 AI 自身能力的清醒认知，也是计划编写标准的核心约束——计划要详细到即使执行者完全没有上下文判断力，也能按部就班完成。

# 一个好的任务计划示例

## Task 1: Create cache configuration module
- File: `src/cache/config.py`
- Create CacheConfig dataclass with fields:
  - backend: Literal["redis", "memcached"]
  - ttl: int (default 300)
  - max_memory: str (default "256mb")
- Add validation: ttl must be > 0
- Verification: `pytest tests/test_cache_config.py` passes

## Task 2: Implement Redis cache backend
- File: `src/cache/redis_backend.py`
- Implement RedisCacheBackend class with:
  - get(key: str) -> Optional[str]
  - set(key: str, value: str, ttl: Optional[int] = None)
  - delete(key: str) -> bool
  - exists(key: str) -> bool
- Each method must handle ConnectionError
- Verification: `pytest tests/test_redis_backend.py` passes

每个任务都定义了：

精确的文件路径
完整的代码接口
验证步骤

任务粒度控制在 2-5 分钟，确保每个子任务都足够小，不会「发散」。

5.4 subagent-driven-development：用「任务隔离」对抗上下文污染

这是 Superpowers 最复杂的技能，也是解决大模型长对话「遗忘」问题的关键。

问题：单个对话上下文会逐渐污染模型行为，越到后期越偏离最初规范。对话越长，AI 越容易「忘记」TDD、跳过审查、开始随意编码。

解决方案：为计划中的每个任务创建一个全新的 subagent，给它一组专门的指令（含上下文裁剪）。

主 Agent
├── Task 1 → Subagent A（干净上下文，仅含任务1指令）
│   ├── 执行实现
│   └── 触发两阶段审查
│       ├── 规范合规性审查（Spec Reviewer Subagent）
│       └── 代码质量审查（Code Quality Reviewer Subagent）
├── Task 2 → Subagent B（干净上下文，仅含任务2指令）
│   ├── 执行实现
│   └── 触发两阶段审查
│       ├── 规范合规性审查
│       └── 代码质量审查
└── ...

两阶段审查：

规范合规性审查：专门的审查者 subagent 检查实现是否符合原始设计/计划
代码质量审查：另一位审查者从架构、可维护性、风格等维度评估质量

这种模式的好处：

上下文隔离：每个任务在干净上下文中执行，降低「之前对话越攒越乱」的风险
审查独立：审查者不被开发过程的「情绪」影响，只对照规范和质量标准评价
自然形成「多人协作」：虽然角色都由同一个基础模型扮演，但上下文隔离使得行为接近多人协作

5.5 test-driven-development：写代码先写测试

TDD 技能是最典型的刚性技能，强制执行 RED-GREEN-REFACTOR 循环：

# RED 阶段：先写失败测试
def test_cache_set_and_get():
    cache = RedisCacheBackend(config=CacheConfig(backend="redis"))
    cache.set("user:123", '{"name": "test_user"}')
    result = cache.get("user:123")
    assert result == '{"name": "test_user"}'

# 运行测试 -> 失败（因为 RedisCacheBackend 还没实现）

# GREEN 阶段：写最小实现
class RedisCacheBackend:
    def __init__(self, config):
        self.client = redis.Redis(...)

    def get(self, key):
        return self.client.get(key)

    def set(self, key, value, ttl=None):
        self.client.set(key, value, ex=ttl)

# 运行测试 -> 通过

# REFACTOR 阶段：重构（提取公共方法、添加类型注解等）

硬性门控：

如果 AI 在测试之前写了实现代码，必须删除代码，先写测试
每个任务完成后必须确认所有测试通过
不得跳过 REFACTOR 阶段直接进入下一个任务

5.6 systematic-debugging：四阶段根因分析

当出现 bug 时，Superpowers 不允许 AI 猜测性地修修补补，而是强制执行四阶段调试流程：

1. 复现（Reproduce）→ 确认问题可稳定复现
2. 缩减（Reduce）→ 最小化复现条件
3. 定位（Locate）→ 找到根因
4. 修复（Fix）→ 针对根因修复，不是对症下药

每个阶段都有明确的退出条件：

不能在复现之前开始调试
不能在缩减之前提出修复方案
不能在定位根因之前写修复代码

六、第四层：Agent 定义——把「角色」变成可复用构件

6.1 代码审查 Agent

agents/code-reviewer.md 定义了一个高级代码审查员角色：

---
name: code-reviewer
model: inherit
---

# Code Reviewer

You are an experienced senior engineer performing a code review.

## Review Dimensions
1. Spec compliance: Does the implementation match the approved design?
2. Code quality: Is the code clean, well-structured, and maintainable?
3. Architecture: Does this fit the project's overall architecture?
4. Testing: Are edge cases covered? Are tests meaningful?

## Severity Classification
- **Critical**: Must fix before proceeding (security, data loss, spec violation)
- **Important**: Should fix (performance, maintainability, missing tests)
- **Suggestion**: Nice to have (naming, style, minor improvements)

注意 model: inherit 字段——审查 Agent 不强行指定模型，而是沿用父会话的选择。这意味着在不同平台、不同模型组合下都能被技能安全复用。

6.2 子审查提示词

在 subagent-driven-development 技能目录下，内置了专用提示词：

spec-reviewer-prompt.md：规范审查，关注「是否按照设计实现了」
code-quality-reviewer-prompt.md：质量审查，关注「代码本身好不好」

从架构角度看：技能定义流程，Agent 定义角色，两者组合才形成完整的开发工作流。

七、第五层：测试基础设施——把「提示词工程」当代码来测

7.1 测试目录结构

Superpowers 明确把技能当作「行为代码」，建立了完备的测试体系：

tests/
├── claude-code/          # 技能文档审查系统、subagent 集成、Token 用量
├── opencode/             # 插件加载、技能优先级、工具功能
├── brainstorm-server/    # 可视化伴侣 WebSocket 协议、Win 兼容性
├── skill-triggering/     # 基于用户提示的自动技能激活
├── explicit-skill-requests/  # 多轮对话、Haiku 模型兼容性
└── subagent-driven-dev/  # 端到端 subagent 工作流

注意 subagent-driven-dev 目录下有完整的端到端测试案例——Go 分形项目和 Svelte 待办应用。这些不是 toy test，而是用来回归验证整个 subagent 工作流的集成测试。

7.2 writing-skills 元技能：写技能也要 TDD

Superpowers 用 writing-skills 元技能，把「写技能本身」也纳入 TDD 循环：

先写对抗性压力测试场景：在没有技能的情况下跑一遍，看模型会怎样「乱来」
写技能内容：定义约束规则
重新跑测试：验证技能是否真正改变了 AI 行为
提供前后效果评估：引入的改动必须附带效果评估，否则难以通过合并审查

项目 PR 拒绝率达 94%，大部分原因是防止经过仔细调优的技能被无意破坏。这从侧面凸显了：在 Superpowers 的世界里，提示词就是生产级代码。

八、设计原则与约束：支撑整个架构的「硬骨头」

8.1 零外部依赖

项目刻意避免依赖复杂的运行时组件：

核心逻辑全部落在 Markdown 文件和 Shell 脚本上
唯一的 package.json 基本只用于 OpenCode 插件入口
没有 NPM 包、没有 Python 依赖、没有服务端组件

好处：

安装极简：一条命令搞定，适合企业受限环境
安全审计成本低：开发者可以直接逐行阅读所有行为定义
无供应链风险：不存在依赖库漏洞

8.2 指令层级：用户永远在最上层

用户指令（含用户自己的 CLAUDE.md 配置）
    ↓ 可覆盖
Superpowers 技能指令
    ↓ 可覆盖
默认系统提示词

如果你在自己的配置中定义了某些约束，它可以覆盖甚至部分禁用 Superpowers 的行为。最终控制权在开发者手里。

8.3 抵抗「合理化」：不要指望模型自觉遵守

这是 Superpowers 最务实的设计哲学。大模型会想方设法偷懒、跳步、给自己找借口，所以：

危险信号表：提前写好模型常用借口及反驳
硬性门控：不是建议，是规则
两阶段审查：用独立上下文的 subagent 审查，而非自我审查

用 Superpowers 作者的话说：

与其幻想模型会「理解并自律」，不如把规矩写死在系统里，甚至专门为「不守规矩」设计对策。

九、实战：安装与使用 Superpowers

9.1 在 Claude Code 中安装

最简单的方式——官方插件市场：

/plugin install superpowers@claude-plugins-official

或者使用 Superpowers 自己的市场：

# 注册市场
/plugin marketplace add obra/superpowers-marketplace

# 安装插件
/plugin install superpowers@superpowers-marketplace

9.2 在 Cursor 中安装

/add-plugin superpowers

或在插件市场中搜索 "superpowers"。

9.3 在 Gemini CLI 中安装

gemini extensions install https://github.com/obra/superpowers

9.4 在 Codex 中安装

在 Codex App 的侧边栏点击 Plugins，在 Coding 区域找到 Superpowers，点击 + 安装。

9.5 实际使用体验

安装后，你什么都不需要做。Superpowers 会在你开始构建功能时自动激活：

你：帮我实现一个用户注册 API

Superpowers AI（自动触发 brainstorming 技能）：
在我们开始编码之前，我想先确认几个设计决策：

1. 注册方式：邮箱？手机号？第三方 OAuth？
2. 密码策略：强度要求？是否支持无密码登录？
3. 验证流程：是否需要邮箱/手机验证？
4. 并发考虑：是否需要防止重复注册？

基于你的回答，我准备了 3 种方案：

**方案 A：邮箱注册 + 验证码**
- 流程：提交邮箱 → 发验证码 → 验证 → 创建账户
- 优点：标准化流程，用户熟悉
- 缺点：依赖邮件服务，验证码可能进垃圾箱

**方案 B：手机号注册 + 短信验证码**
- 流程：提交手机号 → 发短信 → 验证 → 创建账户
- 优点：验证率高，国内用户习惯
- 缺点：短信成本，需要对接运营商

**方案 C：第三方 OAuth（微信/GitHub/Google）**
- 流程：跳转第三方 → 授权 → 回调 → 创建/关联账户
- 优点：用户体验好，不需要记密码
- 缺点：依赖第三方服务，需要管理多平台集成

你倾向哪种？

确认设计后，AI 自动进入 writing-plans → subagent-driven-development → TDD → code-review 流程。你只需要在关键节点做决策，AI 会自主完成编码工作，甚至可以连续工作几小时不偏离计划。

十、性能优化与进阶技巧

10.1 Token 消耗管理

Superpowers 的技能注入会占用上下文窗口。优化策略：

精简 CLAUDE.md：只保留项目特定约束，通用规则交给 Superpowers
选择性禁用技能：如果你不需要某些技能（比如不用 Git Worktree），可以在配置中禁用
控制 subagent 深度：避免 subagent 嵌套过深

10.2 自定义技能

参考 writing-skills 元技能，你可以创建自己的技能：

---
name: api-design-review
description: >-
  Reviews API designs for RESTful best practices, naming consistency,
  and backward compatibility. Activates when designing new API endpoints.
---

# API Design Review

## Checklist
- [ ] Endpoint follows RESTful naming convention
- [ ] HTTP methods are correctly used (GET for read, POST for create, etc.)
- [ ] Response format follows project standard
- [ ] Error codes are consistent with existing API
- [ ] Pagination is considered for list endpoints
- [ ] Backward compatibility is maintained

## Hard Gate
- MUST NOT implement API endpoint before design review is complete

10.3 与现有项目集成

如果你有一个正在进行的项目，不需要从头开始：

在项目根目录添加 .claude/ 或对应平台的配置目录
在 CLAUDE.md 中加入项目上下文（技术栈、架构决策等）
安装 Superpowers，让 AI 了解现有代码库后按工作流推进

10.4 企业级部署建议

对于团队使用：

统一技能库：在内部 Git 仓库维护共享技能
定制审查标准：在 code-reviewer Agent 中加入公司编码规范
CI 集成：在 CI 中运行 Superpowers 的测试套件验证技能行为

十一、与其他 AI 编程工作流的对比

11.1 Superpowers vs Cursor Agent

维度	Cursor Agent	Superpowers
工作流	内置，不可自定义	可组合技能，可自定义
TDD	不强制	强制
代码审查	内置审查	可自定义审查标准
subagent	不支持	原生支持
平台绑定	仅 Cursor	跨 6+ 平台

11.2 Superpowers vs Devin / Factory

维度	Devin / Factory	Superpowers
模型	自有模型	使用你选择的模型
部署	云端 SaaS	本地运行
成本	按使用付费	免费（开源）
控制权	平台控制	完全自主
工作流	平台定义	用户可自定义

11.3 Superpowers vs 纯提示词工程

维度	纯提示词	Superpowers
可复用	低	高（技能组合）
可验证	靠人	自动审查
可组合	困难	原生支持
上下文管理	靠模型自觉	subagent 隔离
强制执行	无	硬性门控

十二、局限性与思考

12.1 上下文窗口的限制

Superpowers 的技能注入会占用上下文窗口。在小型模型（如 Haiku）上，可能导致可用上下文不足。虽然项目有针对 Haiku 模型的兼容性测试，但体验仍不如大模型流畅。

12.2 技能冲突

自定义技能可能与 Superpowers 内置技能冲突。项目建议用户指令优先级高于技能指令，但在实际使用中需要仔细调试。

12.3 依赖模型遵循指令的能力

Superpowers 的所有约束都基于「模型会遵循 SKILL.md 中的指令」这一假设。虽然硬性门控和危险信号表大幅提高了遵循率，但不能 100% 保证——特别是当模型版本更新导致行为变化时。

12.4 对中文场景的支持

目前 Superpowers 的技能主要用英文编写。中文开发者可能需要：

在 CLAUDE.md 中加入中文项目上下文
自定义中文版技能（参考 writing-skills 元技能）

十三、总结与展望

Superpowers 代表了 AI 编程助手发展的一个重要方向：从「能力增强」转向「行为约束」。

过去一年，AI 编程工具的竞争焦点是「谁的模型写代码更准」，但 Superpowers 提出了一个更深层的问题：写代码准确就够了吗？ 软件工程不只是写代码，它是一套包括需求澄清、方案设计、计划拆解、测试驱动、代码审查、持续交付在内的完整流程。

Superpowers 的价值不在于让 AI 写出更好的代码，而在于让 AI 按工程流程写代码。它的五层架构（平台适配 → 技能引擎 → 工作流管道 → Agent 定义 → 测试基础设施）提供了一个可扩展、可组合、可验证的工程化框架。

核心启示：

Process over Prompt：结构化流程比精心设计的提示词更可靠
约束即赋能：给 AI 加上合理的约束，反而能产出更高质量的代码
零依赖的力量：纯 Markdown + Shell 的架构，证明了「简单」可以很强大
提示词即代码：技能需要和代码一样被测试、版本管理和审查
对抗合理化：不要假设模型会自觉遵守规则，要把规矩写死

未来，随着 AI 编程助手的进一步普及，类似 Superpowers 这样的「工程约束层」将成为标配。不是因为你不需要 AI 写代码，而是因为你需要 AI 按正确的方式 写代码。

项目地址：https://github.com/obra/superpowers
当前版本：5.0.7
Star 数：123,000+（截至 2026 年 4 月）
许可证：MIT
作者：Jesse Vincent (obra) / Prime Radiant 团队