夜雨聆风写在前面
如果你正在使用Claude Code、Codex、Cursor、OpenCode等AI编程工具，你可能已经发现一个问题：这些工具虽然强大，但有时候会"太主动"——不等你想清楚就开始写代码，或者跳过测试直接实现功能，或者在没有计划的情况下就埋头苦干。结果呢？代码写了不少，但需要返工的地方更多。
Superpowers就是为了解决这个问题而生的。它不是一个新的AI工具，而是一套完整的方法论，让你的AI编程助手变得更"靠谱"。它的核心理念很简单：在动手之前先思考，写代码之前先计划，完成之后先验证。
这个系列文章会详细介绍Superpowers的每一个组成部分。我不会照搬官方文档，而是用自己的理解和实际例子来解释，确保你读完能真正用得上。
一、Superpowers是什么
Superpowers是一个软件开发的"配方"，专门给AI编程助手用的。它由一系列可组合的"技能"（skills）组成，每个技能对应开发过程中的一个环节。当你的AI工具加载了Superpowers之后，它会在合适的时机自动触发相应的技能，不需要你额外下令。
想象一下：你对AI说"帮我写个用户登录功能"。没有Superpowers的AI可能直接就开始写代码了。有Superpowers的AI会：
1. 先停下来问你一些问题——你要实现什么样的登录？要不要支持双因素认证？用什么方式存储密码？ 2. 听完你的回答后，给出一个设计草案让你确认 3. 确认之后，它会制定一个详细的实现计划，列出每一步要做什么 4. 开始实现，每完成一步就运行测试验证 5. 完成后还会主动做代码审查，确保质量
这就是Superpowers的日常工作方式。它不是限制AI的能力，而是引导AI用更专业的方式工作。
1.1 核心理念
Superpowers建立在三个核心原则之上：
第一，先想再做。 这是最重要的原则。不管任务多简单，AI都不应该直接跳到写代码那一步。它需要先理解你要什么，明确怎么做，然后才开始实施。一个简单的配置修改可能只需要几句话的设计，但这个步骤不能省。"简单"往往是最容易出问题的——因为简单，所以容易掉以轻心。
第二，小步快跑。 把大任务拆成许多小步骤，每一步都写出可运行的代码、可以通过的测试。每完成一步就验证一步，不等问题堆到后面再一起解决。这也就是我们常说的TDD（测试驱动开发）的核心思路。
第三，验证再宣称。 不管AI觉得工作完成了没有，它必须实际跑一遍验证命令，用输出结果来证明而不是用"应该没问题"来猜测。测试通过才能说通过，构建成功才能说成功。
1.2 安装和使用
Superpowers支持多种AI编程工具，包括Claude Code、Codex CLI、Codex App、Cursor、OpenCode、GitHub Copilot CLI等。安装方式因工具而异，但核心思路是一样的——通过插件机制加载Superpowers技能。
对于Claude Code，用户可以从Anthropic官方插件市场安装，或者添加Superpowers社区市场后安装。安装完成后，AI工具会自动加载所有技能，在合适的时机触发。
安装完成后，大部分技能会在合适的时机自动触发。你只需要用正常的方式表达你的需求，AI就会按照Superpowers的流程来工作。当然，一些平台相关的操作（如插件安装、工作树创建）仍然需要对应的命令，但这些属于工具本身的操作，不是Superpowers引入的额外负担。
二、Superpowers的技能体系
Superpowers由多个技能组成，每个技能对应开发过程中的一个特定环节。它们按照合理的顺序连接起来，形成完整的工作流程。
2.1 技能一览
下面是主要技能的简单介绍，后续文章会逐一详细讲解。注意这里有一个特殊技能排在最先：
using-superpowers 是所有技能的"总管"。它不是让你直接用的工具，而是AI加载Superpowers时的入口技能。它告诉AI已经安装了哪些技能、分别在什么场景下使用、如何按正确的顺序调用。当你启动AI工具并加载了Superpowers插件时，using-superpowers首先被激活，确保AI知道整套工作流程。之后，其他技能才会在各自的时机自动或手动触发。
brainstorming（头脑风暴） 是整个流程的起点。当AI识别到你在创建新功能、添加组件或修改行为时，它会自动触发这个技能。它的任务是确保AI真正理解你想做什么，而不是根据字面意思就开始实现。brainstorming会探索项目背景、提出澄清问题、展示设计方案、在获得批准前不会动手写代码。
writing-plans（编写计划） 在设计方案确认后使用。它的任务是把设计变成可执行的实施计划——具体到每个文件怎么改、每个任务分几步、每步要验证什么。这个计划要清晰到任何一个有基础编程能力的人都能照着做。
test-driven-development（测试驱动开发） 是编写代码的核心方式。它的流程是：先写一个失败的测试，运行确认它确实失败，然后写最少的代码让测试通过，最后重构优化。跳过测试直接写代码是被严格禁止的。
subagent-driven-development（子代理驱动开发） 解决的是如何并行处理多个任务。当计划中有多个独立的任务时，AI会为每个任务创建一个子代理，让它们同时工作。完成后还有两轮审查——先检查是否符合规范，再检查代码质量。
executing-plans（执行计划） 是计划执行的另一种方式，适用于在**独立会话（separate session）**中执行计划，带有审查检查点。AI会加载书面计划，逐个完成任务并在关键节点进行审查。当子代理可用时，优先使用子代理驱动开发；executing-plans 主要用于无法使用子代理或需要跨会话执行的场景。
systematic-debugging（系统化调试） 用于处理任何问题——测试失败、Bug、性能问题、构建失败等。它的核心原则是：在提出任何修复方案之前，必须先找到根本原因。随机尝试修复是严格禁止的。
receiving-code-review（接收代码审查） 和 requesting-code-review（请求代码审查） 处理代码评审的各个环节。收到反馈时需要验证而不是盲目执行，完成重要功能后需要主动请求审查。
verification-before-completion（完成前验证） 是最后一道关口。任何时候想要宣称工作"完成"、"通过"或"修复"了，必须先实际运行验证命令，用输出结果来证明。
writing-skills（技能写作） 用于创建、修改和优化 Superpowers 技能本身的工具。它采用测试驱动开发的方式来保证技能的质量——先写测试验证技能的行为，再实现技能逻辑，最后重构优化。这不是常规文档写作，而是元技能：用来制作和维护其他技能的技能。
using-git-worktrees（使用Git工作树） 确保工作发生在隔离的分支上，避免污染主分支。
finishing-a-development-branch（完成开发分支） 处理收尾工作——验证测试、检测环境、呈现选项（合并、创建PR、保留或丢弃）、执行选择。
dispatching-parallel-agents（并行代理调度） 当有多个独立的问题需要调查时，同时派代理去处理，而不是逐个排队。
2.2 技能触发机制
这些技能中的大部分会在合适的时机自动触发。当AI检测到你表达的意思是创建、添加、修改或实现什么东西时，brainstorming会自动触发。当设计确定后需要计划时，writing-plans会自动触发。测试驱动开发在编写代码时会自动遵循红绿重构的纪律。
但也有一些技能需要你主动调用。比如 requesting-code-review 在你完成重要功能后需要手动触发审查流程，executing-plans 在你需要让AI跨会话执行计划时使用，using-git-worktrees 在需要隔离工作空间时触发。这些技能不是自动的——它们是对特定场景的针对性操作。
总体来说：你不需要额外去学什么新命令，正常表达需求，AI会自动进入对应的工作流程。但了解这些技能的存在和适用场景，能让你在需要时主动利用它们。一些平台相关的操作（比如Claude Code的/plugin install、工作树创建等）仍然需要使用对应的命令，但这些都是工具层面的操作，不属于Superpowers引入的学习成本。
三、为什么需要这样一套方法论
你可能会问：AI不是已经很聪明了吗？为什么要给它设置这么多"规矩"？
3.1 AI的常见问题
我见过太多这样的情况：你让AI写一个功能，它二话不说就开始写代码。写到一半你发现它理解错了，或者实现方式不符合你的预期。你不得不停下来纠正它，然后看着它删掉一部分代码重新来过。
还有更糟糕的：AI跳过测试，说"这个功能太简单了不需要测试"，结果上线后出现Bug。或者AI没有验证代码是否真的能跑，就告诉你"完成了"，结果你一运行发现编译错误。
这些问题不是AI的错——它们缺少足够的"工程纪律"。Superpowers就是给AI补上这一课。
3.2 人类工程师的思考方式
回想一下你作为人类工程师是怎么工作的：
当你接到一个新任务时，你不会立刻开始写代码。你会先问清楚需求，然后设计方案，评估技术选型，列出实现步骤，写代码的时候也是先写测试，写完以后运行测试验证，最后还会做代码审查。
Superpowers做的事情，就是把这种专业的工程思维教给AI。
四、这个系列会讲什么
接下来的文章会逐一深入讲解每个技能。以下是计划的内容：
第二篇会详细讲解**brainstorming（头脑风暴）**技能——为什么它在动手之前必不可少，如何通过提问来澄清需求，如何展示设计方案并获得确认。
第三篇会讲解writing-plans（编写计划）——如何把模糊的设计变成详细的实施计划，计划应该包含哪些内容，怎么写出让任何人都能执行的任务步骤。
第四篇会深入讲解test-driven-development（测试驱动开发）——红-绿-重构的流程，具体怎么写测试，为什么不能先写代码再补测试。
第五篇会介绍subagent-driven-development（子代理驱动开发）——当你需要同时处理多个任务时，如何让AI高效地并行工作，同时保持质量。
第六篇会讲解systematic-debugging（系统化调试）——遇到Bug时怎么系统地找到根本原因，而不是凭感觉乱试。
第七篇会讲代码审查的学问，包括receiving-code-review（接收审查）和requesting-code-review（请求审查）——如何正确处理反馈，如何主动寻求审查。
第八篇会介绍verification-before-completion（完成前验证）——为什么"运行一下看看"比"我觉得没问题"更重要。
第九篇会讲解using-git-worktrees（Git工作树）和finishing-a-development-branch（完成开发分支）——如何安全地隔离工作，如何正确地结束一个开发周期。
第十篇会介绍dispatching-parallel-agents（并行代理调度）——当你面对多个独立问题需要调查时，如何让AI并行处理来提高效率。
第十一篇会讲解executing-plans（执行计划）——当你的AI工具不支持子代理，或者需要跨会话执行计划时，如何让AI加载已有的计划并逐个完成。
五、总结
Superpowers不是要取代AI的能力，而是让AI的能力用在正确的地方。它教会AI先理解需求再动手，把大任务拆成小步骤，每步都验证通过再继续，最后还要用事实来证明而不是用感觉来判断。
这不是什么高深的理论，而是实实在在的工程实践。当AI遵循这些原则工作时，它会变得更可靠、更少返工、产出质量更高。
在接下来的文章里，我会带着具体的例子，详细讲解每个技能怎么工作，怎么用好它。敬请期待。
