如果你整天泡在 AI 编程助手里一定遇到过这种挫败感明明同一个模型有时候回答得像资深架构师有时候又像一个刚入行三天的新手。区别往往不在模型本身而在你有没有给 AI 一套“干活的方法论”。我最近重度使用的superpowers就是专门解决这个问题的一个技能框架——它给 Claude Code 装上几十个可复用的skills让 AI 按资深工程师的套路去思考、调试、写计划、写测试、做代码审查。这篇文章我会说清楚它到底是什么、里面有哪些技能、怎么安装和引入这些技能以及我实际用下来踩过的坑。先给还不了解的朋友一个定位superpowers 不是独立应用而是 Claude Code 的一个插件plugin准确说是一个 skills 集合和技能管理框架。它把“如何引导 AI 完成复杂任务”这件事做成了标准化文件AI 会在合适的时机自动加载对应技能按固定流程输出结果。听起来有点抽象但用顺手之后你会发现 AI 的工作方式从“你说一句它写一段”变成了“它先拆解问题、再给方案、按计划执行、最后自查”整个链路专业得多。1. superpowers 到底是什么把“经验”变成 AI 能读的说明书1.1 为什么需要技能skills而不是靠对话碰运气先讲一个可能被很多人忽略的事实Claude Code 这类工具的底层模型非常强但模型本身不知道“你的团队怎么约定代码规范”“你希望它先写测试还是先写实现”“你习惯怎么拆解需求”。这些知识散落在你的脑子里每次对话都要现教教完它就忘换个项目又得重新教。superpowers 解决的就是这个问题。它将“资深工程师接到任务后是怎么想的、怎么做的”拆解成一整套指令文件每个技能对应一个场景比如调试、写计划、写提交信息、做代码审查。AI 读到这些文件就像新人入职拿到了一本《工作操作手册》不用再靠临场发挥。你可以把它理解成给 AI 灌入一套“SOP”从此它的行为模式稳定且可复现而不是每次看心情。还有一个关键点这些技能不是死板的提示词模板。superpowers 里的技能是有层级、会协作的。比如test-driven-development这个技能内部会调用brainstorming、debugging、writing-plans等一系列子技能形成一个完整的质量闭环。AI 执行任务时不是线性地“读完就做”而是按技能指令去搜索、规划、验证、复盘。1.2 superpowers 的底层机制Markdown 技能文件 自动触发很多人第一次听到“skills”以为是什么高深的东西其实机制特别朴素。在 Claude Code 的约定里一个技能就是一个目录目录里放一个SKILL.md文件。这个文件有固定的格式头部是 YAML 格式的 frontmatter声明技能的名称和描述正文是具体的操作指令告诉 AI 遇到这种情况应该按哪些步骤走。Claude Code 每次开启会话时会扫描技能目录把每个SKILL.md的描述注入到系统提示里。当用户的指令命中描述中的场景时AI 就会自动加载该技能的完整指令并执行。这意味着技能文件本质上就是“可被 AI 动态读取的说明书”。superpowers 做的是替你把一整套经过验证的说明书打包好通过插件市场一键装进 Claude Code省去你自己到处找模板、拼凑流程的麻烦。1.3 为什么叫 superpowers 而不是“claude-skills”这个项目最初由 Jesse Vincentobra发起后来并入了 opendream 组织。名字叫 superpowers玩的就是“给 AI 超级能力”这个梗——它把几十个单点能力组合在一起让 AI 涌现出接近一个成熟开发者的综合素养。实际体验下来这个名字不算夸张它对 AI 工作方式的改变确实像从“徒手搬砖”升级到“拿着一整套工具箱干活”。另外这个框架并不绑定某个特定模型。只要底层的 Claude Code 支持插件机制理论上你可以在不同项目、不同模型配置下复用同一套技能。这意味着你沉淀下来的工作流可以随身携带而不是锁死在某一次对话里。2. 有哪些现成的 skills 可以直接用2.1 开发核心链路从想法到上线的一整套技能我装好 superpowers 后第一件事就是把技能列表翻了一遍。仓库里维护了一批高质量的预置技能覆盖了软件开发的主要环节。我最常用的几个brainstorming正式动手前先结构化梳理需求和思路强迫 AI 列出问题、证据、假设而不是直接甩代码。writing-plans把一个模糊目标拆解成可执行的分步实施计划附带取舍说明和风险点。implementing-plans拿到计划后按部就班实现每一步对应验证防止跑偏。test-driven-development驱动 AI 先写失败测试再写实现代码最后重构。这是我最喜欢的一个技能因为不用你反复强调“先写测试”。test-driven-debugging调试时先写一个能复现问题的测试再开始定位根因避免瞎猜。debugging系统化排查 bug按照“复现—假设—排查—验证”的路径走而不是东一榔头西一棒子。reviewing-code对已有代码做多轮审查关注正确性、安全性、可维护性能提出具体修改建议。creating-pr/writing-pr-descriptions生成 PR 描述和提交信息省去每次手写 commit message 的琐碎。这些技能的价值不仅仅是“AI 会按照步骤走”而是步骤本身是经过大量实战验证的。比如debugging会要求 AI 先复现问题、寻找根因、再修复并且验证修复是否引入新问题——这套流程看起来是常识但如果不显式写进技能文件AI 往往会直接给你一个“看起来对”的补丁根本没有做回归验证。2.2 文档与流程管理容易被忽略的“软技能”除了写代码superpowers 还带了一批面向文档和流程的技能creating-and-reviewing-design-docs起草和评审设计文档推动团队在写代码之前对齐方案。polishing-markdown润色 Markdown 文档规范标题层级、表格、列表常用于 README 和内部文档。writing-commit-messages根据 diff 和上下文生成规范、有信息量的提交信息这个可以做到近乎自动触发。creating-slides把内容整理成幻灯片大纲适合做技术分享和汇报。updating-specification实现完成后反向更新规格说明保证文档不腐化。solving-errors处理报错信息整理错误上下文、尝试路径、最终解法。systematic-approaches面对复杂问题时强制使用结构化的系统性方法拆解。web-development网页开发场景的专用工作流整合了设计、实现、验证环节。另外还有root-cause-update、verifying-implementations这类偏工程质量的小技能。不同版本和分支下技能清单会有些差异以仓库 README 为准但上面列出的是我自己用过的、确认能正常工作的核心项。2.3 技能之间如何协作它不是一箱散装工具我之前用过不少“提示词合集”特点是每个模板独立互相之间没有关联。superpowers 不太一样技能之间有明显的调用关系。举个实际例子你扔给它一个模糊需求brainstorming会先引导你把问题问清楚产出明确的需求描述接着writing-plans把这个描述变成实施计划计划确定后test-driven-development入场让你先写测试再写实现最后reviewing-code对结果做体检。这个过程就像一条流水线每个技能是流水线上的工位AI 自动判断当前该让哪个工位工作。这样带来的直接好处是输出质量的方差变小了。以前同一个问题跑十次能得到七八种风格迥异的答案用了 superpowers 之后答案的思考路径基本一致细节会根据上下文变化但骨架非常稳定。这种稳定性在团队协作里尤其重要因为代码审查和维护最怕的就是“这个代码不像同一个人写的”。3. 想要安装 superpowers从 marketplace 到项目生效3.1 安装前的环境准备superpowers 依赖 Claude Code 的插件能力所以第一步是确认你的 Claude Code 版本。插件机制在 0.2.21 左右开始支持后续版本迭代很快功能变化也大我的建议是直接把 Claude Code 升级到当前最新稳定版省得因为版本太老导致插件装不上或者命令缺失。检查版本用命令行就行claude --version如果版本偏旧就先更新npm update -g anthropic-ai/claude-code这里提醒一句尽量用官方推荐的方式安装和更新不要用乱七八糟的修改版否则后续排错会很痛苦。3.2 三步装好marketplace 地址 安装命令superpowers 的安装非常标准走的是 Claude Code 的插件市场机制。在 Claude Code 对话窗口里依次输入两个斜杠命令/plugin marketplace add opendream/superpowers /plugin install superpowerssuperpowers第一条命令把 superpowers 的 marketplace 添加到你的插件源列表里。第二条命令从该 marketplace 安装名为 superpowers 的插件。执行完之后你可以输入/plugin确认列表中已经出现 superpowers。如果出现说明安装成功。我个人的习惯是安装完立刻重启一次 Claude Code 会话因为技能文件的扫描和注入发生在会话初始化阶段不重启的话可能不会自动加载新技能。3.3 初始化配置onboarding 和技能生成安装只是第一步真正让技能在你项目里生效还需要一个初始化动作。装完后 Claude Code 通常会引导你运行一次 onboarding不同版本触发位置可能不同一般在插件命令列表里能找到/superpowers:onboarding。这个初始化过程会询问你一些项目偏好比如是不是要在当前项目启用技能、要不要生成团队共用的技能说明文件之类。确认后它会在项目里生成对应的技能配置目录通常是在.claude/skills/下。这个目录就是技能的“家”Claude Code 每次启动都会扫描它。如果你的项目里原本没有.claude/skills/目录初始化完成后应该能看到一排技能子目录每个子目录里都有一个SKILL.md。可以随手打开一个看看里面的 frontmatter 和正文结构都很清晰理解成本极低。3.4 手动引入和离线安装方式Claude Code 的plugin marketplace add不仅支持远程仓库也支持本地路径。如果你在的网络环境下访问 GitHub 不太顺畅这里不展开懂的都懂可以考虑先把仓库 clone 到本地再通过本地路径添加 marketplacegit clone https://github.com/opendream/superpowers.git然后进入 Claude Code执行/plugin marketplace add /本地路径/superpowers /plugin install superpowerssuperpowers效果和远程安装完全一样而且后续你本地改了技能文件会立刻生效调试自定义技能时会方便很多。我个人在刚开始接触 superpowers 时就是用的本地 clone 方式改完文件不用重新装插件对学习这个框架的运作机制帮助很大。还有更“裸”的引入方式直接复制技能目录。比如你只想用debugging这一个技能不需要装整个插件那就把仓库里对应的技能目录复制到项目.claude/skills/下。Claude Code 只认目录不认来源。这种方式适合只想取其中某几个技能、不想引入整套体系的场景。4. superpowers 的具体使用从触发到落地的完整路径4.1 触发方式斜杠命令和自动触发各管一摊superpowers 里的技能有两种触发路径。一种是显式调用比如你输入/superpowers:brainstormAI 会强行进入头脑风暴模式不管你给它的任务有多具体——这种适合在需求模糊、自己还没想清楚的时候用。另一种是自动触发AI 根据你的描述和技能文件里的 description 匹配发现自己正在处理的任务命中了某个技能场景就会自动加载指令。实际使用中我总结的规律是命令触发适合“主动干预流程”自动触发适合“让 AI 按默认经验干活”。比如我会在接到一个新需求时主动敲/superpowers:brainstorm逼自己把需求整理清楚但 commit message 这种我就完全不管writing-commit-messages会在 git commit 场景自动接管。有一个细节值得注意自动触发依赖技能文件里的 description 写得好不好。superpowers 预置技能的描述都经过打磨基本不需要你操心但如果你自己写自定义技能description 一定要写清楚触发场景否则 AI 不知道什么时候该用这个技能装了也白装。4.2 实操案例用一整套技能走完一个小需求举个我自己跑过的例子。任务是“给一个 Python 项目增加按用户角色过滤列表数据的接口”。如果没有 superpowers我直接描述需求AI 大概率会生成一个接口然后加个 if 判断完事。但有了技能流之后流程变成了这样我先调用/superpowers:brainstorm。AI 没有立刻写代码而是反问我“这个接口是给内部管理系统用还是给外部客户端用用户角色从哪里获取过滤是发生在 SQL 层还是应用层”这些问题逼我把需求边界重新想了一遍最后确认了过滤应该发生在 SQL 层并且角色信息从登录态里取。需求明确后调用writing-plansAI 输出一份实施计划包括数据库查询改动、接口签名、测试用例设计、兼容性影响每一条都标了优先级。计划确认后我切到test-driven-development模式。AI 先根据计划写了三个失败测试管理员能看到全部数据、普通用户只能看到自己部门的数据、未登录用户返回 401。然后才写实现代码。代码写完后我做了一个小改动要求加一个额外的排序参数这时候发现原来的测试没覆盖这个分支。我调用了/superpowers:test-driven-debuggingAI 先补了一个复现该场景的测试确认失败接着定位到排序逻辑写死在 SQL 里修改为动态参数后重新跑全量测试全部通过。整个过程我几乎没有说“你先写测试”“你注意边界情况”这种话全是技能在背后驱动。输出质量和人工引导时的差距不大但省下的口舌非常多。4.3 自定义技能的最简模板把团队规范固化下来如果你不想完全依赖预置技能可以动手写自己的。最简模板长这样放在.claude/skills/技能名/SKILL.md--- name: my-custom-skill description: 当用户要求处理日志脱敏或涉及敏感信息时使用 --- # My Custom Skill 1. 识别输入中所有疑似敏感字段手机号、身份证、token。 2. 按项目 .env.example 中的字段清单核对。 3. 对匹配字段统一替换为 ***保留前三位和后四位。 4. 输出处理结果并提醒用户人工复核。写完后重启会话问 AI 一个会命中该场景的问题它就会自动按这套流程走。这个模板看起来简单但实际价值很大你可以把团队的代码规范、安全策略、文档风格全部技能化让任何接入项目的 AI 都遵循同一套标准。5. 常见问题与排查技巧实录5.1 技能文件没有生效怎么回事这是问得最多的一个问题。装完 superpowers技能目录也生成了但 AI 的表现和之前一模一样完全看不出技能在起作用。排查思路按顺序来确认 Claude Code 版本足够新旧版本根本不支持插件机制。确认.claude/skills/目录位置正确。注意项目级技能放在项目根目录的.claude/skills/全局技能放在用户目录的~/.claude/skills/放错地方 AI 看不到。确认SKILL.md文件名和目录名一致frontmatter 格式正确必须有name和description两行。重启会话。技能扫描发生在会话初始化阶段修改技能文件后必须重启才能加载。在对话里直接问 AI“你现在加载了哪些技能”它能列出来说明生效列不出来就是没读取到。我遇到过最隐蔽的问题是 frontmatter 里description写得太笼统AI 无法判断什么时候该触发。比如“当用户需要帮助时使用”这种描述基本等于没写。具体一点命中率会高很多。5.2 插件命令找不到或者安装失败如果你在 Claude Code 里输入/plugin提示命令不存在多半就是版本问题。升级到最新版再试基本都能解决。安装失败的情况常见原因有两个网络原因导致拉取仓库超时或者 marketplace 地址拼写错误。注意地址是opendream/superpowers不是obra/superpowers旧地址虽然还能访问但推荐以官方 README 为准。如果是本地路径方式确认路径写的是仓库根目录而不是仓库里的某个子文件夹。另外/plugin install后面跟的superpowerssuperpowers是“插件名marketplace 名”的格式不要少打后半段。装完后输入/plugin检查是否出现在已安装列表里。5.3 技能冲突多个来源定义了同名技能这个问题我在同时使用多个插件时碰到过。两个 marketplace 都提供了debugging技能Claude Code 加载时后安装的会覆盖先安装的最后生效的行为和你预期的不一样。排查方法是查看两个插件各自技能目录里的SKILL.md文件对比内容确认哪个是你要的版本。最干净的办法是只保留一个来源把另一个插件移除不要心存侥幸同名技能迟早会出问题。5.4 我踩过的几个不是坑的坑最后分享几个经验性的教训。第一不要一股脑把全部技能都复制到全局~/.claude/skills/。技能描述会占用上下文空间技能装得越多留给对话和代码的 token 越少反而影响效果。按需安装用哪个装哪个这才是正确姿势。第二第一次引入 superpowers 时我会建议你在一个试验项目里跑一遍而不是直接在核心生产项目上实践。因为它的工作流和 AI 默认行为差异很大你需要先适应“AI 先问一堆问题再动手写代码”这个节奏否则会觉得它变啰嗦了。用几次之后你会发现这顿啰嗦换来的是返工率大幅下降。第三技能不是银弹。它就是一套流程说明书如果你的指令本身模糊、需求本身矛盾再好的技能也救不回来。我自己从一开始的“甩一个需求等结果”慢慢变成了“先花两分钟把目标和约束说清楚然后让技能去执行”。配合得当之后superpowers 才能真正发挥出那种“给 AI 装上超能力”的效果。我个人现在的习惯是所有新项目第一时间装好插件并初始化技能目录日常工作完全依赖自动触发只有需求特别模糊或复杂时手动调出brainstorming和writing-plans。这套工作流跑通之后我再也没回到“裸奔”状态。你要是也在用 Claude Code强烈建议花十分钟把它装起来试一圈尤其是test-driven-development和debugging这两个技能我敢说你很难再退回原来的用法。