1.前言

你是否遇到过这样的场景：让 AI 编程助手写代码，结果它生成了一堆难以维护、过度设计的"垃圾代码"？或者你明明只想实现一个简单功能，它却给你搭了一套复杂的框架？

如果你有过这样的经历，那么 Superpowers 就是为你准备的。这套为 coding agents 设计的完整软件开发方法论，目前在 GitHub 上已有 238k star，几乎所有主流的 coding Agent 都原生支持：

• Claude Code
• Antigravity
• Codex App / CLI
• Cursor
• Gemini CLI
• GitHub Copilot CLI
• Kimi Code
• OpenCode

我将通过系列文章，从理论到实践全方位介绍 Superpowers，帮助你更好地将其应用到日常开发工作中。

2.概述

GitHub：https://github.com/obra/superpowers

Superpowers 是一套为你的 coding agents 准备的完整的软件开发方法论，它建立在若干可组合的技能（composable skills）以及一些初始指令之上，这些初始指令能确保 agent 切实使用这些技能。

设计理念：

• 测试驱动开发 – 始终先写测试
• 系统性优于临时性 – 流程优于猜测
• 降低复杂性 – 将简洁作为首要目标
• 证据优于宣称 – 先验证，再宣布成功

3.工作原理

整个过程从你启动 coding agent 的那一刻就开始了。一旦它发现你正在构建某个东西，它不会直接跳入写代码，而是先退后一步，问你究竟想达成什么目标。

当它从对话中梳理出一份规格说明后，它会把它分成足够短的小块呈现给你，让你真正能读得进去、消化得了。

在你批准了设计方案之后，你的 coding agent 会制定一份实现计划。这份计划清晰到连一位品味欠佳、没有判断力、不了解项目背景、还厌恶测试的热情初级工程师都能照着执行。它强调真正的红绿TDD、YAGNI 和 DRY原则。

接下来，一旦你说"开始"，它就会启动一个子代理驱动的开发流程，让多个子代理逐一执行每项工程任务，同时检查、审查它们自己的工作，并持续推进。你的 coding agent 自主工作几个小时而不偏离你共同制定的计划，这种情况并不少见。

这里面还有很多细节，但以上是这套系统的核心。而且由于这些技能会自动触发，你不需要做任何额外操作——你的 coding agent 就这样拥有了"超能力"。

3.1 红绿TDD

是一种将测试用例的编写置于实现代码之前的软件开发实践。它不仅是验证手段，更是一种设计工具，通过"失败—通过—优化"的短循环驱动出清晰、可维护的代码结构。这一循环通常用"红—绿—重构"来形象地表示，其中"红"与"绿"对应于自动化测试运行器给出的视觉反馈状态。

1. 红色阶段（编写失败测试）
   在编写任何功能代码之前，开发者首先基于当前的需求或用户故事，编写一个自动化测试用例。该测试描述了一个尚未被实现的行为预期，因此当其首次执行时，必然因缺失对应实现而失败（测试运行器通常以红色标示）。这一阶段的目的是明确要解决的问题边界，并建立可衡量的验收标准，确保后续代码有明确的目标，同时也为重构提供安全网。

2. 绿色阶段（实现最小通过代码）
   紧接着，开发者编写最少量的实现代码，仅仅足以使刚才的失败测试转为通过（测试运行器变为绿色）。在这一步中，不应引入任何额外的功能或过度设计，代码可以暂时不够优雅，甚至可以包含硬编码，唯一的目标就是让测试变绿。这一约束迫使开发者聚焦于当前最紧迫的需求，避免"预测未来"而添加不必要的逻辑，从而贯彻 YAGNI（You Aren’t Gonna Need It） 原则。

3. 重构阶段（优化设计与消除冗余）
   在测试通过并保持绿色之后，开发者安全地对代码进行重构——即在不改变外部行为的前提下，改善代码的内部结构，例如消除重复、提升可读性、改善命名、抽取公共方法等。由于已有的测试套件充当了"防护网"，任何重构引起的回归错误都会迅速被捕获，从而保证代码的健康演进。这一阶段体现了 DRY（Don’t Repeat Yourself） 原则，并持续提升代码的内聚性与可维护性。

3.2 YAGNI

YAGNI 是 You Aren’t Gonna Need It 的首字母缩写，是极限编程（Extreme Programming, XP）中的一项核心原则。其基本主张是：仅在当前需求明确要求时才实现功能，而不应为"将来可能用到"的假设性场景提前添加额外功能或复杂架构。

这一原则旨在对抗开发过程中普遍存在的"过度设计"倾向。软件开发中，开发者（包括 AI 编码助手）常常出于"防患于未然"的考虑，主动引入抽象层、扩展接口、配置项或通用化框架，以便在未来需求变更时能够快速应对。然而，实践中这种"提前投资"往往难以收回成本——预测未来的需求变化极其困难，大量预先设计的灵活性从未被实际使用，反而成为系统的负担。

YAGNI 的约束具体体现在以下层面：

• 降低复杂性：每增加一个未使用的接口、抽象或配置参数，都会提升代码库的认知负担和维护成本。YAGNI 通过砍掉这些"可能有用"的成分，使系统在当下保持最简单、直接的状态。
• 提升交付效率：避免将时间和精力投入到当前无关的"基础设施"建设上，使开发聚焦于交付用户切实需要的功能。
• 保持重构弹性：当未来真正产生新需求时，可以在已有简单代码的基础上安全地重构、扩展，而非背负着预先设计的沉重框架寸步难行。

