1. 先弄清楚Superpowers解决了什么我给Claude Code装了又卸、卸了又装的原因1.1 为什么“会聊天的AI”和“会干活的AI”之间差着一整套流程先说我自己的经历。第一次听说Superpowers这个项目时我下意识以为它又是一个“提示词收藏夹”——把几十条精心调教的prompt打包让AI表现得更聪明。当时我正被Claude Code的“一问就会、一干就废”搞得很烦你让它修一个Bug它能立刻给你一个貌似合理的结论改完代码一跑问题原封不动甚至多出两个新问题。不是模型不行而是它缺少一套“干活的方法论”。Superpowers恰恰补的是这层东西。它不是教AI“说什么”而是教AI“按什么流程做”。我把它的skills目录装进Claude Code之后最直观的变化是AI在遇到Bug时不再直接给结论而是先复现、再收集证据、形成假设、逐个验证最后才动手改。这个过程听起来像是个成熟工程师的标配但对LLM来说如果没有外部提示它天然倾向于“跳步”。所以Superpowers解决的本质问题是把隐性的工程流程变成模型可读取、可执行的显性指令。这也是它和普通配置文件最大的区别。一般的CLAUDE.md、AGENTS.md、system prompt描述的是“你是什么角色、你有什么知识、你注意什么风格”而Superpowers里的每个skill描述的是“你遇到某类任务时必须按哪几个步骤做每步做到什么标准才算完成”。一句话概括一个是身份设定一个是操作手册。1.2 Skills本质上是一份可执行的“操作手册”不是提示词Superpowers的核心单元叫skill。一个skill就是一个目录里面有一份SKILL.md文件文件头部是YAML格式的元信息包括技能名称、描述、适用场景、版本号正文部分则是具体的操作流程、检查清单、注意事项。关键在于加载机制Claude Code启动时会把所有可用技能的元信息注入到系统提示词里模型知道“我有这些技能各自用于什么场景”。当对话内容命中技能描述中的场景时模型就会主动展开对应的完整流程执行。它不是靠你手动输入“请使用debugging技能”才生效而是靠场景匹配自动触发。我举个例子方便你理解。没有Superpowers时你和Claude Code说“帮我看看这个接口为什么超时”模型可能直接开始翻代码、猜原因、给修复方案。有了Superpowers的debugging技能后它会先问你要复现步骤然后带着明确目标去查日志、看监控、对比参数甚至主动提议写一个最小复现用例。同一句话触发的是完全不同的工作路径。这也解释了为什么Superpowers不叫“prompt包”而叫“超能力”——它改变的不是模型的知识量而是模型在特定场景下的行为模式。1.3 什么场景才值得上用别把它当万能插件说句实在话不是所有项目都需要Superpowers。如果你只是拿Claude Code写点脚本、跑个Demo、翻译代码那装不装区别不大反而会觉得它“啰嗦”——debugging技能会让你先复现再排查TDD技能会催你先写测试这些流程对一次性任务来说确实是负担。真正值得上的场景有三个一是你在维护一个有一定规模的存量项目改代码容易牵一发动全身二是你的团队对代码质量有要求希望AI生成的内容经过测试验证而不是“看着没问题”三是你在用AI做批量重构、跨模块排查这类高难度任务需要它每一步都谨慎、可回溯。我个人现在的做法是日常写小工具时不启用它进入正经项目开发时打开。 你不用因为社区热度高就强行装先想清楚自己是不是真的需要一套“工程化流程”来约束AI。2. 安装前必须搞明白的三件事目录、版本和生效机制2.1 环境要求与我踩过的版本坑Superpowers对运行环境的要求其实很朴素一个能正常跑Claude Code的环境Node版本别太老API权限支持工具调用。我在安装前卡过一个大坑——没有看分支说明直接clone了master结果装完发现技能列表里什么都看不到。后来查了项目文档才明白Superpowers的目录结构是跟随Claude Code的skills机制迭代的。早期版本通过plugin方式注入后来的版本则直接把每个技能目录放在~/.claude/skills/下Claude Code会自动扫描这个目录。所以安装前第一件事是确认你的Claude Code版本支持技能扫描具体判断方法很简单在对话里输入/skills如果能列出技能面板说明机制可用如果提示unknown command说明你的版本太旧或者skills功能默认没开。另一个容易忽略的点是系统提示词长度。每个skill的元信息都会占掉一部分上下文窗口如果技能装得太多模型分给实际代码分析的上下文会变少。我的建议是先装核心的几个别一次性全量拉下来。2.2 克隆到哪个目录、怎么确认加载成功以当前常见的安装方式为例核心操作是把Superpowers仓库克隆到Claude Code的技能扫描目录git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers如果你在团队项目里只想给当前项目启用也可以放到项目级目录路径通常是.claude/skills/下。这里有个细节仓库本身包含了全部技能但Claude Code扫描的是skills/子目录所以克隆完后要检查一下目录层级是否多套了一层。确认是否生效我习惯用三步重启Claude Code输入/skills看面板里是否出现Debugging、TDD、Refactoring等条目。直接问一句“你现在有哪些技能可以调用”模型应该能列举出来。新建一个临时文件故意制造一个简单Bug看它是否主动走“先复现、再定位”的流程。第一步和第二步是判断“加载成功”第三步才是判断“真的有用”。2.3 Java项目里的第一次实测流程因为热词里专门有“superpowers java”我说一下Java场景下的实测路径。我用的是一个Spring Boot的存量模块初始目标是让AI给我重构一个老旧的Service类。第一次会话里我没直接说“重构”而是描述症状“这个类有3000行里面有大量重复的分支逻辑我想拆分成多个策略类。”Superpowers的refactoring技能被触发后模型没有立刻动手改代码而是先让我确认目标边界梳理现有行为列出一份“当前逻辑清单”然后建议用“引入策略模式逐步迁移”的方式切分。整个过程最让我意外的是它坚持小步操作每拆出一个方法就跑一遍已有测试而不是等全改完再统一验证。这一步看起来很慢但实际比一次性大改安全得多因为任何一步出问题都能立刻定位到是哪一个迁移引起的。Java项目里还有一个额外好处技能流程里包含“先让测试通过再进入下一步”的约束这对有JUnit基础的项目几乎是无缝衔接。如果你的项目测试覆盖比较差它会先建议你补关键路径的测试再开始重构——这个建议在工程上是完全正确的。3. 核心技能逐个拆解哪些是我每天真在用的3.1 Debugging从“AI瞎猜Bug”变成“按证据链排查”Debugging技能是我留下来不卸载的最大理由。它要求模型遵循一套类似“根因分析”的流程先确认Bug能否稳定复现如果不能先找复现条件复现后查看相关日志、报错栈、输入输出形成假设每个假设都先想好“如果这个假设成立应该观察到什么”再去找对应证据最后才定位到可疑代码给出修复。听起来很基础对吧但原生的AI行为不是这样的。原生状态下你说“日志里出现了NullPointerException”它大概率会直接猜测“某个对象没初始化”然后建议加判空。而有了Debugging流程约束后它会反过来问你哪个对象、在哪一行、什么条件下传入了null、上游数据从哪里来。一个是“猜”一个是“查”质量完全不同。我在实际项目里最喜欢的一点是它不会轻易让你改代码。有时排查到一半结论是“这个Bug是第三方SDK的已知问题绕行方案是降级”它会把证据链整理出来让你自己决定是修还是绕。这种克制在AI工具里很少见但对工程决策来说无比重要。3.2 TDD红-绿-重构AI写测试比我想象的靠谱我对AI写测试一直持保留态度原因很简单它经常写着写着就开始“测试自己写出来的代码”而不是“测试真实行为”。但如果用TDD技能先把流程定死情况会不一样。模型的执行顺序是先理解需求拆分验收条件根据验收条件写失败测试运行测试确认失败再写最小实现让它通过最后重构并保持绿色。这个顺序里最关键的约束是“测试必须先失败”。如果你让AI直接“给这个方法补测试”它往往会写出一个怎么跑都能过的假测试但在TDD流程下它必须先证明测试能捕获缺陷再谈实现。我试过一个例子给一个金额计算工具类补TDD测试。技能触达后模型先列出几个边界条件——负数、零、除不尽、精度溢出——然后针对每个条件写断言运行后确实红了再开始补实现。整个过程大约15分钟比我手动写还慢但生成的测试覆盖质量比我本人写的要高因为它不会偷懒跳过边界值。对于精度敏感的业务代码这个技能带来的安全感非常明显。3.3 Refactoring小步迁移的正确打开方式Refactoring技能的核心约束就一条在重构过程中任何时刻都不能让系统处于“大面积不可运行”的状态。它会把大型重构拆成一系列小变换每步变换后都要有验证点。这句话看起来容易做起来很难因为AI在自由状态下总是倾向于一口气改完。我见过太多次它把一个老类重写后留下十几个编译错误、三个行为变化。Superpowers的refactoring技能会用checklist强制它“每提取一个方法就检查一次调用方”。另一个我很受用的设计是它会让模型先明确“重构不改行为”和“新功能要改行为”的边界。你去动存量代码时AI经常顺手把功能逻辑也改了这在测试覆盖不足的项目里等于埋雷。有了边界约束它至少会先问清楚“这次重构是否允许改变对外行为”这个问题值回所有安装成本。3.4 Shell和其他让它在终端里真正“动手”除了这三个核心技能Superpowers里还有Shell技能用来约束模型执行终端命令时的行为——比如运行命令前先解释要做什么、遇到失败输出要贴原始报错、批量操作前先列出计划。这个小技能在日常工作中提升很大因为它让AI从“只会生成代码”变成“能主动跑测试、看日志、查端口”。我给你一个真实场景排查一个本地服务启动慢的问题。原生状态下AI会建议“你去看看日志”然后把球踢回给你。装了Shell技能后它会主动提出执行curl -w测接口耗时、用jstat看GC情况、甚至写一个小脚本连续采样。它不是替你思考而是替你把“拿到证据”这件事做了。对于懒人工程师来说这个技能的价值可能比Debugging还高。4. 把Superpowers移植到Codex适配过程和我踩的三个坑4.1 为什么有人要在Codex里用Superpowers“codex superpowers”这个热词出现得很自然。Codex CLI是OpenAI推出的终端编程助手底层模型不同、交互方式不同但很多人用惯了Claude Code里的Superpowers流程换到Codex后总觉得AI“野”——回话快、动手快、但稳定性差。本质原因是流程约束丢了。同样的任务在有Superpowers的Claude Code里会先做复现、再排查在裸Codex里会直接给结论。所以社区里有人尝试把Superpowers的SKILL.md直接复制到Codex的技能目录想让Codex也遵守这套流程。这个想法完全可行但绝不是“复制粘贴就完事”。我在迁移过程中踩了三个坑一个是目录理解错了一个是语法兼容问题还有一个是工具机制差异。4.2 目录挂载方式的差异我第一次移植时想当然地把Superpowers放到了~/.codex/skills/结果Codex没有任何反应。后来翻了Codex的文档才意识到它的技能机制和Claude Code不同部分版本约定是把技能说明写进AGENTS.md或者放在项目级别的.codex/目录下而不是全局扫描skills/子目录。这里我不给死命令因为两个工具都在快速迭代目录约定经常变。正确的打开方式是先看对应工具的技能文档确认它扫描哪个目录、识别什么格式再动手迁移。唯一的通用规律是技能元信息必须能被系统提示词读到否则不会被自动触发。如果Codex不支持自动扫描你可能得手动在规则文件中引用技能内容效果会打折但总比没有强。4.3 私有语法与工具调用的不兼容这是移植失败的重灾区。Superpowers的skill文件里大量使用了Claude Code的私有扩展语法典型的有两种一种是在命令行执行时的参数占位符$ARGUMENTS另一种是从文件读取内容时的filename语法。这些在Claude Code里能正常工作但Codex不认识只会把它们当成普通文本。我迁移debugging技能时前几次运行完全无效就是这个原因。排查过程是这样的我先用一条简单命令验证技能有没有被加载发现加载了再让模型执行技能里的“查看错误堆栈”步骤发现它读不懂$ARGUMENTS直接跳过最后打开SKILL.md逐行检查把所有私有语法替换成Codex能理解的变量形式才跑通。所以迁移的功夫不在复制文件而在“翻译”文件。你需要通读每个技能的操作步骤把Claude特有的表达替换成目标工具的规则语法。技能文件越长翻译成本越高这个心理准备要有。4.4 移植后哪些技能水土不服翻译完语法之后还有个更隐蔽的问题不同模型对“流程性指令”的服从度不一样。Refactoring技能要求“每次小步操作后验证”Claude Code执行得很好但迁移到Codex后同一个技能文件里同样的文字模型偶尔会“跳步”——它读懂了但它觉得“这个步骤没必要”。我自己的体验是Debugging技能的移植效果最好因为“先复现再排查”符合Codex模型的长处TDD技能能用但需要你在对话里盯紧流程Refactoring技能最容易退化因为它依赖前后状态对比和验证动作而Codex在这方面的工具链不如Claude Code顺手。如果你打算移植我的建议是不要全量搬挑两三个你最依赖的技能做深度适配比一次性移植十几个技能更可持续。5. WorBuddy这类集成包是怎么回事开箱即用和原版怎么选5.1 集成包到底集成了什么“worbuddy怎么用superpowers”这个热搜词我猜问的是社区里一类打包好的配置包。它们的定位很清晰把Superpowers的核心Skills、一套顺手的CLAUDE.md、推荐的权限配置甚至预设的系统提示词整合在一起让你通过一次安装就获得一个“能直接干活”的Claude Code环境。如果你是第一次接触这类集成包把它理解成“别人帮你调好的一台电脑”就行。原版Superpowers是偏朴素的工具箱里面每个工具都是独立的用不用、怎么组合都由你自己决定而集成包往往夹带了作者的私货——它预设了作者认为最优的交互方式、提示词风格、工具调用策略。这不一定是坏事。我见过一些集成包确实做了很好的优化尤其是权限白名单和常用命令预设能大幅减少AI“想干但不能干”的情况。但也要明白集成包不是官方出品它代表的是一个作者或一个社区的使用偏好。5.2 “worbuddy怎么用superpowers”的一般步骤这类集成包的使用逻辑通常逃不出三步下载包、放到配置目录、重启会话。第一步按文档要求把包里的skills目录合并到你的技能目录。第二步如果包里带CLAUDE.md或AGENTS.md放到项目根目录或全局配置目录。第三步重启工具输入/skills或/status确认加载。这里有一个通用建议合并前先把原目录备份用diff对比一下。很多集成包会覆盖你已有的全局设置尤其会改动模型行为偏好、工具白名单、权限模式这些重要配置。为了避免“装个包把原有环境搞乱”我习惯把每个集成包先放到项目级目录里试用确认没问题再提升到全局。项目级路径通常比全局优先级高这个机制恰好适合用来试水小范围验证完再决定要不要全局启用。5.3 我的取舍先裸装原版再考虑集成包我的观点可能和社区主流不太一样不要一上来就用集成包先花一个下午裸装原版Superpowers把机制搞明白再回头决定要不要用集成包。原因很简单集成包省掉的是“理解成本”但如果你不理解技能的加载机制、目录层级、权限逻辑遇到问题会非常被动。裸装原版时你会被迫搞清楚“技能装到哪”“为什么没生效”“权限文件怎么改”这些基础问题这些知识在后续所有场景里都会复用。等你对原版有手感之后再来用集成包你能看懂它改了什么、哪些改动对你有益、哪些可以删掉。到了这个阶段“worbuddy怎么用superpowers”就不再是问题——它只是你随手可拆的一堆配置而已。6. 高频故障排查与我的日常使用习惯6.1 技能没生效时我的排查顺序装了Superpowers之后遇到最多的问题是“技能好像不起作用”。我的排查顺序基本固定从外到内第一步确认技能目录结构正确。打开~/.claude/skills/看Superpowers仓库是否被克隆成多级嵌套比如superpowers/superpowers。常见错误就是多套了一层目录导致扫描不到。第二步重启会话并查看/skills面板。如果面板里有技能但模型不自动触发问题大概率出在场景匹配上——你的问题描述和skill元信息里的“适用场景”没对齐。比如debugging技能声明自己用于“定位Bug根因”你说“帮我改一下这个报错”它可能不触发。解决办法是把问题说清楚“这是一段报错日志帮我定位根因”。第三步检查系统提示词是否被截断。技能装太多、元信息过长时部分模型会在上下文压缩时丢掉技能描述。表现是第一次会话能用聊长了之后技能失效。我的应对是只在需要时临时挂载技能目录用完就换掉。6.2 权限、白名单和免确认的边界Superpowers里的技能经常要执行Shell命令这会撞上工具的权限确认机制。每次命令都手动确认会非常烦但全量免确认又很危险。我的折中方案是只对安全命令开白名单ls、cat、grep、git status、git diff这类只读命令直接放行rm -rf、git push、chmod这类高风险操作保持手动确认。另外一个很容易被忽略的点技能里的交互式命令和无限循环。有些skill会引导模型写一个持续监听日志的脚本如果权限配置不当进程会在后台一直跑占资源还不好清理。对这种场景我会要求模型必须加超时退出否则就禁止执行。不要因为追求“AI全自动”就把权限全放开。全自动的下一站往往就是事故。保留一些手动确认的节点本身也是对任务质量的把关。6.3 把它当成“结对程序员”而不是“执行器”最后聊点习惯层面的东西。Superpowers真正改变我工作方式的不是那些具体技能而是它让AI从“生成答案”变成了“走流程”。这带来的直接好处是我可以在关键节点插话、纠偏、补充信息而不必担心AI在一个错误的方向上狂奔。我现在对待带Superpowers的Claude Code更像是对待一个能力强但经验尚浅的结对程序员。它出方案我审方案它排查我给线索它提议重构我定边界。这套流程天然地把我从“操作员”变成了“技术负责人”而让AI承担大量具体劳动。这种协作方式最终带来一个副产品我开始把自己日常处理任务时那些“只可意会”的步骤整理成文字写进自己的技能文件里。Superpowers的用法不只是安装别人写好的技能它更像是一套方法框架——当你习惯了“把流程写成模型能读的规则”你手里的AI就会在无数项目里复用它学到的工作方式而不是每次从零开始猜你要什么。如果你也想给编码助手加一套真正可用的“超能力”我的建议很简单先装原版、跑通一个技能、验证它对你有用然后再谈扩展。流程感这种东西一旦你体验过就回不去了。