1. superpowers 是什么一套让 AI 从“嘴强王者”变成“带方法论搭档”的技能库1.1 AI 写代码最大的坑从来不是模型不够聪明我最近把 Claude Code 用得很重但一直有一个绕不开的痛点它太容易“想到哪写到哪”。你说“帮我实现一个用户登录功能”它恨不得三秒之内就把一整段代码甩出来看起来像模像样实际一跑全是问题后面就是无穷无尽的返工。这不是模型不行是它缺少“过程控制”。你让一个刚入职的实习生直接写模块他也能写出来但大概率跳过需求澄清、不划分优先级、不写边界测试、写完也不自查——AI 在普通对话里就是这个状态知识渊博但流程缺失。superpowers 解决的正是这件事。它不换模型不改 UI而是给 Claude Code 这类支持 skills 机制的 AI 编程工具挂载了一个“结构化技能库”。每个技能就是一份干活的 SOP从头脑风暴到系统思考从任务规划到调试复盘AI 会在合适的场景自动加载对应技能先想再做、按步骤执行、做完自查。我装上之后最大的感受是它逼着 AI 走流程而这恰恰是过去几百次对话里我最想要却始终没拿到的东西。1.2 为什么是“技能包”而不是提示词或插件很多同类方案是写一大段 system prompt或者写个插件拦截请求。superpowers 的做法完全不同它把每个能力封装成一个独立目录目录里有 SKILL.md 主文件包含 YAML 格式的 frontmatter技能名称、描述、触发条件、允许调用的工具和正文具体的工作流步骤旁边还能放模板、示例、子步骤等辅助文件。AI 读到这个文件时相当于翻开了对应的“工作手册”。我自己的理解是提示词是一次性的、不可组合的而技能包是模块化的、可插拔的。你可以单独启用某个技能也可以把两个技能串起来形成新流程甚至完全不用的技能直接删掉——都不影响其他部分。对普通用户来说不需要理解它的工程哲学只要记住一点装好之后AI 手里多了一整套工具箱它会在合适的时机自动翻开对应那本说明书。1.3 这套技能库到底适合谁、能解决什么我先说清楚适用人群。如果你只是偶尔让 AI 写个一次性脚本说实话没必要折腾这套东西但如果你在用 Claude Code 做正经项目开发、做技术预研或产品规划又总是觉得 AI 输出不稳定、不可控那 superpowers 就是你缺的那块拼图。它把“遇事不决先发散”“动手之前先规划”“写完必须自查”这些优秀工程师的思维习惯变成了一套可执行的外部流程让模型的聪明才智真正落在正确的工作路径上。就我个人体验而言它带来的变化有三个层次第一输出质量更稳定AI 不会再一上来就写一堆没想清楚的代码第二过程可预期它每一步在做什么、为什么这么做都有据可查第三方法论可复制我可以把团队规范固化成自定义技能以后每个任务 AI 都会默认遵守。后面我会把安装、技能清单、调度方式和踩坑记录完整过一遍。2. 从零安装5 分钟把 superpowers 跑起来2.1 安装前先把“底座”理清楚superpowers 是给支持 skills 机制的 agent 用的目前用得最多的场景就是 Claude Code。安装之前建议先确认三件事。第一Claude Code 本身能正常跑起来至少跑通过一个简单任务第二系统里有 git 和 node因为很多技能在执行时会调用它们来做项目操作或脚本验证第三想清楚技能装在哪里。关于安装位置一般有三条路。全局安装把技能放在用户目录下的全局 skills 文件夹里对所有项目生效适合个人日常使用项目级安装放在当前项目的 skills 目录只对这个项目生效适合隔离不同项目的规范团队共享把技能目录作为插件仓库管理通过版本控制分发适合小团队统一工作流。我给新手的建议是先做全局安装简单、见效快跑顺了再考虑项目级拆分。2.2 安装的完整步骤以全局安装为例我实测下来最稳妥的步骤是这样# 1. 克隆技能仓库 git clone https://github.com/obra/superpowers.git # 2. 进入仓库确认目录结构 cd superpowers ls # 你会看到 skills/ 目录里面按技能名称分了多个子目录 # 3. 查看当前的全局技能目录 ls ~/.claude/skills # 如果没有这个目录就手动创建 # 4. 把 skills 里的每个子目录复制或链接到全局技能目录 cp -r skills/* ~/.claude/skills/如果你是项目级安装就把第 3、4 步的路径换成项目里的.claude/skills。第 4 步有个细节容易踩坑很多人图省事把整个仓库根目录复制过去了结果技能目录套了一层Claude Code 就识别不出来了。正确的做法是把skills/下面那一层真正的技能子目录放进去也就是说~/.claude/skills/brainstorming/SKILL.md这个层级必须是对的。2.3 怎么确认技能真的装上了装完之后重启 Claude Code然后用两种方式验证。第一种在会话里输入/skills看列表里有没有出现 superpowers 的技能第二种直接问它“你现在有哪些技能”正常情况下它会列出一串技能名和适用场景。更靠谱的验证方式是用一个小任务实测触发效果比如这样说“请用 brainstorming 技能帮我分析一下这个想法我想做一个极简待办事项 App但不知道从哪里开始。”如果 AI 真的按头脑风暴的流程输出了一组方案而不是直接甩给你一段功能清单说明技能加载成功并且触发机制在工作。我第一次验证的时候就发现技能没触发后来查出来是路径层级问题这个我放到最后面的排查章节细说。2.4 一个技能目录里到底藏着什么装完之后建议你先别急着用花两分钟看一下技能目录的内部结构。拿 brainstorming 举例skills/ └── brainstorming/ ├── SKILL.md └── templates/ └── brainstorm-template.mdSKILL.md 是核心里面 frontmatter 部分定义了技能的元信息尤其是 description——它决定了 AI 什么时候主动调用这个技能。正文部分则写清楚了完整的操作流程比如先发散再收敛、如何提出假设、如何评估方案优劣。templates 目录里的模板文件可以在 AI 执行过程中被读取作为输出格式的参考。看到这里你应该明白了superpowers 本质上不是传统意义的插件而是一套高度结构化的“文档”。任何会读 Markdown 的 AI 都能使用它这也是为什么它可以适配多种支持 skills 机制的 agent而不仅限于某一个工具。3. 有哪些 skills我把这份技能清单拆开给你看3.1 思考前置类让 AI 学会“想清楚了再动手”这一组技能是我用得最多、也最惊喜的部分它们解决的是“AI 太急着给答案”的老毛病。brainstorming 是名副其实的入门技能。它的触发条件通常是你提出了一个模糊的需求或想法。我经常跟 Claude 说“帮我想想这个功能怎么做”以前它会直接给一个方案现在它会被引导先展开多个角度为什么做这个功能、有哪些实现路径、每个路径的代价和收益是什么、有没有被忽略的约束。做完发散之后再收敛到一两个建议方案。我试了几次之后发现它给出的备选方案里经常有我没考虑到的方向相当于多了一个免费的外部视角。system thinking 是另一个让我觉得“值回票价”的技能。它的作用是让 AI 在做分析时画出系统的关键元素、它们之间的依赖关系、可能的反馈回路。举个例子我想改一个老模块的文件上传逻辑直接问 AI“影响面有多大”它能列出一堆调用点但用了 system thinking 之后它还会主动提醒我这个模块的日志格式、异常处理方式、甚至部署脚本里的相关判断都可能受影响。这种“连坐式”的影响分析靠普通对话很难稳定拿到。planning 则负责把目标转成可执行的计划。它和市面上大多数“生成一个 todo”的逻辑不一样它会强迫 AI 先明确范围边界、设定验收标准、识别风险点再拆阶段。我特别欣赏的是它会要求显式写出“最小可行范围”而不是一口气规划所有事情——这一点我过去在 prompt 里反复强调都做不到现在只要触发 planning 就会自动出现。3.2 执行落地类把计划变成真实产出想清楚之后接下来就是干活。这组技能负责把计划变成代码和产物。MVP thinking 是我个人理解被低估最多的技能。它要求 AI 在做功能时先识别“最核心的价值闭环”然后再动手。比如你要做一个数据看板AI 如果直接规划十几个图表和筛选器你就该让它触发 MVP thinking——它会先把“能跑通的数据列表 一个核心指标卡”作为第一版其他全部放到后续迭代。对独立开发者和产品经理来说这个技能几乎每天都能用上。execution 类技能和 coding 相关的流程负责具体实现。它的核心思想是“小步前进、边做边验证”。我在使用中发现经过 execution 约束的 AI 会主动把大任务拆成多个小 patch每做完一步就停下来检查结果而不是一口气生成几百行代码再让你慢慢找错。这个习惯一旦建立代码的可调试性会明显上升。代码质量和自查类技能也是执行环节的重要一环。它会引导 AI 在输出完成后做 self-review类型定义是否完整、错误处理有没有兜底、极端输入会不会崩溃、性能有没有明显隐患。以前这些检查全靠我在 review 时人肉提醒现在 AI 自己会先过一遍。3.3 复盘改进类让经验在项目里沉淀下来最后是复盘和反思类技能这类技能短期看不出效果但长期用下来价值非常大。reflection 技能会在任务收尾时触发。它不是让 AI 说一句“任务完成”就结束而是引导它回顾整个过程哪里卡住了、为什么卡住、当时的排查思路是否有效、后续同类任务可以怎么优化。我第一次看到它输出复盘报告时挺惊讶的因为它把我在调试时反复走弯路的过程也记录下来了还给出了下一次可以更快定位的建议。如果你持续在一个项目里使用这套技能会发现一个有趣的现象AI 在“你”的项目里表现越来越好。因为每个任务结束后的反思都在补全它对项目上下文的理解。从个人经验来说让这些技能和你的使用习惯磨合一段时间之后复盘的增量价值甚至会超过新建任务时的一轮头脑风暴。我把几个核心技能整理成了一个速查表方便你对照自己的场景去使用技能触发场景核心作用brainstorming需求模糊、想法未成型多方案发散再收敛建议system thinking分析架构、评估影响面识别元素依赖与反馈回路planning任务目标明确、需要拆解输出阶段计划、验收标准与 MVP 边界MVP thinking做功能、做产品设计先锁定核心价值闭环再迭代execution / coding落地实现、写代码小步前进、边做边验证debugging线上或本地出 bug系统化定位问题、验证修复reflection任务收尾、阶段复盘沉淀经验、优化后续流程4. 怎么引入这些技能让 AI 在正确的场景自动调用4.1 自动触发机制你不需要每次手动喊话很多人以为用技能等于“命令里敲一个技能名”其实大部分场景根本不用。Claude Code 会在每次对话开始时读取所有已安装技能的元信息把当前用户请求和技能描述做语义匹配匹配到就自动加载对应技能。这也解释了为什么每个 SKILL.md 的 description 字段如此重要。它就是技能的“路标”写得好不好直接决定触发率。官方技能包的描述都写得比较讲究会包含触发关键词和典型场景如果你以后要写自定义技能最大的坑就是描述写得太笼统比如“用于提高代码质量”AI 根本拿不准什么时候该用它结果就是技能埋在列表里永远不触发。我建议你平常不需要刻意控制技能调度先让它自动跑观察一阵子之后你会慢慢发现哪些场景在线、哪些场景误触发那时候再动细节。4.2 手动指定与控制优先级把控制权拿回手里自动触发不是万能的我至少碰到过两类需要手动干预的情况。第一类是误触发。有次我只是想让它快速改一个样式问题结果它启动了 planning输出了一堆任务拆解和步骤时间线。对简单任务来说这是降智操作。这种时候直接说“不要用 planning直接执行”就能打断。第二类是漏触发。明明是很重要的架构分析需求它却直接开始写代码。这时候我会明确说“先跑一遍 system thinking再给我分析结果和计划”。手动指定的格式很简单在 prompt 里直接写上技能名。比如“使用 brainstorming 分析这个方案”“你是 executor按 execution 流程来做”。实测下来Claude Code 对显式技能名的遵从度很高远高于你让它“认真一点”“多想想”这种抽象指令。4.3 一个完整实战案例从想法到落地我拿最近做的一个小功能来演示完整流程。我给自己的博客加一个站内搜索功能这个需求一开始很模糊我只是跟 AI 说“博客需要一个搜索功能”。第一步它触发了 brainstorming。AI 列出了三个方案用现成的静态站搜索索引、接入第三方搜索服务、自己写一个轻量后端。每个方案都给出了代价和体验上的考量最后建议我先做方案一。第二步是 system thinking。因为博客是静态站构建的AI 分析了构建流程、内容模板、部署脚本、对页面加载速度的影响还提醒我搜索索引需要在每次发布新文章时重新生成。这些点我一开始完全没想到。第三步是 planning。它把工作拆成了五个阶段确认搜索范围和排序规则、生成索引数据、写前端搜索交互、接入构建流程、上线验证。MVP 边界被划在“能搜到标题就行”其他更高级的分词和模糊匹配全部放到下一轮。第四步执行。AI 开始写代码但没直接输出一个大文件而是先写索引生成脚本跑通了检查结果再写前端组件再接入构建流程。每步都小步验证整个过程我没怎么打断它。第五步是调试。实际跑的时候有个搜索词匹配不上的问题AI 触发 debugging 技能没有瞎猜而是先看索引数据的输出格式再用二分法定位到是转义逻辑的问题修完还验证了中文和英文两种场景。最后收尾时它自动做了 reflection总结出下次涉及静态站构建链路的改动应该先确认内容格式再动方案。这个案例里我没有手动指定过任何技能全程都是自动触发加按流程走但你明显能感受到 AI 的“做事风格”完全变了。4.4 把团队方法论固化成自定义技能我学会的最有价值的扩展玩法是把自己的开发规范做成自定义技能。做法不复杂在技能目录下新建一个子目录写一个 SKILL.md。核心还是 frontmatter 和正文两部分。比如我给前端项目写过一个约束技能描述写的是“当任务是修改或新增前端组件时使用”正文里列明流程先确认类型定义、再写业务逻辑、最后补样式和边界用例。装好之后AI 在相关任务中就会自动遵守这套规范不需要你每次在 prompt 里重复唠叨。对我这种带小团队的人来说特别有用团队规范直接变成 AI 的默认行为新人过来也不用手把手讲“我们这儿的代码风格是 xxx”了。5. 常见问题与排查技巧实录5.1 技能列表里看不到 superpowers这是安装环节最容易出的问题我总结了三个排查点按顺序检查基本都能解决。先看路径层级。重复一遍那个教训技能子目录不能嵌套过深~/.claude/skills/brainstorming/SKILL.md是正确的而~/.claude/skills/superpowers/skills/brainstorming/SKILL.md是错的。再确认是否重启了 Claude Code技能加载发生在会话启动阶段中途复制目录进去一般不会自动生效。最后看复制命令执行过程有没有权限报错有些系统目录受权限保护需要改成可写目录或使用符号链接。5.2 技能不触发AI 还是老一套如果你已经能通过/skills看到技能但实际对话里 AI 不按技能走那问题多半出在“当前任务的特征和技能描述的匹配度”上。比如你想让 AI 分析影响的边界它却直接开写代码这时候先尝试手动触发“使用 system thinking 技能分析这个改动的影响面”。如果手动触发有效基本可以确定是描述匹配度不够或者是任务描述里的触发词不够明确。另一种可能是有多个技能同时匹配模型选择了一个优先级更高的这时候把它不用的技能描述稍微改严谨一点减少“交叉覆盖”就能缓解。还有一个容易被忽略的因素是会话历史。如果前面的对话一直在跑一个执行流的技能模型不会因为你说了一个新需求就立刻切到思考类技能。我的做法是开一个新会话或者明确说“接下来切换成 brainstorming 模式”。5.3 技能被触发但输出质量并不理想技能触发了不等于效果一定好。我遇到过 AI 确实走了 brainstorming 的流程输出了“方案一、方案二、方案三”但内容非常空洞全是正确的废话。这种情况多半是技能文件里的正文缺少具体约束。好的技能文件不能只写“先发散后收敛”还要有具体的思考角度、评估标准、甚至“禁止做什么”。如果你自己维护技能文件建议在正文里加上示例输出和要求项比如“每个方案必须包含成本、复杂度、体验影响、失败风险”。带上具体维度的模板AI 的输出质量会肉眼可见地提升。5.4 多个技能冲突输出内容重复当任务同时满足多个技能的触发条件时可能出现“planning 还没写完brainstorming 又插进来发散”的情况。我的排查思路是先看这两个技能的 description 是否有大量相同的触发词然后把边界划分清楚。比如 brainstorming 的触发描述明确写“仅聚焦于需求发散和多方案评估”planning 的触发描述里加上“仅在需求已明确、需要拆解执行步骤时使用”。这样两者互相重叠的部分就会大幅减少。实在不行就用手动指定完全规避自动调度的不确定性。5.5 技能执行时报外部工具缺失有的技能在执行过程中会调用辅助工具比如 git、node、浏览器等。如果报出这类错误先看技能文件里 frontmatter 的 allowed-tools 是否包括了该工具再看当前环境能不能直接执行对应命令。我遇到过一个比较隐蔽的情况技能里写的工具名和我在系统里实际安装的版本不一样比如它默认调用某个指令来操作浏览器但我机器上没用过这个方案。这种时候我选择不强行适配而是改掉 SKILL.md 里的调用方式替换成自己环境里可用的命令。这里也体现了技能包设计的好处它全是文本你想怎么改都行。问题现象可能原因处理方式/skills 列表里没有技能路径层级嵌套过深修正为skills/技能名/SKILL.md技能列表有但不自动触发触发描述与任务匹配度低手动指定技能名或优化 description触发了但输出很水技能正文缺少具体维度模板在正文中补充“方案必须包含”等约束项两个技能同时触发触发描述互相重叠调整触发条件划分明确边界执行时报工具不存在环境缺少依赖或工具名不符安装依赖或修改技能中的命令6. 最后分享一点我的个人体会这套工具用下来我最大的感受其实不是某个技能多厉害而是“流程”两个字对 AI 的约束力远超我之前的预期。过去我花了大量时间在 prompt 里写“请你先思考再回答”“请你按照工程规范来做”效果都很不稳定superpowers 换了一种方式它不给模型下命令而是给它一套可翻阅的手册。模型的判断力加上外部定义的工作流才真正把“聪明的助手”变成了“靠谱的搭档”。如果你准备上手我的建议是刚开始别贪多。技能库里有很多内容但你不需要一次全上。先只启用 brainstorming、planning、execution 这三个跑一两周感受一下流程带来的变化再逐步放开其他技能。用熟了之后更值得研究的是自定义技能把你团队里那些“约定俗成但从未被写下来”的开发规范变成 AI 也能遵守的文档。这件事的价值会随着时间不断放大毕竟规范沉淀得越多AI 在你项目里就越像个“自己人”。