Superpowers实战指南：把AI编程从“写得快”变成“写得可信”

如果你最近在刷AI编程社区，应该没少看到Superpowers这个名字。我第一反应是：又来一个包装精美的提示词合集？直到我把它装进Claude Code，完整跑完一个真实的小功能，才意识到它和提示词工程的思路完全不一样——它让AI编程的重心从“写得多快”变成“写得可信”。简单说，Superpowers是一套技能（skills）体系：需求澄清、设计文档、测试驱动开发、调试、代码审查这些工程环节，全都被做成AI可以按需加载、依次执行的标准作业流程。这篇使用指南是我从安装、跑通真实项目到踩坑总结的全过程，适合那些被AI改代码改到返工、却依然想把AI认真用进日常开发的人。

先给结论：它不会让AI变得更聪明，但会让AI更有纪律。下面我先讲清楚它解决的是什么问题，再拆解安装和核心技能，最后用一次完整实战来验证它到底值不值。

1. 先聊“快”的问题：AI写代码为什么越快越不靠谱

我第一次用AI编程时的感受只有一个字：爽。一句话生成一个爬虫脚本，三分钟搭出接口demo，那种“我在指挥一个无限耐心的实习生”的感觉，确实容易上头。但爽感通常止步于第一个边界条件——比如输入文件名叫a b.txt的时候，爬虫开始乱套了。

1.1 那些年AI帮我“快速”挖的坑

我总结了三个高频坑。第一个是幻觉API。AI非常自信地推荐了一个第三方库，给我写好了文档里根本不存在的函数，一运行就报错，来回改了三轮它还在编。第二个是静默破坏。我让它改A模块的函数签名，它顺手改了调用处但没改全，B模块的调用关系断了，测试没跑，完全没人知道——直到用户报bug。第三个是无据可查。一周后回来改需求，看着AI写的代码完全不知道当初为什么这么设计，整个函数像一坨“能跑的神秘物件”。

这些坑有个共同点：不是AI不聪明，而是没有人要求它为每一步留证据、做验证。传统工程里，测试、评审、文档这些“减速带”恰恰是保证质量的关键。AI编程把这些减速带全部扔掉了，速度上去了，风险也上去了。

1.2 为什么“快”反而成了新的技术债

这里有个被很多人忽略的事实：代码的修改风险是随规模非线性上涨的。改一行代码，可能影响的调用点有几十处；每处调用点如果都没有测试保护，任何一次无验证的修改都是在往地雷阵里趟。无验证的AI编程，本质上是把这种风险以“极高频率”释放出来——它不是写错了，而是“可能写错”，而“可能写错”是最难排查的。

如果要打个比方：以前的开发像开车，虽然慢但有仪表盘、有后视镜；AI编程直接把车变成了火箭，油门踩到底，但仪表盘和后视镜都拆了。快是真的快，但你不知道什么时候会撞上哪座山。

1.3 可靠性的三个杠杆

怎么把火箭重新变成一辆好开的车？我自己的经验是三个杠杆。第一是验证：让改动在合入前有一道客观的闸门，最便宜的形式就是自动化测试。第二是外置上下文：把设计决策写进文档和文件里，而不是指望AI记得住几万token之前的约定；会话会丢，文件不会丢。第三是小步走：把一个大改动拆成多个可验证、可回滚、可评审的小步骤，每一步都看清再说下一步。

这三个杠杆单独拿出来都不是新东西，但把它们系统化地变成AI能执行的工作流，就是我接下来要讲的Superpowers在做的事。

2. Superpowers是什么：把工程纪律变成AI的“技能操作系统”

社区里对它的评价很两极：有人说它是“给AI的驾照”，有人说它是“把人类开发流程硬塞给AI”。我的体验恰好落在中间——它确实啰嗦，但也确实能让AI交出的东西经得起追问。

2.1 它不是提示词模板，是技能体系

先破除一个最常见的误会：Superpowers不是一份写满“请你严谨一点”的提示词清单。提示词是一次性的口头交代——你这次会话里跟AI说清楚了，下次开新会话又得重新讲一遍；而且AI只会把提示词当背景噪音，不太会真的改变工作方式。Superpowers则把规范做成了文件系统层面的标准作业指导书（SOP）。每一个工程环节，比如头脑风暴、写设计文档、测试驱动开发，都是一个独立的技能（skill），以SKILL.md文件的形式存在于本地目录里。

这意味着几件事：技能可以被按需加载——AI看到相关任务时才去读对应SKILL.md；技能可以被组合——一个技能可以依赖另一个技能，形成工作流；技能可以被自定义——你完全可以写一个属于你自己团队规范的新技能，放进目录里就能用。说白了，提示词是口语，技能是写进制度里的岗位说明书。

