最近一直在折腾 Claude Code 的进阶玩法最大的感触是会装工具和会用工具之间隔着一条巨大的方法论鸿沟。很多人把 superpowers 装好之后扔进~/.claude/skills就以为大功告成结果发现模型的行为好像没什么变化于是转头就去论坛吐槽这东西没用。但很少有人意识到问题不在这套技能包本身而在于你根本没理解它到底在解决什么。这篇文章我想认真聊聊 superpowers 的核心价值、它到底有哪些 skills、怎么正确地引入这些技能以及安装之后怎么在真实项目里把它用出效果来。如果你跟我一样不想停留在让 AI 写个函数的层次这篇文章应该能帮你少走不少弯路。1. Superpowers 到底是什么为什么值得装1.1 从会用 Claude Code到用出生产力的差距先交代一下背景。Claude Code 这类跑在终端里的 AI 编程助手热度一直在涨但我和身边的朋友交流一圈后发现绝大多数人的用法还停留在提问-回答层面让 AI 改个 bug、写个函数、解释一段晦涩的代码。这种用法不能说没用但它和你直接打开网页跟模型聊天没有本质区别完全浪费了终端 Agent 最大的优势——它有能力自己读文件、跑命令、迭代修改、反复验证。superpowers 的出现就是冲着这个痛点来的。它不是一个独立的软件而是一套可以直接安装进 Claude Code 的技能包。这些技能以 Markdown 文件的形式存在里面写的不是业务代码而是如何引导模型一步步完成复杂任务的交互协议。换句话说它把一名资深工程师面对复杂需求时的完整思考路径——先想清楚目标、再写详细计划、然后动手实现、边做边验证——全部固化成模型可以自动读取、自动执行的流程。我自己在没装 superpowers 之前经常遇到一个让人血压升高的场景让 Claude Code 做一个稍复杂的重构它吭哧吭哧一顿操作改完七八个文件结果编译直接挂掉。然后我再让它修它又改出一堆风格突兀、跟任务毫无关系的代码。后来我才想明白问题根本不在模型能力而是缺少结构化的约束。装上 superpowers 之后同样的任务它会先要求我确认需求边界列出候选方案给出明确的测试策略然后才开始动代码。体验完全是两个级别。1.2 核心设计理念把资深工程师的方法论固化成交互协议为什么一套 Markdown 指令能有这么大威力这得先理解 Claude Code 的 skills 机制。在配置目录全局默认是~/.claude/skills项目级是.claude/skills下每个子目录代表一个技能。技能目录里通常有一个SKILL.md文件头部用 YAML 写着name和description正文则是详细的执行指令。当模型判断当前任务与某个技能的描述匹配时它就会自动加载这个文件并按照里面定义的流程去执行。superpowers 对技能文件的组织非常讲究。它不是简单写几句你应该认真思考这种鸡汤式指令而是把一整套工作流拆成多个可独立调用的技能。每个技能只解决一类问题技能之间又设计成可以互相衔接的状态机。比如头脑风暴负责把事情想透写实施计划负责把方案落成一步步行动TDD 开发负责保证实现质量系统调试负责在出问题时别靠瞎猜。这种把方法论模板化的思路本质上是很多资深开发者日常工作习惯的抽象总结。我带团队的时候天天跟新人强调先设计后编码但口头说十遍不如给一套可执行的流程。superpowers 做的就是这件事把资深工程师会怎么处理这类问题变成模型每一次都会遵循的路径从而把结果的下限抬得很高。它不会让模型突然变聪明但它能让模型每次都稳定地按正确的方式工作这一点在工程场景里比什么都重要。2. 技能包全景拆解它到底有哪些 skills2.1 任务启动前的想清楚技能组很多人用 AI 编程时最缺失的环节不是编码而是编码前的思考。superpowers 里有一组技能就是专门补这个短板的。第一个是 brainstorm头脑风暴。它不是那种帮你出十个点子的花架子而是引导你对需求本身做系统性提问目标用户是谁、成功标准是什么、有哪些硬性约束、哪些风险已经暴露、哪些边界情况可能翻车。这个过程强烈建议在动手写代码之前完整走一遍尤其是需求本身还模棱两可的时候。我用过几次之后的感受是它逼着我把脑子里那些模糊的大概意思变成可以落到纸面上、可以验证的具体指标。有一次我让它帮我梳理一个数据迁移方案它连续追问了源数据量级有多大停机窗口多长失败回滚策略是什么这几个我之前完全没考虑的问题这几个问题后来直接决定了方案选型。第二个是写实施计划。这个技能会在方案确定之后帮你把任务拆解成阶段性里程碑每一步要改动哪些模块和文件、每个阶段的验收方式是什么、哪些地方可以并行、哪些地方有依赖关系。它输出的不是那种空泛的第一步搭环境、第二步写功能废话而是带具体函数名和测试用例级别的行动计划。我会直接把这个计划贴到项目管理工具里当任务清单用。第三个是计划审查。它会模拟一个挑剔的架构师逐条拷问你的方案有没有过度设计有没有遗漏的边界条件改动范围是否可控依赖关系是否合理我经常拿它来制衡自己想到一个方案就急着动手的冲动。有一次我准备引入一个重型状态机库来解决一个其实用两张表就能搞定的问题被它问了两轮之后自己都觉得脸红。2.2 编码执行阶段的写对技能组到了真正写代码的阶段superpowers 里最核心、也是我日常使用频率最高的技能是 TDD测试驱动开发。它不只是要求你先写测试再写实现这么一句简单的话而是把整个 TDD 循环拆成可执行的小步先写一个失败的测试、运行测试确认它失败、写最简实现让它通过、进入下一个用例最后统一重构。它还会在每轮循环结束时要求你总结学到了什么、下一轮该写什么用例。这套流程对有测试经验的开发者来说是熟悉的配方关键变化在于superpowers 让模型不再只是象征性地写一两个单元测试装样子而是真正按照红-绿-重构的节奏推进。我实测下来一个中等复杂的业务模块走完整个 TDD 流程前期节奏确实会慢一些但后期几乎不需要返工修 bug 的次数直线下降。这里面的原因很简单每个步骤都有可验证的中间产物模型没有机会一口气写出 100 行然后告诉你应该没问题。代码审查技能也值得单独拎出来说。它可以对你已经写好的代码做逐行审查关注点不只是能不能跑还包括命名是否表意、边界情况是否覆盖、函数是否过长、模块耦合是否过重。我把这个东西当作一个免费的 code reviewer每次准备提交 PR 之前先让模型过一遍很多低级问题在提交之前就暴露了。值得一提的是它的审查结论不是只有这里有问题而会给出修改建议和理由这一点对新人理解代码规范特别有帮助。2.3 收尾与协作阶段的质量保障技能组除了开发阶段的技能superpowers 还涵盖了很多容易被忽略但同样重要的环节。比如文档生成技能它可以基于代码实际行为来生成 README、接口文档或者变更日志而不是凭空脑补。我自己写开源项目的时候最头疼的就是文档维护跟不上代码演进用了这个技能之后每次改完接口就让模型重新生成一份变更说明文档陈旧的问题缓解了不少。另一个是 git 工作流相关的技能。它会引导模型在提交前检查变更范围、写规范的 commit message、处理 rebase 冲突时保持小步提交。这些听起来很简单但模型默认的 git 操作习惯其实挺粗糙的动不动就在一个 commit 里塞几十个文件。技能的存在能把提交习惯拉回到一个可审查、可回溯的节奏上。还有一类是复盘类的技能比如 postmortem事故复盘。它能帮你在线上问题处理完之后结构化工区梳理时间线、根本原因、临时方案、长期修复项、后续预防措施。这个技能我本来是抱着试试看的态度用的但有一次处理完一个棘手的线上接口超时问题后顺着它的引导把所有信息整理出来发现整个复盘文档的质量比我团队里大多数同事手写的都要高。这类技能平时用不上但真到用的时候价值极大。3. 安装与引入技能从零到能跑3.1 三步完成安装含目录设计先讲安装。superpowers 的项目代码托管在 GitHub 上整个过程三步就能完成。第一步把仓库克隆到本地。我建议放在一个固定的目录比如~/superpowersgit clone https://github.com/obra/superpowers.git ~/superpowers第二步建立技能目录的软链接。Claude Code 默认会从全局~/.claude/skills目录加载技能所以我们要把仓库里的 skills 目录链接过去mkdir -p ~/.claude/skills ln -sf ~/superpowers/skills/* ~/.claude/skills/第三步验证安装是否成功。启动 Claude Code输入一句和某个技能相关的自然语言请求比如帮我想一个方案。注意观察模型回复里有没有出现结构化的引导流程比如它主动说我会分几步来帮你梳理这个需求。如果能看到这类内容说明技能已经正确加载。需要补充的是以上命令是我根据个人实践总结的写法实际安装时建议以仓库 README 的最新说明为准因为项目迭代挺活跃的目录结构有可能调整。这里还要多说一句目录设计的概念。全局技能目录对所有项目生效适合那些你希望默认就存在的工作流比如 TDD、代码审查项目级技能目录只对当前项目生效适合放团队特定的工程规范。我第一次用的时候图省事全放在全局后来发现团队项目的规范混进了个人项目反而碍事。后来我养成的习惯是通用方法论放全局团队专属规范放项目级。3.2 技能如何被发现与触发很多人装完 superpowers 之后有一个共同的困惑我到底怎么调用某个技能是不是要输入什么魔法命令实际上Claude Code 的 skills 机制是自动触发的。模型会根据你当前的任务描述结合每个技能description字段里的关键词自己判断应该加载哪个技能。你只需要用自然语言说出需求比如我想给用户模块增加一个导出功能模型如果判断有必要就会自动加载 brainstorm 技能来帮你澄清需求。但这不代表你完全不能干预。一个很实用的小技巧是在问题里直接点名技能名称比如用 TDD 技能给这个函数写测试或者先跑一遍 brainstorm 技能把这个需求理清。我实测下来点名调用的成功率比纯靠自动触发要高不少尤其是在任务描述比较笼统、包含多个可能触发条件的场景下。点名之后模型会优先加载指定技能而不是自己在十几个技能里猜。有一点要提醒技能不是越多越好。superpowers 默认带了几十个技能全部加载之后模型在每次决策时都要扫描一遍技能描述确实会增加一些上下文开销。如果你感觉响应变慢或者技能经常串台可以把不常用的技能移出目录只保留核心的几个。我自己日常只留了 brainstorm、写计划、TDD、debugging 和代码审查其他都归档到一个备份目录里需要的时候再临时链接回来。3.3 一个完整的 TDD 工作流实录光说不练假把式我拿一个真实场景完整演示一遍。假设我要给内部工具新增一个根据用户积分计算会员等级的函数需求描述是0 分以下视为普通用户0 到 1000 分为铜牌会员1000 到 5000 分为银牌会员5000 分以上为金牌会员。如果直接让 Claude Code 写它大概率会一次性输出整个函数外加几个测试用例看着挺完整但边界值定义可能有问题——比如 1000 分到底算铜牌还是银牌负数和 0 是否要区别处理。用 TDD 技能走一遍流程完全不一样。第一步它会先确认需求边界。它会明确问1000 分这个临界值归哪一档输入为负数怎么办会不会出现分数为 null 的情况这些细节不确认清楚后面写出来的测试边界就是错的。第二步创建测试文件只写第一个测试用例比如输入 0 分应返回铜牌。然后运行测试确认它失败——此时函数还没有实现失败是符合预期的。这个确认失败的步骤非常关键它保证了测试本身是有效的而不是一个永远通过的假测试。第三步写最小实现让这个测试通过。注意是最小实现不要顺手把整个逻辑全写完更不要顺手加一堆以后可能用得上的抽象接口。这一步对模型来说特别反直觉因为模型的默认倾向是一步到位而技能的约束就是为了压制这种倾向。第四步循环进入下一个用例比如输入 5000 分应返回金牌。重复写失败测试、确认失败、最小实现、确认通过的循环直到所有边界用例覆盖完。这里有一个体验上的变化模型在走完两三个循环之后会逐渐进入一种你知道它下一步要干嘛的节奏非常稳定。第五步全部通过后停下来做一次重构检查看有没有重复逻辑、命名是否清晰、有没有需要提取的辅助函数。重构之后还要再跑一遍完整测试套件确认没有回归。这套流程走下来最大的价值是每个步骤都有验证点最终交付的代码质量是可控的而不是靠运气。4. 踩坑记录与排查技巧4.1 技能不生效的常见原因用了一段时间之后我发现 superpowers 并不是装完就一劳永逸了。我把自己和身边朋友踩过的坑整理了一遍最常见的有三个。第一个是技能加载路径不对。有人把 skills 目录建在了项目下的.claude/skills然后在另一个项目里使用时发现技能完全不生效于是怀疑安装失败了。其实只是因为项目级技能只对当前项目生效。我的建议是如果你想让 superpowers 成为默认工作方式就装全局目录如果只在特定项目里用再放项目级目录。两者不冲突可以同时存在。第二个是 SKILL.md 文件格式被破坏。比如某些编辑器默认把 YAML frontmatter 里的冒号替换成全角冒号或者用 tab 缩进模型解析元数据时就会失败整个技能被静默跳过。排查方法很简单打开技能文件确认头部几行是标准的name、description字段缩进用的是空格而不是 tab。第三个是模型版本兼容性。不同版本对技能指令的遵循程度有差异我在旧版本上遇到过模型把技能内容当成普通对话背景、而不是必须遵守的流程的情况升级到最新版本之后明显好转。如果你发现技能偶尔触发、偶尔不触发优先检查 Claude Code 版本是否过旧。现象可能原因排查方法技能完全不触发目录路径不对或软链接失效检查~/.claude/skills下是否有技能目录部分技能被跳过SKILL.md 的 YAML 格式损坏用空格缩进重写 frontmatter触发不稳定模型版本过旧升级到最新版本后重试响应明显变慢技能数量过多只保留常用技能其余移出目录4.2 使用中的几个认知误区很多人把 superpowers 当成模型外挂觉得装完 AI 就变聪明了。这个认知需要纠正。技能的本质是一个流程控制器它提升的是结果的稳定性和可复现性而不是单次回答的智商。模型该不懂的知识还是不懂该犯的推理错误也可能犯但技能能让你在它对的时候知道它对错的时候通过测试发现错。换句话说它不能保证模型永远正确但能保证错误不会悄悄溜过去。另一个常见误区是滥用技能把完整流程不加选择地套在一切任务上。比如你只是改一个文案拼写错误也非要走一遍头脑风暴加 TDD纯属浪费时间。我自己后来形成了一套判断标准任务越复杂、影响面越大、越需要写清楚给别人看越值得走完整流程小修小改、一次性脚本直接让模型快速完成就行。superpowers 的核心价值在于复杂任务上的路径稳定性而不在于把简单的事情搞复杂。4.3 团队落地时的经验之谈最后聊一点团队层面的东西。我后来把 superpowers 推给了团队其他成员发现推广最大的阻力就两个字习惯。有经验的工程师早已形成自己的工作节奏对被一套流程管着这件事天然反感这种反应完全可以理解。我的做法是从一个小模块开始试点让一两个愿意尝鲜的人先跑通流程拿真实案例说话。比如同样一个需求走了 TDD 技能的模块在集成测试阶段几乎没有返工没走的模块改了三次逻辑。这种对比数据比任何宣讲都管用。另外建议让团队在 PR 描述里统一标注是否走完了 brainstorm 或 TDD 流程这样代码评审的时候reviewer 可以快速判断这个任务的测试覆盖是否经过完整推演评审效率会高不少。还有一个容易被忽略的点把技能文件纳入版本管理。superpowers 本身更新很活跃直接依赖上游仓库的HEAD会有风险某个技能的行为可能悄悄变化。我们团队的做法是把仓库 fork 一份到内部基于它维护自己的一套技能集合既能统一版本又能沉淀团队专属的工程规范。我们后来自己加了一条Go 项目必须使用表驱动测试的技能规则每次模型在 Go 项目里生成测试时都会自动遵循效果很直接。我个人在实际操作中的体会是这类技能包的真正价值不在于它开箱自带的那些文件而在于你肯不肯花时间去裁剪它、扩展它让它从别人的方法论变成你自己的工程习惯。