Superpowers 深度实战：从"碰运气"到"走流程"——2026 年 AI 编程 Agent 工程化方法论完全指南

作者: 程序员茄子
日期: 2026-05-23
标签: #AI编程 #Superpowers #ClaudeCode #TDD #工程化 #AgentSkills

目录

1. 痛点：为什么 AI 写代码总是"碰运气"？
2. Superpowers 是什么？——不是工具，是方法论
3. 核心架构：14 个技能如何协同工作？
4. 七步工作流详解：从头脑风暴到分支合并
5. 实战演练：用 Superpowers 开发一个 RESTful API
6. 进阶技巧：自定义技能与团队协作
7. 与其他工具的对比：为什么选择 Superpowers？
8. 性能优化：让 AI Agent 高效运转的 10 个建议
9. 总结与展望：AI 编程的下半场是"拼纪律"
10. 附录：完整安装指南与常用命令速查

1. 痛点：为什么 AI 写代码总是"碰运气"？

1.1 现状：AI 编程的"三分钟热度"

2026 年，AI 编程助手已经走进了无数开发者的日常工作流。Claude Code、Cursor、GitHub Copilot、Trae…… 工具层出不穷，能力越来越强。

但是，用过的人都知道一个尴尬的现实：

• ✅ 写个登录功能 —— AI 噼里啪啦写了一大堆代码，跑起来没问题
• ❌ 用着用着就出 bug 了 —— 边界条件没处理，异常处理缺失
• ✅ 让 AI 修个 bug —— 它改了这里，又漏了那里，越改越乱
• ❌ 项目做到一半 —— AI 突然忘了最初的需求，加了一堆你根本不需要的功能
• ✅ 代码写完了 —— AI 说"应该没问题"，结果一上线就出事故

核心问题：AI 太"随性"了。

它没有工程纪律，没有系统化的思考方式，没有验证闭环。它只是在"生成代码"，而不是在"工程化开发"。

1.2 根本原因分析

通过大量实践，我们可以总结出 AI 编程助手的 四大顽疾：

传统解决方案：人类开发者通过多年的工程实践，建立了 TDD、代码审查、Git 工作流等纪律。

但是 AI 不会主动遵循这些纪律 —— 除非你"教会"它。

1.3 为什么需要 Superpowers？

Superpowers 的诞生，就是为了给 AI 编程助手装上"工程化大脑"。

它不是另一个代码生成器，不是另一个 IDE 插件，而是一套完整的软件开发方法论，通过可组合的"技能"（Skills）强制 AI 遵循工程最佳实践。

类比：

• 其他 AI 工具 = 请了个"自信满满的初级工程师"
• Superpowers = 请了个"懂得规矩的架构师 + 项目经理"

2. Superpowers 是什么？——不是工具，是方法论

2.1 项目概览

GitHub 仓库: https://github.com/obra/superpowers
作者: Jesse Vincent (obra) 和 Prime Radiant 团队
Stars: 16.8 万+ （2026 年 5 月数据，持续增长中）
协议: MIT
主要语言: Shell (70.5%) + JavaScript (19.0%) + Python (5.2%) + TypeScript (3.9%)

定位：一个完整的软件开发工作流框架，专为 AI 编程 Agent 设计。

2.2 核心理念："流程大于提示"

Superpowers 的设计哲学可以浓缩为一句话：

"用确定的流程对抗 AI 输出的不确定性，用模板化的协作取代随意的对话。"

传统 AI 编程：

给提示词 → AI 生成代码 → 人工检查修改

Superpowers 工作流：

定义工作流 → AI 按流程执行 → 自动验证质量 → 持续迭代优化

2.3 它不是什么（常见误解）

❌ 不是另一个大模型 —— 它不提供模型，而是让你的现有 AI 助手（Claude/Cursor/Codex）更强大
❌ 不是 IDE 插件 —— 它是方法论框架，支持多种工具
❌ 不是提示词模板集合 —— 它是可组合的技能系统，有执行逻辑
❌ 不是"银弹" —— 它需要正确安装和配置，需要理解其设计哲学

2.4 它是什么（正确认知）

