1. superpowers到底解决了什么问题先说结论如果你已经在用 Codex CLI、Claude Code 这类 AI 编程工具但总觉得 AI 写代码“脑子跟不上手”——让写就写改个需求就推倒重来复杂一点的跨文件改动动不动改崩一片——那 superpowers 就是冲着这个痛点来的。1.1 为什么普通的“AI 帮我写代码”不够用我最早用 AI 编程工具的时候体验大致是提一个需求它哗啦啦生成一坨代码我看着好像挺对一跑就报错。让它改它再糊一版。来回几次代码里已经堆满了补丁式的 if 分支和临时变量比我自己手写还难维护。为什么因为大多数 AI 编程工具的本质是“单轮对话驱动的代码生成器”它没有项目上下文、没有执行计划、没有验证步骤更没有一个“发现问题后如何收敛”的兜底机制。你要让它开发一个功能它不会先问清楚边界条件不会先考虑现有架构怎么融入更不会主动写测试来证明自己写的东西是对的。它只是按概率把下一个 token 预测出来仅此而已。1.2 superpowers 的工作哲学技能不是命令是流程superpowers 的思路完全不一样。它不是一个“更强的代码生成器”而是一套**技能包skills**体系。每个技能是一个带明确指令的 SKILL.md 文件定义了某一类工作的完整流程。比如“头脑风暴”技能会引导你先把需求聊透“写计划”技能会要求它产出一份可执行的分步计划“TDD”技能会强制它先写测试再写实现。说白了它是给 AI 装了一套“工作方法论”。就像你带了一个新人你不指望他第一次就写出完美代码但你希望他拿到需求之后知道先问什么、先做什么、怎么验证。superpowers 就是把这套“带人流程”固化成了 AI 能读、能执行、能按顺序调用的指令集。这套东西最早是 Jesse VincentPerl 社区那个 obra开源的核心文件就躺在 GitHub 仓库里全部是 Markdown没有任何魔法。它支持的也不只是 Codex CLIClaude Code、Roo Code 这类支持 skills 机制的终端型 AI 工具都能用。最近国内不少人在 Trae Work CN 里折腾怎么挂载这套 skill说明它已经不局限于某一个工具了。2. 安装前置条件给 superpowers 一个能跑的家说句实话我见过很多人在装 superpowers 的时候卡住不是因为项目本身难装而是前置环境没准备好。它本质上是一包“让 AI 按流程工作”的指令文件必须寄生在一个支持 skills 机制的 AI 编程工具里。所以第一步不是装 superpowers而是确认你的“宿主”够不够新。2.1 Codex CLI 的安装与初始化如果你走的是官方推荐路线那宿主就是 Codex CLI。它是 OpenAI 出的命令行编程代理跑在终端里能读你的仓库、调你的编辑器、执行命令。装它之前有几个硬性条件你得先确认Node.js 版本不能太低建议 18 以上20 LTS 最稳本机要有可用的终端环境Windows 用户建议直接用 Windows Terminal 而不是老旧的 cmd你得有一个能访问 Codex 服务的账号并且完成 CLI 登录。安装命令很简单一行搞定npm install -g openai/codex装完以后先跑一下codex --version能输出版本号宿主就位了。然后进行初始化登录codex login它会拉起浏览器完成 OAuth 授权。这块要注意登录成功以后Codex CLI 会把这个会话信息存在本机配置里后续用的时候不要反复登出登入否则容易触发风控。2.2 验证运行环境与模型配置环境装好之后别急着装 superpowers先随便提一个简单问题验证整个链路通不通codex 用 python 写一个阶乘函数它能正常回复说明网络、认证、模型调用这些底层环节都是好的。如果这一步就挂了得先排查代理、网络策略或者账号权限因为大概率不是 superpowers 的问题。还有一点Codex CLI 支持通过配置文件指定模型。不同型号的模型对复杂指令的执行能力差异非常大我建议至少用 Codex 系列里偏强的那档模型便宜的老模型在跑多步骤 skill 流程时经常“中途失忆”——前面让它做的计划写到后面就忘了。3. 安装 superpowers 的完整步骤前置环境没问题之后安装 superpowers 本身其实很快。官方仓库里有两种装法一键脚本和手动 clone。两条路我都走过分别说下适用场景。3.1 官方一键脚本安装官方推荐的方式是直接跑安装脚本curl -sSL https://install.superpowers.dev | bash执行完这个脚本它会把整个技能包下载到你用户目录下的~/.superpowers文件夹里。这个文件夹里装的是所有技能的定义文件以及配套的 agent 定义、工作流模板。装完之后脚本一般会提示你下一步需要去~/.codex/config.toml里确认相关配置有没有被自动写入。这个方式最省心适合第一次装、不想跟文件结构较劲的人。脚本会做几件事拉取最新仓库、把 skills 目录放到约定位置、在 Codex 配置里注册技能路径。整个过程一两分钟失败率很低。3.2 手动 clone 方式的适用场景与目录结构如果你是想改技能包源码、甚至自己往里面加技能的进阶玩家建议手动 clonegit clone https://github.com/obra/superpowers.git ~/.superpowers手动装的话你需要自己处理两件事一是把技能目录告诉 Codex CLI二是确认 Codex 的 skills 开关是开着的。打开~/.codex/config.toml里面至少要有类似这样的内容[skills] enabled true superpowers_path ~/.superpowers/skills这里有一个我在社区里反复看到的问题很多人手动 clone 之后忘了改superpowers_path导致 Codex 一直报“找不到 skills 目录”。如果你也是手动装的装完第一件事就是打开配置文件看一眼路径对不对。3.3 在 Trae Work CN 中挂载 skills 的注意事项最近不少人在搜 Trae Work CN 安装 superpowers skill这块我也顺手测过。Trae Work CN 本身支持 skills 机制但它的技能目录和 Codex 不在一起。你需要把~/.superpowers/skills里的技能文件复制或者软链到 Trae 的 skills 目录下。我建议用软链而不是复制原因很简单superpowers 这个仓库更新很勤作者会经常调技能的提示词和流程你用软链的话每次git pull之后 Trae 里自动就是最新版复制的话每次更新完你还得手动再拷一遍极易遗忘。具体软链命令在 macOS/Linux 下是ln -s ~/.superpowers/skills /path/to/trae/skills/superpowersWindows 下没有直接等价命令可以右键目录创建符号链接或者干脆复制一份毕竟你是手动更新仓库的话多复制一份也没多大事。4. 核心技能包拆解每个技能都在什么时候派上用场装好只是开始真正需要花时间的是理解这套技能包在设计上是怎么分层的。很多人装完只会用“让它写代码”这一个对话入口那和没装区别不大。4.1 brainstorm 与 planning开工前的两次深呼吸superpowers 流程里最容易被跳过、但恰恰最值钱的两个技能就是 brainstorm头脑风暴和 writing-plans写计划。我见过太多人——包括以前的我——让 AI 干活的时候上来就是一句“帮我实现一个 XX 功能”然后 AI 直接开写。问题是什么需求里的歧义太多了。“用户登录”这四个字在不同项目里含义完全不同是 JWT 还是 Session刷新逻辑要不要第三方 OAuth 接不接错误提示做到什么程度AI 一旦在模糊需求下开写后续的返工基本是注定的。superpowers 的 brainstorm 技能强制 AI 在动手前先做一个“需求澄清会话”它会主动向你提问把边界条件、约束、异常场景都问清楚甚至会把几个可能方向摆出来让你选。你会发现一个神奇的变化AI 从“你说一句它写一坨”变成了“你说一句它问三句”。这不是它变聪明了而是技能文件里就是这么写的——它必须走完这个对话流程才能进入下一步。等需求聊透了再调用 writing-plans 技能让 AI 把整个实现过程拆成分步计划每一步包含文件路径、改动内容、验证方式。这一步的作用是强制 AI 在动手前把整个地图画完而不是走一步看一步。我实测下来这个计划文件简直是无价之宝——后面执行出任何问题你都可以回头对着计划看是哪一步跑偏了。4.2 TDD 与 subagent-driven-development让 AI“自己检查作业”计划写完进入执行阶段。superpowers 在这里的设计尤为激进它默认的工作流是先写测试再写实现。这其实就是 TDD测试驱动开发的工程实践被固化成了技能指令。TDD 技能会要求 AI 针对计划里的每个功能点先写出失败用例然后跑一次测试确认用例确实是失败的这叫“验证测试的有效性”再写实现代码直到测试通过。这一套流程人为跑都觉得麻烦让 AI 跑反而成了优势——它不嫌烦它只是以前没人要求它这么干。subagent-driven-development 就更进一步了它会让主导的 AI agent 把具体开发任务拆给子 agent 去做每个子 agent 只负责一个文件或一个模块的改动主导 agent 负责审查和集成。这就像项目经理把活分给不同工程师每个人提交代码后项目经理做 Code Review 再合并。好处是每个子 agent 的上下文窗口都很干净不会被整个项目的无关文件干扰主导 agent 又能保持全局视角防止各个子 agent 的改动互相打架。4.3 troubleshooting 与 pre-flight出问题时的兜底机制写代码不可能不报错。superpowers 里专门有 troubleshooting故障排查技能定义了 AI 面对报错时的一整套排查流程先复现、再定位、查日志、缩小范围、验证修复、回归测试。它相当于强制 AI 用“结构化排障法”而不是“瞎猜法”来工作。pre-flight 技能则是提交代码前的最后检查。它会要求 AI 站在“马上就要发布”的角度审视改动有没有没删掉的调试代码有没有硬编码的敏感信息测试覆盖了哪些分支配置文件改对了没这些检查项不是靠 AI 的“责任心”而是靠技能文件里写死的流程一步步执行出来的。我个人的感受是troubleshooting 和 pre-flight 这两个技能单拎出来任何一个都值得长期使用。因为人类工程师最容易在一天高强度工作后犯低级错误而 AI 是从来不累的让它做机械式的逐项检查反而是它最擅长的事。5. 从“装了”到“会用”一种更高效的协作模式技能包备齐之后真正的问题在于你的工作习惯能不能跟得上。很多人装完之后依然是“需求一句话、代码一大片”的用法那就等于买了个工具箱但只用螺丝刀捅人。我下面用一个完整的功能开发流程演示一下正确姿势长什么样。5.1 会话启动时如何召唤技能superpowers 的技能调用有两种方式一种是你直接在对话里点名比如请使用 brainstorm 技能和我一起理清这个需求的细节。另一种是它根据你的描述自动匹配技能。不同版本的 Codex CLI 对自动调用的策略不太一样早期版本是偏自动的后来版本慢慢改成偏保守宁可不调也不乱调。所以最稳的方式还是你在会话里主动指示它调用哪个技能。有几个高频启动话术你可以直接拿去用“用 brainstorm 技能我们先把需求聊透。”“整理一份实施计划用 writing-plans 技能。”“按 TDD 流程实现这个功能先写测试。”“跑一下 pre-flight检查这次改动有没有问题。”这里有个技巧你不需要一次只调一个技能。官方设计的完整流程是 brainstorm → writing-plans → TDD → subagent-driven-development → pre-flight。你可以在一开始就说“请按标准流程处理这个需求”它会自动走完整个技能链。5.2 一次完整功能开发的对话流拆解我拿一个真实场景举例给我的博客系统加一个“文章浏览量统计”功能。第一轮我输入用 brainstorm 技能我要给博客加一个浏览量统计功能。它会开始提问一系列问题“浏览量是每个用户访问都加一还是需要去重”“需不需要展示热门文章排行”“统计维度是只按文章维度还是按天归档”“要不要做防刷限制”这一轮对话结束一个模糊的需求已经变成了可执行的规约。第二轮我输入计划没问题用 writing-plans 技能生成实施计划。它会产出类似这样的分步计划新增views.py定义浏览量记录的模型新增views_middleware.py在每次文章详情请求时触发计数编写test_views.py覆盖正常访问、重复访问、并发访问三个场景修改详情页模板展示浏览量运行全量测试确保旧功能不受影响。第三轮我输入按这个计划用 TDD 流程实现。它就会先去写测试用例跑失败再实现逻辑再跑测试直到通过整个过程它会自己循环不需要你每一步都催。第四轮功能跑通了我再输入run pre-flight它会对整个改动做收尾检查确认没有把测试文件里的临时数据写进数据库、确认没有硬编码用户 ID、确认接口没有暴露不必要的信息。你会发现整个流程里我作为一个“甲方”只干了提需求和做决策两件事剩下全部由技能流程驱动。这才是这套东西真正值钱的地方——它让 AI 从“写代码工具”进化成了“带流程的开发者”。5.3 什么情况下不需要用 superpowers但我也得说句公道话不是所有场景都适合上全套技能。一个典型例子是你只是想改一个按钮的颜色、调一个 CSS 间距、或者加一个文案。这种平凡改动如果也走 brainstorm → plan → TDD 的完整流程纯属杀鸡用牛刀。你光等它问完那一堆需求问题自己手动改都已经改完了。正确做法是小改动直接普通对话让它改改完自己肉眼验证一下只有涉及多个文件、有业务逻辑、需要长期维护的功能开发才启动完整技能链。这样安排你是用它的方法论管住复杂项目而不是让简单任务被流程拖死。6. 安装与使用中频繁踩坑的排查记录每次有新工具出来社区里最常见的声音就是“装完了不好用”“为什么我的不行”。我在各个群里观察了很久superpowers 的“翻车”案例基本逃不出下面几类。我把它们按出现频率排个序你对照排查能省下半天时间。6.1 模型能力不足导致技能“失效”最隐蔽也最坑的一种就是表面上看技能都装了、也都调用了但输出质量非常差计划写得很空洞测试用例没有覆盖关键分支改着改着把前面的计划忘了。根源基本都在模型选择上。superpowers 的技能文件本质是“高负载的上下文指令”它对模型的指令遵循能力和长上下文保持能力要求很高。如果你用的模型偏弱它读得懂“要写计划”这句话但执行起来就像实习生背了流程却不知道每个环节该怎么深挖。我的建议很直接这类场景别心疼钱用你账号里能调用的最强模型。一次复杂功能开发的 token 消耗相比它帮你省下的返工时间完全不值一提。6.2 skill 文件未被识别时先查会话开关与版本这种情况的表现是你明确说了“用 brainstorm 技能”但它完全无视你的指令或者回复“我现在无法使用这个技能”。排查链路其实很短按这三步走基本能定位第一步确认宿主工具的 skills 功能是开着的。Codex CLI 在某一段较新的版本里默认关闭了自动技能调用你需要去config.toml里确认配置没问题第二步确认 superpowers 的技能目录能被找到。手动安装最容易在这里踩坑——路径写错、没有权限、目录名不对都会导致加载失败第三步确认你的 Codex CLI 版本够新。技能机制本身也在迭代旧版本可能根本不认识这些新目录结构。如果你已经用了一两个月没升级先更新再说npm update -g openai/codex这套排查顺序是“先看配置、再看路径、最后看版本”不要一上来就怀疑技能包坏了。superpowers 仓库本身维护很活跃真有重大 bug 半天之内就会被社区喷爆不太可能是它的锅。6.3 与 AGENTS.md、MCP 共存时的优先级混乱还有一个进阶坑。很多人不是裸用 Codex CLI仓库里既有 AGENTS.md项目级 AI 指令文件又配了 MCP 服务还装了超多个 skills。这几个信息来源如果不一致AI 就会陷入“到底听谁的”的混乱。我遇到过的情况是项目 AGENTS.md 里写了“所有文件改动必须附带变更日志”但 superpowers 的执行计划里没有这一步结果 AI 在走完技能流程后压根没更新日志被 CI 流程拦下来。问题看起来像是 superpowers 不听话实际上是 AGENTS.md 和技能流程之间缺少一个“统一指令口”。我的解法是在 AGENTS.md 里显式写一条“所有工作必须遵循 superpowers 工作流”然后在技能调用时再口头强调项目的特殊要求比如“执行计划里加上变更日志更新步骤”。相当于在两层指令之间搭一座桥AI 就不会精神分裂了。7. 关于 superpowers 使用边界的一些个人体会写到这我想说点纯主观的东西。superpowers 不是万能药它改变不了模型的智力上限。模型本身不够强再好的技能流程也只是“把烂活干得更有条理”而已。但反过来讲模型能力到位之后决定 AI 产出质量上限的反而就是这个流程框架了。这就像一支球队球员个人能力再强没有战术体系场上还是踢成一盘散沙。我用了几个月最大的感受是它改变了我对“用 AI 写代码”这件事的预期。以前我觉得 AI 是个“高级自动补全”它更多地像一个插上流程就靠谱的初级工程师。你不需要永远盯着它看但它每一步干了什么、下一步打算干什么你随时都能打开计划文件看清楚。这种可追踪性带来的安心感比它偶尔写出一段惊艳代码更值得。如果你现在还在“AI 写代码一时爽上线之前火葬场”的循环里真心建议把这套技能包装上耐着性子走完一个完整流程试试。前面可能会觉得对话轮数变多了、效率变慢了但等它把一套复杂功能稳稳当当跑通、测试全绿的时候你会发现——之前的“快”都是假快。