★ FEATURED ARTICLE 1. 先搞清楚 Superpowers 到底解决什么问题1.1 一个让我转型的痛点场景说实话我第一次听到 superpowers 这个名字的时候第一反应是又一个 AI 插件。但真正把我拉进去的是一次让我印象深刻的失败经历。当时我在用 Claude Code 做一个中型重构任务。代码库大概二十万行涉及多个模块的依赖调整。我给了 AI 一个很明确的需求把支付模块的接口从同步改成异步。结果它二话不说就开始改文件改到一半我发现它对全局的影响完全没有评估——有些调用方还在用同步方式等待返回值有些测试直接编译不过。最后我只能回滚重新用非常详细的提示词一步一步引导它先分析调用链、再列出影响面、再写方案、最后才动手。那次之后我意识到一个核心问题AI 编码助手最大的短板不是不会写代码而是没有一套稳定的工作方法。它像一个很聪明但毫无经验的新同事——你问它什么它都能答但你让它独立负责一个任务它就容易凭直觉横冲直撞。Superpowers 就是冲着这个问题来的。1.2 SKILL.md把经验固化成流程的核心设计Superpowers 是 Jesse Vincent也就是 Perl 社区的老熟人 obra发起的开源项目。它的核心思路非常朴素把资深工程师的工作方法写成 AI 可以稳定执行的技能说明书。在 Superpowers 里每个技能skill就是一个包含SKILL.md文件的目录。这个文件用 Markdown 编写头部带 YAML 格式的元信息——技能的名称、描述、适用场景。正文部分则是非常具体、非常啰嗦的操作步骤告诉 AI接到这个任务之后第一步做什么、第二步做什么、每一步要输出什么。你可以把它理解为给 AI 写的一本岗位 SOP。比如调试技能它不会只说请修复这个 bug而是会指导 AI先复现问题拿到可重复的最小触发条件再用二分法或日志插桩定位根因而不是猜测每次只验证一个假设明确记录证据修复后补充回归测试防止问题复发听起来很基础对吧但问题就在于这些基础方法 AI 不是不知道而是不会主动想起。你直接问 Claude帮我修个 bug它可能跳过复现直接开始改代码。而一旦你加载了调试技能它就会严格按照这套流程走。技能的本质就是把人类工程师理所当然的常识显式地写进提示词里让模型每次都照着执行。1.3 技能不是插件是操作手册这里要纠正一个常见的误解很多人把 Superpowers 理解成类似插件市场的东西装一个技能就等于给 AI 加了一个新功能。实际上不太一样。插件通常意味着模型本身做不了这件事需要外部程序来帮忙。而 Superpowers 的技能绝大多数是模型本来就能做但做得不稳定、不系统的事情。比如头脑风暴、写实施计划、做代码评审——这些Claude模型本身完全会但让它自由发挥的时候质量随缘。技能的作用是把高质量的做法固定下来让 AI 每次都以同样的标准完成。打个比方你可以让一个厨师自由发挥做一道菜味道时好时坏但如果你给他一本菜谱写明食材比例、火候时间、装盘步骤他做出来的东西就会稳定得多。Superpowers 就是这本菜谱集而且菜谱的撰写者是一群有多年一线经验的工程师。搞清楚这一点很重要因为它直接影响你后续怎么使用这个工具——你不只是在装软件你是在给 AI 注入一套工作方法论。2. 安装 Superpowers完整实操记录2.1 环境准备与版本要求在动手之前先确认你的环境满足基本条件。Superpowers 目前主要面向 Claude Code 这类基于 agent 模式的 AI 编程工具也就是你的 AI 助手需要具备自主执行命令、读写文件的能力而不只是聊天窗口里的问答。我实测的环境是这样的macOSLinux 同理Windows 建议用 WSLClaude Code 已安装并完成登录系统里有curl和bash版本不太老就行如果你用的是其他支持 MCP 或技能机制的 agent 工具安装路径可能略有出入但核心思路一致。这个项目本身不挑语言环境它生成的技能文件就是纯 Markdown 加少量脚本任何能读取技能的 agent 都可以用。2.2 一键安装脚本做了什么官方推荐的安装方式是一条命令curl -sL https://superpowers.obra.io/bootstrap.sh | bash我在本地执行的时候脚本大概做了这么几件事检测你的~/.claude目录是否存在不存在就创建创建skills子目录也就是技能的存放位置从项目仓库拉取一批默认技能每个技能一个子目录配置让 Claude Code 在启动时能发现这些技能整个过程不到一分钟。装完之后我特意看了一下目录结构~/.claude/skills/ ├── brainstorming/ # 头脑风暴技能 ├── implementing/ # 功能实现技能 ├── debugging/ # 调试技能 ├── TDD/ # 测试驱动开发技能 ├── subagents/ # 子代理管理技能 └── ...每个目录下面都至少有一个SKILL.md有些还带着辅助脚本和示例文件。提示curl | bash这种安装方式圈内一直有争议——它意味着你把系统权限交给了远程脚本。我的做法是先下载脚本看一眼内容再执行或者用curl -sL URL -o install.sh保存下来检查。对于开源项目这个级别的东西风险通常可控但好习惯还是要有的。2.3 安装后的验证装完之后怎么确认它真的生效了我的验证方法很简单。打开 Claude Code直接问它你有哪些 skills 可以使用如果安装成功它会列出从技能目录里读取到的技能清单并附上一句话描述。我第一次跑这个验证的时候Claude 的回答是brainstorming帮助你在动手前充分探索和评估想法writing-plans把需求拆解成可执行的实施计划implementing按照计划逐步实现功能debugging系统化地定位并修复问题TDD用测试驱动的方式开发subagents管理异步和同步子代理并行推进任务看到这个清单基本就可以确认技能已经被正确加载了。另一个验证角度是试着触发一个技能。比如你描述一个模糊想法说我想给这个工具加一个命令行交互模式然后问它应该怎么开始。如果它没有直接甩给你一堆代码而是先问你几个澄清问题、帮你梳理思路那说明brainstorming技能已经被正确调用了。2.4 安装失败与权限问题的处理我周围有不少朋友在安装时踩过坑主要集中在两种情况。一种是权限问题。脚本需要写入~/.claude目录如果目录被其他进程占用或者归属权限不对会报Permission denied。这个好解决手动把目录所有权改回来就行chown -R $(whoami) ~/.claude另一种是网络问题。仓库拉取失败典型的报错是Could not resolve host。这种情况多半是网络环境受限需要你配置代理或者换个网络再试。这里不再展开属于常规排查手段。还有个隐藏很深的坑如果你之前手动创建过~/.claude/skills目录里面放着一些同名技能bootstrap 脚本默认可能会跳过或覆盖导致新旧技能混杂。我建议安装前先看一眼目录里有没有同名文件夹做好备份再动手。3. 自带 skills 全景这些技能分别解决什么问题3.1 工作流类技能从灵感到落地的完整链路Superpowers 默认带的技能里最核心的一组是围绕一个功能是怎么从想法变成代码这条链路设计的。brainstorming头脑风暴负责最前端的环节。它的价值在于阻止 AI想到就做。当你抛出一个模糊需求时这个技能会把过程拆成几步先澄清目标、列出各种可行方案、对每个方案做成本收益分析、最后收敛出一个推荐方案。它的输出通常是一份结构化的文档而不是代码。writing-plans编写计划接在头脑风暴后面。它把确认好的方案变成可执行的步骤清单明确先改哪个文件、后改哪个文件、每个步骤的验收标准是什么。这份计划会成为后续实施阶段的行为约束。我在用的时候发现只要计划写得足够细实施阶段的返工率会明显降低。implementing实施负责实际动手。它会要求 AI 严格按照已有的计划执行每完成一步就停下来验证而不是一口气改十个文件。这个技能还包含发现计划有漏洞时怎么办的处理流程——先停下来重新评估而不是硬着头皮继续。三个技能放在一起其实就是一套完整的先想清楚再动手的开发方法论。如果你经常觉得 AI 写代码跑得太快、想得太少这组技能就是解药。3.2 工程实践类技能把基本功夫刻进提示词第二组技能对应的是工程师日常的基本功调试、测试、代码评审。debugging调试是我个人用得最多的技能之一。它的核心原则是定位根因之前不要改代码。技能文档里会引导 AI 先建立可复现路径、再通过二分排除缩小范围、每次修改前先记录当前行为、用证据驱动判断。这听起来像废话但如果你让 AI 直接改过 bug 就会知道——它非常容易看到一个可疑点就立刻改。这个技能就是用来压制这个坏习惯的。TDD测试驱动开发也不是什么新鲜概念但把它变成技能之后效果很有趣。AI 会被引导着先写一个失败测试、再写最小实现让它通过、然后重构小步快跑。对于生成型模型来说这种方式反而更稳因为每一步的目标都非常明确模型犯错的概率比一次性写完整个功能低很多。code-review代码评审则是把评审标准标准化。它不会只丢一句代码写得没问题而是从正确性、可维护性、安全性、性能等维度逐个过一遍最后输出一份带严重级别标记的问题列表。这三项技能放到一起覆盖了写完代码之后怎么保证质量的整个链路。3.3 协作效率类技能让 AI 学会并行工作第三组技能围绕的是 agent 之间的协作最典型的是subagents子代理管理。单个 AI 会话执行任务时是串行的——写一个文件、等它返回、再写下一个。但对于大型重构任务完全可以拆分给多个子代理同时推进。subagents 技能定义了同步和异步两种子代理模式同步子代理主代理等待子代理完成适合需要立刻拿结果做判断的场景异步子代理主代理先派发任务子代理在后台执行主代理同时做别的事最后统一收拢这个技能最大的价值在于让 AI 学会合理的任务拆解。它会指导主代理判断哪些任务可以并行、哪些任务存在依赖必须串行、每个子代理的上下文边界在哪里。我第一次用异步子代理跑一个跨三个模块的重构时间节省了将近一半但那是我已经把任务边界想得很清楚的情况下。如果你任务本身耦合度高硬拆反而会更慢。3.4 理解类技能先读懂再动手最后一类技能面向的是阅读代码这个场景。reading阅读技能会引导 AI 系统性地理解一段陌生代码先看入口、再看数据结构、追踪调用链、最后总结模块的职责和边界。它输出的通常是一份代码说明文档。这个技能看起来最不起眼但实际用途非常大。AI 在没有引导的情况下读代码经常东看一眼西看一眼总结出来的东西是碎片化的。用 reading 技能之后它的分析结构会清楚得多而且在读完之后你可以直接让它基于这份理解去改代码准确性比上来就改高不少。4. 实战怎么真正把这些技能用起来4.1 自动调度每个技能就是挂在提示词后面的默认动作第一次接触 Superpowers 的人最常问的问题就是怎么引入这些技能——是需要在提示词里手动写请使用 brainstorming 技能吗其实不用这么麻烦。Superpowers 的机制是技能描述会出现在 AI 的上下文里AI 会根据任务内容自动判断该调用哪个技能。你什么都不用做只要正常描述需求就行。比如你直接说我想给我的脚本加一个自动重试机制不需要强调请先头脑风暴AI 看到这个需求后会觉得这属于方案探索类任务自动走到 brainstorming 的流程里去。它会先问你重试的触发条件、最大次数、退避策略而不是直接帮你把代码写了。这个自动调度机制是 Superpowers 设计里最精妙的部分。它不强制你改变使用习惯只是在后台默默给 AI 加了一套行为准则。4.2 手动召唤精确控制 AI 进入特定模式自动调度虽然方便但 AI 的判断偶尔会跑偏。尤其是你明确想让 AI 干某件事的时候自动调度反而多此一举。这时候就需要手动指定技能。方法也很直白在提示词里直接写明请使用 debugging 技能帮我分析这个报错粘贴错误信息或者请使用 code-review 技能审查我刚才提交的那段代码。使用某某技能这个短语会精确触发对应的SKILL.md流程。我实测下来这种显式指定比自动调度的可靠性高很多尤其是在多个技能都可能匹配的情况下。AI 一旦进入指定技能模式就会严格按文档里的步骤走且通常会先简述它接下来的行动顺序让你有机会在中途纠正方向。4.3 把多个技能串成一条完整流水线Superpowers 里单个技能虽然好但真正的威力在于串起来用。我在做一个新功能模块的时候典型的工作流是用 brainstorming 梳理需求确定方案用 writing-plans 把方案拆成实施计划用 TDD 指导开发先写测试再写实现用 code-review 对最终代码做一遍自查遇到问题插队使用 debugging 定位根因你可以直接一次性把整条链路告诉 AI我们按这个流程来先 brainstorming 确定方案再 writing-plans 做实施计划然后 TDD 开发最后 code-review。AI 会很自然地按顺序切换技能每个环节结束时主动汇报当前状态再进入下一个环节。我实际用下来的感受是当 AI 知道自己在一条流程的哪个位置时它的输出质量会稳定很多因为每一个独立步骤的目标都变小了、更清晰了。4.4 一个真实项目里的技能调用顺序拿我之前一个实际项目举例我要给内部工具加一个导出报表为 Excel 的功能。如果按照传统方式直接让 AI 写它会立刻去查库、写代码、引入依赖然后可能卡在某个文件权限或者依赖版本的问题上。而用 Superpowers 的流程跑下来节奏完全不一样第一步brainstorming 让 AI 反问了我几个问题报表字段是固定的还是动态的导出的数据量级有多大Excel 格式有没有版本要求要不要支持模板这些问题我之前根本没想过但它们直接决定了技术选型。第二步writing-plans 给出了详细的实施计划先定义导出数据模型、再写序列化逻辑、最后接入 CLI 命令入口每一步都标注了验收标准。第三步TDD 阶段按照计划先写了针对导出函数的单元测试然后一步步实现每次跑测试确认绿灯。第四步code-review 阶段 AI 自己发现了一个我没有注意到的隐患大数据量下一次性构建整个 Excel 对象可能导致内存溢出于是建议改成流式写入。整个过程下来我基本没有返工只在小细节上调整了几次。这在以前用裸 Claude Code 的时候是不可想象的——以前它的代码我总要自己再检查一遍因为不确定它有没有跳过什么关键步骤。5. 编写与引入自定义技能把团队经验沉淀成 SKILL.md5.1 技能目录的规范结构Superpowers 的价值不止在于内置技能更在于它提供了一套低成本的自定义技能机制。你完全可以把自己团队的工作规范、项目特有的操作流程写成自己的 skill。一个标准的技能目录结构长这样my-skill/ ├── SKILL.md # 技能说明文件必填 ├── scripts/ # 可选辅助脚本 ├── resources/ # 可选参考文档或模板 └── skills/ # 可选嵌套子技能重点是SKILL.md这个文件。它的 YAML frontmatter 一般长这样--- name: my-skill description: 这个技能用于处理某某类型的任务。当用户提出某某需求时使用。 ---name是技能的标识description是 AI 判断何时调用该技能的依据。description 写得好不好直接决定了自动调用的准确率——写得太笼统AI 容易在无关场景里触发它写得太狭窄AI 又会在该用的时候忽略它。5.2 一个完整 SKILL.md 的字段拆解正文部分就是我前面说的岗位 SOP。拿一个简单的例子来说假设我想给 AI 定义一套发布前检查清单技能## 执行流程 1. 读取当前分支的变更文件清单确认没有未提交的临时文件 2. 检查所有新增的环境变量是否已在配置文档中登记 3. 运行测试套件确认全部通过 4. 扫描代码中是否残留调试输出console.log、print、debugger 5. 确认 CHANGELOG 已更新并写明变更描述 6. 输出一份发布检查报告标明每项检查的结果通过/未通过/跳过 ## 注意事项 - 第 2 项如果发现未登记的变量不要直接修改代码先询问我是否需要补充登记 - 第 4 项扫描结果里包含误报时逐一说明理由不能静默跳过 - 所有检查项必须给出明确的证据不要使用看起来没问题这种模糊结论把文件保存到~/.claude/skills/release-check/SKILL.md然后重启 Claude Code这个技能就被加载了。我在自己的团队里做过类似的东西把代码风格规范、数据库迁移步骤、接口设计约定都写成了技能效果比发文档给同事背好得多。5.3 依赖、资源与子技能的组织方式进阶用法是给技能配置资源和子技能。比如你的技能在执行过程中需要参考一份公司内部的编码规范文档可以放在resources/目录下并在SKILL.md里用相对路径引用。AI 需要的时候会主动去读这份文档。如果某个流程足够复杂可以拆成多个子技能形成层级关系。例如主技能发布流程可以拆成测试检查构建打包部署验证三个子技能每个子技能一个目录主技能的文件里按顺序调用它们。这种组织方式的好处是可复用性。子技能可以在不同主技能之间共享比如构建打包既可以被日常开发流程调用也可以被发布流程调用。不用重复写修改时也只需要改一处。5.4 从能用到好用的迭代方法自定义技能想写得好我自己的经验是不要一次追求完美先写一版能跑的然后靠实际使用反馈迭代。第一版技能往往写得过于理想化——步骤很多、条件很多但你很快会发现 AI 在某个环节频繁卡住或者某个检查项根本不适用。这时候就回来改SKILL.md把它变得更精简、更贴合实际。我有个自己写的数据库迁移技能改了七八个版本才稳定下来。第一版我写了一大堆安全检查和备份步骤结果 AI 每跑一次都要问我两三个问题烦得很。后来我把一些明确可以默认的值写死在技能里只在真正出现模糊性的地方才提问效率立刻上来了。这个迭代过程本身就是 Superpowers 的核心理念你通过不断编辑技能文件把对 AI 的调教结果沉淀下来。今天你为了让 AI 正确完成某个操作而额外补充的那句提示完全可以写进技能里让它明天自动照做。6. 用了两个月的教训与心得6.1 这些坑我真实踩过将近两个月用下来有四个问题我认为值得单独拎出来讲。第一个坑技能描述太宽泛导致 AI 频繁误触发。我有个同事给技能写的 description 是处理任何与代码质量相关的事情。结果 AI 几乎每个任务都会调用这个技能然后技能本身又什么都管反而把简单的事情搞复杂了。后来我把 description 改成非常具体的触发条件比如当用户要求审查代码、重构代码或者评估技术方案时使用误触发率明显下降。第二个坑技能步骤要求太死板AI 会为了走流程而走流程。我一开始写的技能里要求 AI 每步都输出详细报告结果它花大量时间生成格式完美的报告却忽略了实际任务。后来我在技能里加了一条规则如果某一步的结论不影响后续决策可以一句话带过不用展开。第三个坑旧技能没有及时清理。项目迭代之后某些技能描述的技术方案已经过时但 AI 还是会调用它导致给出的建议跟当前代码架构不匹配。这块儿没有银弹只能靠定期回顾技能目录删掉没用的、更新过时的。第四个坑并行子代理的资料共享问题。异步 subagents 之间如果存在共享数据依赖容易出现各改各的、最后合不上的情况。用 subagents 技术之前务必确认任务之间的边界足够清晰。6.2 什么项目最适合用它基于我的使用体验Superpowers 最适合的场景是中等以上复杂度、需要多步骤完成的工程任务——功能模块开发、代码重构、bug 系统排查、代码评审。这些任务里 AI 最大的问题是缺乏节奏感而技能恰好能补上节奏。反而不太适合的场景是那种一次性小任务比如把这个字符串格式改一下“给这个函数加个参数”。这种场景下技能反而显得累赘——AI 花在走流程上的精力比干活还多。另外一点如果你是团队负责人Superpowers 的价值会被放大。因为它把个人经验变成了团队资产。团队里任何一个人踩过的坑、总结出的写代码规范都可以固化成技能文件其他同事的 AI 就能直接复用。这比发文档、开分享会要有效得多。6.3 我的个人使用建议最后聊几个具体操作层面的建议。第一装完之后先别急着干活花十分钟把自己常用的几个技能看一遍了解每个技能大致干什么、什么时候触发。你越了解它你越知道怎么指挥 AI 切换技能。第二手动指定的优先级永远高于自动调度。当你带着明确目的使用 AI 时直接说出要用的技能名称不要依赖 AI 自己判断。自动调度属于兜底方案适合你也不太确定该怎么下手的时候。第三把技能文件纳入你的版本控制。我的~/.claude/skills目录是挂在 Git 仓库里的。改坏了可以回滚跟同事同步也方便。尤其是自定义技能一旦丢失重写一遍的成本很高。第四保持简单。技能的价值在于稳定复现而不是功能大而全。一个技能如果超过十个步骤我建议拆成两三个子技能否则 AI 执行到后面容易丢掉开头的上下文。我现在的日常节奏已经完全是技能驱动的了任何开发任务进来先让 AI 跑 brainstorming 理清思路再 writing-plans 出计划然后 TDD 一步步实现。AI 还是那个 AI代码能力没有变强但因为每一步都按流程走输出质量肉眼可见地稳定了下来。如果你也在用 agent 模式写代码并且经常被AI 太着急动手困扰我建议你花十分钟装一下 Superpowers然后试着让它在某个中等任务上全流程跑一遍——你大概率会刷新对 agent 能力的认知。
阅读完成 · 觉得有帮助？
