Superpowers —— 让 Claude Code 从 Vibe Coding 进阶到工程化开发

发表于 分类于 Changyan： 本文字数： 5.5k 阅读时长 ≈ 20 分钟

2025 年是 AI 编程工具的爆发之年。从 Cursor、Claude Code 到 Aider，开发者们从未有过如此多的选择。但一个尴尬的现实是：很多人在用 AI 写代码，却很少人能写得好。本文要介绍的 Superpowers，正是为了解决这个”从能用到好用”的最后一公里问题。

一、AI 编程的现实困境：「能跑就行」的陷阱

先来看一个真实的场景：

1
2
3
4
5
6
7
8
你：帮我写一个用户登录接口
AI：好的！（30秒后掏出一段代码）
你：跑一下看看
AI：报错了...（又30秒后掏出修复版）
你：再跑
AI：又报错了...
（循环 N 次后...）
你：算了，能用就行

这个场景每天都在无数开发者的终端里上演。我们把这种方式称为 Vibe Coding —— 凭感觉写 Prompt，让 AI 直接写代码，跑通了就算完。

Vibe Coding 的问题不在”能不能跑”，而在”跑完之后”：

  • 测试缺失：AI 只写业务逻辑，不写测试。你能跑出结果，但你不知道边界情况是否正确。
  • 上下文丢失：长会话超过 Token 限制后，AI 会”忘记”之前的设计决策。你不得不重复解释。
  • 调试地狱：出问题时，AI 的修复往往是对症状的临时补丁，而不是根因分析。补丁叠补丁，最终变成「屎山」。
  • 无法重现：你无法知道他人在另一个会话里如何让你的 AI 重新产出相同质量的结果。

核心问题：AI 执行的是你的「规格说明」，而不是你的「意图」。给模糊描述 = 得到随机代码。

二、Superpowers 是什么

Superpowers 是由 Jesse Vincent（GitHub: obra）创建的一套 Claude Code 软件开发方法论和工作流框架。它的本质不是在 Claude Code 外面包一层，而是通过一套”技能库”（Skills）来约束和引导 Claude Code 的工作方式。

打个比方：

普通 Claude Code装了 Superpowers 的 Claude Code
一个自由职业设计师，想到什么画什么一个有完整 SOP 的资深架构师，先出方案、再画线稿、再上色、最后验收
你想删一行代码，它可能重构整个文件它先写测试覆盖现有行为，再动代码，最后验证

Superpowers 提供了 20+ 个技能（Skills），分为四大类：

graph TD
    SP[Superpowers 技能库] --> T[Testing 测试]
    SP --> D[Debugging 调试]
    SP --> C[Collaboration 协作]
    SP --> M[Meta 元开发]

    T --> T1[test-driven-development<br/>测试驱动开发]
    T --> T2[testing-anti-patterns<br/>测试反模式]
    T --> T3[condition-based-waiting<br/>条件等待]

    D --> D1[systematic-debugging<br/>系统化调试]
    D --> D2[root-cause-tracing<br/>根因追踪]
    D --> D3[verification-before-completion<br/>完成前验证]
    D --> D4[defense-in-depth<br/>纵深防御]

    C --> C1[brainstorming<br/>需求打磨]
    C --> C2[writing-plans<br/>计划编写]
    C --> C3[executing-plans<br/>计划执行]
    C --> C4[dispatching-parallel-agents<br/>并行代理调度]
    C --> C5[subagent-driven-development<br/>子代理驱动开发]
    C --> C6[requesting-code-review<br/>代码审查请求]

    M --> M1[writing-skills<br/>编写技能]
    M --> M2[sharing-skills<br/>分享技能]
    M --> M3[using-superpowers<br/>使用Superpowers]

这些技能不是「建议」——它们是强制性约束。比如 TDD 技能会要求「先写失败的测试，再写最小实现代码」。如果 Claude Code 试图跳过这一步，技能会拦截并报错。

三、Vibe Coding vs Superpowers：本质区别

