如果你最近开始重度使用 Claude Code 这类跑在终端里的 AI 编程助手大概很快就会撞上一个情景模型本身很能打你问什么它答什么可一旦任务跨了好几个文件、需要来回验证它就容易东一榔头西一棒子把前面说好的约束忘得干干净净。我前阵子重构一个老服务的时候就被这个问题折腾了一整个下午——最后发现不是模型不行而是我缺少一条把“工程方法”稳定传递给 AI 的通道。后来试了试社区里那套叫 superpowers 的技能包思路才一下子打开。这篇不是官方文档复述是我自己从安装、引入到天天用来写代码的真实体验适合那些已经有一定终端 AI 编程工具使用基础、想把它从“聊天工具”升级成“干活搭子”的人。1. 从“聊天助手”到“技能化工作流”superpowers 解决的到底是什么1.1 先搞懂 Claude Code 的 skills 机制很多人第一次听说 superpowers 的时候第一反应是问它到底是个插件还是一个新模型都不是。它本质上是一套“技能包”建立在 Claude Code 的 skills 机制之上。所谓 skill你可以理解成一份写给 AI 的标准化作业指导书。文件本身是 Markdown 格式头部有一段 YAML 元信息写着技能的名字和触发描述正文则是具体的操作步骤、约束条件、输出格式和检查清单。Claude Code 在启动时会扫描指定的 skills 目录把每个技能的名字和描述加载进模型可感知的上下文里。当你在对话中遇到某个场景模型会根据这些描述判断该调用哪个技能然后读取对应的完整指导书来执行。superpowers 就是在这个机制上做出来的一个高质量技能集合。它把调试、规划、测试驱动开发、子代理编排、技术调研这些平时要靠人反复叮嘱的工程实践全部固化成一个个结构完整的技能文件。这样做的好处非常明显你不用再在每次会话里重新跟 AI 解释“你要先这样、再那样”只要它识别出场景、加载了技能就会自动按照一套经过验证的流程走。我第一次感受到这种差异是在一次 bug 排查里。以前让 Claude Code 查问题它经常直接跳到“我猜是这里有问题”然后给出一个修改建议。但加载了调试类技能之后它会先要求我提供复现步骤再逐步缩小排查范围甚至会在动手改代码前先设计一个验证方案。行为模式从“猜”变成了“实验”这才是工程化该有的样子。1.2 很多人对 superpowers 的第一个误解先泼一盆冷水装了 superpowers不等于 AI 突然就能写出更好的代码。它不是魔法也不改变模型本身的推理能力。我见过不少人装上之后第一句就是“帮我重构整个项目”然后等着 AI 自己把所有事情做完结果发现该翻车还是翻车。这是因为 superpowers 改变的是工作流程而不是能力上限。它的价值在于当 AI 的能力足以完成一类任务时它确保 AI 能稳定地、按章法地去完成而不是东一榔头西一棒子。说得更直白一点模型就像一个很有天赋但没什么纪律的新人superpowers 就是给他的一份员工手册告诉他遇到什么情况该按什么 SOP 来。另外它和普通的系统提示词也不太一样。系统提示词是全局生效的不管什么任务都在后台占着上下文而 skill 是“按需触发”的平时只加载一句描述进去真正用到时才读取完整操作步骤。这种设计在长会话里尤其舒服省下的上下文空间可以留给真实的业务代码。2. 安装 superpowers 之前先搞清依赖、路径和版本2.1 环境准备如果你想复现我下面的流程建议先把环境对齐。我用的是 macOS 环境但 Windows 和 Linux 也差不多只是个别路径写法不同。终端环境建议用 zsh 或 bashWindows 用户优先考虑 Git Bash 或 WSLNode.js 环境要能正常跑npx命令版本最好在 18 以上Git必须装因为安装脚本本质上就是从仓库拉代码Claude Code 本体这个不用说肯定要先装好并且跑通过一个会话。这里有个很多人忽略的点superpowers 的目标运行环境一直在往前迭代新版本可能会依赖更新的 Claude Code 版本。我最开始装的时候没注意版本结果装完了在旧版本上跑技能文件能被扫到但一直不触发排查了半天才发现是版本太低。建议安装前先claude --version看一眼然后以项目 README 里标注的最低版本为准。别偷懒看都不看就直接装这个坑我替你踩过了。2.2 常见安装流程目前社区里最主流的装法是从 GitHub 把仓库 clone 下来然后跑仓库里的安装脚本。大致是这样的流程git clone https://github.com/obra/superpowers.git cd superpowers ./install.sh注意这是我写这篇分享时社区里常见的做法不同时期项目结构可能会有调整你实际操作时一定要先看一遍 README以里面的最新安装方式为准。安装脚本通常会做两件事一是把仓库里的 skills 目录同步到你本地的 Claude 全局配置目录二是生成一个配置文件方便你后续管理开关哪些技能。从旧版本升级的时候不要图省事只用git pull。我的习惯是重新跑一遍安装脚本让脚本自己处理软链接的更新和清理工作。手动去覆盖文件很容易留下旧的 skill 残留到时候在会话里看到两个名字一模一样的技能模型反而不知道该选哪个。2.3 安装后的目录结构装完之后你可以用下面这个命令看一下实际生成了什么ls -la ~/.claude/skills正常情况下你会看到一排软链接每个链接指向 superpowers 仓库里对应的技能目录。比如debugging - /path/to/superpowers/skills/debugging planning - /path/to/superpowers/skills/planning tdd - /path/to/superpowers/skills/tdd看到软链接而不是复制出来的文件这是个好信号。意味着以后升级 superpowers 只需要去仓库里拉新代码你本地所有项目不需要重新配置软链接会自动指向新的技能内容。如果你在这个目录里看到的是一大堆手动复制出来的文件夹那我建议你把它清掉重新用安装脚本生成软链接。因为复制出来的文件没有版本追踪你会很快陷入“到底哪个项目在用哪个版本”的混乱里。2.4 校验安装结果装完之后先别急着写代码花两分钟确认一下环境是否真的就绪。第一步检查目录结构确认技能软链接都在第二步打开一个全新的 Claude Code 会话直接问一句“你当前有哪些可用的 skills”第三步对照模型回答的技能列表和你ls看到的目录一一比对。正常情况下模型只会回复它实际扫描到的技能不会把你目录里删掉的东西也列出来。如果模型给出的列表和你目录里的软链接对不上优先检查是不是有多个 skills 目录在互相干扰。Claude Code 同时支持全局目录和项目目录项目级别的.claude/skills会覆盖或叠加在全局技能之上。所以有时候你改了全局配置老半天没生效其实是项目目录里有一份同名技能把它盖住了。3. superpowers 的技能图谱我实际用到的几个大类3.1 规划类把模糊需求变成可执行计划我用的最多的其实是规划类技能。以前接一个大需求我会在对话里手敲“先拆成几个阶段每阶段给一个验收标准”然后前三次 AI 还能记住到了第五轮基本就放飞了。但有了规划技能之后AI 会主动按固定的框架输出目标、约束、拆解步骤、风险点、验收清单。有个词叫 thinking 的引导说白了就是让模型把思路写出来。但 superpowers 的规划技能更狠的地方在于它会强制要求把每个步骤的输出物写清楚而且明确标注哪些是不可以跳过的检查点。我用它拆过一个涉及六个模块的迁移任务AI 最后给出来的计划表里甚至标出了每个模块之间的依赖顺序。这种结构化程度靠纯聊天提示是达不到的。3.2 调试类让 AI 照着“科学方法”查问题调试技能是我推荐每个人都用的。它把排查问题变成了一套固定的流程先描述预期行为和实际行为再要求提供最小复现路径然后列出所有可能的假设按优先级逐一验证最后才落到代码修改上。这个流程看起来很朴素但真正用起来才知道它的价值。没有调试技能的时候模型遇到报错往往直接说“我建议你改成这样”你改完发现下一个错误冒出来了陷入打地鼠循环。用了调试技能之后模型会先反问“复现步骤是什么”如果你说不出来它会主动帮你构造测试用例。这套东西逼着人用科学方法而不是直觉去解决问题效率反而高得多。3.3 测试驱动开发先写红再写绿TDD 技能是争议最大的一个因为它改变了写代码的顺序。它的核心逻辑是先根据需求写出失败的测试然后让实现代码去“填坑”最后再做小步重构。我一开始觉得这套流程在 AI 编程场景里很拖沓实际跑了几次之后承认它确实能减少返工。尤其是当任务边界比较模糊的时候测试用例本身就是对需求的一种确认。AI 写实现代码之前先写测试等于先把验收标准立住了。后面改代码的时候只要测试还是绿的你就可以大胆重构。如果你的项目本身没有测试体系不建议一上来就开这个技能否则 AI 会先花大量时间搭测试框架反而拖慢节奏。3.4 子代理编排把任务拆出去并行这一项是 superpowers 里比较高级的玩法依赖 Claude Code 的子代理机制。它的思路是让主代理不要事必躬亲而是把独立的子任务派给专门的子代理去执行主代理只负责汇总和决策。听起来很炫实际用起来的感受更像是在一个无人管理的项目组里给自己配了一个项目经理。我试过让它同时开三个子代理去调研三个不同的技术方案最后主代理把三份报告汇总成一份完整的选型建议。整个过程比我手动切换会话高效得多。不过这个功能对上下文窗口的消耗比较大小任务没必要用大任务里用一两次就足够。3.5 写作与研究类除了代码superpowers 里还有一批非代码类技能比如技术文档写作和技术调研。文档写作技能会强制规定结构背景、现状、方案、利弊、推荐结论。技术调研技能则会要求列出信息来源、验证方法和结论的可信度评估。我拿它写过几份内部的架构设计文档比我自己从空白页开始憋要快不少。而且因为流程固定生成的文档风格非常统一同一批文档放在一起不会出现一个写得像散文、一个写得像会议纪要的割裂感。3.6 技能速查表下面是我这段时间使用频率最高、也最推荐新手上手尝试的几个技能技能类别核心使用场景我的使用频率规划大任务拆解、写实施计划每天调试定位线上问题、分析报错每天测试驱动开发新功能实现、重构保护一周数次子代理编排多方案调研、并行任务处理视任务而定文档写作架构文档、方案评审一周数次新手第一次用我建议先只保留规划和调试两类等熟悉了机制的触发逻辑再逐步打开其他技能。一下装上十几个很容易让模型在会话里频繁切换状态反而显得不稳定。4. 把这套技能真正引入工作流从手动调用到自动触发4.1 三种触发方式很多人以为装了 superpowers 之后所有技能会自动在任何合适的时机触发其实没那么简单。根据我的观察实际触发有三种方式第一种是显式请求。你在对话里直接说“用调试技能看看这个报错”模型看到技能描述里匹配度很高就会加载并执行。这是最可控的方式适合你对自己要走的流程有明确判断的时候。第二种是语义触发。你不说技能名字但你的描述命中了技能的 description比如你说“这个问题我复现不出来”调试技能的描述里如果包含“复现问题、定位故障”相关关键词模型就可能自动激活调适技能。这种方式的体验最丝滑但对 description 的写作质量要求很高描述写得太泛模型反而啥都往套写得太窄又经常触发不到。第三种是手动注入。直接把 SKILL.md 的文件内容贴到对话里然后让模型按这个流程执行。这种方式适合在别的工具里临时使用或者你想测试一个新写的技能是否有效。缺点是比较费上下文文件太长的时候不建议这么做。一个非常值得实操的技巧是先在意明白意图别让模型靠猜。比如我不说“帮我查一下这个 bug”而是说“请按照调试技能的标准流程分析这个报错先给出复现方案再改代码”。这种带着明确预期的指令模型几乎不会跑偏。4.2 自己写一个最小可用的 SKILL.md如果你想给项目定制一个团队专属技能并不需要去改 superpowers 的源码。你可以直接在项目里建一个自己的技能文件。一个最小可用的 SKILL.md 长这样--- name: code-check description: 在提交代码前执行静态检查识别潜在的空指针、未处理错误和资源泄漏问题 --- # 代码检查流程 1. 读取待检测代码文件列出所有函数入口和资源获取操作。 2. 逐项检查未处理的错误、可能的空指针、未关闭的句柄。 3. 输出一份问题清单每条包含文件位置、问题描述、可能的影响、修复建议。 4. 对每个问题给出严重级别高、中、低。这个文件放在项目的.claude/skills/code-check/SKILL.md重启 Claude Code 后就可以使用。有没有发现这就是 superpowers 的全部秘密——它本身也只是一堆写得更讲究、更完整的 SKILL.md 而已。写自定义技能的时候有两条经验第一description 是灵魂。模型靠它决定什么时候触发所以要把触发场景写得具体一点甚至可以写上几个“别用它”的场景来降低误触发。第二正文一定要有输出约束面。只写步骤不写输出格式模型很容易把流程走一遍却给你一份乱七八糟的总结你把每步的输出模板固定下来质量立刻稳定。4.3 控制触发灵敏度和加载开关随着安装的技能越来越多我遇到了模型“什么都想套一下”的尴尬。比如我只是让它改个变量名它非要走一遍完整的规划流程把三分钟能做完的事拖成十五分钟。后来我发现超级的力量是可以在配置里关掉不常用的技能只保留高频技能参与触发判断。这操作比我想象中简单——把对应的软链接从 skills 目录里挪出去或改一下配置文件里的开关列表等用到的时候再临时开回来。你要是不确定哪个技能在影响行为可以开一个“排查模式”直接问模型“你刚才为什么调用这个技能触发依据是什么”模型通常会把匹配到的描述片段讲出来你根据这个反馈微调技能的描述或者开关状态就行。4.4 全局还是项目级一个容易被忽略的选择这里有个关键选择技能放在全局目录还是项目目录。全局目录方便所有项目复用但不同项目的工程文化不一样——有的团队强制测试驱动有的团队根本不写测试。我把 TDD 这类风格强、约束硬的技能放在项目级目录里只有确实需要它的项目才加载把调试、规划这类通用技能放在全局保证任何项目都能用。这个划分听起来很简单但避免了大量“技能在项目 A 里很顺利、在项目 B 里变成节外生枝”的问题。项目级技能还有个额外的好处跟着 git 仓库走。团队 clone 下来代码技能自动带过去省掉每个人单独配环境的步骤。5. 使用反馈与排错记录我踩过的几个真实坑5.1 skill 永远不触发这是我遇到过的最糊弄的场景。目录里明明能看到技能文件也确认加载了但跟模型聊半天它就是不用。我最后定位到三个原因。第一个原因是技能文件放进了错误的子目录。Claude Code 对目录结构有要求SKILL.md必须放在skills/技能名/SKILL.md这个层级直接放在skills/下面通常扫不到。第二个原因是 description 里的触发场景和我实际的问法相距太远模型完全没把这两者关联起来。第三个原因比较隐蔽——旧版本的客户端对技能数量有限制技能太多时后面的直接不参与匹配。排查链路建议这样走先看目录结构对不对再在对话里用技能描述里的原词去提问最后确认版本。别一上来就怀疑是模型笨大概率是配置问题。5.2 多个技能同时命中行为互相干扰有一次我让 AI 修一个测试里发现的 bug结果调适技能和 TDD 技能同时被触发。调试技能想让模型先做最小复现、再加日志定位TDD 技能则想让模型先写一个失败测试来暴露问题。两条流程各有道理但叠加在一起就让模型行为变得很拧巴一会儿准备加日志一会儿又开始写测试。后来我的处理方式很简单遇到这种容易重叠的场景先在对话里指定只用一个技能。比如“只用调试技能处理这个问题不进入 TDD 流程”。次数多了之后我会考虑写一个组合技能把“先写复现测试再定位”合并成一条固定路径两个技能就不再打架了。5.3 上下文窗口被技能说明占满技能文件写得越长触发时消耗的上下文就越大。有些技能动不动几千字把模型的分析空间挤得很小处理大文件时就容易“忘了前面的代码”。这是个很现实的权衡技能太短说不清流程技能太长拖累执行。我的习惯是技能正文控制在 800 到 1500 字关键步骤写清楚但绝不堆细节。真正需要展开的模板、检查清单可以拆分到独立的参考文档里技能正文只写流程骨架和引用路径。这样既保留规范又不挤占过多窗口。5.4 团队协作时各装各的环境乱七八糟你把自己的环境玩明白了不等于团队其他人也玩明白了。我经历过一次团队内部联调我本地跑得顺的流程同事那边一跑就完全不是一回事。后来检查发现他装的版本旧技能目录路径还不一样配置文件也没对齐。后来我把技能相关配置直接纳入了项目仓库并写了一个快速校验脚本大家克隆完代码跑一遍自动检查技能数量和版本是否一致。这事不复杂但能避免大量嘴皮子功夫。如果你的团队已经重度使用这类工具这一条非常值得做。6. 我的最终使用建议什么项目适合、什么项目别乱用6.1 高杠杆场景大型重构规划技能和测试技能搭档先拆解再动手风险能控制住。疑难 bug 排查调试技能把排查过程标准化不再靠猜。新项目脚手架规划技能推出目录结构、技术选型和里程碑文档写作技能生成设计文档。技术选型调研子代理编排并行搞定多方案对比。6.2 不建议用 superpowers 的场景不是所有任务都需要这套重流程。改个文案、写个一次性脚本、快速验证想法这些场景直接跟模型对话反而更快。强行走技能流程就像下楼买瓶酱油也要先开个项目启动会冗余得过分。判断标准其实就一条这个任务是否要求“过程可复现”。如果答案是肯定的值得上技能流程如果只是临时起意、结果优先那就别折腾。6.3 从 superpowers 上学到的方法论用到现在我最大的收获反而不在那几个具体的技能文件而是它展示了一种思路把你想让 AI 执行的复杂行为拆成一个一个带触发条件、带操作步骤、带输出约束的独立“能力单元”再组合进日常流程。就算你最后不用 superpowers 本身这套“技能化封装”的方法也完全可以迁移到自己的工具链里。我现在的习惯是先给团队维护几个定制技能再配合 superpowers 的几个通用技能一起工作。慢慢你会找到一个自己的平衡点哪些流程需要 AI 自动执行、哪些需要你显式指定、哪些干脆不用。这个平衡点会随着你对工具的熟悉程度不断变化不用急着一天定下来。试错本身也是用这类工具的一部分乐趣。