最近我发现身边用AI编程助手的人分成了两派一派觉得就是玩具写点小脚本还凑合一上大工程就露馅另一派却能让AI把一个几万行的仓库啃下来改bug、写方案、做code review都像模像样。差别在哪很大程度不在模型而在你怎么给AI下达指令有没有给它一套可复用的工作方法。今天要聊的Superpowers就属于后者——一套目前社区热度很高的AI编码技能集也就是常说的skill pack专门用来给Claude Code、Codex CLI这类代理式编程工具装上系统化、可复用的方法论。我第一次听说这个名字是看有人在帖子分享我用Superpowers之后AI的调试行为完全变了。当时我正好被手头项目折腾得够呛代码风格差、测试缺失的历史包袱项目AI改了A处又弄坏B处。听完之后我就去试了实测下来确实和我以前把任务直接甩给模型的用法完全不同。这篇文章就把我这几周折腾Superpowers的经验整理出来从它解决的问题、怎么安装到有哪些skills、如何自定义再到使用中的坑一次性写清楚。想让你手头的AI编码工具从会写代码进化到会干活的可以跟着往下看。1. 这个超能力到底解决的是什么问题1.1 为什么你的AI助手总是越帮越忙先说说我以前的典型使用方式打开Claude Code输入一句帮我修一下登录页面的bug然后回车。遇到简单的报错模型确实能直接改好但一旦问题是跨文件的、需要先复现再假设最后验证的AI就会陷入两种状态——要么在文件里乱翻一通给出一个看似合理但根本编译不过的改动要么反复猜测问题原因最后把无辜的代码也改了。我自己用下来的感受是模型本身不缺知识缺乏的是工作结构。它知道什么是调试但它不知道你在一个具体项目里希望调试按什么顺序来。比如是先看报错堆栈还是先找最近改动是改完直接提交还是需要先补回归测试。这些方法论通常藏在老工程师脑子里AI没有。这也是为什么光靠提示词工程很难稳定复现高质量工作流。临时在prompt里写好好调试是没有用的模型无法把这个模糊指令转成可执行的步骤。它需要的是某种机制把一套完整的、带步骤带模板的指令集在合适的时机自动加载到上下文里。1.2 Superpowers的核心思路把方法论装进技能包Superpowers的解决思路很直白把调试、规划、代码审查、架构设计、测试驱动开发等方法论写成一个个Markdown技能文件。每个文件就像一个岗位说明书里面包含该技能的适用场景、完整执行步骤、输出格式、注意事项。AI在接到任务时会根据任务描述去加载对应的技能文件然后严格按照里面的步骤来干活。这个思路听起来简单但落地之后效果提升非常明显。原因在于技能的加载是按需触发的模型先理解用户的任务然后决定调用哪个技能再执行技能里的步骤。比如你说帮我查一下这个崩溃日志模型会自动匹配到debugging技能然后先引导你提供日志、系统版本、复现步骤再逐步缩小范围。整个过程不再是即兴发挥而是照着一套成熟流程走。这里要注意区分两个概念MCPModel Context Protocol给AI的是工具比如读取数据库、发HTTP请求Superpowers给AI的是方法论比如怎么排查问题、怎么拆解任务。两者可以共存但解决的是完全不同的东西。我身边不少朋友在纠结要不要装一堆MCP服务器其实很多时候缺的不是工具而是流程。2. 动手安装三分钟先跑起来2.1 先搞定Skilled CLISuperpowers的官方推荐方式是通过Skilled CLI来管理。Skilled是一个专门用来创建、安装、更新技能包的命令行工具目前同时支持Claude Code、Codex CLI以及一批其他AI编码工具。我这边是用Rust的cargo装的命令很简单# 装Skilled CLI任选一种方式 cargo install skilled-cli # 或者用Homebrew brew install skilled装完后可以先确认一下版本skilled --version如果你本机没有Rust环境也可以直接去Skilled的GitHub release页面下载对应平台的二进制文件解压后放到/usr/local/bin之类的目录里。这跟大多数命令行工具的安装方式一样没什么特殊之处。我第一次装的时候因为cargo编译比较慢一度以为卡住了其实等两三分钟就好。后来改用release二进制速度就快很多了。2.2 创建项目并接入Claude Code装好Skilled之后进入你想要使用Superpowers的项目目录执行下面的命令cd /path/to/your-project skilled create superpowers这条命令会在项目里创建一个技能相关的配置文件然后自动把Superpowers技能包下载进来。接着Skilled会询问你想接入哪个AI工具比如claude-code或codex按实际使用场景选择即可。整个过程有一点像git init只是在初始化技能环境。完成之后你可以打开项目里新生成的配置看看里面会列出可用的技能目录。用Claude Code的话重启一次终端再启动Claude Code技能就生效了。怎么确认技能有没有被加载最简单的方法是直接问AI你现在可以调用哪些skills如果配置正常模型会列出Superpowers里的一堆技能名称比如debugging、planning、code-review。这个验证方式很关键我建议每个人装完之后都先做一遍免得后面发现技能根本没加载上还百思不得其解。2.3 不想装CLI手动clone同样可行如果你的项目环境比较特殊装不了Skilled CLISuperpowers本身也是一个开源仓库完全可以手动clone下来用。操作大致是git clone https://github.com/workstuff/superpowers.git然后把你项目的AI工具配置文件里加上对Superpowers技能目录的引用比如Claude Code会读取CLAUDE.md你可以在里面加一段说明当需要调试、规划、代码审查时加载superpowers目录下对应技能。这种方式的缺点是技能更新需要手动pull优势是你能直接看到每个技能文件的内容对理解运行机制非常有帮助。我个人建议如果你只是普通使用直接用Skilled CLI就好省心如果你想在Superpowers基础上改造成自己的技能包那手动clone是必须的第一步因为你有机会读源码、改提示词。3. 内置技能清单与选用场景3.1 调试与排查类debugging、bug-hunting、investigate这是Superpowers里我最常用的一类也是它最出圈的地方。debugging技能是整个技能包的招牌模型启用后会严格按复现问题、采集信息、提出假设、验证假设、修复回归的流程走不会再像个无头苍蝇一样乱改代码。实际体验下来最明显的变化是AI会先问你问题而不是急着给答案。比如你给AI一段崩溃日志启用debugging后它会先确认这个日志是哪个版本产生的是稳定复现还是偶发有没有最近的代码改动这些问题看似简单但会极大减少AI瞎猜的概率。bug-hunting更像是针对没有明确堆栈、只知道某个功能不对劲的场景侧重通过代码审查和差分对比来缩小可疑范围。investigate则偏向研究性任务比如我们这个接口为什么突然变慢查一下它会输出一个调查计划而不是直接甩一个武断结论。这三个技能虽然都属排查类但触发条件不同。AI会根据任务描述里是有报错、行为异常还是需要调查来选择。如果你需要遵循一套特定的排查规范也可以在自定义技能里引用它们组合使用。3.2 规划与实现类planning、writing-plans、architecting、TDD第二个大头是干活之前先动脑子类的技能。planning是什么简单说就是让AI在动手改代码之前先输出一份实施计划。这份计划不是空话而是包含具体改哪些文件、每个文件怎么改、有没有依赖顺序、怎么验证。启用这个技能后AI一改以前直接开始改的习惯先问你要不要它制定计划。我一开始觉得这多此一举后来发现对于跨多个文件的重构提前计划能避免改到一半发现方向错了的尴尬。writing-plans则是把这份计划固化成文档适合团队协作方便Code Review的人来对照。architecting什么时候用当你需要在现有的混乱代码上新增一个模块时它会先分析当前架构识别可能的影响点再给出一套最小侵入的实现方案。很多代码库烂不是功能不work而是每次新功能都直接往上堆缺乏架构层面的通盘考虑architecting就是针对这个问题的。test-driven-developmentTDD这个技能估计不少人愿意为它单独装一套Superpowers。启用后AI会按先写测试、再写实现、再重构的顺序工作。我开始以为这会拖慢节奏结果在一次性任务里反而稳了很多——因为每个小步都有测试兜底后期不用花大量时间补回归。3.3 审查与协作类code-review、analyze-and-commit这一类日常也很有用。code-review技能不只是让AI看看有没有bug它会按照可维护性、代码风格、潜在边界条件、依赖影响等维度逐项审查并给出结构化的评审意见。以前我让AI review代码它总是说整体不错建议补个注释这种废话启用这个技能后输出就变成了这里有一个数组越界风险这块逻辑在并发下可能出问题实用得多。还有analyze-and-commit这货简直是人肉review小助手。它的工作方式是先扫描这次改动涉及的diff分析风险等级再生成规范的提交信息最后还可以帮你把大commit拆分成多个逻辑提交。我在团队里给新人看改动时经常会先让它分析一遍确保没有低级错误再合入。这节省的时间用可感知来形容都是低估了。3.4 其他容易忽视但关键时刻有用的技能还有一些不那么显眼但特定场景下能救命的技能。比如canary-deployments它讲的是灰度发布策略AI会基于你的项目情况生成分阶段上线的建议。performance-tuning会在你给它性能瓶颈描述时先做profile计划、再逐项优化而不是上来就推荐缓存。simplifying专门用来简化过度复杂的代码逻辑比较适合接手别人的烂摊子时用。updating-docs则会在你改完代码后自动检查并更新相关文档和README。最后一个值得提的是subagent-driven-development这是给支持子代理subagent的AI工具用的。它会把一个大任务拆成多个子任务分别交给多个子代理并行处理然后由主代理汇总结果。这个模式对长流程项目提升非常明显不过对项目的上下文管理要求也更高建议有一定经验之后再研究。4. 运行时机制与自定义技能写法4.1 渐进式披露是怎么工作的Superpowers的基础机制叫渐进式披露progressive disclosure。这句话听起来高级实际意思很简单不要一开始就把所有技能说明全部塞进上下文那样既占token又让模型无所适从。取而代之的是只在配置里给每个技能一个简短描述——名字、用途、何时调用。当模型发现当前任务和某个技能描述匹配时它才去读取该技能的完整内容。这就好比一本书的目录很短但你翻到对应章节时才会看到大量细节。这也是为什么Superpowers的每个技能文件都会在frontmatter里写一段清晰且带触发条件的description。描述写得好不好直接决定了AI能不能在正确时机调用它。比如debugging技能的描述里会提到当用户报告bug、崩溃、异常行为时使用这样用户说一句我这边登录失败了模型就会自动联想到它。理解了这个机制你就能明白为什么安装Superpowers之后日常对话里的响应会稍微慢一点——因为模型在决策是否要读取技能文件。这一点延迟非常值得换来的是一套完整的方法论而不是AI凭感觉发挥。4.2 技能文件长什么样一个标准的技能文件就是Markdown最顶部用YAML格式写元信息后面是正文指令。以我自己的理解结构大致是--- name: my-custom-skill description: 当用户需要XXX时使用比如遇到YYY问题 --- # 技能名称 ## 输入要求 在执行本技能前需要明确以下信息 - 问题描述 - 相关文件或日志 ## 执行步骤 1. 先复现问题 2. 收集上下文 3. 定位根因 4. 修复并验证 ## 输出格式 必须包含根因分析、改动内容、验证方式正文部分写的是给模型的详细指令相当于一个带上下文的提示词。你写得越具体、步骤越可执行模型输出就越稳定。相反如果你只写一句打开文件看看那效果和随便聊天没什么区别。Superpowers里的技能文本普遍很长有的多达上千词并不是为了凑数而是因为复杂的调试流程确实需要这么多细则来约束模型行为。你可以把技能文件类比为一个岗位SOP它不代替人的判断但能保证任何人或者任何AI按照它做事时下限不会太低。我以前总觉得AI写代码看运气后来发现只要把流程约束住输出质量基本都在可接受范围之上。4.3 写一个自己的review-changes技能理论讲完直接动手写一个。假设我想让AI在合入代码前做一轮轻量自查就创建一个review-changes技能文件放在技能目录下内容大概这样--- name: review-changes description: 在用户准备提交代码前对本地未提交的改动做一轮结构化检查重点关注安全性、边界条件和破坏性变更 --- # 工作流 1. 先运行 git diff --stat 了解本次改动范围。 2. 再运行 git diff 查看具体代码变更。 3. 逐个文件检查 - 有没有未处理的错误分支 - 有没有可能破坏现有功能的改动 - 有没有硬编码或敏感信息 4. 给出结论可以直接提交、需要修改后提交、或需要补充测试。写好之后保存重启AI工具然后随便改一行代码再让AI执行review-changes。如果描述写得准确模型会在你没点名的前提下自动选择使用它。第一次看到自己写的技能被AI自动调用时那种感觉还是有点爽的。不过也要提醒一句自定义技能不是写得越多越好。我试过一口气给AI塞十几个自造技能结果模型经常选错因为它们之间的边界不清晰。建议先维护三四个真正用得上的跑顺了再慢慢扩展。5. 实测中的行为变化与避坑记录5.1 开箱前后的行为差异装了Superpowers大约一周后我做了一次对比测试同一个Bug报告分别用空白Claude Code和带Superpowers的Claude Code来修。前者的响应是——看起来是空指针异常把user.id改成非空判断即可后者则是——这个问题可能涉及user对象在不同调用链中的生命周期我先复现路径再检查相关调用点最后给出修复方案。结果如何前者改完A文件测试又报错因为它没发现还有一个异步路径也会触发同样问题后者一次性改了两处并补了一个回归测试。这种对比不是说模型变聪明了而是Superpowers强迫它走了完整排查流程。尤其当你面对的是一个自己不太熟悉的老项目时这套流程的价值会进一步放大。另一个让我觉得值回票价的变化是AI不再那么爱拍脑袋了。以前它输出一个我觉得应该没问题的修复我总要多留个心眼现在它会主动在结尾写验证方式执行xxx命令预期输出yyy让我心里有底。这种结构化输出才是技能包真正的护城河。5.2 技能不触发的几个常见原因用了一段时间也踩过一些坑。最大的坑就是装完之后技能不生效AI根本不理那些技能。我复盘下来主要有几个原因第一是配置只对当前目录生效。有些AI工具的配置是按项目隔离的你在项目A里执行skilled create superpowers换到项目B就不认识了。别嫌麻烦在每个需要用的项目根目录都跑一遍或者把配置放到全局用户目录看工具的官方说明。第二是描述和实际指令之间的匹配问题。比如你自定义技能时description写得太泛AI就难以判断什么时候该用。碰到这种情况观察一下AI的回复如果它完全没有提到技能名称大概率是描述不触发。尝试把触发条件写得更具体比如当用户提供了一段报错日志并询问原因时使用。第三是更新之后技能没刷新。Superpowers仓库更新很勤我一开始用的版本和最新的技能名有差异导致模型想调用但找不到文件。定期跑一下skilled update然后重置一次AI会话确保技能包同步到最新。5.3 一些配置上的建议最后聊点配置层面的个人偏好。第一个建议是别一股脑把所有技能全开。Superpowers默认提供的技能列表很长但不是每个项目都用得上。比如你只是维护一个内部工具可能用不到canary-deployments和subagent-driven-development。技能太多会让模型在选择时出现犹豫反而影响效率。我一般会保留调试、规划、审查、TDD这几个和高频场景强相关的其余的等需要再说。第二个建议是把项目自身的规范写进自定义技能而不是靠口头提醒。比如我们团队要求所有API变更必须带兼容性说明我就写了一个api-change-checklist技能让AI在改动公共接口前强制检查。团队成员看到AI主动提醒自己写兼容性说明都觉得不可思议其实就是把SOP变成了自动流程。第三个建议是不要完全迷信技能输出。Superpowers能大幅提升AI的稳定性但它本质上是一套提示词方法论不是魔法。遇到特别底层的疑难问题该用perf工具、该看内核日志AI还是需要你提供材料。把它当成一个强制AI先思考再动手的护栏比把它当成万能修复工具要合理得多。我个人这几周的实际体会是Superpowers不是一个你需要完全掌握每个细节的工具你真正吃透一两个核心技能比如debugging和planning就能让日常开发产生肉眼可见的改观。等这套流程成为习惯之后再慢慢往里面加自己的技能你会发现AI编码工具从帮你写代码到陪你干活并没有那么难跨越。如果你也准备试试看建议先从一个小项目开始花半小时装上亲手感受一次AI先列计划再动手的感觉你会回来感谢我的。