用一个表来对比就非常清楚：

维度Vibe CodingSuperpowers
工作方式写 Prompt → AI 生成代码 → 跑一下 → 修 → 再跑头脑风暴 → 写计划 → TDD 驱动 → 并行执行 → 代码审查 → 验证
测试几乎不写强制 RED-GREEN-REFACTOR 循环
规划无，边走边看生成完整的 PLAN.md、progress.md、verification.md
上下文随时间丢失持久化到 Markdown 文件，跨会话不丢失
调试补丁式修复系统化四阶段调试：根因调查 → 模式分析 → 假设验证 → 实施修复
协作单人单 Agent支持并行子 Agent 执行不同任务
可追溯性极低完整的计划和进度文件，事后可复盘
适合场景快速原型、探索生产系统、团队协作

这里有一个来自业界的真实案例：

2025 年 7 月，一位创业者在 Vibe Coding 时，让 AI「优化数据库性能」，结果 AI 直接删除了生产数据库。这不是 AI 的错——它执行了模糊指令下的一个”优化方案”。

Superpowers 预防这类问题的机制：

  1. brainstorming 技能会先追问：「你确定要在生产环境直接操作吗？」
  2. writing-plans 技能会生成计划：「第一步：备份数据库；第二步：在 staging 环境测试；第三步：…」
  3. verification-before-completion 技能在每一步完成后运行验证命令。

四、Superpowers 的核心工作流

Superpowers 定义了三个核心斜杠命令，构成完整开发闭环：

第一步：/superpowers:brainstorm — 需求打磨

不是简单回一句「好的我来做」，而是苏格拉底式的对话：

1
2
3
4
5
6
7
8
9
10
你：帮我做一个 TODO 应用
Claude（brainstorm 模式）：
  1. 这个 TODO 应用是单用户还是多用户？
  2. 数据需要持久化吗？用本地存储还是后端数据库？
  3. 需要什么功能？添加、删除、标记完成、优先级、截止日期？
  4. 有没有特殊约束？比如离线支持、实时同步？
  5. 你预期的使用场景是什么？个人使用还是团队协作？

你：（回答这些问题）
Claude：好的，需求已明确，让我们进入计划阶段。

第二步：/superpowers:write-plan — 计划生成

将需求拆解为 可验证的微小任务：

1
2
3
4
5
6
7
# PLAN.md（自动生成）
## 任务 3：实现 TODO 添加功能
- 文件：src/components/TodoInput.tsx
- 预期：用户输入文字后按 Enter，TODO 项添加到列表
- 测试命令：npm test -- TodoInput
- 验收标准：输入有效文本 → 添加到列表；输入空字符串 → 不添加并提示
- 预估：3 分钟

关键点：每个任务 2-5 分钟可完成，颗粒度极细。

第三步：/superpowers:execute-plan — 计划执行

每个任务派发给独立的子 Agent（Subagent）执行：

1
2
3
4
5
6
7
任务 3 → Subagent A（独立会话，干净的上下文）
任务 4 → Subagent B（独立会话，干净的上下文）
任务 5 → Subagent C（独立会话，干净的上下文）
          ↓
      两阶段审查：
      Phase 1: 是否按计划实现？
      Phase 2: 代码质量审查

这解决了”长会话上下文膨胀”的问题。 每个子 Agent 只处理一个微小任务，上下文保持干净，质量更高。

五、安装和配置

5.1 安装 Superpowers

在 Claude Code 中执行以下命令：

1
2
3
4
5
6
7
8
# 第一步：注册 Superpowers 插件市场
/plugin marketplace add obra/superpowers-marketplace

# 第二步：安装核心插件
/plugin install superpowers@superpowers-marketplace

# 第三步：重载插件生效
/reload-plugins

安装成功后，执行 /help 你会看到新增的命令：

1
2
3
/superpowers:brainstorm
/superpowers:write-plan
/superpowers:execute-plan

5.2 可选：安装扩展插件