2.2 一个SKILL.md长什么样

我直接拿一个简化版举例，方便你理解它的结构：

--- name: test-driven-development description: 在实现任何新功能或修复 bug 之前，先编写会失败的自动化测试。适合需要改动代码逻辑的任务。 depends_on: - writing-design-docs --- # 执行步骤 1. 明确本次改动的最小可测试单元 2. 先编写能表达期望行为的测试用例 3. 运行测试，确认它们如预期失败（RED） 4. 编写刚好能让测试通过的最小实现（GREEN） 5. 运行全部测试，确认没有回归 6. 重构时保持测试全绿（REFACTOR）

最关键的其实是开头的frontmatter。name是技能名，description是AI决定“什么时候读这个技能”的依据；depends_on让技能能按顺序串联。如果description写得模糊，AI可能在该用的时候想不起来；写得太宽泛，又会频繁触发打断流程。这是定制技能时最花心思的地方。

2.3 安装与目录结构

安装本身不复杂。官方推荐的方式是在Claude Code会话里直接执行：

/plugin install obra/superpowers

它会自动把插件仓库拉到本地并注册。如果你更喜欢手动控制，也可以自己clone到插件目录再在Claude Code里加载。装完之后，技能会落在类似这样的目录结构里：

~/.claude/skills/ ├── brainstorming/SKILL.md ├── writing-design-docs/SKILL.md ├── turning-design-docs-into-tasks/SKILL.md ├── test-driven-development/SKILL.md ├── debugging/SKILL.md └── doing-code-review/SKILL.md

怎么确认装好了？最简单的办法是直接问AI：“你现在有哪些技能？”或者开一个新会话看它是否主动提到可以使用brainstorming。需要提醒的是，这个项目迭代非常快，插件命令和目录位置在不同版本可能有调整，一切以仓库README为准——我写这篇时用的就是上面的命令。

2.4 按需加载：技能为什么不会撑爆上下文

这是Superpowers在设计上最聪明的一点。如果把所有工程规范一次性塞进系统提示词，上下文窗口立刻爆炸；而它的做法是：利用Claude Code的hooks机制，在会话启动时只往上下文里放一份“技能清单”（每个技能的name和description），真正的SKILL.md正文先不读。等对话进行到某个节点，AI发现当前任务与某个技能的描述匹配，才去读取对应的完整步骤。

同时，Superpowers还大量使用带@标签的文件。比如设计文档写到.specs/@design.md，这等于给文件加了个可引用的标签。当前面某个决策被反复引用时，AI可以通过标签把对应文档拉回视野，而不是靠记忆硬撑。这两个机制合起来，既保证了纪律，又守住了上下文预算。

3. 核心技能管线拆解：从想法到上线，每个环节都有岗位说明书

Superpowers的价值不在某一个技能，而在整条管线。从你一句“我想做个功能”开始，到代码真正合入，每个环节都有人管、有章法。

3.1 Brainstorming：先别写代码，把需求聊清楚

整个管线里，我最喜欢也最常用的是brainstorming技能。触发场景很日常：你刚说了一句“我想给这个项目加个批量重命名功能”，AI不会立刻开始写代码，而是会告诉你“我建议先用 brainstorming 技能把需求理清楚”，然后开始一轮轮提问。

它会问的大概是这些：这个功能的核心用户是谁？除了批量重命名，还要支持正则吗？要不要递归处理子目录？如果目标文件名已经存在，是报错、跳过还是自动改名？要不要支持dry-run预览？这些问题的价值在于：它把“模糊的愿望”翻译成了“可验收的需求”，而且是在动手前就完成翻译。

我见过太多AI翻车都源于需求歧义。你跟它说“帮我优化一下这段代码”，它不知道“优化”指的是性能、可读性还是结构，最后交出一份全错的答卷。brainstorming本质上是在给AI减少自由度——自由度越小，幻觉空间越小。

3.2 写设计文档与任务拆解

聊清楚了，下一个技能通常就是写设计文档。AI会生成一份包含数据流、边界情况、模块划分、测试策略的文档，我一般是让它写到项目的.specs/目录里。这一步看着像走形式，实际价值极大：设计文档把“上下文”从易失的会话内存，搬到了持久的文件系统。就算第二天重新开会话、甚至换个人来接手，约束和决策都在文档里，AI不会因为上下文丢失而把前面的约定推翻。

