
superpowers这个词在AI编程工具圈子里最近确实很火。我第一次看到这个项目的时候第一反应是“这不就是个技能包合集吗”但实际用了两个星期之后我得承认它改变了我和AI协作的方式。简单说superpowers是一套可以安装到AI助手比如Claude Code这类工具里的skills集合每一个skill都是一份结构化的指令文件告诉AI在特定场景下该按什么流程干活。它的价值在于把“AI很有潜力但常常不会干活”这个问题变成了“让AI按照你的套路来干活”。这篇内容我打算从零开始讲清楚三件事superpowers到底解决什么问题、有哪些核心skills、以及怎么在你的环境里安装和真正用它干成事。无论你是刚接触AI辅助开发的新手还是已经在深度使用AI编程工具的老手这套东西都值得你花半小时试一试。1. 先搞清楚superpowers到底是什么1.1 它解决的是“AI有潜力但不会干活”的尴尬用过AI编程助手的人应该都有过这种体会刚装好的时候觉得它神了能写代码、能解释报错、能帮你重构。但用着用着就会发现它在处理小任务时很聪明一遇到稍微复杂一点的需求就开始“自由发挥”——写出来的代码能用但不是你想要的风格改动了一个文件却忘了关联的测试让你审查代码它泛泛而谈说“代码质量不错”一句有用的都没有。问题出在哪出在AI缺少“工作方法”。它知道的东西很多但它不知道你的团队约定、不知道你想要的输出格式、不知道一个完整的代码审查该分几步走。你每次都要在对话里重复交代这些背景一旦漏了它就给你一个“正确但没用”的答案。superpowers的思路是把这些工作方法沉淀成一个个“技能卡”。每张卡里写清楚这个技能适用的场景、执行步骤、输入输出要求、以及常见坑。AI在执行任务前先读取对应的技能卡然后按卡上的流程来干活。你不需要每次重新教它技能卡就是它的“操作手册”。1.2 核心设计skills就是最小可用的“技能卡片”这个项目的核心概念就是skills。一个skill本质上是一个目录里面至少包含一个SKILL.md文件。这个文件采用Markdown格式用结构化的方式描述技能的名称、描述、使用场景、步骤、示例和注意事项。举个例子一个名为code-review的技能卡它的SKILL.md里面会写这个技能用于AI辅助代码审查触发条件是用户要求审查代码变更执行步骤是先读取diff、再检查逻辑正确性、然后检查边界条件、最后输出带有严重级别标记的审查意见清单输出格式是列表每条意见包含问题描述、所在文件、风险等级、修改建议。你可能会说这不就是提示词吗对本质上就是比普通提示词更规范、更模块化、更可复用的提示词。但关键区别在于superpowers不是让你把一大堆提示词堆在系统提示里而是让AI按需加载。用哪个技能就调用哪个技能不用的不占上下文空间。这一点在实际使用中非常重要——上下文窗口是有限的一次性塞入所有提示词只会浪费token还会导致AI抓不住重点。2. 怎么安装superpowers以及两种引入方式2.1 安装前先确认你的运行环境在动手之前先确认你用的AI编程工具支持自定义skills。目前主流的Claude Code、Cursor这类工具基本都支持通过目录结构加载自定义技能。如果你用的是其他工具建议先查一下文档里有没有类似“skills directory”或“commands”的配置项。另外要注意superpowers本身是社区驱动的开源项目安装方式一直在迭代。我用的版本是基于Git仓库直接克隆的整个安装过程不需要编译也不需要装额外的运行时依赖只要你的机器上有Git和基本的命令行环境就行。我个人建议在安装之前先创建一个干净的测试目录比如~/superpowers-test在里面做实验。这样做的好处是万一装坏了或者不满意直接删掉这个目录就恢复原状不会污染你平时的工作项目。2.2 方案A用安装器一键装这个项目提供了一个安装脚本适合大多数使用者。打开终端执行以下命令git clone https://github.com/example/superpowers.git cd superpowers ./install.sh安装脚本会做三件事第一把skills目录拷贝到你当前用户目录下的AI工具配置目录比如~/.claude/skills第二创建一个环境变量文件记录skills的根路径第三在终端里输出一行提示告诉你安装完成。装完之后可以验证一下ls ~/.claude/skills正常情况下你会看到一堆以技能名命名的目录比如brainstorming、code-review、git-workflow这些。看到这些目录就说明安装成功了。注意如果你之前已经在~/.claude/skills里放了自己的技能不要直接跑./install.sh它可能会覆盖同名目录。先备份再安装。2.3 方案B手动克隆并软链适合定制一键安装省事但如果你像我一样有定制需求我推荐手动方式。手动方式就是把skills目录软链到你的项目里这样你可以随时改技能内容而且改动对所有项目生效。步骤很简单# 1. 克隆仓库到你喜欢的位置 git clone https://github.com/example/superpowers.git ~/superpowers # 2. 在你的项目里建立软链 ln -s ~/superpowers/skills ~/my-project/.claude/skills这种方式的优势是“所见即所得”。你想修改某个技能直接打开~/superpowers/skills/code-review/SKILL.md编辑即可下次AI加载的就是新版本。而且不同项目可以链接到同一份技能目录维护起来很省心。2.4 环境变量与配置项不管用哪种方式安装都要确认AI工具能读到技能目录。以Claude Code为例它会在启动时扫描当前工作目录下的.claude/skills以及用户目录下的~/.claude/skills。两边都会加载但优先级不同项目目录下的技能会覆盖用户目录下的同名技能。如果你想自定义技能的扫描路径可以设置环境变量export SUPERPOWERS_SKILLS_DIR$HOME/superpowers/skills设置了之后确保AI工具的配置里包含了这个路径。具体怎么加看工具文档一般是写进配置文件里。3. 有哪些实用的skills以及各自的使用场景3.1 技能清单概览superpowers里到底有多少个skills我数了一下我本地这个版本大概是二十多个。数量不算多但每个技能的定位都很明确。下面我把最常用的几个列成一个表方便你对照查看技能名称适用场景核心价值brainstorming需求不明确时先做思路梳理和方案发散避免AI拿到模糊需求就硬写代码writing-plans把一个复杂任务拆解成可执行的步骤清单让AI先规划再执行减少返工executing-plans按照既定计划逐步实现代码改动防止AI跳步、遗漏关键环节code-review对已有代码进行结构化审查输出带严重级别的审查意见test-driven-development按TDD流程写测试和实现代码强制先写测试再写实现git-workflow规范化Git提交、分支操作和冲突处理让AI帮你按团队规范提交代码debugging系统化排查运行时错误和逻辑bug让AI按“复现-定位-根因-修复-验证”五步走subagent-delegation把一个大任务拆给多个子Agent并行处理突破单线程上下文限制creating-issues根据对话内容自动生成规范的Issue描述保持项目管理的输入质量documentation自动生成和维护项目文档让文档写作用统一的结构化模板每个技能都不是孤立的。实际使用的时候它们经常组合出现。比如接到一个新需求你可能先用brainstorming梳理方案再用writing-plans生成执行计划然后用executing-plans逐步落地最后用code-review检查成果。整套流程走下来就像带了一个很懂规矩的实习生。3.2 重点skills的实操演示以code-review为例光看清单还是不够直观我拆一个大家最有感知的code-review技能看看它的SKILL.md是怎么组织内容的。--- name: code-review description: 对代码变更进行结构化审查输出严重级别标记的审查意见 --- # Code Review ## 触发条件 - 用户要求审查代码、检查PR、review diff - 用户提供了一段待审查的代码或指出了变更范围 ## 执行步骤 1. 获取要审查的代码diff或文件列表 2. 逐文件阅读重点检查逻辑正确性、边界条件、安全风险 3. 对照项目的编码规范检查风格问题 4. 汇总问题清单 ## 输出格式 - 输出为Markdown列表 - 每条意见格式[级别] 文件:行号 - 问题描述 - 级别分为Critical必须修复、Warning建议修复、Nit可选优化 ## 注意事项 - 不要只做语法检查要关注逻辑层面 - 不要输出“代码整体不错”这类空洞结论 - 如果问题数量超过15条按严重级别排序后只输出前15条这个技能卡的精髓在于最后那两条注意事项。没有这一条AI往往会输出一堆正确的废话。有了这一条AI才会真正去抠逻辑漏洞并且控制输出量不会让你陷入信息过载。实际用的时候我会在对话里告诉AI“请用code-review技能审查一下src/utils.ts的改动”。AI就会按照技能卡的流程去执行最终给出的意见是分级的、带文件位置的、可操作的。那种“这里可能有问题但我不确定”的模糊话术明显变少了。3.3 自己写一个skills要遵循的要点用了一段时间之后你大概率会想写自己的技能。我建议先模仿现有技能的结构不需要从零发明。记住几个要点第一技能描述要写清楚触发条件。AI判断该用哪个技能主要靠的就是description字段里的关键词。描述越具体召唤的成功率越高。比如“用于审查代码变更”就比“代码审查”好用因为后者太宽泛AI无法判断什么时候该触发。第二步骤要写“可执行的动词”不要写“思考性的形容词”。与其写“仔细分析问题”不如写“列出输入的所有边界值”。AI对具体指令的遵循程度远远高于抽象指令。第三一定要写“不要做什么”。这个技巧很反直觉但效果出奇地好。因为AI模型本身倾向于讨好用户、说好话如果你不明确禁止它很容易输出“代码质量较高但有一些地方可以优化”这种彬彬有礼的废话。在技能卡里明确写入“不要输出空洞结论”之后输出质量会立刻上一个台阶。4. 真正上手我用superpowers完成一个实际任务的完整过程4.1 任务定义说了一堆概念我们来走一个真实场景。假设我手上有一个Python脚本data_cleaner.py负责清洗CSV数据。这个脚本有一个bug当输入文件包含空行时会导致索引错位最终输出结果不对。我决定用superpowers帮我修掉这个bug并且顺便补上测试用例。这个任务正好可以用到两个技能debugging用于定位根因test-driven-development用于补测试。4.2 运行过程记录我先在AI工具里发起请求“请用debugging技能帮我排查data_cleaner.py中的空行处理问题”。AI读取了debugging技能卡然后按步骤执行。第一步是复现问题AI先阅读了脚本找到了读取CSV的部分接着自己生成了一个带空行的CSV测试文件并运行脚本成功复现了索引错位。第二步是定位根因AI发现脚本在处理每一行数据时直接用row[0]取值但如果这一行是空行row就是一个空列表索引访问就会跳过这一行但索引计数却仍然增加导致后面的数据全部对不上。第三步是修复AI把原先“逐行索引取值”的逻辑改成先用列表推导式过滤空行再统一处理。修复之后重新跑测试数据输出正常了。这个过程中最有价值的部分是AI没有上来就改代码而是先复现、再定位、最后才动手。这就是技能卡里“执行步骤”的约束力。接下来我要求“用test-driven-development技能为修复后的脚本补充测试用例”。AI先读取技能卡然后按照“先写失败测试、再写实现、最后让测试通过”的流程来操作。它生成了三个测试用例空行文件、包含空行但不以空行结尾的文件、全空文件。第一个用例在修复前会失败修复后通过第二个用例验证了中间空行不会破坏索引第三个用例验证了极端情况下不会抛异常。最终脚本修复完成测试全部通过。整个过程中我只需要在关键节点说几句话确认方向其他都是AI按照技能卡自动执行的。4.3 效果与对比如果不用superpowers同样的任务AI大概率会直接读一遍代码然后给出一个修复建议。运气好的时候它一次改对了但更多时候它改完代码不会主动去验证也不会想到要补测试用例。有了技能卡AI的行为模式从“快问快答”变成了“按流程办事”。我自己最直观的感受是返工率明显降低了。以前让AI改代码经常要来回好几轮现在它按流程走一次通过的概率高了很多。而且因为过程规范了最终产出也更可控代码风格和你预先定义的规范更一致。5. 常见问题与排查技巧实录5.1 安装后AI找不到技能这是出现频率最高的问题。症状是技能卡明明已经放进目录了但让AI执行某个技能时它说“我不知道这个技能”或者“没有找到相关技能”。排查思路按顺序来。先检查技能目录的路径是否在AI工具的扫描范围内。用ls命令确认目录结构重点看看是不是多套了一层目录。比如你把skills放在~/.claude/skills/superpowers/skills下面AI扫描的是~/.claude/skills那它看到的是一堆子目录而不是技能目录自然加载不到。再检查一下SKILL.md的文件名是否正确。有些工具对技能文件的命名有严格要求必须是SKILL.md大小写都不能错。如果是skill.md或者skills.mdAI也识别不了。最后一个容易忽略的地方修改技能卡之后需要重启AI工具或重新发起一个新的对话才能生效。有些工具会缓存技能内容如果没重启你改的东西不会立即加载。5.2 技能加载了但没按技能执行有时候AI能“看到”技能但在执行任务时没有严格按照技能卡里的步骤来做。比如技能卡要求“先写测试再写实现”但AI还是直接写了实现。这种情况大概率是技能卡的指令和用户当前提示词发生了冲突。AI倾向于优先响应用户的最新指令。如果你在对话里说“先帮我改一下代码”AI就会直接改哪怕技能卡里写着要先写测试。解决办法有两种。第一种是严格约束AI的启动流程在对话最开头明确说“请使用test-driven-development技能执行并且严格按照技能中的步骤顺序来做不要提前写实现代码”。第二种更稳妥把对步骤顺序的要求直接写进技能卡的第一句比如“这是唯一可接受的执行顺序。开始执行时先展示你对步骤的理解然后按步骤操作”。把“唯一”“必须”这类强约束词写进去AI遵循的可靠性会高很多。5.3 上下文被大量技能卡占满效果反而变差我刚接触superpowers时犯过一个错误把二十多个技能全部塞进系统提示词里。结果AI变得非常“啰嗦”——它总是试图在回答里体现自己“记得”很多技能实际有效地执行反而变差了。原因很简单上下文窗口是有限的。技能卡是给AI学习用的“操作手册”不是给用户看的“产品目录”。把几十个技能说明一起塞进去AI会迷失在“我有哪些能力”的自我展示中而忽略了“我现在该执行哪一项”。正确的做法是“按需加载”。superpowers的设计本来也是按需加载的——你让AI用哪个技能它才去读取对应的技能卡。不要试图把所有技能混在一起全局加载。如果某些技能的使用频率特别高可以考虑单独建立一个精简版技能卡只保留最核心的步骤。5.4 版本更新时技能内容变化旧项目失灵superpowers更新比较活跃有些技能的内部结构会调整。我之前有一个自动化脚本依赖git-workflow技能卡里的某个输出格式。结果技能更新之后输出格式变了脚本解析就崩了。这个问题的解决方案其实很朴素把技能目录锁定在一个固定的commit版本上不要总是拉最新代码。改用软链管理的话在克隆仓库之后执行一次git checkout指定到你验证过的commit即可。新版本可以先在测试环境里跑几天确认没问题再切过去。6. 一些来自实际使用的避坑心得最后聊点书本上看不到的体会。superpowers最核心的价值不是“让AI更聪明”而是“让AI更听话”。它把模糊的协作过程变成了明确的执行流程。但这也意味着技能卡本身的质量直接决定了AI的执行质量。如果你只是从仓库里拉下来就直接用效果可能并不会立竿见影——因为通用技能卡面向的是大多数人的场景你的项目可能有自己的编码规范、自己的Git工作流、自己偏好的文档风格。建议你先跑通默认技能然后挑最影响你效率的一到两个技能花点时间做定制。定制时不要贪多。先改一个比如把code-review的输出格式改成你们团队提PR时的模板格式。用两周感受一下变化再决定下一个改哪个。一上来就大改特改很容易失去重点。另外提醒一点技能卡里的“负面约束”比“正面指令”重要得多。AI天然有讨好用户的倾向如果你不在技能卡里明确写“不要说什么”它就会输出一堆正确的废话。我见过的最实用的技能卡往往有一半篇幅都在写“不要做什么”。这条经验值得你写第一个自定义技能时重点参考。superpowers这套东西后续能怎么扩展我自己在尝试的方向是把团队的经验文档、Code Review规范、发布检查清单都整理成技能卡让每个接手项目的AI都能快速进入状态。等积累到一定量之后新同事入职培训的很多内容都可以交给AI来执行。这个思路比让AI记住一堆公司文档要有用得多。