Superpowers 市场还提供了更多插件：

1
2
3
4
5
6
7
8
# 英文写作风格指导
/plugin install elements-of-style@superpowers-marketplace

# 跨会话记忆（语义搜索对话历史）
/plugin install episodic-memory@superpowers-marketplace

# 实验性技能（Tmux 交互式 CLI 控制等）
/plugin install superpowers-lab@superpowers-marketplace

5.3 验证安装

重新启动 Claude Code 后，执行：

1
2
# 验证技能是否加载
/superpowers:brainstorm 帮我实现一个简单的计数器，验证 Superpowers 是否正常工作

如果 Claude 开始向你追问需求、澄清边界条件，而不是直接写代码——恭喜你，Superpowers 已经在工作了。

六、从入门 Demo 到生产级项目

6.1 入门 Demo：命令行 TODO 应用

我们来完整走一遍。假设你在一个空文件夹 ~/projects/my-todo 中启动了 Claude Code：

第 1 阶段：探索（Vibe Coding，30 分钟）

1
2
3
4
你：帮我用 Python 写一个命令行 TODO 应用，支持添加、查看、删除功能
AI：好的，这是代码...（生成 todo.py）
你：跑一下
AI：# 能跑了

这样你有了一个大概能用的原型，但代码可能：

  • 没有测试
  • 没有错误处理
  • 没有文件结构
  • 数据结构是散装的

第 2 阶段：规范提炼（Superpowers + Brainstorm，15 分钟）

1
2
3
4
5
6
7
8
9
/superpowers:brainstorm 我们有一个 TODO 应用的 Python 原型。
需要将其重构为工程化版本。请帮我梳理需求和架构。

Claude 会追问：
  1. 数据用什么存储？JSON 文件还是 SQLite？
  2. 需要支持哪些操作？添加、删除、标记完成、列表、筛选？
  3. 命令行接口格式是什么？argparse 还是 click？
  4. 需要什么工程化基建？makefile？CI？pre-commit hooks？
  5. 预期的质量目标？测试覆盖率？

第 3 阶段：计划生成（Superpowers + Write-Plan，20 分钟）

1
2
3
4
5
6
7
8
9
10
11
12
/superpowers:write-plan 根据刚才确认的需求，生成完整的实施计划。

# Claude 输出：
# PLAN.md（20+ 个 2-5 分钟的微任务）
# - 任务 1：项目骨架（setup.py, 目录结构）
# - 任务 2：TODO 数据模型（dataclass, JSON 序列化）
# - 任务 3：存储层接口和实现
# - 任务 4：CLI 参数解析
# - 任务 5-8：各命令实现（TDD 先行）
# - 任务 9-12：错误处理、边界情况
# - 任务 13-15：集成测试
# ...

第 4 阶段：TDD 执行（Superpowers + Execute-Plan，45 分钟）

每个任务都是 RED-GREEN-REFACTOR 循环：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 任务 3：存储层（先写测试）
# tests/test_storage.py

def test_add_todo():
    storage = JSONStorage("test_data.json")
    storage.add(Todo(title="Buy milk", done=False))
    todos = storage.list()
    assert len(todos) == 1
    assert todos[0].title == "Buy milk"

# 运行：pytest tests/test_storage.py::test_add_todo
# 预期：FAIL（RED —— 类还没实现）

# 然后写最小实现
# 再运行：PASS（GREEN）
# 最后：重构（REFACTOR）

第 5 阶段：审查与交付

1
2
3
4
5
# Superpowers 自动执行：
# 1. Code Review 每个子任务
# 2. 运行全量测试
# 3. 验证验收标准
# 4. 询问：Merge / Create PR / Keep branch / Discard

6.2 生产级项目：FastAPI 用户认证系统

对于真实的生产项目，Superpowers 的优势更加明显。以下是一个 FastAPI 用户认证系统的完整开发流程，适合 Python 开发者参考：

Before（Vibe Coding）：

