说实话，我从去年就开始重度用AI写代码，快是真快，但不靠谱的时候也是真让人头大——明明就问它一个小问题，它能自信地给出一版完全跑不通的方案，还顺手把项目里三个无关文件改了。最近我一直在折腾一套叫superpowers的技能包，它原本是给Claude Code准备的，后来我花了半天把它也装进了Codex CLI，实测下来AI的行为模式变化非常明显：写代码前会先规划，写之前会先写测试，出了bug会按步骤排查而不是直接瞎猜。这篇文章是我完整的使用记录，包含superpowers是什么、怎么安装、核心技能怎么用、有哪些坑，适合所有正在用AI编程工具、想让AI真正像工程师一样干活的人参考。
1. superpowers到底是什么，为什么值得装
1.1 它本质是一套“经验固化的技能文件”，不是玄学
superpowers这个名字听起来很中二，翻译过来就是“超能力”，但它是个正经的开源项目，作者是Jesse Vincent，最初在Claude Code生态里以插件形式分发。它的核心是一堆按工程场景组织的技能文件：调试、测试驱动开发、代码审查、项目规划、需求拆解、子任务协调等等。每个技能不是几行提示词，而是一套完整的操作方法，包括什么时候该用、具体分几步执行、每一步要满足什么条件、结束前要检查什么。AI在干活的时候，读到这些文件，就像是拿到了一本老工程师写的操作手册，按手册来而不是自由发挥。
以TDD技能为例，它的SKILL.md大概长这样：
--- name: tdd description: 当需要实现新功能或修改现有功能时使用 --- # 测试驱动开发 ## 何时使用 - 需求已明确 - 需要编写新代码或修改现有行为 ## 操作步骤 1. 将需求拆分为最小行为单元 2. 为每个单元编写失败测试 3. 运行测试确认失败（红） 4. 编写最简实现 5. 运行所有测试确认通过（绿） 6. 在测试保护下重构这种设计跟你平时写“请你先写测试再写代码”有本质区别。你用提示词要求AI，它可能这次听，下次就忘；但把TDD的完整流程写成技能文件挂在项目里，AI每次进入相关任务时都能读到，而且执行完一步会主动停下来检查结果，再决定下一步。我用了之后最直观的感受是：它不再像那种“你说一句它动一下”的实习生，更像一个手里拿着checklist的靠谱工程师。
1.2 它解决了AI编程里几个很真实的痛点
先说说AI编程最常被吐槽的三个问题：
第一个是AI太“自信”。你问它一个API的用法，它能把不存在的参数说得头头是道；让它改bug，它瞄一眼就动手，改完你发现别的地方又坏了。这种幻觉问题靠模型升级解决得有限，但如果让它按技能要求“先复现、再验证、再修改”，出错概率会明显下降。
第二个是缺乏工程纪律。AI没有“写代码→跑测试→看结果→重构”这个肌肉记忆，经常跳过验证环节。我见过太多次AI直接甩出一大段代码，里面包裹着一堆没用的边界处理，但关键逻辑反而是错的。superpowers把工程纪律拆成了具体步骤，AI每走一步都要确认结果。
第三个是不可复现。这次让它用正确方式解决问题，下次开个新会话又放飞自我。技能文件是实体文件，可以做版本管理，可以跟着项目走，一次调教，长期复用。团队场景更值，因为superpowers是文件形态，直接放仓库里，所有成员的AI工具读同一套技能文件，相当于把个人经验变成了团队规范。
适合谁也很明确：如果你只是偶尔用AI查个资料、写个临时脚本，那用不上它；但如果你每天在IDE或终端里用AI写业务代码、修bug、做重构，尤其是多个项目并行，强烈建议试试。
2. 安装与配置：Claude Code原装、Codex CLI移植的完整步骤
2.1 Claude Code原生安装：一条命令就能装好
Claude Code是superpowers的“原配”，装起来最简单。在Claude Code对话里执行插件安装命令：
/plugin install obra/superpowers装完之后，Claude会提示你选择要导入哪些技能到当前项目。这里我的建议是第一次先全选，跑几天之后再根据自己项目特点精简。导入之后，项目里会出现一个技能目录，里面是技能文件副本。从这一步开始，Claude在项目里处理任务时，会读取这些技能文件并在相应场景调用。
要注意Claude Code插件的加载依赖项目级别的配置文件（比如CLAUDE.md），如果你之前自定义过CLAUDE.md，最好检查一下里面有没有跟技能文件冲突的指令。比如你以前写了“改代码前不要问问题直接动手”，这就跟Brainstorming技能的精神正好相反，AI可能无所适从。我遇到过这种情况，最后是把CLAUDE.md里那些跟技能互相矛盾的旧规则清掉了，AI的行为才回归正常。
验证是否生效有个很土但有效的办法：直接问Claude“请复述一下TDD技能的操作步骤”。如果它能把红-绿-重构的流程清晰说出来，并且提到要“先写失败测试”，说明技能已经被加载。如果它只会泛泛回答，那大概率是目录配置问题，看后面第4章的排查部分。
2.2 Codex CLI移植安装：把技能注入AGENTS.md
Codex CLI没有一键安装superpowers的命令，但社区已经摸索出了通用做法，核心思路是：把superpowers的技能目录复制进项目，再在AGENTS.md里明确告诉Codex什么时候去读哪个技能文件。我实测的步骤是这样：
git clone https://github.com/obra/superpowers.git mkdir -p your-project/.superpowers cp -r superpowers/skills your-project/.superpowers/然后在项目根目录创建AGENTS.md，写清楚技能读取规则：
# 项目AI助手使用指南 在开始任何编码任务前，请先阅读 .superpowers/skills/ 下与任务类型对应的技能说明。 例如： - 实现新功能前：阅读 TDD 技能，按红-绿-重构流程执行。 - 排查 bug 时：阅读 Debugging 技能，按复现-假设-验证的步骤排查。 - 接到复杂需求时：阅读 Brainstorming 技能，先拆解问题再动手。 执行过程中，每完成一步，向用户汇报当前结果，再继续下一步。Codex CLI默认会读取AGENTS.md作为项目级指令。你在对话里让它实现一个功能，它会先想到去读TDD技能文件，然后照着里面的流程走。这里要提醒一下，Codex对技能文件的读取不是绝对强制的，取决于模型对指令的遵循程度，但实测下来，只要AGENTS.md写得足够具体，大部分时候它都会照做。
如果想让某个技能全局生效，可以把对应SKILL.md的内容精简后合并到用户目录下的AGENTS.md里，但我不太建议这么做，因为全局文件的权重太高，容易让所有项目的行为都变得僵化。比如你全局挂了Debugging技能，AI去处理一个压根不需要调试的文档任务，也可能先给你列一串排查步骤，很啰嗦。
2.3 Codex CLI的权限与沙箱设置：这一步很多人会漏
Codex CLI执行shell命令时有权限控制，配置文件一般在这个位置：~/.codex/config.toml。TDD流程里最关键的“运行测试”这个动作，如果被沙箱或授权策略挡下来，整个红-绿循环就断了。所以安装superpowers到Codex之后，第二件事就是检查测试命令能不能正常执行。
以pytest为例，你可以在config.toml里把测试命令加入允许列表，或者把授权策略调成更宽松的模式，让AI能直接跑测试。我在最开始移植的时候没注意这层配置，结果TDD技能生效了，但AI每跑一次测试就弹出一次授权请求，来回折腾了十几次，体验非常糟糕。调好授权之后，AI能自己跑测试、看输出、改代码，整个流程就顺畅多了。
2.4 配置生效前的好习惯：三连确认
配置加载完之后，我习惯做三件事确认没白装。第一，检查技能文件路径确实存在，AGENTS.md或插件配置里写的是相对路径而不是错路径，这一步能排除90%的“没生效”问题。第二，开一个新的AI会话再测，避免旧会话缓存了没有技能的上下文。第三，用任务验证：故意丢一个小bug给AI，看它会不会先复现、再生成假设、再修。这三步走完，基本能确定superpowers是否真的在工作。
3. 核心技能实战拆解：TDD、Debugging、Brainstorming怎么用
3.1 TDD技能：让AI先写测试再写代码，实测效率不降反升
TDD技能是我用下来收益最大的一个。经典流程是红-绿-重构，superpowers把它拆成了可执行步骤：第一步，把需求拆成最小行为单元；第二步，为这个行为写一个测试，运行它，预期失败；第三步，写刚好能通过测试的最简代码；第四步，运行全部测试确认通过；第五步，在测试保护下重构，去掉重复和坏味道。
跟不对AI做任何技术约束时对比，差别很明显。没有技能时，我让AI写一个工具函数，它一上来就写完整实现，附带一堆我没要求的边界处理，代码看起来很完善，但核心逻辑反而可能踩空。有TDD技能后，它会先写断言，先跑红，再补实现。我自己在项目里实测，用TDD技能时AI写的代码一次通过的几率明显提高，因为测试相当于先把需求定死了。代价就是过程看着麻烦一点，多跑几次测试，但这种“麻烦”换来的是不用半夜起来修线上bug。
有一点需要特别说明：AI执行TDD时，必须给它运行测试的能力。在Claude Code里要允许工具调用shell命令，在Codex CLI里要确保测试执行命令在你的授权允许范围内。否则AI跑不了测试，红-绿循环就断了，它只能口头上“假装”写了测试，这是一个非常常见的坑。
3.2 Debugging技能：AI排查bug终于不再靠猜
Debugging技能解决了我最大的一个痛点：AI修bug全靠猜。没装superpowers之前，我给AI描述一个报错，它经常直接给出一版重构代码，改了文件名、改了函数签名，最后连问题出在哪都没搞清楚。superpowers的Debugging技能逼着它按顺序做：先精确复现问题，再列出所有可能原因，按可能性排序，用最小改动做实验，每做一步都收集反馈。
举个我实际遇到的例子。有个并发问题，只会在特定数据量下出现。以前让AI看，它分析半天直接说“加个锁就好”。但按Debugging技能的流程，它会先问我要复现脚本，然后缩小数据规模，确认临界条件，检查共享变量的访问路径，最后才提加锁方案。这个过程的产物不只是一个修复，还有一份“为什么会出现”的记录。即使这次修错了，排查路径也是可追踪的，后续可以继续往下挖。
这个技能还带一个我个人很喜欢的习惯：它在操作步骤里要求AI记录“已排除的原因”。好处是防止AI在同一个坑里来回打转，你也能随时看到它排除了哪些分支、还剩哪些可能，整个排查过程对你是透明的。对于团队协作来说，这份记录可以直接丢给同事看，比自己脑补“AI怎么修的”强太多了。
3.3 Brainstorming技能：把模糊需求拆成可执行任务
Brainstorming技能特别适合需求还很模糊的时候用。AI最怕的就是用户一句“帮我优化下这个模块”然后直接动手改。这个技能要求AI先提出一组问题：这个功能给谁用？输入可能有什么边界？跟现有模块的交互在哪？数据不一致的时候怎么处理？先把问题列出来，再结合你的回答生成方案，最后才进入编码阶段。
我自己用过一次印象很深：有个老项目的登录逻辑，我想让AI帮忙重构，但只给了一句“把登录流程理清楚”。没装技能之前，AI大概率直接开始重写接口。装技能之后，它先列了五个问题，比如“现有的session过期策略是什么样的”“第三方登录是否保留”“失败尝试次数限制在哪里配置”。我逐条回答完，它给的方案基本一次通过测试。这种体验是普通提示词很难逼出来的，因为问题清单本身就是工程经验的体现。
superpowers里的writing-plans技能也值得提一下，它要求AI把大项目拆成阶段，每个阶段有明确的可验收结果。我用于一次项目重构，AI按技能模板输出了一份分三步的实施计划，每一步都附带测试点和回滚方案。这种结构化的规划能力，属于思维方式的差异，不是简单堆提示词就能达到的。
4. 我踩过的坑与排查技巧：一篇避坑速查
4.1 装完不生效：先查路径，再查会话缓存
“装了superpowers，AI却完全没有技能化行为”是大家问得最多的一个问题，我自己也踩过。一次是路径写错了，技能目录在.superpowers/skills下面，我却在AGENTS.md里直接写了.superpowers/，AI找不到具体的SKILL.md文件，自然学不会。另一次是上下文缓存，老会话还在运行，新配置没被加载进去。
解决办法就两条：第一，检查AGENTS.md或插件配置里指向的路径是否精确到技能文件那一层；第二，关掉旧会话，新开一个会话再试。如果还不生效，可以在AGENTS.md里加一句“当任务是代码修改时，必须先阅读对应技能文件再行动”，用更强的指令提示让模型优先走技能流程。还是不行的话，直接把某个技能文件的核心步骤贴进对话里当上下文，虽然粗暴，但管用，能帮你确认问题到底出在文件配置还是模型执行上。
4.2 多个技能互相干扰：明确任务边界和优先级
技能之间也会打架。TDD技能强调先写测试，Brainstorming强调先提问，如果同时触发，AI有可能行为漂移。我自己遇到过AI在一个已经明确实现方案的任务里，还非要先列一堆“假设性问题”，然后又跳到写测试，折腾了半天。
我的处理原则是：在配置里写清楚任务类型和技能之间的映射关系。比如“当用户明确描述需求细节时，直接进入TDD流程；当需求描述模糊、有多处开放选项时，先执行Brainstorming”。如果是团队共用一个技能仓库，最好由技术负责人统一维护这份AGENTS.md，不要每个人都各写一套，否则同一个项目里不同会话的行为可能完全不同，别人接手时会很崩溃。
4.3 与MCP工具、Agent模式的协同：互补关系大于冲突
有朋友问superpowers和MCP是不是重复了。我的理解是：MCP是给AI接外部工具——数据库、浏览器、文件系统，解决的是“AI能碰到什么”的问题；superpowers是给AI接工程方法论，解决的是“AI应该怎么干活”的问题。两者完全不冲突，反而互补。
实际用法上，我经常让AI先读Debugging技能，再通过MCP工具去查日志、查数据库，最后综合信息给结论。Agent模式或subagent技能同理：复杂任务拆给子Agent并行跑，每个子Agent再套用superpowers的TDD或调试技能，整体质量更可控。要注意的是，子Agent能不能读到技能文件取决于临时上下文内容长度，如果子Agent窗口有限，可以只给它传对应的单个技能文件而不是全部技能目录。
4.4 维护与更新：技能文件不是装完就一劳永逸
superpowers的技能文件本身会随着项目更新，建议定期把远程仓库的最新版拉下来，对比看看有没有你需要的增量。更重要的是，你完全可以在社区版本基础上增加自己的技能文件——我就在项目里加过一个专门针对“数据库迁移脚本审查”的技能，写清楚了迁移脚本必须包含回滚方案、必须经过灰度验证等团队规范。这种技能日常使用频率极高，AI每次处理迁移类任务都会自动读到并要求自己遵守，比在评审会上反复强调有效得多。
写在最后的体会
这套东西用了两三周之后，我最大的感触是：superpowers不是哪项技能特别神，而是它把“AI应该先思考再动手”这件事变成了结构化的流程。以前我靠人盯人式地给AI下指令，累而且不稳定；现在技能文件一挂，AI自己知道什么时候该写测试、什么时候该排查、什么时候该停下提问。如果你也在折腾AI编程，建议别满足于“能跑就行”，先装一套superpowers，只开TDD和Debugging两个技能，用半个月再对比一下AI写出来的代码质量。到时候你就明白，superpowers这个名字，不是虚的。