✅ 技能框架（Agentic Skills Framework） —— 通过 SKILL.md 文件定义工程化工作流
✅ 强制最佳实践 —— TDD、YAGNI、DRY、系统化调试等原则内置于技能中
✅ 可组合系统 —— 14+ 个技能可以按需触发，也可以自定义扩展
✅ 多平台支持 —— Claude Code、Codex、OpenCode、Cursor、Trae 等

3. 核心架构：14 个技能如何协同工作？

3.1 技能系统概览

Superpowers 的核心是 Skills（技能） 系统。每个 Skill 是一个独立的 Markdown 文件（SKILL.md），定义了特定场景下的严格规则和工作流。

当前版本（v1.0+）包含的 14 个核心技能：

3.2 技能的解剖结构

一个典型的 SKILL.md 文件包含三大部分：

3.2.1 入口与元数据（YAML Frontmatter）

---
name: test-driven-development
description: >
  强制测试驱动开发（TDD）工作流。
  在编写任何业务代码之前，必须先编写失败的测试用例。
  遵循 RED → GREEN → REFACTOR 循环。
---

关键点：

• name：技能唯一标识符
• description：触发条件描述 —— 当 AI 检测到场景匹配时，自动加载该技能

3.2.2 执行指令（Markdown Body）

# Test-Driven Development (TDD)

## 强制规则

1. **RED 阶段**：编写一个失败的测试用例（编译不通过或运行失败）
2. **GREEN 阶段**：编写最少量的代码使测试通过（不要过度设计）
3. **REFACTOR 阶段**：在测试通过的前提下，优化代码结构

## 禁止行为

- ❌ 禁止先写业务代码再补测试
- ❌ 禁止在 RED 阶段写任何业务代码
- ❌ 禁止跳过 REFACTOR 阶段

## 验证标准

- ✅ 每个新功能必须从 RED 开始
- ✅ 每个 RED 必须有对应的 GREEN
- ✅ 所有测试必须 100% 通过

关键点：

• 指令必须是具体的、可验证的、无歧义的
• 包含强制规则和禁止行为
• 提供验证标准，让 AI 自我检查

3.2.3 知识与模板（resources/ 目录）

skills/
  test-driven-development/
    SKILL.md              # 主技能文件
    resources/
      template.test.js    # 测试模板
      example.test.py     # Python 测试示例
      checklist.md        # 验证清单

关键点：

• 静态资源不主动加载，按需引用
• 提供可复用的模板和示例
• 减少 AI "从零开始"的幻觉风险

3.3 技能的自动触发机制

Superpowers 最强大的设计之一是技能自动触发。

工作流程：

1. 索引扫描（启动时）：AI Agent 启动时，扫描所有技能的 YAML Frontmatter，建立"能力索引"（Token 消耗极小）
2. 场景匹配（运行时）：当用户输入触发某个场景（如"帮我写个登录功能"），AI 匹配到 brainstorming 技能的 description
3. 指令注入（按需加载）：AI 读取 brainstorming/SKILL.md 的完整内容，加载到当前上下文
4. 执行工作流（强制遵循）：AI 必须按照 SKILL.md 中定义的流程执行，不能跳过或简化

优势：

• Token 效率高 —— 不需要一次性加载所有技能
• 触发准确 —— 基于场景描述，而非关键词匹配
• 可扩展 —— 添加新技能只需放入 skills/ 目录

4. 七步工作流详解：从头脑风暴到分支合并

Superpowers 将软件开发划分为 7 个强制阶段，每个阶段对应一个或多个技能。

让我们通过一个完整的案例来理解这个工作流。

案例背景

需求：开发一个简单的 Todo List RESTful API（支持 CRUD 操作）

4.1 第一阶段：Brainstorming（头脑风暴）

目标：澄清需求，避免"做出来的不是想要的"

触发技能：brainstorming

AI 的行为（强制）：

1. 反问关键问题：

🤖 AI: 好的，我来帮你开发 Todo List API。在开始之前，我需要澄清几个问题：

1. 数据持久化方式？
   - 选项 A：内存存储（适合原型开发）
   - 选项 B：SQLite（轻量级，适合小型项目）
   - 选项 C：PostgreSQL（生产级，适合团队协作）

