夜雨聆风它很聪明，打字比我快十倍，什么语言都会写，凌晨三点也不用休息。但它有一个毛病——太急了。
你跟它说"帮我加个登录功能"，它立刻噼里啪啦写三百行代码。没有测试，没有文档，数据库的表结构是它自己编的，字段名还拼错了一个。等你花一个小时读完它写的东西，再花两个小时修完它留下的坑，天已经快亮了。
它不是不够聪明。它是不够沉得住气。
后来我给它装了一样东西，叫 Superpowers。装完之后，它像是换了个人。
它是什么
Superpowers 是 Jesse Vincent 做的一套开源技能包，目前到了 v5.1.0。说白了，它不是一个新的 AI，而是给现有 AI 编程助手加了一套工作规矩——14 个技能，串成一条完整的软件开发流水线。
支持 Claude Code、Codex CLI、Gemini CLI、Cursor、Copilot CLI，基本上主流的 AI 编程工具都能用。
装上之后，你的 AI 不再上来就写代码。它会先想清楚要做什么，再动手。
核心工作流
整套流程分七步。官方文档里列得很清楚，我按自己的理解捋一遍。
第一步：brainstorming——先坐下来聊聊。
现在我说"帮我做个 XX"，它不会立刻动手。它会先问我问题，一次一个，不会十个一起甩过来。你到底要什么？有什么限制？怎样算做好了？
问清楚之后，它给我两三个方案，各自有什么好处和代价，推荐哪个、为什么。我点头了，它才把设计写下来，存成 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，提交到 Git。
老实说，第一次用的时候我有点不耐烦——我都想好了你直接写不就行了？但后来发现，它问的那几个问题，真的帮我想清楚了好几个我自己没考虑到的边界情况。
第二步：using-git-worktrees——找一间干净的房间。
设计通过后，它不会直接在主分支上动手。它会用 Git worktree 创建一个隔离的工作空间，开一条新分支，跑一遍项目的测试确认基线是干净的，然后才开始干活。
这一步很容易被忽略，但其实很重要。在一个干净的环境里开始工作，出了问题能立刻知道是自己引入的，不用花时间排查"这 bug 是不是之前就有的"。
第三步：writing-plans——把一件大事拆成很多小事。
设计定了，环境也准备好了，它开始拆活。一整件事被拆成若干个小任务，每个 2-5 分钟能做完。要改哪个文件、写什么代码、怎么验证，都写得清清楚楚，存到 docs/superpowers/plans/ 下面。
它自己说，这些任务要详细到"一个没什么判断力的初级工程师也能照着做完"。我笑了。它说的那个初级工程师，就是它接下来要派出去的子智能体。
第四步：subagent-driven-development（或 executing-plans）——一个人变成一支队伍。
这一步是我觉得设计得最聪明的地方。
它不会在一个上下文里把所有任务从头做到尾。原因很实际——做到后面，前面的事就忘了。上下文窗口就那么大，塞满了就开始丢东西。
所以它给每个任务派一个全新的子智能体（subagent），拿到精确的任务描述和必要的上下文，干完一件事就交差。主智能体负责协调和质检，像一个项目经理。
这里有两种模式可以选。subagent-driven-development 是在同一个会话里连续执行，中间不停顿，适合你想让它一口气跑完的场景。executing-plans 是分批执行，每批之间会停下来让你检查，适合你想保持更多控制的场景。
第五步：test-driven-development——先写考题，再写答案。
整个实现过程中有一条铁律：RED-GREEN-REFACTOR。
先写测试，跑一下，看它挂掉（红灯）。再写最少的代码让测试跑过（绿灯）。最后重构，清理代码。如果子智能体偷懒先写了实现再补测试，会被要求删掉重来。
这条规矩听着死板，但确实管用。我见过太多"测试后补"最后变成"测试不补"的情况了。
第六步：requesting-code-review——做完一件，审一件。
每个任务完成后要过两道审查。第一道是 spec compliance review，看实现有没有偏离设计——多做了不行，少做了也不行。第二道是 code quality review，看代码本身写得好不好。
审查没过就打回去改，改完再审，直到过为止。严重问题（Critical）会直接阻断后续任务的执行。
有点像一个严格的师傅带着一群徒弟。徒弟干活，师傅验收。
第七步：finishing-a-development-branch——收拾干净再走。
所有任务做完，先跑一遍测试确认全过了，然后给你几个选项：直接合并到主分支、创建 Pull Request、保留分支、或者放弃。你选，它执行，最后清理工作目录和 worktree。
技能全家福
14 个技能分四类，这里列一下，方便查阅。
协作类——关于怎么想和怎么计划：
brainstorming：把模糊的想法变成清晰的设计writing-plans：把设计拆成可执行的任务清单executing-plans：分批执行，每批之间有人工检查点subagent-driven-development：子智能体驱动，同一会话里连续执行dispatching-parallel-agents：并行派发多个独立任务
质量类——关于怎么保证做得好：
test-driven-development：测试驱动，强制 RED-GREEN-REFACTORrequesting-code-review：主动发起代码审查receiving-code-review：收到审查意见后怎么处理verification-before-completion：完成前必须拿实际输出证明结果
调试类——关于怎么修问题：
systematic-debugging：四阶段根因分析，没找到原因不许动手修
工程类——关于怎么管理代码：
using-git-worktrees：用 Git worktree 创建隔离工作空间finishing-a-development-branch：分支收尾writing-skills：写新技能的规范
还有一个 using-superpowers，是整套系统的入口，每次对话开始时自动加载，决定接下来该调哪些技能。
哪些规矩能变，哪些不能
技能分两种脾气。
有些是铁的。 TDD、systematic-debugging、verification-before-completion——这几个不能绕。你没跑测试就说"搞定了"？不行，拿证据来。你没找到根因就提了个 fix？不行，回去查清楚。
说实话我有时候也觉得烦，明明一个很小的改动还要走一遍完整流程。但每次想跳过的时候，我就想起之前那些"小改动引发大事故"的惨痛经历，然后老老实实走完了。
有些是活的。代码审查具体关注什么、设计文档写多细、任务拆多小，这些可以根据项目情况调。
还有一条：你说的话永远比它的规矩大。 你在 CLAUDE.md 里写了"不要用 TDD"，它就不用。工具服务于人，这一点它很清楚。
怎么装
Claude Code 用户，一行命令：
/plugin install superpowers@claude-plugins-officialCodex CLI 用户，在插件搜索界面搜 superpowers 装。Gemini CLI 用户：
gemini extensions install https://github.com/obra/superpowersCursor 用户在 Agent 聊天里输入 /add-plugin superpowers。
装完之后不用做别的。下次你跟 AI 说"帮我做个 XX"，它会自动走完整套流程——先 brainstorming 问你问题，再 using-git-worktrees 开辟工作空间，然后 writing-plans 拆任务，接着 subagent-driven-development 逐个执行，全程遵守 test-driven-development，每个任务完成后走 requesting-code-review 审查，最后 finishing-a-development-branch 收尾。
也可以手动触发，比如直接说"用 brainstorming 来想想这个功能怎么做"。
设计文档和执行计划都存在项目的 docs/superpowers/ 目录下，会提交到 Git。 下次你或别人接手，打开这些文件就能看到当时的思路。这个我觉得是个很好的副产品——很多项目最缺的不是代码，是"为什么这样写"的记录。
它让一切变慢了
这大概是 Superpowers 最反直觉的地方。
问问题要时间，写文档要时间，拆任务要时间，两轮审查要时间。走完整套流程，比直接让 AI 甩代码慢得多。
但出来的东西不一样。
怎么说呢。以前它写的代码，我要花很长时间去理解、去修、去补测试。现在它写的代码，我大部分时候看一眼就能合进去。总时间算下来，其实差不多，甚至更短。
而且省掉的不只是时间，还有那种"这代码到底能不能用"的焦虑。
它安静了很多。不再上来就是一通输出，而是先停下来想一想，问一问。有时候我盯着它问我的那些问题，会觉得——诶，这个问题我自己确实没想过。
最后
说到底，Superpowers 做的事情并不复杂。就是把软件工程里那些"大家都知道应该做但经常偷懒不做"的事情，变成了一套自动执行的流程。
想清楚再动手，写了测试再写代码，做完了要检查，检查完了要收拾。
这些事情你我都知道。但知道和做到之间，差了一个 Superpowers。
