最近有大半年时间我几乎每天泡在 Codex 里写代码。用得越久越发现这些编程助手有个普遍的毛病你让它改一个 bug它改完就结束同一个问题过两天再问它又是一副从没见过的表情。它不缺聪明缺的是“做事的章法”。后来我在 GitHub 上翻到 superpowers 这个开源项目看到三个词skills、drivers、commands才明白它想干什么——把 AI 编程助手从一个“对话窗口”改造成一个有方法、有流程、可复用的同事。superpowers 是一个技能框架作用很直接给 Codex、Claude Code 这类命令行编程助手批量安装“可复用技能”。每个技能由一份 SKILL.md 和配套的参考实现组成AI 会在合适的场景自动调用对应技能而不是每次临场发挥。它适合那些已经把 AI 编程助手当日常工具、但觉得它不够稳定、不够系统的人。这篇内容就围绕安装、核心技能、Java 项目实战和常见坑展开希望能帮你少走弯路。1. superpowers 是什么给 AI 编程助手装上“可复用技能库”1.1 名字很中二逻辑却很工程superpowers 直译过来是“超能力”听起来像中二病晚期。但看完它的设计你会发现思路非常工程化。整个项目可以拆成三块Skills、Drivers、Commands。Skills 是核心可以理解成岗位能力。比如调试、写测试、重构、代码评审、Git 工作流每一个都可以封装成一个技能。每个技能目录里必备一份 SKILL.md用统一的 frontmatter 格式写好技能名称和描述正文则写清楚这个技能在什么场景用、具体怎么做。AI 在对话中拿到任务后会根据描述判断要不要加载这个技能加载后按照里面写好的方法一步步执行。Drivers 是适配层。同一个技能要能在 Codex、Claude Code 等不同工具里跑就得做兼容。不同 CLI 的能力有差异比如 Codex 更适合长时间自主执行多步骤任务Claude Code 则更倾向逐步确认。Drivers 就是把差异封装掉让技能作者不用为每个工具单独写一套方法。Commands 是快捷入口类似给 AI 预设好的一批常用指令方便快速触发某个技能或组合流程。三块合在一起就组成了一套完整的“AI 工作方法论系统”。这个项目以开源方式维护社区里已经有大量现成技能可以直接安装。你不需要自己从零写先拿来用再慢慢改。1.2 技能为什么比提示词更靠谱有人会问我把一套调试方法直接写进提示词不行吗为什么还要额外装一个技能框架关键在于“动态加载”和“上下文代价”。假设你想让 AI 按 TDD 流程开发如果不装技能你得在每次新对话里重新写一遍“请你先写测试再写实现每写一个功能都要跑测试……”这段话会占用上下文窗口而且写多了容易走样AI 可能写到一半就忘了。装上技能以后你只需要说一句“按 TDD 帮我实现这个接口”AI 会自动去技能库里找 test-driven-development 技能读取 SKILL.md 里的步骤然后按标准流程执行。你不需要重复交代省下来的上下文全都可以用在真正的业务逻辑上。可以打个比方提示词像是把整个工具箱都背在身上重且乱技能框架像是给每个工具标好了抽屉AI 需要哪个就打开哪个抽屉。这个思路在实际使用中差别非常明显。2. 安装与环境准备按部就班十分钟搞定2.1 安装前置条件与完整流程安装 superpowers 前先确认三样东西能正常联网的终端环境、git、以及已经装好至少一个 AI 编程助手Codex、Claude Code 都可以。Node.js 不是必须但很多技能会用到 Node 脚本装上没坏处。安装流程不复杂核心就两步从 GitHub 仓库把项目克隆到本地。执行仓库里的安装脚本。安装脚本会扫描你机器上已安装的 CLI 工具列出检测到的 Codex、Claude Code 等询问你要为哪些工具启用技能集。用方向键选择、回车确认就行不需要手改配置。脚本执行完毕后技能默认会被放到~/.superpowers/skills/目录下同时脚本会把这些技能符号链接或复制到各 CLI 能识别的位置。这一步比较关键如果未来手动往~/.superpowers/skills/里加新技能最好也通过脚本重新同步一次而不是自己往 CLI 的配置目录里乱塞。安装完成后把 CLI 完全退出再重新打开让新技能被扫描到。第一次启动时可以手动执行一次任意指令确认技能目录能被正常访问。2.2 不同 CLI 下的配置差异与验证方法Codex 和 Claude Code 对权限的处理方式差别挺大这里单独提一下。如果你主要用 Codex我建议在进行有文件写入需求的任务时使用 full-access 模式或者至少给工作目录开足够的读写权限。原因是 superpowers 里的很多技能会生成计划文件、测试文件、修改源码权限不足时 AI 做到一半就会停下来问你“我能不能写这个文件”体验非常割裂。我自己实测下来full-access 配合技能使用是最顺滑的组合。Claude Code 本身有一套权限确认机制如果觉得每次授权太烦可以在项目里按需放开目录。核心原则是让 AI 有足够权限完成多步骤任务但别把整个系统目录都丢给它。验证安装是否成功两个办法在 CLI 里直接问一句话“你现在有哪些 superpowers 技能”检查~/.superpowers/skills/下面有没有一批技能文件夹。正常情况你会看到少则几十、多则上百个技能目录。看到这些目录就说明安装成功了。提示技能不是越多越好。AI 是根据技能描述来选技能如果同时装了几百个它选错的概率也变大了。建议先用核心技能跑熟之后再逐步扩大技能库。3. 核心技能拆解最值得优先用的六个能力3.1 debugging 与 root-cause-analysis把“头痛医头”变成系统排查调试是最常见的开发场景也是 superpowers 里最有价值的技能之一。没有调试技能的时候AI 遇到一个 bug 通常会直接看报错猜一个原因动手改然后跑一次失败就再猜。这种碰运气的方式在一两次能蒙对但遇到复杂问题就会陷入死循环。有了 debugging 技能之后AI 的行为会明显变化。它先要求复现问题写最小化复现用例然后逐步缩小范围用二分法定位到具体模块再提出假设、验证、修复、做回归测试。每一步都是结构化的有点像老医生问诊而不是蒙答案。root-cause-analysis 技能则是深度定位根因。它适合那种“表面修好了但换个场景又冒出来”的顽固问题。AI 会持续追问“为什么会出现这个现象”“为什么是这一层”“为什么之前没发现”把整个链路理清楚而不是只盯着最表面的报错。Java 项目里这两个技能特别好用。遇到 NullPointerException 或者偶尔出现的并发问题AI 会先把调用链、状态变更、异常日志串起来定位到具体哪一次调用产生了空值再顺着源头修复。我第一次看它这么干活的时候有种“这同事比某些真人靠谱”的感觉。3.2 writing-plans 与 test-driven-development动手前先把计划落地writing-plans 技能是我个人最爱。以前 AI 接到一个复杂需求经常直接开写写了三分之一发现方向不对再推翻重来浪费大量 token。有了这个技能AI 会先分析需求、拆解任务、生成一份执行计划按优先级排列然后才开始动手。这个技能的使用方式很简单你说“帮我实现一个用户积分功能”AI 就会先输出计划文档里面包含要建哪些文件、要做哪些步骤、怎么验证。你确认之后它再往下执行。计划本身是产物你可以随时检查、修改而不是黑盒式地等它写完一坨代码。test-driven-development 技能则强调了先写测试再写实现。它适用于功能开发也适用于修 bug。AI 会先写一个失败测试来复现问题然后写最小代码让测试通过最后跑回归。这套流程对工程质量的提升是实打实的尤其是在 Java 这种重测试的项目里效果比让 AI 直接写实现要好得多。我建议这两个技能搭配使用先让 writing-plans 出方案再让 TDD 落地实现。AI 会把“计划”和“执行”两件事分开不会一边写一边乱改方向。3.3 code-review 与 git-workflow把评审和提交也变成标准流程code-review 技能让你的 AI 变成一个不偏袒自己的评审人。它从代码正确性、边界条件、性能、安全问题、可读性等维度做检查输出一份评审意见。它不会直接改代码除非你明确要求这点很关键因为 AI 自己写的代码如果自己马上改常常陷入“自己写自己审”的盲区。git-workflow 技能用来规范化 Git 操作。包括生成符合规范的提交信息、创建分支、合入主干前检查变更范围、整理 commit 粒度。它特别适合多人协作场景能避免“fix bug”“update”这种毫无信息的提交信息。下面是这几个技能的一个速查表技能典型触发场景主要产出debugging测试挂了、线上报表bug、现象不明最小复现、根因定位、修复验证root-cause-analysisbug 反复出现、修复无效事件链路分析、根因结论、预防措施writing-plans新功能开发、大型重构任务拆解、执行顺序、验收清单test-driven-development新功能开发、bug 修复失败测试、最小实现、回归通过code-review合并请求前、完成代码后结构化评审意见git-workflow提交代码、开分支、准备 PR规范提交信息、分支操作流程4. 在 Java 项目里的实战从 Spring Boot 到重构旧代码4.1 用 superpowers 驱动日常 Java 开发的完整流程纸上谈兵没意思直接看一个 Java 场景在一个 Spring Boot 项目里新增一个订单查询接口。传统做法是告诉 Codex“帮我写一个订单查询 Controller带分页。”它大概率会直接生成一个 Controller、一个 Service、一个 Mapper看起来功能齐全但可能没有测试或者异常处理不规范。用 superpowers 之后我会这样说“用 TDD 技能帮我实现订单分页查询接口。”AI 的行为会变成先读取项目里的 pom.xml 或 build.gradle确认用的是 Spring Boot 版本、有没有 Lombok、测试框架是 JUnit 4 还是 JUnit 5。根据 writing-plans 技能输出一份简短计划创建哪些类、接口定义、测试策略。先写一个失败的测试文件比如 OrderControllerTest验证调用 /api/orders 返回分页结果。运行测试确认它是红的失败。按计划创建 Controller、Service、Repository补上实现。再次运行测试直到全部通过。这个过程里你几乎不用手动干预只要在关键节点上检查计划是否合理、实现是否符合项目规范。遇到测试编译不过或者依赖缺失AI 会自己调整 pom 配置并重新跑测试。省心程度直线上升。我自己的经验是Java 项目信息密度高、依赖关系复杂AI 单靠对话很容易在类名、包名、Bean 注入上绕晕。技能框架强迫它先做上下文检查、再写代码反而大大降低了出错率。4.2 把团队规范沉淀成自定义技能superpowers 最大的潜力不是用现成技能而是把你自己团队的项目规范、代码风格、约定俗成的写法沉淀成自定义技能。举个例子。你所在团队写 Controller 有很多硬性要求必须用 DTO 入参、必须加参数校验、异常统一由全局异常处理器捕获、返回值必须包一层 Result。这些规范靠口头传给 AI每次都会漏点东西。现在可以自己做一个技能。操作步骤如下在~/.superpowers/skills/下新建一个目录比如java-spring-controller/。在里面创建 SKILL.md。写一份参考实现代码作为 AI 的模仿样本。SKILL.md 的内容大致长这样--- name: java-spring-controller description: 当用户要求创建或修改 Spring 项目中的 Controller 时使用。强制使用 DTO 入参、Result 统一返回、全局异常处理不直接在 Controller 里写业务逻辑。 ---正文部分则写清楚具体流程比如“先确认是否存在对应 Service 接口”“按controller - service - repository的依赖方向组织代码”“参数校验使用 jakarta.validation 注解”等等。做完之后在 Codex 里说“按团队规范写一个用户注册接口”AI 就会自动调取这个技能按照规范来写。团队成员克隆同一个技能库之后大家用 AI 写出来的代码风格高度统一比任何文档都有约束力。这套玩法也特别适合团队共创把技能目录提交到 Git谁发现新的好实践就更新 SKILL.md其他人拉下来即可用。我甚至见过有人把安全检查、日志规范、数据库迁移规范都做成了技能AI 每次写相关代码时自动带着规范走。5. 常见问题与排查技巧实录5.1 新手上路最容易踩的五个坑技能没生效。这是出现频率最高的问题。多数原因是安装完之后没有重启 CLI技能根本没被加载。另一种情况是 SKILL.md 里的描述写得过于宽泛AI 判断不出来当前任务该用哪个技能。验证方法是直接问 AI “你有哪些技能”以及检查技能目录内容。权限不足导致执行中断。Codex 默认可能没有工作目录之外的文件写权限多步骤任务跑到一半就停下来问。解决办法是在任务开始前就切换到 full-access 模式或者把当前项目目录的权限放给 CLI。技能版本和 CLI 版本不匹配。superpowers 更新频率不低如果你的 CLI 版本太老兼容层可能出问题。遇到无法解释的怪现象先升级 CLI 和技能库到最新版。技能之间互相冲突。装了多个描述相似的技能比如 debugging、root-cause-analysis、troubleshootingAI 可能选错。建议把相似功能的技能合并或者禁用一个保留描述最精准的那个。AI 完全不按技能走。很多时候是因为你用的提示词不够明确。不要只说“帮我弄一下”要让任务意图足够清晰比如“用 debugging 技能定位并发问题”“先出 write-plans 再实现”。5.2 几个让效率翻倍的隐藏技巧技能可以组合使用效果远超单个技能。常见组合是“writing-plans TDD code-review”先出计划按计划写测试和实现最后评审结果。你在提示词里一次性带上这几个技能名AI 会自动串成一个流水线。善用异步后台任务。Codex 在多步骤执行时可以把任务拆成后台异步执行在等待测试跑完的同时继续处理其他文件。实测下来涉及改动多模块 Java 项目时这个机制能节省不少时间。把常用指令收进 Commands。如果你有反复使用的固定流程比如“清理代码并提交”可以用 Commands 机制预设好之后一键触发不用每次重复写提示词。定期清理技能库。技能装多了不是好事AI 在做技能匹配时的准确率会下降。每季度做一次清理关掉不用或重复的保持技能库精简。注意自定义技能里的参考实现代码最好选择真实项目中的优秀代码不要造伪示例。技能的本质是让 AI 模仿好的工程实践参考样例的质量决定了产出质量。最后再分享一点个人体会我用 superpowers 从好奇到真正依赖经历了一个很有感触的转变。最初我把它当成一个指令集看看它能跑通哪些流程直到有一天我回头看自己用 Codex 写的一个复杂模块发现它调用了计划、测试、重构三个技能整个实施路径清晰得像一个有十年经验的工程师在做东西我才意识到这个框架的真正价值。它解决的问题不是“AI 能不能写代码”而是“AI 能不能靠谱地写代码”。我真心建议第一次试用时先只启用三五个核心技能不要一口气全装。在一个真实项目里跑上两周形成肌肉记忆再慢慢增加技能、修改描述、沉淀自己的规范。工具只是框架真正的超能力是你对 AI 工作方式的理解和驾驭能力。