1
2
3
4
5
6
你：帮我写一个 FastAPI 用户登录接口
AI：好的，给你一个 /api/login 端点...
你：加上邮箱验证
AI：改好了...
你：加上 JWT 和限流
AI：改好了...（但之前的邮箱验证逻辑被覆盖了，依赖也没加到 requirements.txt）

After（Superpowers）：

PLAN.md 结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
项目：FastAPI 用户认证系统
阶段 1：项目骨架和依赖
  任务 1.1：初始化项目结构（src/ 目录、__init__.py）
  任务 1.2：配置 pyproject.toml（ruff, mypy, pytest）
  任务 1.3：锁定依赖（fastapi, uvicorn, sqlalchemy, pydantic, python-jose, passlib, slowapi）

阶段 2：数据层（TDD 先行）
  任务 2.1：User SQLAlchemy 模型（先写测试：test_user_model.py）
  任务 2.2：Alembic 数据库迁移（先写测试：test_migration.py）
  任务 2.3：UserRepository（先写测试：test_user_repo.py → test_create_user, test_get_by_email）

阶段 3：业务逻辑（TDD 先行）
  任务 3.1：Pydantic schema 定义（注册/登录请求体，先写 test_schemas.py）
  任务 3.2：密码哈希服务（passlib + bcrypt，先写 test_password_service.py）
  任务 3.3：JWT Token 服务（python-jose，先写 test_token_service.py → test_create_token, test_verify_expired）
  任务 3.4：限流依赖（slowapi，测试：test_rate_limit.py → 10次/分钟后返回 429）

阶段 4：API 路由（TDD 先行）
  任务 4.1：POST /auth/register（测试：test_register.py → 有效数据→201, 重复邮箱→409, 无效邮箱→422）
  任务 4.2：POST /auth/login（测试：test_login.py → 正确凭据→200+token, 错误密码→401）
  任务 4.3：GET /auth/me（测试：test_me.py → 有效token→200, 过期token→401, 无token→403）

阶段 5：集成测试和安全审查
  任务 5.1：完整注册→登录→访问受保护路由流程（test_integration.py）
  任务 5.2：限流端到端测试（并发11次请求，验证 429 响应）
  任务 5.3：安全审查（SQL 注入、密码哈希强度、Token 过期策略）

TDD 示例代码（任务 4.1：注册端点）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# tests/test_auth.py — 先写测试（RED）

import pytest
from httpx import AsyncClient, ASGITransport
from app.main import app
from app.database import engine, Base

@pytest.fixture(autouse=True)
async def setup_db():
    async with engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)
    yield
    async with engine.begin() as conn:
        await conn.run_sync(Base.metadata.drop_all)

@pytest.mark.anyio
async def test_register_with_valid_data_returns_201():
    async with AsyncClient(
        transport=ASGITransport(app=app), base_url="http://test"
    ) as client:
        response = await client.post("/auth/register", json={
            "email": "test@example.com",
            "password": "SecurePass123!"
        })
        assert response.status_code == 201
        data = response.json()
        assert data["email"] == "test@example.com"
        assert "id" in data
        assert "password" not in data  # 绝不泄露密码哈希

@pytest.mark.anyio
async def test_register_duplicate_email_returns_409():
    async with AsyncClient(
        transport=ASGITransport(app=app), base_url="http://test"
    ) as client:
        payload = {"email": "dup@example.com", "password": "SecurePass123!"}
        await client.post("/auth/register", json=payload)  # first
        response = await client.post("/auth/register", json=payload)  # duplicate
        assert response.status_code == 409

@pytest.mark.anyio
async def test_register_invalid_email_returns_422():
    async with AsyncClient(
        transport=ASGITransport(app=app), base_url="http://test"
    ) as client:
        response = await client.post("/auth/register", json={
            "email": "not-an-email",
            "password": "SecurePass123!"
        })
        assert response.status_code == 422
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# app/routers/auth.py — 最小实现（GREEN）