在 Superpowers 的上下文中，特别强调 YAGNI 是因为 AI 助手倾向于"过于贴心"——它在生成代码时往往会顺手添加日志接口、配置开关、抽象工厂等"以防万一"的结构。这些看似周全的设计，实则违背了"仅在需要时才构建"的纪律。Superpowers 通过强制遵循 YAGNI，确保 coding agent 产出的代码始终保持精炼，不掺杂任何未经需求验证的冗余成分。

3.3 DRY

DRY 是 Don’t Repeat Yourself 的首字母缩写，由 Andy Hunt 和 Dave Thomas 在《程序员修炼之道》（The Pragmatic Programmer）一书中正式提出。其核心要义可概括为：系统中的每一份知识，都必须拥有单一、明确、权威的表示形式。

在实际编码中，DRY 最直接的体现是：避免复制粘贴代码。当同一段逻辑在多个位置出现时，一旦需求发生变化，就需要在所有副本处逐一修改，这不仅效率低下，更极易引入遗漏性缺陷。DRY 原则要求将这些重复的逻辑抽取为公共的抽象——可以是函数、模块、类或配置项，使该逻辑在系统中仅存在"一处定义"，所有需要的地方均引用该定义。

DRY 原则的价值体现在以下几个维度：

• 降低维护成本：当业务逻辑发生变化时，只需修改唯一的事实来源（single source of truth），所有依赖该逻辑的调用者将自动受益，消除了"改漏一处"的风险。

• 提升一致性：确保了系统各模块对同一业务规则的理解和执行完全一致，避免了因重复实现导致的行为分歧。

• 促进代码复用：强制开发者识别共同模式并将其抽象化，进而形成可复用的组件库，为后续开发积累高质量的基础设施。

• 增强可测试性：公共抽象模块可独立进行单元测试，相比于分散在各处的重复逻辑，测试覆盖更集中、更彻底。

需要特别指出的是，DRY 并非简单追求"代码行数最少"，而是追求知识（Knowledge）的单一化。如果两段代码"看起来相似"但服务于不同的业务语义，强行合并可能引入不必要的耦合，反而违背 DRY 的初衷。真正的 DRY 强调的是同一业务规则、同一算法逻辑、同一配置信息在系统中只出现一次，其抽象粒度应以领域含义为依据，而非仅以文本相似度为准。

在 Superpowers 的实践中，通过强制性约束 coding agent 遵循 DRY 原则，有效避免了 AI 因"省事"而生成大量重复性代码结构，从而使得最终产出的软件系统具备更高的可维护性和可演进性。

4.基本工作流程

• brainstorming – 在编写代码前激活。通过提问来完善粗略的想法，探索替代方案，以分区的方式呈现设计以便验证，并保存设计文档。
• using-git-worktrees – 在设计获批后激活。在新分支上创建隔离的工作空间，运行项目设置，验证干净的测试基线。
• writing-plans – 在设计获批后激活。将工作拆分为细粒度的任务（每个任务 2–5 分钟）。每个任务都包含精确的文件路径、完整代码和验证步骤。
• subagent-driven-development 或 executing-plans – 在有计划后激活。前者为每个任务派发全新的子代理，进行两阶段审查（先检查规格合规性，再检查代码质量）；后者以批处理方式执行，并设置人工检查点。
• test-driven-development – 在实现过程中激活。强制执行红-绿-重构循环：编写失败测试，观察其失败，编写最少代码，观察其通过，然后提交。删除在测试之前编写的代码。
• requesting-code-review – 在任务间隙激活。对照计划进行审查，按严重程度报告问题。严重问题会阻塞进度。
• finishing-a-development-branch – 在任务全部完成后激活。验证测试，提供选项（合并/创建 PR/保留/丢弃），并清理工作树。

代理在任何任务之前都会检查是否存在相关技能。这些是强制性工作流程，而非建议。

5. 技能库

测试

• test-driven-development – 红-绿-重构循环（包含测试反模式参考）

调试

• systematic-debugging – 四阶段根因定位流程（包含根因追踪、纵深防御、条件等待等技术）
• verification-before-completion – 确保问题已被真正修复

协作

• brainstorming – 苏格拉底式设计精化
• writing-plans – 详细的实现计划
• executing-plans – 带检查点的批量执行
• dispatching-parallel-agents – 并发子代理工作流
• requesting-code-review – 审查前检查清单
• receiving-code-review – 回应反馈
• using-git-worktrees – 并行开发分支
• finishing-a-development-branch – 合并/PR 决策工作流
• subagent-driven-development – 快速迭代，带两阶段审查（先检查规格合规性，再检查代码质量）

元技能

• writing-skills – 遵循最佳实践创建新技能（包含测试方法论）
• using-superpowers – 技能系统简介

6.总结

核心要点回顾：

维度	关键点
是什么	为 coding agents 设计的完整软件开发方法论
为什么	解决 AI 生成代码过度设计、难以维护的问题
怎么做	通过可组合的技能自动触发，强制执行最佳实践
核心原则	TDD + YAGNI + DRY
工作流程	需求澄清 → 计划制定 → 子代理执行 → 代码审查 → 完成交付

下一篇文章预告：

在《Superpower 实战篇》中，我将使用 Claude Code 作为演示环境，通过一个真实项目展示：

• Superpowers 在 Claude Code 中的配置与启用
• 完整的开发流程实操：从需求分析到代码交付
• 实际遇到的问题与解决方案
• 效果对比：使用前 vs 使用后

---

如果这篇文章对你有帮助，欢迎点赞、收藏、转发。有问题欢迎在评论区讨论！