紧接着会有一个把设计文档变成任务列表的技能。它会把整个功能拆成一个个小任务：“先写重命名计划的纯函数”“再加CLI参数解析”“最后处理冲突策略”，每个任务都小到可以独立验证。这一步对应的是我前面说的小步走原则——大改动被拆开后，每一步都有检查点，AI不容易跑偏。

3.3 TDD：可靠性的心脏

任务拆完之后，最核心的环节来了：测试驱动开发（TDD）。AI会按照技能要求，先写一个表达期望行为的失败测试，运行一次确认它是红的，然后才写最简实现让它变绿，最后跑全部测试确认没有回归。这个过程对AI而言是一种“强制诚实”机制——它必须先承认“现在这个功能还不存在”，再证明“现在它符合预期”了。

这里有一个绕不开的前提：你的项目必须有一个能本地运行的测试命令。Python项目就是pytest，Node项目是vitest或jest，Rust项目是cargo test。Superpowers自己不会创造测试基建，它只是在逼你把基建用起来。我第一次用的时候正好踩了坑：仓库里的旧代码连一个测试都没有，AI想按TDD流程走，结果跑测试就跑不起来。后来我先补了一个能通过的空测试，才把这个环节跑顺。

为什么说测试是幻觉检测器？因为AI最大的问题是“自信地编造”。没有测试时，它可以信誓旦旦说“改好了”；有了测试，跑一遍，红就是红，绿就是绿，没有任何辩解的余地。这是我在实操里感受最深的点。

3.4 调试、代码审查与重构

测试全绿之后，管线还没结束。如果中途遇到bug，Superpowers会切到debugging技能：先建一个能稳定复现失败的用例，再做根因分析，而不是让AI凭着记忆疯狂加日志乱猜。这个思路和资深工程师排障的逻辑一模一样：先复现，再定位，最后修复，每一步都有依据。

代码写完之后还有代码审查技能。它会让AI自己review一遍diff，检查边界条件、异常处理、命名一致性。你别说，我发现AI自查真能抓到不少问题——尤其是它自己在长对话里写出来的那些“顺手”代码。最后，当测试网足够密的时候，重构技能才敢放心使用。没有测试保护的重构是赌命，有测试保护的重构才是工程。

4. 实战复盘：用Superpowers给一个CLI工具加“批量重命名”命令

空讲没意思，我拿上周刚做的一个真实小功能来复盘。项目是一个Python写的文件处理CLI工具，我当时的原始需求只有一句话：“加个批量重命名命令，支持正则替换。”

如果按以前的习惯，我大概率会直接让AI写代码。但装了Superpowers之后，AI先回了一句：“建议先使用brainstorming技能明确需求。”接着它问我：匹配方式是只替换文件名还是也处理目录名？递归遍历子目录吗？目标文件已存在时，报错还是覆盖？要不要dry-run？要不要输出变更日志？要不要处理后缀名？这些问题我大部分其实没想过，边答边把需求补全了。一轮下来，需求从“正则替换”变成了“递归替换文件名，冲突时默认跳过，支持--dry-run预览，输出JSON格式日志”。动手前就清晰到这个程度，这在以前是不可想象的。

4.1 设计文档、任务拆解、红绿循环

需求明确后，AI写了一份设计文档到.specs/batch-rename.md，然后拆出四个任务：纯函数build_rename_plan、CLI参数解析、冲突策略、日志输出。第一个任务我先让AI按TDD流程来，它在测试文件里写下了这样的用例：

# tests/test_renamer.py from renamer import build_rename_plan def test_conflict_skips_existing_target(): files = ["a.txt", "b.txt"] mapping = {"a.txt": "b.txt"} plan = build_rename_plan(files, mapping, on_conflict="skip") assert len(plan) == 1 assert plan[0].skipped is True

先跑了一次，测试如预期失败；然后AI写了最简实现让测试变绿；再跑全部测试确认没回归。整个过程我可以看到每一步的证据：红在哪、绿在哪、为什么这样改。说实话，这种“被验证过的进度”带来的安全感，和以前那种“看起来能跑”完全是两码事。

4.2 中途改需求：测试救了我一次

项目做到一半，需求变了：冲突处理策略从“跳过”改成“自动加后缀”。这个改动放在以前，我会很慌——因为AI可能只改主逻辑、忘记改测试和文档，甚至静默地留下不一致的行为。但这次流程是倒过来的：我先让AI改测试，把期望行为从跳过改成b_1.txt这样的后缀文件；测试红；再改实现；测试全绿。最后AI还主动更新了设计文档里的冲突策略章节。

那次之后我想明白了一件事：测试在这里护的不是代码，是“需求变更时的安全感”。没有测试，需求变更就是赌博；有测试，需求变更就是一次可预期的重构。

