最近我发现，身边用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技能，然后先引导你提供日志、系统版本、复现步骤，再逐步缩小范围。整个过程不再是"即兴发挥"，而是照着一套成熟流程走。
这里要注意区分两个概念：MCP（Model Context Protocol）给AI的是"工具"，比如读取数据库、发HTTP请求；Superpowers给AI的是"方法论"，比如怎么排查问题、怎么拆解任务。两者可以共存，但解决的是完全不同的东西。我身边不少朋友在纠结要不要装一堆MCP服务器，其实很多时候缺的不是工具，而是流程。
2. 动手安装：三分钟先跑起来
2.1 先搞定Skilled CLI
Superpowers的官方推荐方式是通过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 CLI，Superpowers本身也是一个开源仓库，完全可以手动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-development（TDD）这个技能，估计不少人愿意为它单独装一套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先列计划再动手的感觉，你会回来感谢我的。