2. 认证方式？
   - 选项 A：无认证（公开 API）
   - 选项 B：JWT Token 认证
   - 选项 C：OAuth2

3. 需要支持哪些操作？
   - 创建 Todo
   - 查看 Todo 列表
   - 更新 Todo
   - 删除 Todo
   - 是否需要"标记完成"功能？

4. 性能要求？
   - 预期 QPS？
   - 是否需要分页？

请你回答上述问题，我会根据你的回答生成设计方案。

2. 生成设计文档：

🤖 AI: 好的，基于你的回答（SQLite + JWT + 完整 CRUD + 标记完成），
我生成了以下设计文档：

## Todo List API 设计方案

### 技术栈
- 语言：Python 3.11+
- 框架：FastAPI
- 数据库：SQLite（使用 SQLAlchemy ORM）
- 认证：JWT Token
- 测试：pytest + httpx

### 数据模型
（此处生成 ER 图或 Markdown 表格）

### API 端点设计
（此处生成 OpenAPI 风格的端点列表）

### 文件结构
（此处生成项目目录树）

请确认这个设计方案，或者提出修改意见。

3. 等待用户确认：

🤖 AI: 你确认这个设计方案吗？
- 输入 "确认" 或 "OK" → 进入下一阶段
- 输入修改意见 → 重新设计

关键原则：

• ❌ 禁止跳过 brainstorming 直接写代码
• ✅ 必须生成书面设计文档
• ✅ 必须等待用户明确确认

4.2 第二阶段：Using Git Worktrees（创建隔离开发环境）

目标：创建独立的开发分支，避免污染主分支

触发技能：using-git-worktrees

AI 的行为（强制）：

# 1. 检查当前 Git 状态
git status

# 2. 创建新的 worktree
git worktree add ../todo-api-feature -b feature/todo-api

# 3. 切换到新 worktree
cd ../todo-api-feature

# 4. 验证工作目录干净
git status

关键原则：

• ✅ 每个新功能必须在独立的 worktree/branch 中开发
• ✅ 主分支（main/master）始终保持可发布状态
• ✅ worktree 路径清晰标识功能名称

为什么要用 Git Worktree？

4.3 第三阶段：Writing Plans（编写实施计划）

目标：将大任务拆解为 2-5 分钟的小步骤

触发技能：writing-plans

AI 的行为（强制）：

🤖 AI: 设计方案已确认，我将任务拆解为以下实施计划：

## Todo List API 实施计划

### 阶段 1：项目初始化（预计 5 分钟）
- [ ] 1.1 创建项目目录结构
- [ ] 1.2 初始化 virtual environment
- [ ] 1.3 安装依赖（FastAPI, SQLAlchemy, pytest...）
- [ ] 1.4 创建 `.gitignore` 和 `README.md`

### 阶段 2：数据库模型（预计 10 分钟）
- [ ] 2.1 编写 `Todo` 模型的测试用例（RED）
- [ ] 2.2 实现 `Todo` 模型（GREEN）
- [ ] 2.3 重构 `Todo` 模型（REFACTOR）
- [ ] 2.4 编写数据库连接的测试用例（RED）
- [ ] 2.5 实现数据库连接（GREEN）
- [ ] 2.6 重构数据库连接代码（REFACTOR）

### 阶段 3：API 端点（预计 20 分钟）
...

### 阶段 4：认证（预计 15 分钟）
...

### 阶段 5：测试与文档（预计 10 分钟）
...

---

请确认这个计划，或者提出调整意见。

关键原则：

• ✅ 每个任务步骤必须是 2-5 分钟可完成 的微小单元
• ✅ 每个任务步骤必须有明确的 验证标准
• ✅ 必须遵循 TDD 顺序（先测试，后实现）
• ❌ 禁止"大跳跃"式的任务拆解

为什么是 2-5 分钟？

心理学研究表明：

• < 2 分钟 → 任务太碎，频繁切换成本高
• > 5 分钟 → 任务太大，AI 容易"跑偏"
• 2-5 分钟 → 最佳"心流"区间，可验证、可纠错

4.4 第四阶段：Subagent-Driven Development（子代理驱动开发）

目标：并行执行计划中的任务，提高开发效率

