Superpowers到底是个什么级别的工具很多人一开始是低估它的。第一次听说时我以为它不过是一套AI编程提示词合集充其量让Claude、Cursor这类工具更听话一点。真正用了一段时间后我才意识到这东西解决的根本问题不是“让AI多写两行代码”而是把AI编程里最让人头疼的随机性按下去让产出从“看起来能用”变成“真的敢上线”。这篇东西就把我的实际使用过程、踩过的坑、以及为什么它能改变AI编程方式的逻辑一次说清楚。如果你正在用AI编程助手每天生成代码很多但合并到主干就报错如果AI信誓旦旦说测试都过了结果一跑就挂如果你已经开始意识到“提示词技巧”救不了稳定性——那Superpowers就是为这个场景准备的。它跟我见过的那类花架子Prompt模板完全不是一回事它更像一套把成熟工程方法论塞进AI工作流里的技能组合套装。1. 先搞懂Superpowers在解决什么问题1.1 从“生成代码”到“交付可靠代码”的差距在哪过去一年我用过不少AI编程工具最直观的感受是它们生成代码的速度确实快快到你甚至会产生一种错觉觉得一个下午就能把一个项目从0推到上线。但这种“快”是有代价的。AI在上下文不够清晰、验证手段缺失的情况下会非常自信地给出一个语法完全正确、设计却有致命问题的方案。我遇到过的最典型的情况是这样的让AI“实现一个订单导出功能”它直接撸了一个CSV生成函数文件能跑但没有任何编码处理没有空值判断日期格式还是美国人的习惯。测试没有。异常处理没有。问它“边界情况呢”它说“我还没有考虑”。这就是典型的“快而不靠谱”——它不是在偷懒而是没有一套流程强制它停下来想清楚再动手写。Superpowers这个名字取得很准确它给AI“装”上的不是某个单一技能而是一整套与工程相关的行为约束。装上之后AI再接到需求不再是一秒进入代码输出模式而是先拆解、再问边界、再补测试、最后才落实现。整个过程肉眼可见地从“手快”变成“脑快”。1.2 它不是提示词模板而是一套“工作方法论”我在网上看过不少人把Superpowers理解成“更长的提示词”这是最大的误解。如果你只是把一段所谓的Superpowers咒语粘贴进对话框AI可能会有那么两三轮的“角色扮演”但很快就会打回原形。核心原因在于提示词是会话级的它没法把行为方式固化下来更没法让AI在不同的文件、不同的子任务里持续保持一致的工作习惯。Superpowers采用的方式是“技能包”。你可以把它理解成给AI装了若干份岗位说明书一份写着“遇到新需求先做反向澄清”一份写着“写任何函数之前先定义它的可观察行为”还有一份写着“每次调试必须先复现禁止瞎猜”。这些说明书挂在AI的运行环境里每次交互它都能读到并且在后台自动调用不需要你反复提醒。这种设计理念跟我们带新人很像。你给新人讲一万句“你写代码要细心”不如给他一份Checklist开工前过一遍、写完过一遍、提交前再过一遍。Superpowers干的就是这件事只不过这份Checklist的执行者不是人是AI。1.3 解决了AI编程里的“黑盒失控”焦虑很多程序员不用AI做主力开发不是不相信AI的能力而是受不了那种失控感。你根本不知道它基于什么假设写出了这段代码也不知道它在哪个环节开始跑偏。Superpowers带来最大的改变就是把黑盒变成白盒——它让AI把思考过程显性化当前的问题定义是什么候选方案有哪几种选这个方案的理由是什么风险集中在哪测试应该覆盖哪些行为。我用的这套工作流里AI每做一步决策都会产生一条“思考痕迹”。我作为程序员可以随时停下来指出“这个假设不成立”AI会调整而不是嘴硬。这种体验是真的爽——你不再需要一个AI替你拍板你需要的是一个随时能配合你Push Back的执行团队。2. 安装与引入把Superpowers装进你的AI编程环境2.1 前置条件需要一个支持“自定义技能”的AI编程工具Superpowers不是独立软件它需要跑在一个已经具备技能加载能力的AI编程工具上。目前我主要用的环境是Claude Code其它支持自定义技能Skills的AI编程工具也可以参考同样的思路。判断你的工具是否支持一般就看两件事第一它有没有独立的技能配置目录比如.claude/skills/第二它能不能通过斜杠命令的方式触发某个预设指令比如输入/test-driven-development这种形式。如果你的AI编程环境还不支持自定义技能那就先别急着上手Superpowers。虽然你也可以把它的核心技能内容手动粘贴到上下文里但那只是权宜之计效果会大打折扣。技能真正厉害的地方在于“随时可查、按需触发、不需要占用有限的对话上下文”这是普通粘贴做不到的。2.2 两种主流安装方式我推荐第二种我踩过不少安装过程的坑这里给你两种最稳的方式方式一通过插件市场一键安装。如果你的AI编程工具内置了插件体系一般来说可以直接通过插件市场搜索安装。这种方式最省事适合第一次接触、不想折腾文件结构的用户。方式二通过Git仓库手动引入更可控。这种方式是我个人更推荐、也一直在用的。你先从Superpowers的主仓库把项目代码拉下来然后根据仓库里的说明把skills目录里的内容链接或复制到你当前项目对应的技能目录下面。我自己的习惯是创建一个统一的技能目录然后在不同的项目里通过软链接指向它这样你只需要维护一份技能文件不用每个项目都复制一遍。整个安装过程里最重要的一步是确认技能文件的目录层级正确。因为AI编程工具读取技能文件时对路径非常敏感。你如果多套了一层文件夹或者目录名写错了大概率技能根本加载不出来而且不会给你任何报错提示。装完以后一定要先跑一遍技能自检把所有技能列表拉出来看一眼再开始正式干活。2.3 安装后如何确认所有技能已经生效装完不能直接开干你得确认技能真的加载了。我见过太多人装完就问“为什么AI还是老样子”结果一检查技能文件放错了目录AI压根没读到。实操方法很简单你直接在对话里输入/或对应的技能命令看能不能弹出技能列表。一般来说如果安装成功你会看到一串以/开头的技能名比如/brainstorming、/test-driven-development。如果输完毫无反应优先检查目录路径和文件名不要着急重装。另外一个判断办法是观察AI的行为变化。如果技能已经生效你在描述一个需求之后AI不再像以前那样直接抢答代码而是会先问问题或者主动给出一个实施计划。这是所有技能加载后最明显的特征。3. 核心技能全解析Superpowers到底给了你哪些skills3.1 技能地图从需求澄清到测试驱动开发用了这段时间我整理了一张自己常用的技能清单。这张表是我实际用下来的核心感受不一定跟官方文档逐字一致但足够你了解这套体系在解决什么问题。技能名核心作用什么时候触发Brainstorming给AI装上“多方案生成器”在动手前先列出尽可能多的问题拆解角度需求模糊、无把握时Test-Driven Development强制先写测试再写实现拿可验证性当第一道关卡任何新的函数或模块Systems Thinking让AI分析改动会涟漪到哪些位置避免头疼医头需求牵涉多处改动时Root Cause Analysis禁止AI“头痛医头”引导它定位根因遇到Bug但原因不明Debugging优先建立可复现路径再谈修复报错出现但无法稳定复现Code Review让AI站在审查者视角用挑剔的逻辑挑刺写完代码准备提交前Refactoring保持行为不变的前提下改善代码结构代码能跑但可读性差Planning把大目标拆成可执行的小步骤并按依赖排序需求跨度大、功能点很多时我刚开始看到这么多技能时有点发懵觉得用起来也太复杂了。后来才意识到它们不是让你手动逐条调用的而是AI会按照当前情境自动决定先启用哪一项。你只需要在关键节点上做确认就好比一个组长不需要给组员逐条安排工作只需要知道他们各有所长然后分配对任务就行。3.2 每个技能的使用时机如果只能选一个最核心的技能我会毫不犹豫选Test-Driven Development。在Superpowers这套工作流里TDD不是一种“额外的测试工作”而是AI编程的主线逻辑。这个技能触发时你会看到AI先停下来写测试再回头实现功能。对于不习惯TDD的人来说这个过程刚开始确实会有点“反直觉”但你让AI连续跑几轮之后再回头统计Bug数区别非常明显。Brainstorming这个技能也很有意思。它会在你提需求之后不是马上写代码而是先发一份“问题清单”回来。比如我说“要加一个用户积分功能”它会先列出来积分的来源有哪些过期策略是什么是否涉及并发扣减是否需要对刷积分做风控这些问题如果让AI直接就写很可能一上来就是一张简单的积分加减表上线后必然翻车。Brainstorming推迟了代码出现的时间但也推迟了翻车的时间。Systems Thinking和Root Cause Analysis放在一起用效果最好。我遇到过一次比较诡异的问题一个页面偶发白屏AI一开始查了半天都说“可能是缓存”但用了Root Cause Analysis技能之后它会强制自己按“问题复现路径、环境差异、数据差异”的框架排查最后定位到是某个用户的热点数据里出现了特殊字符。这个技能帮我省下的排查时间绝对值回票价。3.3 技能间的组合关系别把它们当孤立工具用技能真正的威力在于组合而不是单个使用。在实际使用中我最常走的链路是Brainstorming → Planning → TDD → Code Review。举个例子接到一个导出功能的需求我让AI先启动Brainstorming把需求边界理清楚然后启动Planning把“生成数据、格式化、写入文件、错误提示”这几个步骤拆开接着对每个步骤按TDD方式写测试和实现最后用Code Review做一次整体挑刺。这条链路走完代码质量和我以前直接让AI开干完全不是一个量级。还有一个容易被忽视的点Superpowers这套技能体系是会自动把“当前任务上下文”带入到下一个技能里的。比如AI先用Brainstorming整理出了一份关键假设后面写测试的时候它会自动把这几个假设转化为测试用例。这种连续性也是它跟普通提示词最大的区别——你不需要每次重新叮嘱“刚刚我们讨论的边界你还记得吗”都不需要。4. 实操记录用Superpowers完成一个“计算器模块”的开发4.1 场景设定与其空谈原理不如直接回顾我是怎么把Superpowers用在一个具体任务上的。这个任务其实非常简单写一个带加、减、乘、除、取余的计算器模块。但越简单的需求越容易暴露问题。直接用AI写它可能三五行就交了但如果真要把这个模块做得能进生产需要考虑的细节远不止运算符和数字。我先给AI一个最简单的需求陈述“写一个计算器模块支持五种运算输入两个数字和一个操作符返回计算结果。”放在以前AI可能直接就上代码了。但Superpowers这套工作流生效的情况下它没有马上输出代码而是先启动了Brainstorming技能开始追问需求细节。4.2 第一步让AI先写测试而不是先写实现在AI追问完需求细节之后我让它进入Test-Driven Development模式。这一步是整个流程里最容易让程序员“手痒”的环节——因为明明一眼就能看到实现代码AI却要先写测试给人一种“绕路”的感觉。但当我看到AI写出的测试用例时我明白了这套流程的价值。它生成的测试覆盖了这些场景正整数运算、负数运算、除以零的处理、浮点数精度、操作符非法时的报错、除法和取余对零的特殊处理。如果按以前的习惯直接让AI写实现我大概率需要自己事后补这些测试而且还可能漏掉其中几个。AI写完测试后并没有立刻写实现代码而是先停下来等我确认。这一停非常关键因为它给了我一个“审题”的机会。我看了它的测试设计后发现它没有考虑“极大数溢出”的场景于是追加了一条要求让测试把这一边界也覆盖进去。这种对需求的动态细化只有在这种“先测试、后实现”的节奏里才能自然发生。4.3 第二步AI实现并通过全部测试测试用例确认后AI进入实现阶段。这时候它的行为明显变得非常克制——它不再“发挥创造力”而是以最快的速度让所有测试变绿。写完第一版实现后它主动跑了一遍测试其中一个浮点数相关的测试挂了。这里又出现了我特别欣赏的一个行为它没有马上“糊一个修复”而是先进入Debugging技能建立了一个最小复现用例然后分析浮点误差的来源。最终它给出的方案不是对计算结果做四舍五入而是在比较浮点数时采用精度阈值。这两个方案的差别行家一眼就能看出来。前者把问题的表现盖住了后者把问题的根源解决了。等所有测试都通过后它把完整的实现代码和测试结果整理给我并且提醒我说如果这个模块要用于金融场景浮点数方案还需要进一步调整。这种“主动提示风险”的行为在没装Superpowers之前我很少遇到——那时候AI更像一个卑微的工具人你不问它就不说你问了它才解释。4.4 第三步做一次代码审查实现通过测试后我没有急着收工而是让AI用Code Review技能对自己的代码做了一次“内部审查”。这个技能启动后它会主动切换视角从“实现者”变成“挑剔的审查者”。审查下来还真发现了一个之前没暴露的问题AI的实现里有一个分支如果操作数是-0它会因为相等性判断而返回一个不规范的结果。这个问题在测试用例里没覆盖到但它的确是一个极端输入场景。AI在审查报告中明确指出这个问题并建议我决定是直接在实现层处理还是在入口处对-0做归一化。整个过程看下来最核心的感受是这个模块的最终代码不是我“逼”出来的也不是一次侥幸生成出来的而是通过一套流程逐步“逼”出来的。它每一步都有依据每一个行为都有一个可执行的测试用例。这种确定性正是“可靠”二字的来源。4.5 提示词与交互设计的细节在使用这套工作流时我总结了一套自己的提醒方式。不一定要直接说“请使用Test-Driven Development技能”你可以更自然地表达比如“先帮我写测试确认覆盖了主要边界再写实现。”这种表达方式是给AI一个明确的流程指令同时不会因为死记技能名而显得生硬。我还发现一个操作上的细节不要让AI一次性完成“面试题”式的完整流程。你让它一口气做完所有事它会倾向于省略中间环节。正确做法是分阶段确认每个阶段结束都停下来问一句“这一步够了吗”。比如先看测试用例是否覆盖完整再放行实现实现跑通后再做一次审查。这种“阶段闸门”的做法把工作流里的每一步都变成了可审计的节点。另外如果有多个需求要处理不要试图在一个会话里批量处理完。把每个需求拆到独立的分支或独立的任务里让AI在一个时间只专注一件事。这样技能的调用顺序会非常干净不容易出现上下文污染。5. 常见问题与排查技巧实录5.1 技能装了但明显没生效先查这三处很多人遇到“技能没生效”第一时间想的是重装我建议先做这三步排查。第一步确认目录结构。技能系统对目录极其敏感最常见的错误是技能文件多嵌套了一层目录。正确的方式是让技能文件夹直接位于技能根目录下文件夹名就是技能名里面放一个说明文件。如果你不知道自己的目录有没有放对可以先新建一个技能名“test”并写一行简单内容然后看AI能不能触发它。能触发说明路径没问题触发了但没实际效果说明技能内容有问题。第二步确认文件名和格式。技能说明文件必须是预设的命名规范比如SKILL.md这类。如果你改成了其他文件名AI根本不会把它当技能读。我犯过这种低级错误老老实实折腾了十来分钟才反应过来。第三步确认技能是否真的被对话上下文引用。有些AI工具默认只加载一部分技能或者要求你在对话里显式“提及”某个技能名。如果是这种情况你输入相关关键词但没提到技能名它可能不会主动启用。最简单的做法是输入技能名看它返回的“技能说明”是否符合预期。5.2 AI“假装”遵守了流程实际在应付怎么办使用Superpowers这类基于工作流的技能框架还会遇到一个头疼的问题AI在“表演”遵守流程。它嘴上说着“让我先分析一下”实际生成的内容却还是原来那套直接给代码。我处理这个问题的办法是看它输出的“中间产物”。真正的流程遵守一定会留下中间产物Brainstorming阶段会产生问题清单Planning阶段会产生任务清单TDD阶段会产生测试代码Code Review阶段会产生审查意见。如果AI一步到位直接给了最终代码却说它“已经完成了全部分析”这就是在偷懒。此时你不需要发火只需要用技能命令强制它执行某一阶段。你可以直接说“先只做Brainstorming把问题清单列出来不要写代码。”这样它就绕不过去了。记住AI是一个概率系统它偶尔会“抄近路”你的职责就是帮它走正路。5.3 技能越多越好吗我踩过的坑刚接触Superpowers时我是个“技能囤积癖”把所有相关技能一股脑全装上结果发现非但没有变得更可靠反而让AI在多个技能之间反复横跳行为变得很分裂。比如它可能一半时间在按TDD流程走另一半时间又突然冒出“系统思考”式的大段分析结果代码没写几行。后来我改用“按需加载”的思路把技能分成两类一类是默认全局启用的核心技能比如TDD、Brainstorming另一类是特定场景才触发的技能比如Debugging、Code Review。全局启用太多技能没有意义反而会稀释AI的注意力。把技能精简化之后AI的行为稳定了很多我现在常用的一套核心技能组合不超过五个。还有一个细节是技能之间的“指挥权”会冲突。假如你同时启用了“Debugging”和“Root Cause Analysis”在碰到一个Bug时它俩可能给出两种不同风格的排查路径反而干扰了AI的判断。我的处理原则很简单同一时间只让一种“方法论”主事其他角色全部靠边站。6. 使用心得与扩展建议6.1 从“快”到“可靠”真正改变的是协作节奏使用Superpowers之前我和AI的协作节奏是“我提需求、AI给代码、我改Bug”。使用之后变成了“我提需求、AI问问题、我给约束、AI写计划、我确认计划、AI写测试、AI写实现、AI自审、我最后验收”。前一种节奏看起来快但每一轮都要返工后一种节奏看起来慢但每一步都在往前走。这个节奏变化本质上改变了我对AI编程的理解。AI不是一个“替你手写代码的工具”而是一个“需要按工程纪律约束的协作者”。代码的质量不取决于它生成的瞬间有多惊艳而取决于它在生成之前有没有经历足够多的思考确认环节。Superpowers给我最大的价值就是把这些“思考确认环节”变成了AI的默认习惯而不是需要我每次去催促的东西。6.2 这套思路能扩展到哪里去Superpowers的思路其实可以迁移到很多AI应用场景里不只是写代码。我试过把它应用在“AI写技术方案”“AI做数据分析”“AI生成临时脚本”上效果都很好。核心逻辑是同一个在AI执行任务前先让它把“边界、假设、验证方法”摊开给你看你确认了再往前推进。我现在写一个新的AI辅助工作任务都会先问自己一句这个任务里AI最容易在哪个环节“自以为是”然后针对那个环节设置一道闸门。这个习惯就是从使用Superpowers里学来的。它不是某个固定技能而是一种思维方式把最关键的可靠性节点嵌入到流程的必经之路上。我个人在实际使用中的体会是Superpowers这类工具不需要天天研究新功能真正值得花时间的是把它默认的那套工程纪律内化成自己的习惯。等哪天你发现哪怕不装这个工具你在给AI下需求时也自然会说“先列边界、再补测试、别急着写实现”——那才是它真正生效的时候。