from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.ext.asyncio import AsyncSession
from app.schemas import UserRegister, UserResponse
from app.services.user_repo import UserRepository
from app.dependencies import get_db

router = APIRouter(prefix="/auth", tags=["auth"])

@router.post("/register", status_code=201, response_model=UserResponse)
async def register(body: UserRegister, db: AsyncSession = Depends(get_db)):
    repo = UserRepository(db)
    if await repo.get_by_email(body.email):
        raise HTTPException(status_code=409, detail="Email already registered")
    user = await repo.create(body.email, body.password)
    return UserResponse(id=user.id, email=user.email)

执行时，阶段 4 的三个 API 路由任务可以并行派发给三个子 Agent：

sequenceDiagram
    participant H as 人类
    participant M as 主Agent
    participant A as Subagent A<br/>Register 路由
    participant B as Subagent B<br/>Login 路由
    participant C as Subagent C<br/>Me 路由
    participant R as Code Review

    H->>M: /superpowers:execute-plan
    M->>A: 任务 4.1（新会话，含测试）
    M->>B: 任务 4.2（新会话，含测试）
    M->>C: 任务 4.3（新会话，含测试）

    A-->>M: ✅ 完成（含 pytest 测试）
    B-->>M: ✅ 完成（含 pytest 测试）
    C-->>M: ✅ 完成（含 pytest 测试）

    M->>R: 两阶段审查
    R-->>M: ✅ 全部通过
    M->>H: 全部完成，建议 merge

结果对比：

指标Vibe CodingSuperpowers
从零到生产2-4 小时（含大量 debug）< 30 分钟
测试覆盖率0%> 90%（pytest + httpx）
安全性（限流、注入防护）手动提醒才加计划阶段就包含
可维护性「别碰，能跑」结构化、有测试、可重构
交付物单个 app.pysrc/ 包结构 + pyproject.toml + 测试套件 + 迁移脚本

七、Superpowers 的设计哲学

理解 Superpowers 为什么这样设计，能帮助你更好地使用它：

7.1 「如果技能适用，你必须使用它」

Superpowers 有一个 SessionStart 钩子，在每次会话开始时自动注入技能感知。这不是一个可选菜单——如果你的任务属于某个技能覆盖的范围，该技能会被强制执行。

这种设计源于一个简单的事实：AI 会走捷径。 如果没有强制约束，Claude 会倾向于跳过规划和测试，直接写代码，因为「你能跑就行」在统计上是最多的训练样本。

7.2 Token 轻量化

Superpowers 的核心引导代码 不到 2000 Token。技能按需加载（通过 Shell 脚本），不会在每次会话中塞满上下文。重型实现工作委托给子 Agent。

这意味着：你不会因为装了 Superpowers 而显著减少可用上下文。

7.3 「万物皆 Markdown」

PLAN.md、progress.md、verification.md —— 全都是 Markdown。这不是巧合，而是有意为之：

  • Markdown 对人类可读
  • Markdown 对 AI 可解析
  • Markdown 对 Git 友好（diff、blame、history）

规范本身就是代码。 修改 Markdown → AI 读取 → AI 修改代码 → 验证。

7.4 复杂度精简

Superpowers 的首要目标不是「做更多」，而是「做得更简单」。如果一个设计可以被简化，技能会推动简化，而不是堆叠功能。

八、同类框架对比

Superpowers 不是唯一试图解决 AI 编程质量问题的框架。以下是当前 Claude Code 生态中五个主流同类框架的横向对比。

8.1 框架速览

graph TD
    subgraph 轻量规范派
        OS["OpenSpec：规范驱动，EARS 格式"]
        SP["Superpowers：技能约束，强制 TDD"]
    end

    subgraph 重型编排派
        GSD["GET SHIT DONE：6阶段+Wave并行"]
        OMC["Oh-My-Claude-Code：32 Agent 军团"]
        EC["Everything-Claude-Code：13 Agent+40 Skills"]
    end

    subgraph 多平台派
        TL["Trellis：14+平台，工作空间记忆"]
    end

    OS -.->|互补| SP
    SP -.->|互补| TL
    GSD -.->|竞品| OMC
    OMC -.->|竞品| EC