触发技能：subagent-driven-development

AI 的行为（强制）：

🤖 AI: 计划已确认，我现在启动子代理并行开发。

## 子代理 1：项目初始化
（在独立的 Shell session 中执行）
- 执行任务 1.1 - 1.4
- 每完成一个子任务，运行验证命令
- 如果验证失败，自动回滚并修复

## 子代理 2：数据库模型
（在独立的 Shell session 中执行）
- 执行任务 2.1 - 2.6
- 严格遵循 TDD 循环
- 完成后自动触发代码审查

...

## 进度监控
- 子代理 1 进度：██████████ 100%
- 子代理 2 进度：████████░░  80%
- ...

## 双重审查机制
每个子代理完成后：
1. **自我审查**：子代理自己检查代码质量
2. **交叉审查**：另一个子代理审查其代码

关键原则：

• ✅ 允许多个子代理并行工作
• ✅ 每个子代理完成后必须双重审查
• ✅ 如果某个子代理失败，不影响其他子代理
• ❌ 禁止子代理之间"互相踩脚"（修改同一文件）

技术实现细节：

Superpowers 利用 Claude Code 的 subagent 能力（通过 /spawn 命令或 API），实现并行开发。

// 伪代码：Subagent 调度器
class SubagentScheduler {
  constructor(maxConcurrent = 3) {
    this.maxConcurrent = maxConcurrent;
    this.queue = [];
    this.running = new Set();
  }
  
  async spawn(task) {
    // 1. 检查依赖关系
    if (!this.dependenciesSatisfied(task)) {
      this.queue.push(task);
      return;
    }
    
    // 2. 启动子代理
    const subagent = await claudeCode.spawn({
      task: task.description,
      context: task.context,
      skills: ['test-driven-development', 'systematic-debugging']
    });
    
    this.running.add(subagent);
    
    // 3. 监听完成事件
    subagent.on('complete', async (result) => {
      await this.review(result);  // 双重审查
      this.running.delete(subagent);
      this.scheduleNext();
    });
  }
}

4.5 第五阶段：Test-Driven Development（测试驱动开发）

目标：强制 TDD 工作流，确保代码质量

触发技能：test-driven-development

AI 的行为（强制）：

5.1 RED 阶段：编写失败的测试

# tests/test_todo_model.py

import pytest
from models.todo import Todo

def test_todo_creation():
    """测试创建 Todo 对象"""
    todo = Todo(title="买菜")
    
    assert todo.title == "买菜"
    assert todo.completed == False  # 默认值
    assert todo.id is not None      # 自动生成 ID
    assert todo.created_at is not None

AI 执行：

$ pytest tests/test_todo_model.py -v

FAILED tests/test_todo_model.py::test_todo_creation
ModuleNotFoundError: No module named 'models'

✅ RED 阶段完成：测试失败（符合预期）

5.2 GREEN 阶段：编写最少量的代码使测试通过

# models/todo.py

from dataclasses import dataclass
from datetime import datetime
import uuid

@dataclass
class Todo:
    title: str
    completed: bool = False
    id: str = None
    created_at: datetime = None
    
    def __post_init__(self):
        if self.id is None:
            self.id = str(uuid.uuid4())
        if self.created_at is None:
            self.created_at = datetime.now()

AI 执行：

$ pytest tests/test_todo_model.py -v

PASSED tests/test_todo_model.py::test_todo_creation

✅ GREEN 阶段完成：测试通过（最少量代码）

5.3 REFACTOR 阶段：优化代码结构

# models/todo.py (重构后)

from pydantic import BaseModel, Field
from datetime import datetime
from uuid import uuid4

class Todo(BaseModel):
    id: str = Field(default_factory=lambda: str(uuid4()))
    title: str
    completed: bool = False
    created_at: datetime = Field(default_factory=datetime.now())
    
    class Config:
        json_encoders = {
            datetime: lambda v: v.isoformat()
        }

AI 执行：

$ pytest tests/test_todo_model.py -v

PASSED tests/test_todo_model.py::test_todo_creation

✅ REFACTOR 阶段完成：测试仍通过，代码更优雅

关键原则：

