你有没有遇到过这种情况跟Claude Code聊了近一个小时技术方案、接口设计全都定了第二天打开终端它像失忆了一样把昨天的决定全忘了。我被这种“金鱼记忆”折磨了两个月直到开始折腾superpowers。说白了superpowers就是把Claude Code变成一个带着完整技能库的协作系统——它不再是一问一答的聊天框而是一个会自己规划、自己拆任务、自己验收的“老工程师”。这篇文章我从安装讲起把具体怎么使用、内置有哪些skills、怎么引入这些技能以及最关键的“怎么写自己的skills”都过一遍适合所有被Claude的健忘和无组织搞到崩溃的人。1. superpowers是什么一套让Claude自主管理技能库的插件体系1.1 为什么需要技能系统而不是堆提示词很多人给Claude Code“调教”的方式是在CLAUDE.md里写一大段规则“每次都要先问需求”“不要急着写代码”“写完必须自测”。这么做不是没用但有三个硬伤。第一上下文窗口是有限的。规则写多了模型真正用来思考的注意力被稀释了规则之间还可能互相打架。第二提示词本质上是“要求它做什么”而不是“告诉它怎么做”。同一句规则在不同场景下的执行质量波动很大。第三提示词是一次性的每次开新会话这些“调教成果”能不能稳定生效全看运气。superpowers换了个思路把一次完整的工作方法封装成独立技能模块。“头脑风暴”是一个技能“写实施计划”是一个技能“按TDD流程实现”是一个技能。每个技能都有自己的SKILL.md文件里面有明确的触发条件、执行步骤和产出物。Claude读到这些技能就像拿到一本带详细批注的工作手册而不只是收到一张写着“你要靠谱”的纸条。我习惯打一个比方提示词是给新人的一张纸条上面写“你要细心一点”superpowers的技能是给新人一套标准作业程序每步干什么、卡住了怎么排查、做完怎么验收都写得清清楚楚。纸条靠自觉SOP靠流程这是本质区别。1.2 核心设计SKILL.md、custom command与agent三件套superpowers不是单个脚本而是一套组合拳拆开看是三块拼起来的。第一块是SKILL.md。每个技能对应一个目录目录里至少有一个SKILL.md文件。文件头部是YAML格式的元信息正文是这个技能的具体操作指引。你可以把SKILL.md理解成技能的“说明书操作手册”。以后你自己写技能写的也是这种文件。第二块是custom command也就是斜杠命令比如/plan、/brainstorm。它是人主动触发技能的入口适合“我明确知道现在要进入哪个环节”的场景。你敲下/planClaude就进入规划模式按规划技能的整套流程走。第三块是agent也就是子任务执行器。superpowers会创建一些专门的子任务执行器负责写代码、负责走查、负责跑测试。它们可以在后台独立执行较长任务主会话负责统筹调度。三者的关系我用一句话总结custom command是点单SKILL.md是菜谱子任务执行器是后厨里照着菜谱做菜的厨师。你点完单后厨按菜谱出菜而不是临时现编。2. 安装superpowers插件市场、重启、授权三步走2.1 先用插件市场装核心插件安装本身不复杂但很多人第一步就卡住了——不知道该在哪里输命令。superpowers的安装命令不是shell命令要在Claude Code的交互界面里输入命令以斜杠开头。大致流程是这样打开Claude Code会话依次输入/plugin marketplace add obra/superpowers-marketplace /plugin install superpowerssuperpowers-marketplace第一条命令把官方插件市场源加进来第二条命令从源里安装superpowers插件。装完之后最好执行一下/plugin update superpowerssuperpowers-marketplace确认拉到的是最新版本然后完全退出Claude Code再重新启动。装完看不到任何变化是正常的。插件本身只是一层壳真正发挥作用的是它随后带来的skills和custom commands。如果输入/plugin status能看到superpowers标记为enabled就说明壳装好了可以进入下一步。2.2 首次启动授权Claude自己管理技能库重启之后你会发现Claude的行为跟之前不太一样。它会主动跟你确认检测到superpowers插件希望把推荐的skills安装到~/.claude/skills目录下同时会请求允许它自己管理技能文件。这一步我建议直接同意。很多人的第一反应是“让AI自己改自己的技能文件靠谱吗”我一开始也犹豫过。但superpowers的核心设计恰恰就是“让Claude对自己的技能库拥有读写权”。它只有能自己增删改SKILL.md才能在发现你重复某个工作流的时候主动提议把流程固化成技能。如果你不给这个权限插件就只剩一堆静态文档价值大打折扣。授权之后它会根据当前项目和你的对话历史推荐一组初始技能。比如你经常写Python它可能会装代码评审、TDD一类的技能你经常处理数据分析它可能会装数据清洗相关的技能。这个推荐名单不是固定的你随时可以增删。2.3 版本与路径两个容易翻车的细节第一个细节是版本。superpowers迭代很快对Claude Code的版本有隐性要求。装之前先用claude --version看一眼太旧的版本容易出现“插件显示已安装但技能不生效”的诡异问题。遇到这种情况不要急着翻配置文件先执行/plugin update把两端都升到最新。第二个细节是技能文件的存放路径。全局技能放在~/.claude/skills/项目级技能放在项目根目录的.claude/skills/。两边同名技能冲突时项目级优先。这一点务必记住因为你给插件加的skills和项目里自定义的skills如果重名行为会以项目级为准排查问题的时候这条最容易被忽略。3. 内置skills全景从头脑风暴到调试的完整链路3.1 启动链路brainstorming和planning先让需求落地superpowers内置的技能很多但没有一个技能是“万能钥匙”它更像一条流水线每个环节有专门的技能。按我实际使用频率排序最常用的是项目启动链路也就是brainstorming和planning。brainstorming直译是头脑风暴作用是帮你把模糊想法变成清晰需求。我实测下来的感受是它比我自己逼问自己还有用。你给它一句话“我想做个静态博客”它不会马上推荐框架而是先抛出十几个问题覆盖目标用户、内容形态、发布频率、是否需要搜索、部署环境偏好等等。这些问题会把你的隐性假设一个个逼出来产出是一份需求摘要和一组待决策点。然后是planning。需求清晰之后planning把大任务拆成可执行步骤输出一份plan文档。注意这里不是简单列一个to-do list而是会标注每步的输入输出、依赖关系、验收标准。我在实际使用中通常把Claude产出的plan当成“合同”动手写代码之前先跟它把plan对齐后续执行基本就不用操心了。3.2 执行与验收链路implementing、TDD到reviewing需求定了、计划有了接下来就是implementing。这个技能会把plan里的步骤一个接一个落地。它跟普通对话写代码的差别在于每完成一步它都会回头对照plan里的验收标准而不只是“代码能跑就行”。如果项目对质量要求高可以打开test-driven-development技能。它的流程是死的先写一个会失败的测试再写最小实现让测试通过然后重构。这套流程人类程序员讲了二十年真正坚持下来的团队不多但让Claude执行起来反而干脆因为它没有“嫌麻烦”的情绪。代码写完不等于结束reviewing技能负责走查。它会按内置的checklist逐项检查有没有未处理的错误分支、日志打得到不到位、命名是否一致、有没有明显的性能隐患。我把它当第二双眼睛用经常能抓到我漏掉的问题。3.3 排查链路debugging不靠猜靠流程日常开发里最耗时间的其实是排错superpowers在debugging这个技能上花了不少心思。它的核心流程是先收集现象、再复现、二分定位、修复、最后回归测试。看着平平无奇但它强制Claude在动手改代码之前先回答三个问题问题能稳定复现吗最小复现路径是什么这段代码最近的变更是什么举一个真实例子。有一次构建脚本在CI上偶发失败本地怎么跑都是好的。Claude没有上来就猜是缓存问题而是先让我把所有环境变量差异列出来再逐步在本地模拟CI环境最后定位到是一个未设置的环境变量导致某条命令走了不同分支。先复现、后定位、再修复这个顺序省了我大半天。4. 技能是怎么被调用的读frontmatter、匹配场景、按步骤执行4.1 读取驱动SKILL.md的frontmatter是触发开关要真正用好superpowers必须理解它的调用机制。每次请求进来Claude会扫描技能目录读取每个SKILL.md头部那段YAML元信息。触发开关就是两个字段description和when_to_use。前者说明这个技能是干什么的后者说明什么场景下该用它。很多人自己写技能之后反馈“Claude从来不主动调用”十有八九是这两个字段写得不够精准。比如描述写“帮助用户更好地完成工作”这种话等于没写模型无法判断什么时候该用它。好的写法是“当用户要求创建新的React组件时”“当用户提到构建速度变慢时”。描述越像一条具体的检索条件触发的准确率越高。4.2 从场景匹配到按步骤执行Claude经历了什么为了让你直观理解我把一次调用拆成四个环节。第一步用户输入一段话第二步Claude在上下文里加载技能目录的索引比对description和when_to_use第三步匹配到一两个技能后它读取对应的SKILL.md正文把正文里的步骤当成执行指令第四步按步骤执行并把结果写回项目通常是把中间产物存成文档方便下一个技能接着用。这也是为什么superpowers擅长处理长任务。brainstorming的产物是一份需求文档planning读了这份文档才能写出计划计划写完了implementing照着计划执行。每一个技能都是上一环的消费者、下一环的生产者环环相扣信息不会丢。4.3 让Claude自己装技能、卸技能是这套体系最关键的设计前面我提到授权Claude管理技能库这里展开说。superpowers内置了一个叫Project_Management的元技能它让Claude有能力创建、修改、删除SKILL.md文件。也就是说当它发现你反复做某类事情可能会主动问“我注意到你每次发布前都要跑一遍这三个脚本要不要我生成一个release-prep技能”这种“AI反过来优化自己的工作方法”的能力实际体验相当微妙。我最早觉得它有点越权后来发现真香——它提议生成的技能往往比我自己写的更贴合我的操作习惯因为它是在观察了我大量行为之后总结出来的。当然你也可以手动删掉不想要的技能每次操作都有确认环节掌握权始终在你手里。5. 手把手自定义一个skill把反复做的工作流固化下来5.1 最小可用的SKILL.md长什么样自己写技能才是这套体系的完全体。先给一个最小示例。假设你希望Claude在提交代码时统一按Conventional Commits规范生成提交信息可以新建目录~/.claude/skills/conventional-commit/在里面放一个SKILL.md--- name: conventional-commit description: 按Conventional Commits规范生成git提交信息 when_to_use: 当用户要求提交代码、生成commit message或执行git commit时 version: 1.0.0 --- # 生成规范化的提交信息 1. 运行 git status 和 git diff --staged 查看变更内容。 2. 根据变更类型选择前缀新功能用feat修复用fix文档用docs重构用refactor测试用test杂活用chore。 3. 特殊情况破坏性变更必须在说明中标注BREAKING CHANGE。 4. 输出完整的提交信息等用户确认后再执行 commit。保存后重启Claude Code这个技能就生效了。元信息的作用很清晰name是唯一标识description说明用途when_to_use告诉Claude什么场景激活version方便追踪修改历史。5.2 三个字段写得好不好直接决定技能是不是废技能自定义技能时最忌讳的是把SKILL.md写成一篇小作文。我见过有人把正文写到两千字结果Claude执行的时候上下文被占满反而更容易跑偏。正文应该只保留关键步骤和判定规则细节在步骤里按需展开。再强调一遍description和when_to_use。我自己的经验法则把when_to_use当成一个“搜索索引词”想象用户可能会怎么触发这个技能把高频说法都列上。比如上面的例子“提交代码”“commit message”“git commit”都写了进去覆盖不同表达方式。描述写得不好技能就是躺在目录里的死文件。5.3 从纯流程到可执行三种进阶做法纯文本流程是最简单的技能形态但它只能约束Claude的行为不能扩展它的能力。想做得更深入有三种进阶方向。第一种在正文里引用外部脚本。比如技能正文写“先运行python scripts/analyze.py读取报告再根据报告生成总结”Claude会按步骤调用脚本把脚本输出当成后续判断的依据。这是把本地工具链接入技能的最直接方式。第二种把技能设计成团队SOP的载体。我在团队里用过一个“评审前置检查”技能里面列的是团队约定俗成的二十条检查项Claude每次提交评审前自动过一遍。这种技能看似简单价值在于让团队经验不随个人离开而流失。第三种结合子任务执行器实现半自动执行。superpowers支持把技能内容作为子任务执行器的指令复杂技能交给它在后台跑主会话继续处理别的事。这种玩法适合耗时较长的多步骤任务比如全量回归检查。6. 用了三个月的几点体会和常踩的坑6.1 四个高频问题对应四条解决路径我把自己和身边朋友踩过的坑汇总成一张表遇到同样情况可以直接对照处理。现象常见原因处理方式斜杠命令输入后没反应安装后没重启Claude Code完全退出会话再重开插件显示enabled但技能不生效技能文件路径不对或版本过旧检查~/.claude/skills目录执行/plugin updateClaude从不主动调用某技能description和when_to_use写得太泛把触发场景写具体覆盖用户高频说法项目级与全局技能行为冲突同名技能并存项目级优先保留一个删掉另一个同时检查两个目录还有一类问题容易被忽视技能的正文指令与CLAUDE.md的全局规则冲突。比如全局规则要求“回答尽量简短”而某个技能要求“输出完整分析报告”Claude会陷入两难。遇到这种情况我的建议是在技能正文开头加一行“本技能优先于全局通用规则”把冲突明确化。6.2 什么时候不该用superpowers工具不是越多越好superpowers也有明显不合适的场景。一是纯粹的一次性小任务比如改个文案、查个接口文档没必要触发一整套头脑风暴和规划流程直接对话反而更快。二是模式还没稳定下来的探索期项目过早把工作流固化成技能后面需求一变技能内容就得反复改维护成本比收益还高。我给自己定了一条判断标准同一个操作如果一周内重复超过三次才值得固化成技能。低于这个频率直接用普通对话处理性价比更高。6.3 把技能库当代码管理才不会变成垃圾场最后说说维护。superpowers用久了技能库会越来越庞杂尤其是你允许Claude自己创建技能之后。我现在的习惯是每周抽十分钟做一次整理删掉不再用的合并功能重叠的给改动过的技能更新version。全局技能在~/.claude/skills项目技能在项目根目录.claude/skills都建议纳入git管理哪天改坏了可以回滚。如果要跟团队共享把这些技能目录提交到仓库里其他人clone下来就能获得一致的流程。这比我以前在群里发“大家注意提交信息格式是xxx”有效得多——规则从人嘴里的叮嘱变成了Claude每步都会执行的SOP。我在实际使用中最深的一点体会是superpowers的价值不在于某一个技能多惊艳而在于它把“靠谱”变成了默认选项。以前我开新会话总要反复叮嘱Claude“先想清楚再动手”现在装上superpowers它会自动进入brainstorming和planning的流程主动性完全不一样。最后分享一个小技巧每次让Claude跑完一个复杂任务后顺手问它一句“刚才这个过程有什么值得固化成技能的吗”它的建议往往比我自己的抽象总结更实用。这套东西不是银弹但如果你也受够了AI的健忘和不可控值得花一下午把它跑起来试试。