8.2 详细对比

OpenSpec（Fission-AI）

一句话：用 EARS 格式写规范 → AI 按规范实现。

  • 核心工作流：/openspec:proposal（提案）→ /openspec:apply（执行）→ /openspec:archive（归档）
  • 独特卖点：EARS 需求语法（WHEN...系统 SHALL...），让自然语言需求更精确；规范文件（specs/、changes/、archive/）与代码同仓库管理
  • 与 Superpowers 的区别：OpenSpec 重规范编写，Superpowers 重开发纪律。一个告诉你「写清楚再动手」，一个强制你「先测试再写代码」。两者可以互补使用

GET SHIT DONE（GSD）

一句话：上下文保鲜 + Wave 并行执行 + 自动修复闭环。

  • 核心工作流：Initialize → Discuss → Plan → Execute → Verify → Ship（6 阶段）
  • 独特卖点：
    • Wave 并行执行：根据 depends_on 依赖自动分组，无依赖任务同时并行
    • 四级验证：文件存在 → 空壳检测 → import 完整性 → 数据真实性
    • 上下文保鲜：每个 Plan 最多 2-3 个 Task，主会话上下文利用率始终 30-40%
  • 与 Superpowers 的区别：GSD 更重流程管控和并行编排，但不强制 TDD；Superpowers 更轻量，但 TDD 约束更强

Oh-My-Claude-Code（OMC）

一句话：「别学 Claude Code，直接用 OMC」—— 32 个专业 Agent 组成开发军团。

  • 核心工作流：Team 模式：team-plan → team-prd → team-exec → team-verify → team-fix（循环）
  • 独特卖点：
    • Ralph 模式：持久化验证循环，失败 → 修复 → 再验证，不达目的不罢休
    • 智能模型路由：根据任务复杂度自动选择 Haiku/Sonnet/Opus，省 30-50% token
    • 魔法关键词：说 ralph 激活持久执行，说 autopilot 激活端到端自主开发
  • 与 Superpowers 的区别：OMC 是重型多 Agent 编排器，Superpowers 是轻型技能约束层。OMC 更适合大型项目和团队协作；Superpowers 更适合个体开发者的质量保障

Everything-Claude-Code

一句话：5 万星的全能插件集，13 个 Agent + 40+ Skills + 32 个快捷命令。

  • 核心工作流：四层架构：用户交互层（斜杠命令）→ 智能层（Agent + Skills）→ 自动化层（Hooks）→ 学习层（持续进化）
  • 独特卖点：
    • AgentShield 安全扫描：912 条测试规则，98% 代码覆盖率，检测密钥泄露和 Hook 注入
    • Instinct 学习系统：/evolve 命令让框架从每次交互中学习
    • 全生命周期 Hooks：PreToolUse、PostToolUse、SessionStart、SessionEnd 等自动拦截
  • 与 Superpowers 的区别：Everything 是全家桶——什么都有但信息密度低；Superpowers 是精炼工具包——每个技能都经过实战验证，Token 开销极小

Trellis（Mindfold AI）

一句话：跨平台 AI 开发框架，一次配置，14+ 平台共享规范。

  • 核心工作流：/brainstorm → /before-dev → 实现 → /check → /finish-work → /record-session → /update-spec
  • 独特卖点：
    • 多平台适配：同一套 .trellis/spec/ 规范自动生成 Claude Code、Cursor、Codex、Copilot 等配置
    • 任务 PRD 机制：每个任务有独立 PRD 文件，AI 在明确边界内工作
    • 工作空间记忆：developer journals + handoff notes，跨会话无缝衔接
  • 与 Superpowers 的区别：Trellis 重规范复用和团队共享，Superpowers 重个体开发纪律。Trellis 适合多平台切换的团队；Superpowers 适合专注 Claude Code 生态的开发者

8.3 综合对比表

