最近在代码相关的社群里superpowers 这个词出现的频率高得有点吓人。有人以为它是个新游戏有人以为是什么影视设定但问得最多的其实是三个问题它到底有哪些 skills怎么安装 superpowers以及怎么把这些技能真正引入到自己的工作流里。先把概念说清楚superpowers 在这里指的不是“超能力”本身而是一套给 AI 编程助手准备的技能包。什么叫技能包你可以把它理解成给 AI 装上的一套标准作业流程。普通的 AI 助手很像一个聪明的实习程序员你问它问题它能答让它写代码它能写但它不会主动澄清需求不会先写测试再写实现也不会在出 bug 的时候按章法排查。superpowers 里装的就是这些章法每一项技能对应一套结构化的提示词和方法论AI 干活的时候按这套章法走产出会更接近一个靠谱的正式开发。这篇文章我把它的核心设计、具体技能、安装步骤、触发方式和常见坑都过一遍最后聊聊我自己实际用下来的体会。适合两类人看一类是刚接触 AI 编程助手、想让它从“能聊”变成“能干活”的新手另一类是已经在用、想把自己的团队规范变成一套可复用技能的老手。1. 先搞清楚被叫成“superpowers”的到底是什么1.1 一个类比从“一问一答的实习生”到“会带流程的老开发”很多人第一次看到 superpowers 会以为它是一个独立的软件或者某个模型其实不是。它是建立在现有 AI 编程助手之上的一层“流程层”。AI 本身有很强的知识储备但它不知道你期待它怎么干活。你让它写一个登录功能它可能哗啦一下就给你甩出几十行代码完全不管你的项目结构、编码规范、异常处理习惯。这就像你让一个实习生“把这个页面做一下”他可能真的就做“一下”做完就交差了。superpowers 做的事情是提供一份份“带流程的作业手册”。还是拿实习生举例你给一本手册上面写着先确认需求、拆解任务、列实现步骤、写完自查、跑测试。照着这本手册走实习生做出来的东西就靠谱很多。superpowers 里的每个技能本质上就是这么一本手册只不过 AI 阅读和执行的速度比你带真人实习生快得多。这也是“技能”和“插件”的本质区别。插件通常是硬编码的功能模块得靠外部代码去实现技能则是结构化的指令和组织好的知识AI 会根据指令来决定自己的行为。所以你会发现superpowers 装完之后并没有多出某个按钮而是 AI 在对话里的思考方式变了。1.2 这套技能库解决哪几个具体痛点我在实际使用中感觉它重点解决的是下面这几个让人头疼的问题。第一个痛点是“需求不清就开写”。AI 没有你的业务背景你给它一句话它很容易按照最字面的意思猜一个方案出来。猜对了皆大欢喜猜错了就要推倒重来。superpowers 里的规划类技能会强制 AI 在动手前先提问、先拆解把“你其实想要什么”这件事逼出来。第二个痛点是“代码能跑但质量没底”。AI 生成的代码往往能通过编译但边界情况、异常处理、可维护性都容易被忽略。技能包里的测试驱动开发、代码审查这类能力会让 AI 先写测试再写实现写完之后再按清单自审一遍。等于给代码上了两道保险。第三个痛点更隐蔽就是“AI 排障靠猜”。你反馈一个 bug它可能会连续给你三个可能性每个听起来都有道理但没有一个经过验证。调试类的技能会引导 AI 走一遍标准的排障流程先重现现象、再收集信息、然后提出假设、逐个验证、最后才动手改。这套流程可能比 AI 直接猜要慢但成功率明显高得多。1.3 哪些人适合装哪些人装了也白装先说适合的。如果你每天都在用 AI 写业务代码尤其是项目不是一次性脚本而是要长期维护的那种装它是划算的。它带来的不是“写得快”而是“返工少”。如果你在带团队想让所有人的 AI 使用方式统一起来也适合装因为它天然就是一套可以分发的流程文件。再如果你是提示词工程爱好者那更应该研究一下它因为它的组织方式本身就是一个高质量范本。反过来如果你只是拿 AI 当搜索引擎用问一个问题、复制一段答案那装技能包帮助不大还显得流程很重。再如果你特别反感 AI 反过来问你问题希望它“我说什么它写什么”那这套东西大概率会让你觉得啰嗦。原因很简单技能包的核心理念是把“想清楚再干”变成默认动作这天然就比“一句话出代码”多几个来回你需要接受这个交换。2. superpowers 里到底有哪些 skills各自能干什么2.1 规划类技能动手之前先把思路理清规划类技能是整个技能包的起点也是我觉得最容易被低估的一部分。很多人用 AI 失败不是 AI 能力不行而是问题本身还没被定义清楚就丢给了 AI。规划类技能就是治这个病的。比较常见的有这么几个brainstorming 负责发散它会围绕你的目标生成多个方案而不是只给你一个“看起来最对”的答案。这样做的好处是你可以在方案之间做选择而不是被动接受。planning 负责收敛它会把选定的方案拆成一步步可执行的任务每个任务有明确的输入、输出和验收标准。writing-plans 更进一步它会把计划整理成一份结构化的文档方便你留档、评审或者后续让另一个 AI 去执行。三个技能通常会串联使用。先 brainstorm 出方案再 planning 拆任务最后 writing-plans 落成文档。我见过不少新手跳过了 brainstorming直接让 AI 给计划结果计划看着挺细方向却是错的白忙一场。规划阶段多花十分钟后面能省好几个小时。2.2 执行类技能把“计划”变成“能跑的代码”规划做完之后就该进入执行了。执行类技能里最核心的是 TDD也就是测试驱动开发。这个技能不是让 AI 随口说“我按 TDD 来”而是真正让它先写一个会失败的测试再写让测试通过的实现最后做重构。整个过程 AI 会自己汇报“我现在在写测试、我现在在跑测试、我现在在实现”你一眼就能看到它是不是真的在按流程走。另一个值得聊的是 subagent 驱动的开发。这个机制有点像一个项目经理自己不开工而是把任务派给几个不同的小工等小工交活了再汇总。AI 编程助手在支持子任务执行时可以由主 AI 拆出一个“负责写接口的”、一个“负责写前端页面的”让它们并行干活最后再由主 AI 合并。对于比较大的功能这个模式能有效避免一个 AI 从头写到尾导致上下文不够用、写着写着忘了前面的问题。执行类技能里通常还会有一个通用的“任务执行”能力它像一张任务清单AI 每完成一步就在清单上打个勾确保不遗漏。如果你用 AI 干过那种十几个步骤的活就知道这种“看得见的进度”有多重要。2.3 质量与排障类技能让 AI 自己给自己找茬代码写完了不代表事就完了。质量类技能负责的是“让 AI 自己审自己”。code review 技能会给 AI 一套审查清单不光是找语法问题还包括有没有重复代码、有没有明显的性能隐患、有没有不合理的接口设计、有没有忘记处理错误分支。你写完代码之后让它“用 code review 技能审查一遍”它给出的意见和你直接问它“这段代码有什么问题”是完全不同的因为后者更像是临场发挥前者是照章办事。debugging 技能则是排障的救援队。它遵循一套标准的排查循环第一步重现 bug第二步收集运行信息和日志第三步提出可能的根因假说第四步针对假说做最小验证第五步修改代码第六步做回归确认。每一步都有明确的输出。我实际用下来这套流程最大价值是让 AI 不再“三个可能原因里蒙一个”而是老老实实给你一个带验证路径的结论。还有一类偏 QA 的技能专门用来生成边界测试和异常输入。比如你写了一个解析日期的函数它会主动测试“空字符串传进去会怎样”“月份填 13 会怎样”“闰年的 2 月 29 号能不能过”。这些用例你自己让 AI 生成它可能偷懒但按技能流程走它就会很认真地跑完一遍。2.4 一个 skill 的内部结构长什么样理解了技能能干什么还得理解技能是怎么组织的因为你装完 superpowers 之后大概率会忍不住想改里面的东西。一个典型的技能目录长这样skill-name/ SKILL.md reference/ ... scripts/ ...其中 SKILL.md 是核心文件里面包含三样东西技能的名字、技能的描述、执行技能时需要遵循的指令。描述这块特别关键因为 AI 在对话中看到你的请求后就是靠技能描述来判断当前该不该使用这个技能。描述写得越具体匹配越准写得太宽泛可能每个任务都想套上来用。reference 目录放参考文档比如某种代码规范、某个内部 API 的用法说明。scripts 目录放可选的辅助脚本。了解这个结构之后你会发现 superpowers 并不是什么魔法它就是一套组织得很好的 Markdown 加少量脚本。这也意味着你完全可以往里加自己的技能后面我会专门讲。3. 安装 superpowers 的完整流程从 clone 到跑通3.1 安装前的环境确认有句话我说在前面下面的安装路径和命令是基于当前社区里比较主流的做法写的。这类技能包更新很快不同版本的目录名和配置方式可能有差异但“先拉代码、再放对目录、最后验证”这条思路是通用的你只要把这条主线抓住了具体差异都是小事。动手之前先确认三件事。第一你本地装了支持技能机制的 AI 编程助手并且版本别太老。你可以直接打开终端敲一下版本命令能看到版本号就说明基础环境没问题。第二你用的模型支持在对话中调用外部技能文件。现在主流一点的模型基本都支持但如果你用的是特别早期的版本最好先升级。第三确认你的用户目录下有没有权限创建配置文件。正常情况下没问题但如果你是在公司统一管控的机器上可能要先看看是不是有用户目录的写权限。另外一个小提醒别把技能包放到一个需要 sudo 才能修改的深目录里。你后面会频繁调整里面的描述文件每次改都要提权会非常痛苦放在用户自己的目录下最省心。3.2 把技能包拉下来并检查内容环境确认没问题之后就可以把技能包拉下来了。常用的方式是用 git clone打开终端执行git clone https://github.com/obra/superpowers.git cd superpowers ls -la执行完之后你先不要急着复制花两分钟看一下目录结构。你会发现里面有一个 skills 目录这个目录下面才是各个具体的技能。每个技能就是我们在前面看过的那个结构包含 SKILL.md 和一堆辅助资源。这一步的主要目的是让你对这个包有个整体印象知道自己装了什么。如果你之前已经装过一版再装新版之前先看看自己的 skills 目录里有没有做过定制。很多人装新版直接覆盖结果自己之前改的描述全丢了。正确做法是先备份一份cp -r ~/.claude/skills ~/.claude/skills.bak备份这个东西说多了都是泪我覆盖过不止一次。3.3 把 skills 放到配置目录技能包的目录结构看明白了接下来做安装。不同的 AI 编程助手读取技能的位置不一样但以市面上最常见的方式来说技能目录通常是用户目录下的.claude/skills。你可以分步执行mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/这里有一个选择你是想复制一份还是做软链接。复制的好处是技能目录完全独立之后不会因为原仓库更新被意外覆盖坏处是原仓库以后更新了你得手动再复制一次。软链接的好处是原仓库git pull之后技能自动更新坏处是如果你在原仓库里改了东西可能会被更新冲掉。我个人的习惯是复制一份进配置目录但把原仓库保留在本地某个固定位置。既方便手动对比新版本有什么变化又不影响配置目录的独立性和整洁度。3.4 验证安装是否生效安装完先别急着开始写代码先验证一下 AI 到底有没有“看到”这些技能。第一个验证方式非常直接看文件在不在find ~/.claude/skills -maxdepth 2 -name SKILL.md | head -20正常情况下你会看到一排 SKILL.md 文件每个对应一个技能。如果这里一个文件都没有多半是路径放错了。第二个验证方式是在对话里问它“你能列出当前可用的技能吗”或者“你会哪些技能”如果配置生效它会把你刚装的技能名一股脑报出来。一些新版的编程助手还提供了/skills之类的斜杠命令可以直接在对话里列技能列表。如果它说一个技能也看不到先别急着怀疑技能包有问题九成以上是你的会话没有刷新。退出当前会话重新开一个大多数情况就好了。这一步操作很简单但它能帮你排除后面一大半的“为什么没生效”问题。4. 怎么引入并复用这些技能触发方式与编排思路4.1 技能触发主动点名和自动匹配装好之后最自然的疑问是我要不要每次都手动喊技能的名字答案是不用但手动点名永远是最可靠的方式。技能触发有两种模式。第一种是主动点名你在对话里直接说“使用 planning 技能帮我规划一下这个功能”或者“用 code review 技能检查这段代码”。这种方式的优点是非常确定AI 不会有别的理解空间缺点是你得知道什么时候该用哪个技能等于你自己要先学一遍流程。第二种是自动匹配AI 会根据你的请求内容结合每个 SKILL.md 里的描述自行判断该启用哪个技能。这种方式用起来轻松但偶尔会选错。如果你发现自动匹配经常选错问题大概率出在技能描述上。你自己写技能或者改技能的时候描述里一定要写清楚“什么时候用、什么时候不用”。比如一个技能专门处理日志分析的你就别在描述里写“能帮助解决问题”这种大而全的话而要写“当用户需要分析日志、查看报错信息、定位线上问题时使用”。描述里的关键词就是 AI 做匹配时的路标。4.2 实战演示给项目加一个“导出 CSV”功能光说理论容易飘我拿一个真实场景拆给你看。假设你的项目里有个列表页面你让 AI“给项目加个导出功能把当前列表导出成 CSV 文件”。如果没装技能包AI 大概率会直接开始写导出代码字段名它自己猜。装了 superpowers 之后流程是这样的。先是 brainstorming 技能被激活它会反过来问你几个问题导出范围是当前筛选后的结果还是全量数据字段顺序要不要跟列表保持一致文件编码是用 UTF-8 还是 GBK如果数据量大需不需要加异步处理。这些问题是它基于经验列的每个都可能会影响最终实现。紧接着 planning 技能接手把刚才确认过的需求拆成任务第一步写一个数据查询函数第二步写一个把数据转成 CSV 格式的函数第三步加一个下载入口第四步写单元测试。到这里你大概就能看出来它已经不是在“写代码”而是在“交付一个功能”了。接下来 TDD 技能开始执行它会先写一个测试来验证 CSV 生成函数比如传进去三行数据、断言输出的字符串是不是符合预期。测试通过了才开始实现具体逻辑。最后 code review 技能再扫一遍关注有没有做好特殊字符转义、有没有处理空数据、导出文件流有没有正确关闭。这一整套走下来给你的感受绝对不是“快”而是“稳”。你可能会有种恍惚感好像对面不是一个语言模型而是一个带过几年项目的同事。4.3 多技能编排如何让技能打组合拳单个技能好用多个技能排好队更好用。但“排好队”这个词是关键如果多个技能同时被触发它们可能会打架。我常用的一个组合是brainstorming → planning → TDD → code review。这个组合基本覆盖了一个功能从想法到落地的全过程。使用的时候我会在每一段对话里明确指定当前的主导技能比如“现在只用 planning 技能不要写代码只拆任务”。这句话看着多余但在多技能环境下特别重要。为什么因为 AI 看到你有想法、有任务、又提到代码它可能想同时启用规划和执行类技能。如果你不做阶段限定它就会一边拆任务一边写代码最后两头都不彻底。所以我的经验是一次让一个技能主导阶段完成后再切换。就像放权给项目经理你不能既让他规划又让他直接把所有活都干了他会乱。自己写技能的时候也是一样描述里尽量加上使用边界。不要在描述里写“可以用于开发和测试”而是写清楚“只负责测试用例设计与执行”。边界越清楚组合的时候越不容易出乱子。5. 常见问题与排查技巧实录5.1 装了技能包但 AI 一直说不会这个问题我见过太多次了十个“装完没效果”的人里八个是路径错了。最常见的情况是嵌套层级不对。AI 编程助手读取技能时预期的是skills/技能名/SKILL.md这样的结构。如果你复制的时候多包了一层变成了skills/superpowers/skills/技能名/SKILL.md它就读不到了。遇到这种问题先冷静按顺序排查。先用前面那个find命令看一眼目录结构确认每个技能目录下面确实有 SKILL.md。再确认你放到的是配置目录而不是随便建的文件夹。最后确认会话已经重启过技能文件是在会话启动之前放好的。这三步走完问题基本就解决了。5.2 技能存在但对话里总是不触发文件都在AI 也能列出技能名但真实对话里它就是不用这个问题比单纯找不到要隐蔽一些。核心原因一般是两个。一个是你的请求表达和技能描述里的关键词离得太远。比如技能描述里写的是“代码审查”“Code Review”你在对话里说的是“帮我看看这代码有没有坑”AI 可能就匹配不到。解决方式很直接要么你在对话里主动点技能名要么把技能描述改得更贴近日常说法把“看看代码有没有坑”“查不到 bug 的原因”这类口语加进描述里。另一个原因是某些模型为了安全倾向于不主动启用带操作性的技能。遇到这种情况还是那句话主动点名最靠谱。你可以把它当成一个习惯每次想让 AI 按某个流程走就把技能名说出来。5.3 好几个技能同时抢任务执行乱套多技能同时触发在自动匹配模式下偶尔会发生。比如你说“帮我规划这个功能并实现”AI 一看规划类技能合适执行类技能也合适干脆两个都启用结果它的输出先是一大段计划紧接着又跳到代码代码写到一半又回头补计划整个对话糊成一团。我的处理方式就是之前说的“阶段限定”。在需求刚提出来的时候我先讲清楚“这个阶段只需要规划出计划文档就行”。等计划确定了再开一个新对话“按这份计划开始实现用 TDD”。新对话的好处是上下文干净AI 不会惦记着前面没写完的东西。如果你在自定义技能时遇到冲突可以在描述的末尾加一句“只在用户明确要求时使用”这能有效降低它主动抢活的概率。5.4 装了技能包之后回复变长、流程变重这是很常见的抱怨而且它不是一个 bug它是机制本身带来的副作用。技能包本质上是在给 AI 加流程流程的代价就是对话轮次变多回复长度变长。你让它写个导出功能它反过来问你四个问题再给你四段流程看起来确实不如直接甩代码快。但你要分清“慢”和“浪费时间”。直接甩代码是前十秒快后面可能要改三遍整体更慢。走流程是前面多花两分钟后面一遍过。我把话说得直白一点如果你只是临时写一段一次性脚本把技能关了吧真的没必要。如果你的代码要上线、要维护、要交接那就留着流程这点“重”是值得的。5.5 排查速查表症状可能原因检查与解决对话里完全看不到技能路径错误或层级多套一层用find ~/.claude/skills -maxdepth 2 -name SKILL.md查结构技能列表能看到但对话不触发请求关键词与技能描述不匹配主动点名技能或修改 SKILL.md 描述多个技能同时执行、输出混乱自动匹配选了多个技能在对话中指定“本阶段只用某个技能”回复变长、流程变重流程类技能默认生效按场景裁剪技能目录关掉不常用的技能原仓库更新后自定义内容丢失覆盖安装安装前先备份 skills 目录6. 实操心得装完之后我的工作流发生了什么变化6.1 最明显的变化AI 开始“先想后做”了用了一段时间之后我最大的感受是 AI 的做事风格变了。以前它是个执行力很强的急性子你提需求它马上动手动手就收不住。现在它变成一个会先问“你这个需求背后是什么”的人虽然它还是那个模型但行为方式完全不一样了。最直观的变化有三个。第一它开始主动追问我之前没想到的问题比如导出功能的字段范围、错误日志的处理方式、兼容性要求。第二写代码前先写测试这个习惯一开始我还不适应觉得多此一举直到有两次它因为测试挂了真的停下了修改逻辑我才意识到这个流程在起作用。第三它修 bug 的方式变了不再连着给我三个“可能的原因”而是先跟我确认怎么重现再提出假设并进行验证最后才动手。当然代价也有。初期和 AI 的对话明显变长一个功能从提出到落地要多花几分钟的“确认时间”。但你把返工成本算进去这笔账是划算的。以前我经常要自己盯着 AI 写的代码自己补边界测试现在它把这些活都揽过去了我更多是看计划和结果。我在实际操作中养成了一个小习惯每个新任务开始时我会先问自己一句“这个任务适合走完整流程吗”。适合的就放手让它用技能跑一遍不适合的比如临时查个 API 用法我就明确告诉它“直接用默认模式不要调用任何技能”。这样既享受了流程带来的质量又没让流程拖累简单场景你可以试试。6.2 给新手的三个配置建议如果你刚接触这套东西我给你三个实在的建议。第一别一口气把整个技能包都装上。先用最核心的三个规划类、测试驱动、代码审查。等熟悉了它们的脾气再慢慢把调试、边界测试这些加进来。一下子全装AI 的判断负担大你也看不懂它在干什么。第二每个项目都要有自己的项目级技能。superpowers 装的是通用方法论但你项目里的编码规范、命名习惯、目录约定是特有的。我建议你在技能目录里单独建一个项目技能把团队的约定写成 SKILL.md。这样 AI 在干活的时候不光是会“按流程走”还会“按你们约定的方式走”。第三定期清理和更新。我看到太多人装完就再也不管了结果技能描述写得越来越不符合实际需求自动匹配的准确率越来越差。每隔一两周把不常用的技能挪出目录把常用技能的描述根据最近的使用场景润色一下这个成本很低收益却很实际。6.3 这整套机制还能用来做什么聊到最后一个话题我想说 superpowers 给你的最大价值可能不是那几十个现成的技能而是这整套“把方法论变成可复用文件”的机制。你在团队里带过项目就知道每个人的经验都在脑子里人一走经验就没了。技能包这种 SKILL.md 的组织方式天然适合做经验沉淀。你可以把团队的代码评审清单、上线检查清单、故障处理手册全部整理成技能文件放进配置目录。新人加入AI 助手自动就按团队规范干活了不用靠人肉传话。再往大了说这个机制不只适用于代码。写作团队可以把文章风格规范做成技能数据分析团队可以把取数流程做成技能运维团队可以把巡检清单做成技能。只要是流程明确、步骤清晰的工作都可以沉淀成技能文件。最后再分享一个小技巧你自己写技能的时候SKILL.md 里的描述一定要用“当用户需要……时使用尤其是当用户提到……时”这种句式。因为 AI 是靠描述来触发技能的描述越贴近真实请求触发的准确率就越高。把这个写好了你自定义的技能基本就等于一个永远记得规矩的同事。