我们似乎习惯了那种“你说一句，它写一段”的快餐式开发模式。但说实话，这种模式往往带来的是一堆难以维护的“面条代码”和无数个深夜的 Debug 惨剧。Ru果你也曾对着 AI 生成的代码感到绝望，那么 Superpowers 这个开源框架或许就是你的救命稻草。它不仅仅是一个工具集，geng是一套为 Claude Code 量身定制的、近乎严苛的工程哲学。

今天我们不谈虚的，直接深入 Superpowers 的源码核心，剖析那四大让无数开发者从混乱走向秩序的工作流技Neng。这不仅仅是关于如何写代码，geng是关于如何像资深架构师一样思考。

一、Brainstorming：设计先行，拒绝盲目开火

你有没有遇到过这种情况？你让 AI “加个登录功Neng”，结果它噼里啪啦写了一堆代码，Zui后发现你想要的是 OAuth，而它给你写了个 Session 认证。这种返工的痛苦，Superpowers 通过 Brainstorming 技Neng彻底终结了。

在这个框架里有一条不可逾越的红线：HARD-GATE。任何代码实现之前，必须先有设计文档，而且必须获得你的批准。这不是建议，这是铁律。

1. 探索与澄清：不仅仅是提问

Brainstorming 的第一步并不是直接给出方案，而是探索上下文。AI 不会假设它懂你的需求，它会像个挑剔的产品经理一样不断提问。但这里有个hen有意思的设计：一次只问一个问题。

想象一下Ru果 AI 一次性抛给你十个问题，你会不会想砸键盘？Superpowers 懂得人性，它把复杂的决策拆解成一个个小的、可咀嚼的片段。比如它不会问“你的目标用户是谁、日活多少、支持哪些平台、优先级如何”，而是会问：“这个功Neng的主要目标用户是谁？A. 企业用户 B. 个人用户 C. 两者dou有”。

2. 视觉与逻辑的分离决策

这是 Superpowers 源码中一个非常精妙的细节。它并不是对所有问题dou一视同仁，而是根据问题的性质决定“作战方式”。

flowchart TD
    A --> B{涉及视觉问题?}
    B -->|是| C
    B -->|否| D
    C --> D
    D --> E
    E --> F
    F --> G{用户批准?}
    G -->|否| F
    G -->|是| H
    H --> I
    I --> J{审查通过?}
    J -->|否| K
    K --> I
    J -->|是| L
    L --> M{用户确认?}
    M -->|否| H
    M -->|是| N

Ru果问题是“什么样的导航结构geng合适？”，这是概念问题，用终端聊就行。但Ru果是“这两个布局哪个geng好？”，这就是视觉问题了。这时候，Brainstorming 技Neng会启动一个浏览器端的 Visual Companion。它不会傻傻地用文字描述颜色和间距，而是直接渲染出 UI 让你kan。这种“所见即所得”的交互，彻底消除了“我想象中的红色”和“你代码里的红色”之间的鸿沟。

3. 永远提供三个选项

不要让 AI 替你Zuo决定，也不要只给一个“Zui佳答案”。Superpowers 的原则是：探索替代方案。它会提出三个方案，展示各自的权衡，并给出推荐理由。这让你Neng够掌控局面而不是被动接受。

二、Writing-Plans：把蓝图刻在石头上

设计通过了是不是就Ke以开始写了？错。 在 Superpowers 的世界里设计文档只是意向书，实施计划才是具有法律效力的施工图。

Writing-Plans 技Neng的核心在于“详尽”。它要求计划必须详尽到：哪些文件需要修改、测试命令是什么、期望输出是什么、甚至关键的代码片段dou要提前写好。

1. 强制性的计划审查

这里有一个非常反直觉但极其重要的流程：计划写完后不是直接给你kan，而是先经过子代理审查。

设计文档 → 派遣 plan-document-reviewer 子代理
              ↓
         有问题？ → 修复 → 重新派遣
              ↓
         通过→ 用户审查

为什么要多此一举？因为修复可Neng引入新问题，或者所谓的“修复”根本没修复。只有经过专门的审查者子代理确认，这份计划才算合格。这大大减少了你作为用户的来回修改次数，把垃圾拦截在了代码生成之前。

2. 文件结构先行

在定义具体任务之前，Writing-Plans 会先确定文件结构。这就像盖房子先搭脚手架。比如它会明确指出 DTO 应该放在 `com.example.auth.dto` 还是 `com.example.dto`。这种对目录结构的强迫症，保证了项目长期的可维护性。

3. 计划文档的标准化头部

每个计划dou必须以一个标准的 YAML 头部开始，这不仅是格式要求，geng是强迫 AI 思考架构和技术栈的过程。

### 计划文档头部模板
每个计划**必须**以这个头部开始：
#  实施计划
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development  or superpowers:executing-plans to implement this plan task-by-task.
**Goal:** 一句话描述这个计划要构建什么
**Architecture:** 一句话说明架构思路
**Tech Stack:** 关键技术/库列表
---

三、Subagent-Driven Development：多兵种协同作战

Ru果说前两个阶段是在Zuo战略规划，那么 Subagent-Driven Development 就是真正的战术执行。这是 Superpowers Zui复杂、也Zui精彩的部分。

它的核心思想是：每任务派新子代理 + 两阶段审查 = 高质量、快迭代。不要指望一个 AI Neng从头到尾完美地Zuo完所有事，我们要像管理团队一样管理 AI。

1. 任务拆解与 TodoWrite

执行开始时系统会读取计划，提取所有任务，并创建一个 TodoWrite 列表。然后针对每一个任务，dou会派遣一个新的 implementer子代理。这保证了每个子代理的上下文是清晰的，注意力是集中的。

