先说明白一件事：现在圈子里聊的"superpowers"，并不是什么玄乎的超能力，而是最近在AI编程助手社区里很火的一套开源技能包。它解决的问题很直接——同样是接入Claude Code、Codex、Cline这类工具，有些人总觉得AI"时灵时不灵"，我自己也经历过这个阶段。后来我想通了，问题多半不出在模型身上，而是AI缺少一套可复用的工作流程。superpowers的作用，就是把这些流程固化成一个个独立的skill文件，让AI在做代码审查、缺陷定位、测试生成、重构规划这些事的时候，不再靠临时发挥，而是严格走验证过的步骤。
这篇文章我会按我实际折腾的顺序来写：先讲清楚skills到底解决什么问题，再拆解superpowers里的技能分类，然后是完整的安装流程、使用实测，最后聊几个只有真正用熟了才会注意到的配置细节。内容不挑工具，无论你现在用的是哪家的AI编程助手，思路都通用。
1. 为什么需要"superpowers"这层技能的引入
1.1 先搞明白skills和普通prompt的差别
很多人第一次听说skills这个概念时会觉得：那不就是把prompt写得更详细吗？还真不是。普通的prompt是一次性的，你告诉AI"帮我检查代码"，它理解到的检查可能只是扫一眼有没有语法错误。而skill文件里存的是一整套行为协议，它规定了任务的目标、输入、执行步骤、输出格式，甚至包括边界条件和自查清单。
我用个直白的类比：prompt像你让一个实习生"去把这个项目看看有什么问题"，实习生可能转一圈回来告诉你"代码能跑"。而skill像是你递给他一张SOP检查表，上面列着性能、安全、可维护性、错误处理等等维度，每一条都有具体验证方法，他就算经验不足，照着表走也能交出像样的结果。
superpowers做的就是把这张表变成标准文件。它不仅仅是"提示词仓库"，而是一套可以被AI工具自动发现、加载、执行的技能目录。你在对话里提到相应场景，AI就会自动读取对应的skill并进入该技能定义的执行流程，而不是还在等你给它一步步的指令。
1.2 superpowers解决的三个具体问题
我之所以愿意花时间折腾这套东西，是因为它确实戳中了三个让我很头疼的点。
第一是AI的输出质量不稳定。同一个模型，上午让它重构一个模块，它分三步走，析得清清楚楚；下午同样的问题，它就图省事直接给你甩一版全量改动。这不是模型抽风，而是缺乏流程约束。技能文件里定义了必须"先梳理现状、再列改动计划、最后动手改"这个顺序，AI照章执行，结果就稳定得多。
第二是隐性经验沉淀不下来。一个团队里，老手做代码审查会关注鉴权、数据校验、日志埋点这些点，但这些经验很难通过口头传达给AI。superpowers这类技能包的价值在于，它把这些"资深工程师的操作习惯"结构化地写进了文件里。AI按照文件执行，就相当于一个中级水平的工程师在按资深专家的流程办事。
第三是工具切换成本高。我试过在不同AI编程助手之间切换，最烦的就是同一个需求得重新调教。而skills目录本身就是标准化的，只要工具支持读取，从A工具切到B工具，技能包原样搬过去就能用。对我这种喜欢对比工具的人来说，这省了太多事。
2. superpowers到底装了什么：核心skills目录拆解
2.1 代码审查与质量类技能
装好superpowers之后，我第一件事就是把它的目录结构完整看了一遍。先用tree命令过了一遍，整个人都精神了——里面预置的技能比我想象的多得多。按大类分，最核心的一块是代码审查类。
这类技能的执行逻辑很有意思。以我常用的review技能为例，它不会让AI直接"看代码"，而是要求AI先收集上下文：变更涉及哪些文件、改动范围有多大、关联了哪些模块。然后按固定维度逐一检查，比如错误处理路径是否完整、外部输入是否有校验、敏感信息有没有被打日志、是否存在并发条件下的竞态。每检查一项，AI都会给出具体的证据（文件路径加行号），而不是笼统地说"这里有问题"。
这种方式的优势在多人协作时特别明显。审查意见不再是一句"建议优化"，而是"service层第87行你调用了外部API，但没做超时控制，建议加context超时和错误降级"。这种有依据的输出，可以直接贴在代码评审的评论区里，开发照着改就行。
2.2 测试与验证类技能
测试相关技能是我切身体验最明显的一块。在没有技能包之前，AI写测试基本靠猜：先看一遍源码，然后生成一份看起来正常的测试文件，能不能跑通看运气。superpowers里的测试类技能会强制一个"逆向推导"过程——先找出被测函数的所有分支和边界条件，然后针对每个分支设计用例，最后才写代码。
比如你让它给一个处理订单状态的函数写测试，它不会直接写五六个用例就完事。它会先列出这个函数的状态机：待支付、已支付、发货中、已完成、已取消，以及每个状态之间的合法转换和非法转换。然后针对非法转换断言抛异常，针对边界条件（比如金额为0、数量为负数）做参数化测试。输出的测试文件还自带注释，标明每条用例对应的是哪个分支。
执行路径上还有个细节我特别喜欢：技能定义里要求AI在写完测试后自己"以测试运行者的视角"跑一遍逻辑推演，找出测试代码本身可能存在的问题。这一步看着简单，实际非常有用，能拦下不少测试代码里的低级错误。
2.3 架构与重构类技能
架构和重构类技能是我后补用的，但用完之后我觉得这才是superpowers最值钱的部分。它处理的不再是一个函数级别的任务，而是模块之间关系、依赖方向、边界划分这些本来很难让AI"自觉处理"的问题。
这类技能里有一项"变更影响分析"，我会在改动公共函数或数据模型前调用它。它要求AI先画出调用链（当然不是真的画图，而是列出所有直接和间接调用方），然后评估这次改动会波及哪些上游模块、是否需要同步修改测试、是否涉及数据迁移兼容。这个流程做完，我基本不会再出现"改了个内部逻辑结果把接口调用方搞崩了"这种情况。
重构技能则更保守一些。它开头就会检查：你手上有没有可用的测试基线？如果没有，第一步是先补一个测试基线再动手改。这个约束很重要，因为没基线就重构，等于蒙眼换零件，改完根本不知道有没有装对。技能文件里甚至规定重构要分小步提交，每一步都要保证编译通过且测试不红。这套约束看起来繁琐，实际上是从根上避免了"大爆炸式重构"翻车。
2.4 过程管理与文档类技能
除了直接的代码类技能，superpowers里还装了一批"软技能"，我用得最多的是变更日志生成和模块交接文档。
变更日志生成技能会把git log里的提交信息分类整理，按 feature、fix、refactor、docs 分组，并且严格遵循 conventional commits 的格式输出。这个功能对维护开源项目或者写周报的场合太实用了。我每周五下午会跑一次，五分钟拿到一份能直接贴到更新公告里的变更清单。
模块交接文档技能则是在我休假前生成"项目交接说明"。它会扫描指定模块的结构、核心链路、现有测试覆盖情况，然后生成一份包含模块定位、关键文件索引、常见变更入口、已知技术债的文档。我上个月休假一周，就是用这个技能跑了一份交接文档丢给同事，等我回来发现期间改动完全没跑偏。
3. 安装superpowers的完整流程与踩坑记录
3.1 获取技能包的正确姿势
安装第一步是获取技能包本身。通常的做法是到项目的GitHub仓库拉取最新release，或者直接用git克隆整个仓库。
git clone https://your-repo-url/superpowers.git cd superpowers我建议下载release包而不是直接克隆main分支，因为main分支经常处于开发状态，里面有半成品技能文件，挂载后AI可能会读到不完整的定义。release版本是经过验证的稳定集合，省心。这里说一句题外话：不管从哪获取，拿到之后第一件事先看目录结构和README，不同版本的目录命名差异不小，我对网上那些两年前的教程时就踩过这个坑。
3.2 把skills挂载到AI工作区的步骤
拿到技能包之后，剩下的问题是怎么让AI工具认出来。目前主流AI编程助手普遍支持从工作区的某个特定目录读取技能文件。以我自己用的工具为例，技能目录一般叫.claude/skills或者.cursor/skills这类隐藏目录，看工具文档确认即可。
我实际操作的挂载流程是这样的：
- 在项目根目录创建技能目录：
mkdir -p .claude/skills- 把superpowers里的技能子目录映射进来。这里我不建议直接复制，更稳的是建立符号链接，这样后续技能包更新时，工作区能直接感知。
ln -s /path/to/superpowers/skills/* .claude/skills/- 重启AI会话。这点特别关键，技能文件是在会话启动时扫描加载的，开着旧会话挂载技能，基本不生效。我一开始就是没重启，白折腾半天。
如果你的工具支持全局技能目录，那就更省事——装一次，所有项目通用。方法是把skills目录放到用户配置目录下的对应位置，比如~/.claude/skills。全局安装适合那些跨项目通用的技能，比如代码审查、测试生成；项目级安装适合只给当前项目用的特殊技能，比如某个业务模块的专属检查清单。这两种方式可以共存，它们的优先级通常不一样，具体规则我放到第5部分细讲。
3.3 验证安装是否成功
挂载完怎么确认装好了？最笨也最靠谱的方法：直接在对话里问AI一句"你现在加载了哪些技能"。如果工具支持技能扫描，它会列出可用的技能列表，或者在一段对技能目录的描述中带上关键词。
还有个小技巧是故意展示能给AI触发的关键词，比如你输入"请用review技能帮我看看这次改动"，然后观察AI的反应。如果它开始按照技能文件定义的流程走（先收集改动范围，再逐维度审查），说明技能被正确读取了。如果它只是像普通对话一样开始看代码，那就说明技能没有真正生效，需要走排查流程。
3.4 我踩过的两个坑
第一个坑是符号链接在某些环境下不会被AI工具跟随扫描。我换了一台机器，工作区里的技能目录全是失效链接，AI完全没读到。后来我把symlink方案换成了真实的复制目录，虽然更新麻烦一点，但胜在兼容性稳。做项目迁移时我推荐直接用复制，别省那点磁盘空间。
第二个坑是技能文件里的路径依赖。个别技能包在安装时会写死运行路径，一旦我把它从全局目录移到项目目录，技能内容里的指令路径就对不上了，表现为AI读不到附属文件，流程中途卡死。解决办法很简单：安装后手动改配置文件里的路径变量，把全局路径改成相对路径或项目实际路径。观察目录结构时顺便看一眼是不是有.env或者config.json这类文件，有就先打开看看有没有需要改的路径。
4. 引入技能之后怎么用：具体使用场景实测
4.1 让AI按技能流程处理一个缺陷修复
理论看多了容易飘，实战才是检验真理的标准。我找了一个真实case演示完整链路：线上有个订单超时未支付但状态没翻转的缺陷，我用superpowers的bug-fixing技能来处理。
整个技能流程非常明确。第一步AI要求我提供"可复现路径"，是一个测试命令或一组操作步骤。我给出了触发场景，AI自己补了一条复现用例。然后它不是直接跳到改代码，而是先做根因分析，把可能原因列成了三类：定时任务漏扫、状态变更事件丢失、幂等校验误判。紧接着针对每个原因检查对应代码路径，用日志辅助定位。最后定位到是定时任务扫描的时候，查询条件漏掉了"超时且未被外部事件锁定"的状态组合。
整个排查过程AI全程没有一次性改完，而是每确认一个环节就停下来汇报一次，等着我确认后再进入下一步。这个"先分析、后动手、分步确认"的节奏，就得益于技能文件里的流程定义。换作是普通对话，AI大概率会直接给出一个"我认为是这样"的修复方案，让人没法放心。
4.2 写测试时的技能调用方式
写测试的场景我已经在2.2里讲过大概逻辑了。这里补一个实际调用时的操作技巧：不要只跟AI说"写测试"，而是要明确表达"请使用test-generation技能"。这样AI才会加载完整流程，而不是按自己的习惯模式写。
我让AI给一个工具函数生成测试，它输出的结果让我印象很深——不是简单贴一段pytest代码，而是先输出一个测试矩阵表，列了输入、期望输出、覆盖分支。比如输入为空列表、单个元素、包含None、嵌套结构、超大数量级等场景，都有对应预期。矩阵确认通过之后，它才真正生成测试文件。
关键的是文件末尾附了一份"覆盖盲区清单"，明确标注哪些分支由于依赖外部服务没法单测覆盖，建议接集成测试或Mock方案。我做了多年开发，很清楚这类信息对后续补测试有多重要，以前让AI写测试从来不会给这种信息，全靠自己扫一遍代码脑补。
4.3 不同工具下的使用差异
superpowers的技能机制在不同AI编程助手里效果会有一些差异，这件事得说清楚，免得有人装了用不顺手以为是包的问题。
以我试过的几款主流工具来看，支持原生skills目录的，比如Claude Code和Codex命令行版，效果最贴合设计预期，AI会主动读取技能文件并遵守流程。而某些IDE内置的AI助手，虽然也能从自定义指令或规则文件里读到类似内容，但它对技能文件的解析是"单向注入"，就是说你把技能内容放进规则文件，它看了，但不会像原生的skills机制那样按流程状态机来推进多步骤操作。表现出来就是：AI会用你给的方法，但不会严格按步骤分阶段执行。
因此我现在的策略是分成两套环境：重度重构或者复杂排查用支持原生skills的工具；日常片段式补全直接就在IDE里做，不折腾。这俩场景对流程的要求本来也不一样，没必要强求一把钥匙开所有锁。
5. 用好superpowers的关键配置与个人心得
5.1 技能优先级与自定义技能
当全局技能和项目技能里存在同名技能时，项目级目录一般优先级更高。按我实测，AI在扫描技能时会优先读取当前工作区目录下的技能，读不到才回溯到全局目录。这个设计很合理，因为项目级技能的定制程度肯定更高，更贴合当前代码库的实际情况。
到这一步，我强烈建议你别只停留在用现成技能，试试自己写一个。superpowers的技能文件本质是结构化文本，通常包含name、description、instructions这几段。instructions里按步骤写执行流程就行。我写第一个自定义技能"API兼容性检查"只花了不到半小时，用来检查接口定义变更是否破坏了现有调用方，内置技能里没有这么垂直的场景。
自定义技能最需要注意的地方是description要写准确。AI决定什么时候调用技能，主要就是靠你的描述关键词。我以前有个技能叫"check-api"，描述写得模模糊糊，结果AI在完全不相干的场景也去加载。后来我把描述改成"在修改API接口或数据模型定义时，检查对外兼容性并列出迁移影响面"，准确率就高多了。
5.2 版本管理与团队协作
技能包一旦在团队里用起来，就要考虑同步问题。我在团队里推这套东西的时候，直接做了一个建议：把技能包当成依赖管理。
具体做法是，项目仓库里维护一个skills/目录，并把技能包的版本号写在主目录的README里。谁升级了技能包，提交时会带上变更说明。这样其他人拉取代码后能知道现在用的是哪个版本，不会出现"你机器上明明能跑，我这怎么不行"的尴尬。
还有一个更进阶的玩法：把团队自己的操作规范和编码规范也转成技能文件，放进同一个目录。比如我整理了一份"Go工程代码审查规范"，转成skill后，所有项目成员让AI做代码审查时都会强制套用这份规范，而不再依赖个人口头叮嘱。这个落地效果，我觉得比传统写文档高很多，因为文档人们不会主动看，而技能是被AI在流程中强制执行的。
5.3 不要贪多：按需开启
最后说一个我踩过最深、也最想提醒各位的坑：别一上来就把整个superpowers的全部技能都丢进去。
我第一次装的时候，把默认目录全量复制进项目，结果是AI的对话行为变得非常"重"。明明问一个简单的函数解释，它非要按复杂技能流程走一遍，先列分析、再列影响、最后给结论，响应慢且啰嗦。后来我把技能目录里的内容裁剪到只保留项目真正需要的五六个技能，行为立马清爽了。
用到现在，我固定的技能组合一般是：代码审查、测试生成、缺陷定位、变更影响分析这四项常驻，其他工具类技能按需开启。做新项目时我会先只挂这三四个核心技能跑两三天，观察AI的输出质量稳定之后，再决定要不要加架构规划或者文档生成。
总归一句话，superpowers给你的不是更多能力，而是一套能让现有能力稳定发挥的执行框架。关键不在于装了多少技能，而在于你把哪些日常操作沉淀成了可复用的流程。我现在的习惯是每遇到一类"值得反复做、又容易忘步骤"的任务，就会考虑把它写成新技能补充进去。这个东西用久了，你会发现自己对AI的掌控力确实比以前强了一截——不是因为它神秘，而是因为你终于把话说清楚了。