维度SuperpowersOpenSpecGSDOMCEverythingTrellis
定位开发纪律约束需求规范编写上下文工程多Agent编排全能工具集跨平台规范
强制 TDD✅ 强制❌ 建议❌ 建议❌ 建议⚠️ 可选❌ 建议
规划粒度2-5分钟任务EARS 规范2-3任务/PhasePRD → Task混合PRD + 任务
并行策略子Agent并行无Wave并行Team并行Hooks并行Worktree并行
平台绑定仅 Claude CodeClaude Code 为主15+ 平台Claude Code 为主Claude Code 为主14+ 平台
Token 效率★★★★★ (<2000)★★★★★★★★★★★★★★★★★★
学习曲线中等低中等高高低
GitHub Stars~5K~3K~62K~18K~50K~4.5K
适合场景个人高质量交付需求→实现映射中大型项目大型项目/团队全家桶用户多平台团队

8.4 Superpowers 的定位与选择建议

看完对比，你可能会问：”该选哪个？”

Superpowers 的核心优势不在「功能多」，而在「约束强」：

  • 它是唯一强制 TDD 的框架 —— 其他框架最多建议你写测试，Superpowers 要求你不写测试就不能继续
  • 它是 Token 最轻量的框架 —— 核心引导不到 2000 Token，不会挤占你的工作上下文
  • 它遵循 Unix 哲学 —— 做好一件事（开发纪律），而不是什么都要做

选择建议：

1
2
3
4
5
6
7
你的情况 → 推荐框架

个人开发，追求代码质量 → Superpowers（轻量 + 强制 TDD）
需求容易模糊，需要精确化 → OpenSpec + Superpowers（规范 + 纪律）
需要跨平台一致性 → Trellis
管理大型项目，有团队 → GSD 或 OMC（重型编排）
什么都想试，喜欢折腾 → Everything-Claude-Code

重要提示：这些框架之间并非互斥。一个常见的最佳实践是 OpenSpec 写规范 + Superpowers 守纪律 + Trellis 管团队协作，三者各司其职，互相补位。

九、我推荐的渐进式工作流

结合 Superpowers 的优势和场景适配，我推荐这样的开发策略：

1
2
3
4
5
6
7
8
9
10
11
阶段一：Vibe 探索（30 分钟）
  → 快速验证想法，不写规范，不管代码质量
  → 目的：「这个方向可行吗？」

阶段二：提炼规范（15 分钟）
  → 验证可行后，用 /superpowers:brainstorm 把原型整理成正式需求
  → 目的：「需求到底是什么？」

阶段三：Spec 重建（45-60 分钟）
  → 基于计划，用 /superpowers:write-plan + /superpowers:execute-plan
  → 目的：「写出生产级代码」

不要一开始就用 Superpowers。 在探索阶段需要的是速度和灵活性，Vibe Coding 的即兴特性在这个阶段是优势而非劣势。Superpowers 的价值在第二阶段和第三阶段——当你已经确定方向，需要高质量交付时。

十、总结

Superpowers 不是在 Claude Code 外面包一层，而是给它注入一套「工程纪律」。它的价值不是让 AI 写代码更快，而是让 AI 写出的代码更好。

1
2
Vibe Coding  →  「它跑起来了！」
Superpowers  →  「它跑起来了，而且有测试、有计划、可维护、可复现。」

写规范的能力，正在成为编程能力的核心组成部分。2025 年的赢家不是那些盲目信任 AI 输出的开发者，而是学会做软件架构师的人：定义意图、设定约束、审查工作、有目的地迭代。

代码是意图的有损投影。谁能写出最精确的规范，谁就是最好的程序员。

参考资源：

  • Superpowers 主仓库
  • Superpowers 插件市场
  • Jesse Vincent 的原始博文
  • Simon Willison 的深度解读
  • 火山引擎中文教程：让 Claude Code 具备高级架构师能力
  • 掘金：我如何用 Superpowers 强制 Claude Code 在编码前进行规划