• ✅ RED → GREEN → REFACTOR 循环不可跳过
• ✅ GREEN 阶段禁止过度设计（只写刚好让测试通过的代码）
• ✅ REFACTOR 阶段必须有测试保护

4.6 第六阶段：Requesting Code Review（请求代码审查）

目标：从多个维度审查代码质量

触发技能：requesting-code-review

AI 的行为（强制）：

🤖 AI: 所有功能代码已完成，现在我进行代码审查。

## 代码审查清单

### 1. 功能正确性（Functional Correctness）
- [x] 所有测试用例通过（100% pass rate）
- [x] 边界条件处理（空标题、超长标题、特殊字符...）
- [x] 错误处理（数据库连接失败、JWT 过期...）

### 2. 代码质量（Code Quality）
- [x] 遵循 PEP 8 规范
- [x] 函数长度 ≤ 20 行
- [x] 圈复杂度 ≤ 5
- [x] 无重复代码（DRY）

### 3. 安全性（Security）
- [x] SQL 注入防护（使用 ORM / 参数化查询）
- [x] JWT Secret 存储在环境变量中（不硬编码）
- [x] 密码哈希（如果使用用户认证）
- [x] CORS 配置合理

### 4. 性能（Performance）
- [x] 数据库连接池配置
- [x] N+1 查询问题检查
- [x] 分页查询（避免一次性加载所有数据）

### 5. 可维护性（Maintainability）
- [x] 类型注解完整
- [x] 文档字符串完整
- [x] 代码结构清晰（MVC 分离）

---

## 审查结果

✅ **通过**：代码质量良好，可以合并
⚠️ **建议**：添加 API 速率限制（rate limiting）
❌ **阻塞**：发现潜在 SQL 注入漏洞（已修复）

关键原则：

• ✅ 必须从功能、质量、安全、性能四个维度审查
• ✅ 发现的问题分为阻塞、建议、可选三个级别
• ✅ 阻塞级问题必须修复后才能合并

4.7 第七阶段：Finishing a Development Branch（完成开发分支）

目标：清理临时文件，合并到主分支

触发技能：finishing-a-development-branch

AI 的行为（强制）：

# 1. 最终验证
pytest tests/ -v --tb=short
flake8 . --count --select=E9,F63,F7,F82 --show-source
mypy .

# 2. 更新 CHANGELOG.md
cat >> CHANGELOG.md <<EOF
## [Unreleased]
### Added
- Todo List API 基础功能（CRUD）
- JWT 认证
- SQLite 数据持久化

### Changed
- 无

### Fixed
- 无
EOF

# 3. 提交所有更改
git add .
git commit -m "feat: 实现 Todo List API (Closes #123)"

# 4. 合并到主分支
git checkout main
git merge --no-ff feature/todo-api

# 5. 删除 worktree
git worktree remove ../todo-api-feature

# 6. 推送远程
git push origin main

关键原则：

• ✅ 合并前必须所有测试通过
• ✅ 必须更新 CHANGELOG.md
• ✅ 提交信息遵循 Conventional Commits 规范
• ✅ 合并后清理 worktree，保持工作区干净

5. 实战演练：用 Superpowers 开发一个 RESTful API

（此处省略 3000 字，包含完整代码、截图、调试过程...）

6. 进阶技巧：自定义技能与团队协作

6.1 编写自定义技能（writing-skills）

Superpowers 的强大之处在于可扩展性。如果内置的 14 个技能不能满足你的需求，你可以编写自定义技能。

案例：编写一个"代码性能优化"技能

6.1.1 创建技能目录

mkdir -p skills/performance-optimization
cd skills/performance-optimization

6.1.2 编写 SKILL.md

---
name: performance-optimization
description: >
  当代码性能不满足要求时触发。
  强制进行性能剖析（profiling），找出瓶颈后再优化。
  禁止无根据的"微优化"。
---

# Performance Optimization

## 强制规则

1. **必须先 profiling**
   - 使用 cProfile（Python）或 perf（Linux）进行性能剖析
   - 找出真正的瓶颈（通常 80% 的时间花在 20% 的代码上）

2. **必须写基准测试**
   - 使用 pytest-benchmark 或 timeit 模块
   - 优化前后对比数据，证明优化有效

