1. 先搞清楚Superpowers 到底解决了什么问题先说个我自己的经历。去年有段时间我几乎每天都在跟 Codex 打交道用它写脚手架、补测试、修 bug。说实话单看单次问答它的表现已经很惊艳了可一旦进入完整的工作流——比如“新起一个模块、给它写测试、提交、再对接外部接口”——它就开始露怯。你让它写测试它就写几个样子货你让它做 code review它就挑点缩进和命名问题最让人崩溃的是你让它“按照刚才讨论的方案去实现”它转头就给你搞出一套全新的设计。直到我接触了 Superpowers 这个概念才意识到问题不在模型本身而在工作流的缺失。裸奔的 Codex 像是一个特别聪明但没人给他排日程的实习生你问什么它都能答但没人告诉它“接到需求先拆解、再写测试、再实现、最后自审”这套完整流程。而 Superpowers 干的事情就是把“实习生”变成一个“有职业习惯的工程师”给它装上一整套可复用的技能包让它知道在不同的任务场景下应该按什么顺序、用什么方法去做事。这套东西不挑语言。你写 Python、Java、Go、前端脚本它都能覆盖因为它本质上不是某个语言专属的框架而是一套“行为模式”的集合。所以像“codex superpowers”这个词条才会这么热——大家发现同样一个模型把这个技能包挂上去之后输出质量和工作完成度完全是两码事。适合谁来用我觉得只要符合以下任一情况都值得花一个下午折腾一遍你觉得 Codex / Claude Code 这类工具“单看回答还行但交给它一个完整任务就拉胯”你想让 AI 助手真正进入你的团队工作流而不是只当个高级问答机器人你受够了每次都要在对话里反复粘贴一大段提示词去“调教”AI想一次性把规范固化下来你在研究 AI 编程助手的进阶玩法想知道所谓的“技能包”“技能插件”到底是什么原理。接下来我尽量把安装、接入、实战和踩坑都讲透全文不会去抄官方文档而是站在“一个真正用它写了一两个月代码的人”的角度把那些文档里没写、得自己试出来的东西都说清楚。需要说明的是下面凡是涉及具体配置和操作路径的部分我基于当前主流的接入方式整理如果你看到的版本有变化以实际仓库和工具文档为准但整体思路不会变。2. 安装与接入我建议你按这个顺序来2.1 环境准备先确认你的 AI 助手支持“项目级指令文件”在动手装 Superpowers 之前你首先得搞清楚一件事你的 AI 助手是否支持从项目目录或全局目录读取指令性文件。以 Codex 为例它支持AGENTS.md这类项目级指令文件——放在项目根目录AI 在每次对话开始时就会自动读取把它当作“项目守则”。Claude Code 也支持类似的机制只是文件名和加载方式略有不同。这一点是整个接入方案的基石。Superpowers 的原理并不神秘它把大量沉淀下来的方法论怎么写测试、怎么调试、怎么提交代码写成结构化的技能文档然后通过AGENTS.md或等效机制让 AI 在开工之前先“读过”这些文档。AI 一旦知道了这些规则后面你再提需求它就会自动按技能包里定义的流程去执行。所以如果你的工具压根不支持这类指令文件那 Superpowers 的“自动生效”能力就无从谈起。好在目前主流终端型 AI 编程助手基本都支持这个机制你只需要确认版本够新即可。2.2 把 Superpowers 拉到本地两条路我推荐第二条第一种方式最粗暴直接把整个项目仓库git clone到本地之后要用哪个技能就把对应的文档内容复制粘贴给 AI。这种方式适合你只想零散地试用几个技能比如今天想让它按 TDD 流程写测试就把 TDD 的技能文档贴进去。第二种方式是正式接入把 Superpowers 的技能说明挂到你的全局或项目级指令文件中让它“常驻”在 AI 的上下文里。我最推荐这种方式因为它一劳永逸不用每次对话都手动粘贴。具体操作大致是这样# 1. 克隆仓库到本地某个固定位置比如 ~/.superpowers git clone https://github.com/superpowers/superpowers.git ~/.superpowers注意这只是示意路径。实际仓库地址以你搜到的官方仓库为准。克隆完成之后你会看到里面有一个skills/目录里面每个子目录就是一“个”技能。每个技能的核心是一个SKILL.md文件里面同时包含元信息描述frontmatter和技能正文。接下来要做的是把AGENTS.md技能总入口内容合并进你的指令文件。在 Codex 里全局指令文件一般位于~/.codex/AGENTS.md你也可以在某个具体项目里放一份AGENTS.md只作用于此项目。我的建议是先放到全局跑通之后再考虑按项目定制。2.3 接入 Codex 和 Claude Code 的差异点Codex 侧的接入比较直接全局配置放在~/.codex/AGENTS.md把 Superpowers 根目录里的总入口文件内容追加进去就行。这样每次启动 Codex它都会默认“看过”你装好的全部技能清单。Claude Code 这边思路一样但我个人实测有个细节值得注意Claude Code 对指令文件的读取策略更“俏皮”一些它会根据对话内容动态决定要不要参考某个技能文档而不是像 Codex 那样相对机械地全部加载。这个差异带来的结果是Superpowers 在 Claude Code 里不会占用太多上下文但偶尔也会出现“AI 没意识到该用某个技能”的情况。我的解决办法是在关键任务的提示词里显式点名请参考 TDD 技能包的流程来推进立刻奏效。至于你在网上看到的“worbuddy 怎么用 superpowers”这类问题思路其实是一样的。不管底层是 Codex、Claude Code 还是其他支持自定义技能目录的 AI 编程助手Superpowers 的对接逻辑都逃不出这个框架把技能文档放到 AI 能看到的位置再在对话中按需触发。工具可以换机制是通的。2.4 装完之后先跑一个“握手测试”别急着开干正事。装完之后我强烈建议先做一个简单测试确认技能真的被加载了。你可以随便挑一个小需求比如“帮我写一个 Python 函数从 URL 里解析出路径参数”然后在对话里问一句在动手之前先按你已加载的工作流告诉我你会怎么拆解这个任务。如果它像模像样地给出了“先明确输入输出、再写测试、再实现、再自审”这个流程恭喜你装成功了。如果它的反应和之前一样想都不想直接给代码那大概率是配置文件没生效。别急着往下走先检查指令文件是否放在了正确位置或者看看你的 AI 助手设置里有没有关闭“自动读取项目指令”这个开关。这个测试很便宜但能帮你省掉后面无数个“为什么它不听我话”的深夜。3. 核心技能拆解Superpowers 到底让 AI 学会了什么3.1 头脑风暴与计划技能从“直接写代码”变成“先对齐方案”Superpowers 里最容易被忽略、但我觉得最有价值的是它的brainstorming和writing-plans这两个技能。它们对应的不是某个具体编码动作而是“任务开始前的那一段思考过程”。比如你丢给 AI 一句话“帮我优化一下这个模块的性能。”没有技能包的情况下它可能会立刻给出几个优化点然后直接改代码。这在简单场景下没问题但一旦模块逻辑复杂改动牵一发动全身直接动手往往意味着灾难。而装上这个技能之后AI 会先和你确认你说的“优化”是指响应时间、内存占用还是代码可读性当前模块的瓶颈有没有数据支撑改动范围大概多大可接受的回归风险是什么说白了这个技能就是把一个资深开发者在动手前会做的“需求澄清”给模型化了。它逼着 AI 先问问题而不是先给答案。这套流程你平时可能会在心里默默完成但对于 AI 来说没有技能包的约束它默认的最优策略就是“最短路径出结果”而这恰恰是很多 bug 的来源。在实际项目里我一般会这样用凡是涉及改动范围超过一个文件的活儿我都会先让 AI 用这个技能输出一份简短的计划确认无误后再让它在计划框架内动手。你会发现最终代码质量和返工率都有肉眼可见的改善。3.2 TDD 工作流让 AI 先写测试再写实现这句口号终于落了地TDD测试驱动开发在人类开发者之间推行了很多年喊口号的人多真正严格执行的人少。但让 AI 执行 TDD 反而比人更靠谱——它没有“嫌麻烦”的情绪只要技能包规定了流程它就会老老实实地先写测试、跑测试、再看测试变绿、再写实现。Superpowers 的 TDD 技能大致规定了这样一套循环为需求确定一个最小可验证的功能点写一个会失败的测试Red运行测试确认失败原因是因为功能缺失而不是测试本身写错写最小实现让测试通过Green运行全部测试进行重构Refactor。你可能会说“这不就是教科书里的红绿重构循环吗”对就是它。但关键是这个流程不是“被建议”的而是被技能包固化成 AI 的默认行为。你不需要每次对话都写一遍“先写测试”它自己就知道该这么干。我自己的实测体验是用这个技能去给一个老项目补测试效果比手工写还好。因为 AI 不会像人一样带着“这个模块我熟”的偏见去写测试它会老老实实地按函数行为去枚举边界条件。有几回它甚至发现了我之前手工测试根本没覆盖到的边界 bug。不过有一点要注意AI 写的测试不一定完全符合你项目的断言风格。在让它批量补测试之前最好先给它一两个“你眼中的好测试”做范例能大幅减少后续返工。3.3 调试与排查技能从“瞎猜”变成“科学定位”调试这件事A 和 B 之间的差距大到离谱。普通 AI 拿到报错信息之后最常见的反应是“给你一段修改建议”然后你改了再试再报错再问它。一个下午就这么耗没了。Superpowers 的debugging技能完全换了一套打法。它要求 AI 按科学排查链路走先把错误现象“钉死”——是编译错误、运行时错误还是逻辑错误在什么输入下触发建立假设但要先验证假设再动手改代码加日志或二分法缩小范围而不是一上来就重构确认修复后还要回头检查同类模式避免“只修了这一个点隔壁还有个一模一样的坑”。我最喜欢的是最后一条。之前遇到过多次这样的情况AI 帮我修好了一个 null 指针异常过两天我在另一处代码又踩了同样的坑。有了调试技能之后它在修复完成时会多做一个“同类问题扫描”等于把一次排查的成果放大到整个代码库。这恰恰解决了大家对 AI 编程助手最大的抱怨之一“单点提问很强但遇到真正难缠的问题就抓瞎。”不是模型变聪明了而是它终于有了一个正确的排查方法论。3.4 Git 工作流与自动化收尾让 AI 把活干完整很多人让 AI 帮忙改完代码就完事了commit 信息写得随意分支乱成一团更别提 code review。Superpowers 的git-workflow技能补齐的正是这个“收尾环节”。这个技能一般包含几个动作分析当前改动范围、生成符合规范的提交信息、检查是否误改了无关文件、甚至可以在分支合并前自己先做一轮 review。它不只是“把 git 命令背熟”而是把一套团队协作规范压缩成了可执行步骤。举个例子在我接入了这个技能之后AI 在提交代码时不再写“update code”这种空话而是会结合 diff 内容生成类似“在解析模块中增加对查询参数的编码检测并补充对应单测”这种信息量饱满的提交说明。这不是因为它学会了审美是因为技能包里明确规定了“好提交信息”的结构做了什么、为什么做、影响范围是什么。如果你的项目已经有提交信息规范比如 Conventional Commits也可以在技能基础上再加一层自定义规则。这部分的接入不需要改 Superpowers 本体你在自己项目的 AGENTS.md 里补充规则即可我后面会专门说。4. 实际用起来之后的经验与避坑4.1 技能不生效我踩过的三个坑第一个坑是放错了指令文件的位置。Superpowers 的总入口文件如果你放到了系统全局目录但你实际工作又在某个特定项目里AI 同时会读取全局和项目两份指令文件。正常情况下两者是叠加的但如果项目里的AGENTS.md写了“忽略全局技能类指令”之类的话那技能就会莫名其妙失效。排查方法很简单在对话里直接问 AI“你现在能参考哪些技能”它能说出来就说明加载成功支支吾吾就说明配置有问题。第二个坑是版本差异。AI 编程助手迭代速度极快我有一个月没更新本地 Codex CLI结果新版本的指令加载策略变了技能一直静默失败。AI 助手是“会学习”的但它的宿主工具不会自动帮你维护技能仓库所以每隔一段时间记得git pull更新技能包。第三个坑是技能之间互相打架。最典型的例子是 TDD 技能和“快速原型验证”类技能同时加载时AI 可能不知道该听谁的。我自己的解决办法是在总入口文件里给技能设置优先级说明比如注明“原型探索阶段优先走快速验证流程进入稳定实现阶段后必须切换到 TDD 流程”。4.2 如何让技能适应你自己的项目习惯Superpowers 默认给出的是通用方法论但每个项目都有自己的脾气。比如有些团队提交信息要求带 ticket 号有些项目单测规范的命名习惯不一样还有些项目禁用了某些语言特性。这时候你不需要去改 Superpowers 仓库里的文件因为一更新就会被覆盖。正确做法是在项目根目录的AGENTS.md里写一个“覆盖规则”小节明确说明“以下规则优先级高于技能包默认行为提交信息必须带上 JIRA 编号测试文件命名统一为 test_xxx.py生产代码禁止使用全局可变状态。”AI 具备基本的规则消解能力当项目级指令和通用技能发生冲突时它会优先听更具体、更贴近当前场景的那一份。这其实也解释了为什么 Superpowers 能从一个个人工具扩展到团队协作每个人装同样的技能包但在不同项目里看到的 AI 行为可以完全不同。4.3 Token 消耗和性能不是装了技能就能白嫖我得说点泼冷水的话。Superpowers 不是魔术它本质上是一大堆高质量文字AI 要把这些文字先“读”进去才能输出对应的工作流。如果你把几十个技能全部挂到全局指令里每次对话的上下文开销都会变大对应的 token 费用也会上涨。我实测过把所有技能全量挂在全局的情况下一个中等复杂度任务的 token 消耗大约会增加一到两成。但交付质量和返工率的改善对我来说远cover掉这点成本尤其是在 TDD 和调试这种“免返工”场景下。如果项目对上下文非常敏感建议按需加载而不是全量挂载。你可以把技能文件留在本地磁盘但不放进全局指令。需要某个技能时在对话里发一条指令让 AI 自行读取对应技能文档。这类“按需拉取”的用法对节流效果尤其明显。5. 进阶玩法自己写一个技能包给 AI 定制超能力5.1 技能包到底是个什么样的文件结构理解了技能包的本质之后你完全可以自己写一个满足团队特定需求的技能。技能包的文件结构并不复杂核心就是一个SKILL.md文件开头的 YAML frontmatter 里写上技能的名称、描述、适用场景正文里则用清晰的 Markdown 段落描述这个技能“应该怎么做”。我举个例子。假设你想给 AI 定义一个“发版检查清单”技能要求它在每次准备发布时自动检查十项内容--- name: release-readiness description: 在版本发布前自动执行发版检查清单确保没有遗漏关键步骤。 --- # Release Readiness 技能 当执行发版检查时你必须按顺序完成以下步骤 1. 检查数据库迁移脚本是否存在且可回滚 2. 检查所有环境变量在配置中心有对应项 3. 检查 changelog 是否更新版本号是否提升 4. 运行完整测试套件确认无失败用例 5. 检查关键依赖是否有已知安全漏洞公告 6. 抽查最近 20 条提交确认没有调试日志或临时代码混入 7. 确认构建产物在干净环境下可复现 8. 对照部署文档逐项确认是否还有未执行的步骤 9. 生成发布摘要列出本次变更重点和风险点 10. 将检查结果汇总输出如果有失败项必须停止发版操作。 如果用户没有明确跳过某个检查项不得擅自取消检查。这样写完之后把这个目录放到skills/下再在总入口文件里加一行“本环境内置发版检查技能遇到发版任务必须调用”你的 AI 助手就从“会写代码的工具”变成了“懂发版流程的工程师”。5.2 自己写技能和直接修改提示词有什么区别很多人会问我直接在对话里把这段流程粘贴给 AI效果不是一样吗短期看确实差不多但长期看差异巨大。你每次手动粘贴本质上是把规则放在“对话上下文”里——这只对当前这一轮对话生效而写成技能包规则就沉淀到了项目的知识体系里每一次新的对话、每一个新加入的成员、甚至是换一台电脑你的 AI 助手都能自动继承这套行为规范。更关键的是技能包是可以版本管理、评审、迭代的。你在和 AI 的对话里随手写的一句话不会有人帮你 review 有没有逻辑漏洞但写进SKILL.md之后你的同事可以提 issue、可以改进措辞、可以补充边界条件。这个“方法论资产化”的过程是普通提示词完全做不到的。我现在的工作习惯是任何让 AI 重复执行超过三次的任务都值得花二十分钟把它固化成技能包。一次投入长期回报。5.3 把技能机制搬到团队里的通用思路如果你的团队还没用上这种 AI 工作流你可以先从一次小型试点开始。找一个仓储型项目把AGENTS.md和两三个核心技能包放进去让团队里最愿意折腾 AI 的同事先跑两周。这两周的任务不是追求效率而是收集 AI 行为与团队预期不一致的地方逐步把“团队潜规则”显性化到技能文件里。等这套规则成熟之后再考虑推广到全员。你会发现团队成员之间对 AI 工具的使用差异会急剧缩小因为大家用的是同一套“工作逻辑”。新人也更容易上手——他不用靠猜来理解“我们团队是怎么用 AI 的”读一遍技能目录就知道个大概了。最后分享一个我自己的小习惯我会把每个技能包里的文件都当作“码农写的文档”来对待太抽象的地方通通不合格必须写到一个“从没接触过这个项目的新人”照着做也能完成的程度。这样写的技能包AI 和人类都能看懂团队的隐性经验才能真正变成结构化资产。Superpowers 给我的最大启发不是“AI 变强了”而是“方法可以被封装”。那个封装的过程其实比模型本身的进步更值得我们花时间去打磨。