如果你最近在刷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项目就是pytestNode项目是vitest或jestRust项目是cargo test。Superpowers自己不会创造测试基建它只是在逼你把基建用起来。我第一次用的时候正好踩了坑仓库里的旧代码连一个测试都没有AI想按TDD流程走结果跑测试就跑不起来。后来我先补了一个能通过的空测试才把这个环节跑顺。为什么说测试是幻觉检测器因为AI最大的问题是“自信地编造”。没有测试时它可以信誓旦旦说“改好了”有了测试跑一遍红就是红绿就是绿没有任何辩解的余地。这是我在实操里感受最深的点。3.4 调试、代码审查与重构测试全绿之后管线还没结束。如果中途遇到bugSuperpowers会切到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_conflictskip) assert len(plan) 1 assert plan[0].skipped is True先跑了一次测试如预期失败然后AI写了最简实现让测试变绿再跑全部测试确认没回归。整个过程我可以看到每一步的证据红在哪、绿在哪、为什么这样改。说实话这种“被验证过的进度”带来的安全感和以前那种“看起来能跑”完全是两码事。4.2 中途改需求测试救了我一次项目做到一半需求变了冲突处理策略从“跳过”改成“自动加后缀”。这个改动放在以前我会很慌——因为AI可能只改主逻辑、忘记改测试和文档甚至静默地留下不一致的行为。但这次流程是倒过来的我先让AI改测试把期望行为从跳过改成b_1.txt这样的后缀文件测试红再改实现测试全绿。最后AI还主动更新了设计文档里的冲突策略章节。那次之后我想明白了一件事测试在这里护的不是代码是“需求变更时的安全感”。没有测试需求变更就是赌博有测试需求变更就是一次可预期的重构。4.3 体感对比慢了多少值不值我也记了一下时间账用最直白的数字说话。对比维度以前的裸提示模式用Superpowers走完整流程首轮产出几分钟就出代码先聊天再写文档前30分钟基本在“问和写”总交付时间看似快返工占一半前期慢30%整体反而更快中途改需求心惊胆战靠肉眼查改测试、跑测试心里有底一周后接手代码能跑但不知道为什么有设计文档、有测试、有变更历史所以我的结论是如果你只算“出第一版代码的时间”Superpowers是慢的如果你算“从开始到稳定交付的时间”它大概率更快。可靠性不是免费的但它比返工便宜得多。5. 别硬上Superpowers的边界与依赖条件任何工具都有边界Superpowers也不例外。我用了一段时间以后反而更清楚哪些场景应该果断绕过它。5.1 这三个场景我基本不用它第一个是纯探索性脚本。比如我想临时看某个API返回什么结构写个一次性脚本跑一下直接让AI写就行走完整流程纯属浪费时间。第二个是纯前端视觉细节的迭代。CSS像素级调整、动画手感这类东西自动化测试很难覆盖测试驱动的收益很小。第三个是完全没有测试基建的存量老项目。按TDD流程写第一个测试之前你得先解决“这项目怎么跑测试”这个历史遗留问题否则技能会卡在第一步。顺便说一句不用的场景不代表Superpowers不好而是它解决的是“可靠性问题”不是“便利性问题”。选工具先看痛点这是一个老生常谈但永远有人犯的错。5.2 它的隐藏依赖真要把它用好有几个绕不开的外部条件。首先需要有一个能本地快速运行的自动化测试命令而且项目本身要能稳定跑起来我见过有人拿一个启动要两分钟的巨型单体项目来跑TDD每次循环都在等体验很差。其次需要你愿意保留人工检查点设计文档要人看、关键任务要人验收AI仍是那只会自信犯错的语言模型。最后是token预算完整流程的上下文消耗明显比裸提示多成本会上升对个人开发者来说这是一笔真实开销。5.3 和提示词工程、Cursor Rules的对比市面上常见的AI编程提效方案我放在一起比过。方案形态可靠性来源主要短板提示词工程会话内一次性指令取决于你写得有多细无状态每次会话重新建立AI容易当背景噪音Cursor Rules项目级约束文件限制AI“不要做什么”偏防守缺少主动的工作流Superpowers技能SKILL.md程序化工作流测试、文档、小步验证需要测试基建和更大的token开销三者其实不冲突。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给出的每一个“改好了”多一分自己的判断。