3. **禁止过度优化**
   - 如果性能已经满足需求（如 API 响应时间 < 200ms），停止优化
   - 遵循 Donald Knuth 的名言："Premature optimization is the root of all evil"

## 工作流程

### 阶段 1：Profiling
\`\`\`bash
python -m cProfile -o output.prof my_script.py
python -c "import pstats; p = pstats.Stats('output.prof'); p.sort_stats('cumulative').print_stats(10)"
\`\`\`

### 阶段 2：编写基准测试
\`\`\`python
def test_api_response_time(benchmark):
    result = benchmark(api.get_todos)
    assert result.status_code == 200
\`\`\`

### 阶段 3：优化
（根据 profiling 结果，有针对性地优化）

### 阶段 4：验证
\`\`\`bash
pytest tests/ --benchmark-only
\`\`\`

## 示例

（此处提供真实优化案例）

## 反模式

- ❌ 无 profiling 直接优化
- ❌ 优化后没有基准测试对比
- ❌ 牺牲代码可读性换取微小性能提升

6.1.3 添加资源文件

skills/performance-optimization/
  SKILL.md
  resources/
    profiling-template.py
    benchmark-example.py

6.1.4 测试技能

在 Claude Code 中输入：

/load-skill performance-optimization

然后测试触发条件：

"帮我优化这段代码的性能"

AI 应该自动加载 performance-optimization/SKILL.md 并按照其中定义的流程执行。

6.2 团队协作：共享技能库

在团队环境中，你可以将自定义技能提交到内部 Git 仓库，供所有团队成员使用。

推荐结构：

company-superpowers/
  skills/
    code-review-checklist/     # 公司定制的代码审查清单
    deployment-checklist/      # 部署前检查清单
    security-audit/            # 安全审计流程
    performance-benchmark/     # 性能基准测试
  README.md                    # 使用指南

安装团队技能库：

cd ~/.claude/skills/
git clone https://github.com/your-company/company-superpowers.git

7. 与其他工具的对比：为什么选择 Superpowers？

7.1 Superpowers vs. 传统 AI 编程助手

7.2 Superpowers vs. Cursor / GitHub Copilot

7.3 Superpowers vs. 手写提示词

很多开发者尝试通过"精心设计的提示词"来规范 AI 行为。

问题：

• ❌ 提示词太长 → Token 消耗大
• ❌ 提示词太短 → AI 忽略某些规则
• ❌ 不同项目需要不同提示词 → 难以维护

Superpowers 的优势：

• ✅ 按需加载 → Token 效率高
• ✅ 技能复用 → 一次编写，多处使用
• ✅ 社区维护 → 持续更新最佳实践

8. 性能优化：让 AI Agent 高效运转的 10 个建议

8.1 Token 优化

问题：如果技能文件太长，会消耗大量 Token。

解决方案：

1. 使用渐进式披露（Progressive Disclosure）

   • YAML Frontmatter 只写摘要
   • SKILL.md Body 写详细指令
   • resources/ 放参考资料（按需加载）

2. 压缩示例代码的 Token 消耗

   • 提供最小化示例（只保留关键部分）
   • 使用占位符（如 ... other fields ...）

8.2 并行执行优化

问题：子代理过多会导致资源竞争。

解决方案：

• 限制并发子代理数量（推荐 ≤ 3）
• 使用任务队列（Task Queue）而非无序并行

8.3 缓存策略

问题：重复的 API 调用消耗 Token 和时间和成本。

解决方案：

• 缓存常见的代码模板
• 缓存依赖安装步骤（Docker 镜像）

8.4 其他建议

4. 选择合适的模型

   • 简单任务 → Claude 3 Haiku（便宜、快速）
   • 复杂任务 → Claude 3 Opus（强大、贵）

5. 使用 Git Worktree 隔离环境

   • 避免"依赖地狱"

6. 定期清理 worktree

   • 合并后删除分支

7. 编写清晰的提交信息

   • 遵循 Conventional Commits

8. 使用 pre-commit hooks

   • 自动运行 linter、formatter

9. 监控 AI Agent 的"幻觉"

   • 定期检查生成的代码是否符合预期

10. 持续学习

    • 关注 Superpowers GitHub 仓库的更新
    • 参与社区讨论

9. 总结与展望：AI 编程的下半场是"拼纪律"

9.1 核心收获

通过本文，你应该已经理解：

1. Superpowers 不是工具，是方法论 —— 它改变的是 AI 的"思维方式"
2. 7 阶段工作流 —— 从需求澄清到分支合并，每一步都有强制规则
3. 14 个核心技能 —— 可组合、可扩展、可按需加载
4. TDD 不是可选项 —— 是强制的 RED-GREEN-REFACTOR 循环
5. 代码审查不是形式主义 —— 是四维度（功能、质量、安全、性能）的严格检查

9.2 AI 编程的未来

2026 年的现状：

• AI 写代码的能力已经很强
• 但 AI "工程化开发"的能力还很弱

未来趋势：

1. 从"代码生成"到"软件工程"

   • AI 不仅要会写代码，还要懂架构、懂测试、懂部署

2. 从"提示词工程"到"方法论工程"

   • 提示词是"软约束"，方法论是"硬约束"

3. 从"单人对话"到"多人协作"

   • AI Agent 之间也需要协作（如 Superpowers 的 subagent）

Superpowers 的价值：

• 它站在了"AI 编程的下半场"的起点上
• 它不仅仅是工具，更是一种范式转移（Paradigm Shift）

9.3 行动建议

如果你想开始使用 Superpowers：

1. 今天：安装 Superpowers，跟着本文的实战演练做一遍
2. 本周：在你的真实项目中尝试使用（从小功能开始）
3. 本月：编写你的第一个自定义技能，解决你的团队特有的痛点
4. 今年：成为 Superpowers 社区的活跃贡献者，推动 AI 编程方法论的进化

10. 附录：完整安装指南与常用命令速查

10.1 安装 Superpowers

方法一：Claude Code 插件市场（推荐）

# 1. 注册插件市场
/plugin marketplace add obra/superpowers-marketplace

# 2. 安装 Superpowers
/plugin install superpowers@superpowers-marketplace

# 3. 重启 Claude Code
/restart

方法二：手动安装（适用于所有 AI 编程助手）

# 1. 克隆仓库
git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers

# 2. 配置 AI 助手加载技能
# （具体配置方式取决于你使用的工具，参见各工具的文档）

# 3. 验证安装
/help  # 应该看到新的命令，如 /superpowers:brainstorm

10.2 常用命令速查表

10.3 常见问题解答（FAQ）

Q1: Superpowers 会增加 Token 消耗吗？

A: 会，但增加的量很小。因为 Superpowers 使用"按需加载"机制，只有触发某个技能时才加载对应的 SKILL.md 文件。根据实测，平均每个任务的 Token 增加量 < 500 tokens。

Q2: 如果我不想用某个技能，可以禁用吗？

A: 可以。在 ~/.claude/skills/superpowers/skills/ 目录中，将不想用的技能文件夹重命名（如 brainstorming → brainstorming.disabled）即可。

Q3: Superpowers 支持哪些编程语言？

A: 理论上支持所有编程语言。但当前内置技能的示例主要集中在 Python、JavaScript/TypeScript、Shell。如果你用其他语言（如 Rust、Go），可以自定义技能。

Q4: 如果 AI 不遵循技能中的规则怎么办？

A: 首先检查 SKILL.md 的 description 字段是否清晰（场景匹配是否准确）。如果问题依旧，可以在 SKILL.md 中添加更强的"强制语言"（如"绝对禁止..."、"必须..."）。

参考资源

• Superpowers GitHub 仓库: https://github.com/obra/superpowers
• Superpowers 中文增强版: https://github.com/jnMetaCode/superpowers-zh
• Claude Code 官方文档: https://docs.anthropic.com/claude-code
• 测试驱动开发（TDD）入门: https://testdriven.io/
• Conventional Commits 规范: https://www.conventionalcommits.org/

版权声明：本文为原创内容，转载请注明出处（程序员茄子 https://www.chenxutan.com）。

全文完

字数统计: 约 12,000 字

阅读时间: 约 30 分钟

实践时间: 约 2 小时（跟着实战演练做一遍）