4.3 体感对比：慢了多少，值不值

我也记了一下时间账，用最直白的数字说话。

所以我的结论是：如果你只算“出第一版代码的时间”，Superpowers是慢的；如果你算“从开始到稳定交付的时间”，它大概率更快。可靠性不是免费的，但它比返工便宜得多。

5. 别硬上：Superpowers的边界与依赖条件

任何工具都有边界，Superpowers也不例外。我用了一段时间以后，反而更清楚哪些场景应该果断绕过它。

5.1 这三个场景我基本不用它

第一个是纯探索性脚本。比如我想临时看某个API返回什么结构，写个一次性脚本跑一下，直接让AI写就行，走完整流程纯属浪费时间。第二个是纯前端视觉细节的迭代。CSS像素级调整、动画手感这类东西，自动化测试很难覆盖，测试驱动的收益很小。第三个是完全没有测试基建的存量老项目。按TDD流程写第一个测试之前，你得先解决“这项目怎么跑测试”这个历史遗留问题，否则技能会卡在第一步。

顺便说一句，不用的场景不代表Superpowers不好，而是它解决的是“可靠性问题”，不是“便利性问题”。选工具先看痛点，这是一个老生常谈但永远有人犯的错。

5.2 它的隐藏依赖

真要把它用好，有几个绕不开的外部条件。首先，需要有一个能本地快速运行的自动化测试命令，而且项目本身要能稳定跑起来；我见过有人拿一个启动要两分钟的巨型单体项目来跑TDD，每次循环都在等，体验很差。其次，需要你愿意保留人工检查点：设计文档要人看、关键任务要人验收，AI仍是那只会自信犯错的语言模型。最后是token预算，完整流程的上下文消耗明显比裸提示多，成本会上升，对个人开发者来说这是一笔真实开销。

5.3 和提示词工程、Cursor Rules的对比

市面上常见的AI编程提效方案，我放在一起比过。

三者其实不冲突。Cursor Rules可以管住底线，提示词可以表达偏好，Superpowers负责把“怎么做”变成可执行的流程。我现在的做法是：用Cursor Rules约束红线，把Superpowers当主力工作流，默认提示词只负责描述眼前的目标。

6. 我的实操心得：安装后先做这三件事

6.1 把测试基建配好，再谈纪律

前面提到过，TDD技能最怕的项目是没有测试环境的项目。所以我建议你拿到Superpowers之后，第一件事不是去改老代码，而是新建一个最小的、有测试命令的项目，比如一个只有三四个函数的Python包：配好pytest，跑通一个空测试。然后用这个项目完整走一遍brainstorming→设计文档→TDD的小闭环。第一次跑通循环的体感，比看十篇教程都重要。

6.2 学会“点菜”，不要等AI自己触发

技能虽然是按需加载，但AI的触发判断并不总是完美。我的经验是：该用的场景直接说“用brainstorming技能帮我把这个需求理清”，或者手动输入/skill brainstorming强制触发。不要害羞，这是最有效的控制方式。

另外，自定义技能真的值得一试。SKILL.md的语法很简单，你只要给一个清晰的name、一段准确的description、和几段具体到可执行的步骤就行。我自己给团队写了一个“发布前检查”技能：确认版本号、跑完整测试、更新CHANGELOG、打tag。现在每次发版，AI都会一丝不苟地按这个清单走，比我以前一遍遍口头提醒可靠多了。注意description一定要写清楚触发条件，否则AI该用它的时候想不起来，不该用的时候反而话痨。

6.3 关于速度与成本的实话

最后说点没人写在README里的实话。完整流程确实会让单次任务变慢：一个小功能可能要来回多花二十分钟。但如果你统计的是“从接到需求到稳定上线”的总时长，尤其当项目里开始有历史代码、有多个模块互相依赖时，慢下来的流程反而在帮你止损。我自己的项目里，启用Superpowers之后，AI返工率肉眼可见地降了，最明显的变化是我改需求时不再忐忑了。

而且我逐渐把技能当成了一种团队资产。技能文件可以进版本库、可以被团队共享，等于把“我们团队要怎么做开发”这件事固化成了AI也能读的制度。这才是它最值钱的地方。

如果你也想试，我的建议是别第一天就把所有技能塞给它，只先走一次brainstorming→设计文档→TDD的小闭环，亲身感受一下“被验证过的慢”和“没验证的快”到底哪个更省心。我不保证你会爱上那堆文档和测试，但我保证你会对AI给出的每一个“改好了”，多一分自己的判断。