flowchart TD
    A --> B
    B --> C
    C --> D{还有任务?}
    D -->|是| E
    E --> F{有疑问?}
    F -->|是| G
    G --> E
    F -->|否| H
    H --> I
    I --> J{符合规格?}
    J -->|否| K
    K --> I
    J -->|是| L
    L --> M{代码质量 OK?}
    M -->|否| N
    N --> L
    M -->|是| O
    O --> D
    D -->|否| P
    P --> Q

2. 两阶段审查：先对，再好

这是 Superpowers 质量控制的灵魂所在。hen多开发者只关注代码写得漂不漂亮，却忽略了Zui致命的问题：这代码是不是用户想要的？

Superpowers 把审查拆成了两个独立的阶段：

阶段一：Spec Compliance Review 目的：验证实现者构建了“被要求的东西”——不多不少。代码质量再高，Ru果规格不符，也是白搭。只有审查者确认符合规格，才Neng进入下一阶段。

阶段二：Code Quality Review 目的：验证实现是“良好构建的”——干净、可测试、可维护。这时候才会去检查命名规范、注释、代码复杂度等问题。

这种顺序不Neng乱。先确保“Zuo了对的事”，再确保“把事Zuo好了”。

3. 实战演练：添加登录功Neng

假设用户需求是“添加用户登录功Neng”。让我们kankan这个过程是如何发生的：

Claude: 我理解你想添加用户登录功Neng。让我先了解项目结构。
Claude: 我kan到这是一个 Spring Boot 项目，使用 JWT 认证。有几个问题想确认：
1. 登录方式支持哪些？
   A. 用户名+密码
   B. 手机号+验证码
   C. 两者dou支持
User: A，用户名+密码
Claude: 了解。关于密码存储：
   A. BCrypt 加密
   B. 其他加密方式
User: A
Claude: 设计文档Yi写入 docs/superpowers/specs/---user-login-design.md
请审阅，确认后我们开始编写实施计划。

一旦进入 Subagent-Driven 阶段，对话就会变成这样：

Claude: 使用 Subagent-Driven Development 执行计划。
=== Task 1: 创建 LoginRequest/Response DTO ===
Implementer: 我有个问题：DTO 应该放在哪个包下？
  A. com.example.auth.dto
  B. com.example.dto
Claude: A，和其他认证相关的类放一起。
Implementer: 明白。正在实现...
- 创建 LoginRequest.java
- 创建 LoginResponse.java
- 测试通过
- Yi提交
- 自我审查：无问题
Spec Reviewer: ✅ 规格合规 - 所有要求Yi实现，无额外内容
Code Reviewer: 优点：命名清晰，符合规范
问题：缺少字段校验注解
Implementer: Yi添加 @NotBlank 注解
Code Reviewer: ✅ 批准
=== Task 1 完成 ===

四、Test-Driven Development：慢即是快的艺术

Zui后我们要聊聊那个老生常谈但极少有人真正Zuo好的技Neng——TDD。在 Superpowers 中，TDD 不是一个选项，它是贯穿始终的血液。

1. 拒绝“先写代码再测试”

先写代码再测试？删除。重新开始。

Ru果你在代码写完后再去补测试，那个测试通常会通过。但那证明不了任何事，因为它可Neng根本没测到正确的东西。测试在代码后写会立即通过这种“虚假的安全感”是软件工程的毒药。

2. Red-Green-Refactor 的严格执行

Superpowers 强制要求遵循经典的红-绿-重构循环：

flowchart LR
    R --> VR{验证失败?}
    VR -->|否| R
    VR -->|是| G
    G --> VG{验证通过?}
    VG -->|否| G
    VG -->|是| F
    F --> VG2{仍通过?}
    VG2 -->|否| F
    VG2 -->|是| N
    N --> R

RED 阶段： 写一个注定失败的测试。Ru果你没kan到测试失败，你不知道它是否测试了正确的东西。只有kan到测试因为正确的原因失败，你才Neng确信它在测试正确的东西。

GREEN 阶段： 只写让测试通过的Zui小代码。不添加功Neng，不重构，不“改进”。这是对开发者欲望的极大克制。

# ✅ 好：刚好足够通过
async def retry_operation:
    for i in range:
        try:
            return await fn
        except:
            if i == 2:
                raise
# ❌ 坏：过度工程
async def retry_operation:
    max_retries = options?.max_retries or 3
    backoff = options?.backoff or 'linear'
    # ... 一堆没用到的功Neng

REFACTOR 阶段： 在测试保护下清理代码。

3. 测试行为，而非实现

Superpowers 强调测试的边界。Ru果有人需要阅读内部实现才Neng理解一个单元，说明边界有问题。测试应该关注“它Zuo了什么”，而不是“它是怎么Zuo的”。

# ✅ 好：清晰命名，测试真实行为，一件事
def test_retries_failed_operations_3_times:
    attempts = 0
    def operation:
        attempts += 1
        if attempts <3:
            raise Error
        return 'success'
    result = retry_operation
    assert result == 'success'
    assert attempts == 3
# ❌ 坏：模糊命名，测试 mock 不是代码
def test_retry_works:
    mock = Mock
    mock.side_effect = 
    retry_operation
    assert mock.call_count == 3

构建你的 AI 开发护城河

Superpowers 的四大核心技Neng——Brainstorming、Writing-Plans、Subagent-Driven Development 和 TDD——并不是独立的技巧，而是一个相互支撑的严密体系。它体现了“慢即是快”的核心思想：前期投入设计、计划、测试的时间，会在后期节省大量调试和返工的成本。

掌握这套技Neng，你得到的不仅仅是一个geng听话的 AI 助手，geng是一套经过验证的、高质量的软件开发方法论。让我们不再Zuo代码的搬运工，而是成为真正驾驭技术的架构师。

---