你有没有遇到过这种情况同一个AI编程助手在别人手里像开了挂一样从需求到测试一条龙产出到了你手里却像个记性很差的新同事——上次聊过的技术选型忘了刚约定好的代码风格转头就破坏改一个bug还能顺手带出两个新bug。区别往往不在模型本身而在于你怎么用它。最近我在看一个叫superpowers的开源工具它就是专门治这种AI编程体验分裂的。简单说这东西把一套结构化的工作技能装进 AI 编程助手比如 Codex CLI、Claude Code让助手自带测试驱动开发、自动创建子代理、跨会话记忆、任务分解这些能力。标题里的 superpowers 不是动画里的超能力而是一整套让 AI 从聊天机器人变成有职业素养的结对程序员的增强层。如果你搜到过 superpowers 使用指南、superpowers 安装、甚至 codex superpowers 这些热词那这篇文章基本就是为你写的我会从安装、核心机制、到 Java 项目里的实测配置和踩坑完整过一遍。1. 为什么松散对话式的AI编程让人抓狂Superpowers想解决的顽疾先聊一个所有重度用过 AI 编程助手的人都会有共鸣的场景你打开 Codex CLI让它写一个订单导出的功能。它写得挺快几分钟给你一整段代码。但当你要求基于这个功能再加一个定时重试机制它可能会把原有逻辑推倒重写当你指出这个错误处理跟项目里其他模块不一致它一脸无辜地道歉然后给你一个同样不符合规范的新写法。问题的根子不在模型能力而在对话形态。模型的上下文窗口再大也是一次会话内的临时记忆。项目配置、编码规范、团队约定、历史决策这些东西如果没有被主动喂给模型它就是靠猜。猜对了是运气猜错了是常态。更要命的是同一个问题每次会话都要重新解释一遍效率全耗在对齐上下文上。1.1 嘴上说记住实际上什么都没记住我曾经在一个 Java 项目里反复要求 AI 用 Lombok 减少样板代码它每次答应用完就忘。原因很简单那句要求只存在于某一次对话的上下文里下一次会话没人提它就不存在。你需要的不是一个记性更好的AI而是一个能把约定持久化存储、每次自动加载的机制。这正是 Superpowers 这类工具的核心切入点。1.2 从单次聊天到可积累的工作台Superpowers 的思路其实特别朴素把 AI 编程助手当成一个员工来培养。员工需要什么需要岗位职责说明书、团队工作手册、以及一本可以往前翻的工作日志。对应到 Superpowers 里就是三样东西子代理subagents定义各自的专职角色策略文档strategies约束工作流程记忆系统memory沉淀跨会话的项目信息。这套东西放在一个项目仓库里AI 每次启动时自动加载相当于把散装对话升级为结构化工作台。当时我看到这个设计的第一反应是这不就是给 AI 写 SOP 吗但把 SOP 落到实操层面、还能让 AI 主动执行这件事的价值比想象中大得多。因为大多数人的 AI 用法还停留在问一句、答一句的线性模式而 Superpowers 提供的是目标 流程 记忆的闭环。2. 安装前的几个判断环境依赖与版本兼容如果你搜到过superpowers 安装这个热搜词说明你已经知道有这么个东西卡在第一步了。安装本身不难但我建议先做好三个判断省得后面反复折腾。2.1 判断一你的Node环境是否达标Superpowers 是 Node.js 生态的工具底层依赖较新的运行时特性。官方通常要求 Node.js 20 及以上版本最好用 22 LTS。这个要求卡住了不少人——很多老项目环境还停在 Node 16 或 18跑 npm install 会直接报 engine 校验错误。我的建议是先检查当前版本node -v npm -v如果版本不够用 nvm 装一个干净的 Node 22 并切换过来不要直接覆盖系统级 Node。nvm 的好处是可以按项目切换版本不影响别的开发任务。我自己的经验是Superpowers 尽量跑在隔离的环境里别跟公司统一管理的旧工具链混在一起。2.2 判断二你想搭配哪个AI编程助手Superpowers 目前主流的搭配对象是 Codex CLI 和 Claude Code。从热词里能看到 codex superpowers 是高频搜索说明很多人是冲着 Codex CLI 来的。Codex CLI 是 OpenAI 出的终端编程助手支持在命令行里以会话方式完成编程任务Superpowers 可以以插件或增强层形态挂载到 Codex 上。选择依据其实很简单如果你日常已经用 Codex CLI 用得顺手那就直接挂 Superpowers如果你用的是 Claude Code也有一键集成方式。两个都试过之后我的体验差异主要在模型代码风格上工具链本身没有明显的谁优谁劣。提示在安装 Superpowers 之前先把 Codex CLI 装好并完成登录认证。否则后续首次联动会卡在认证环节容易被误判成 Superpowers 的问题。2.3 安装三步走整体流程就三步克隆仓库、安装依赖、注册集成。git clone https://github.com/obra/superpowers.git cd superpowers npm install装完依赖后项目里一般会有一个交互式安装脚本或 install 命令作用是把自己的子代理目录、策略目录、记忆目录注册到 Codex CLI 的配置里。运行后它会检查你本机是否已有 Codex CLI并把相应配置写入你的用户配置目录。装好以后随便在一个项目里启动 Codex CLI输入类似你现在有哪些可用的技能这样的提示词如果能看到 Superpowers 加载出来的策略和子代理列表就说明挂载成功。这一步是很多新用户会跳过的验证环节——装完不验证等真正用的时候才发现没挂上又得回头排查。3. 核心机制拆解子代理、策略文档与跨会话记忆理解了安装接下来最关键的是搞懂 Superpowers 的三个核心机制。很多人装上以后觉得也就那样其实是因为没有把这几个机制的作用弄明白用起来自然摸不到门道。3.1 子代理给AI配一组专职同事子代理subagents是 Superpowers 最立竿见影的特性。它允许你在一个任务里创建多个专职子代理每个子代理有独立的职责描述、行为准则甚至输出格式。比如写一个功能时可以让一个子代理负责分析需求另一个负责设计测试用例另一个负责实现代码再由一个负责 code review。对应到本地文件系统就是项目里有专门的子代理配置文件每个文件用 Markdown 描述职责。我会固定维护一套通用子代理模板让 AI 在需要时自动调用。用生活化类比理解以前你只有一个啥都会一点的实习生你得把每件事的上下文塞给它。现在你有了一组各有专长的工程师你只需要说目标它们内部自动拆解和协作。实际体验下来子代理在复杂任务中的价值不是并行提速因为最终还是要按顺序推理而是每个代理可以把上下文聚焦在自己的职责范围内减少信息干扰输出质量明显更稳。3.2 策略文档把团队规范写进AI的工作流如果说子代理管人策略文档管流程。策略文档是 Markdown 格式的指令文件定义了 AI 处理任务时应该遵循的工作流。比如核心的 TDD 策略要求 AI 在写任何功能代码之前先写失败测试、再跑测试、再写实现、再重构。用生活化类比策略文档就像公司的开发流程规范不是让你想着遵守而是当你开工时系统自动把规范文件塞到你面前并且要求你逐条执行。对 AI 来说这就绕过了临时叮嘱的失效问题把流程变成了启动条件。我自己最常用的是三条一是 TDD 强制策略保证测试先行二是提交信息规范策略让 AI 生成的 commit message 符合项目的 conventional commits 约定三是代码审查策略让 AI 在收尾阶段主动扮演 reviewer挑自己的毛病。3.3 跨会话记忆AI的长期工作日志记忆系统是拉开使用体验差距的关键。Superpowers 把项目的关键决策、已解决的问题、常用命令、用户偏好等信息存到项目的 memory 目录。每次新会话启动时AI 会主动读取这些记忆做到上次聊到哪、这次接着来。记忆的写入可以手动也可以让 AI 自动沉淀。比如你在会话里说这个模块以后都用 constructor 注入不要用 field 注入AI 可以把这条约定写进记忆文件下次新会话提到相关模块时它就能直接遵守。这里有一个使用习惯需要刻意培养每当对话里出现一个以后都不该再犯的教训时主动让 AI 把它写入记忆。时间越长你的记忆文件就越像一本项目血泪史AI 也越懂你的口味。这才是 Superpowers 真正越用越值钱的地方。机制没装 Superpowers装了 Superpowers跨会话上下文每次从零开始自动加载记忆和项目约定任务分工用户反复交代职责自动创建专职子代理测试保障写完代码随口问要不要测TDD策略强制先测后码代码规范每次重复描述仍可能违约策略文档持续约束行为4. Java项目中的实测TDD工作流与代码生成看到热搜里有 superpowers java我就知道很多人在搜 Java 场景能不能用、怎么用。我自己主力语言就是 Java这部分重点展开实测过程和配置方式。4.1 先构思一个可复现的Java场景为了写这篇体验我搭了一个最小的 Spring Boot Maven JUnit 5 项目目标是让 AI 实现用户注册接口包含参数校验和单元测试。我故意不提供任何实现细节只把需求描述清楚然后观察 Superpowers 在 Java 场景下的实际反应。任务描述我写成了这样一段提示词请使用TDD方式实现用户注册接口。要求 1. 先写失败的单元测试 2. 再实现Controller和Service 3. 运行测试直到全部通过 4. 最后进行一次重构消除重复代码在裸 Codex CLI 下这个提示词很容易被执行成直接生成全部代码然后象征性地补两个测试。但装好 Superpowers 之后AI 会严格按照 TDD 策略执行先输出测试类然后主动调用 Maven 运行测试看到红叉后再生成实现类再跑测试直到绿灯最后还会主动跑一遍编译确认重构没有破坏行为。这就是策略文档的约束力。它不是建议而是 AI 任务执行链条上的一个环节跳过会被视为未完成任务。4.2 Java场景的三个实测亮点第一个亮点AI 会自动用 MockMvc 而不是只测 Service 层。这其实超出了我的提示要求原因是策略文档里写了一句Java Web 项目的测试应包含 Controller 层集成验证。它读到策略后自动选择了更完整的测试方式。第二个亮点编译错误驱动修复AI 不猜了。Java 是强类型语言编译器给出的错误信息非常明确。Superpowers 的调试子代理拿到 Maven 编译报错后能精准定位是类型不匹配还是缺少注解不会像以前那样反复生成看起来差不多的代码。第三个亮点重构阶段真的会主动做。TDD 流程的最后一步AI 检查了 Controller 里的校验逻辑发现有几个重复的字段校验主动抽取了一个 validator 方法并且重新跑了一遍全量测试确认没有回归。4.3 Java场景的配置注意点如果你也想在 Java 项目里用这套工作流有几个实际配置要注意。一是确保项目的 pom.xml 有明确的可运行测试命令AI 默认会通过 mvn test 跑测试如果你用的是 Gradle一定要在策略文档里写明用 gradle test否则 AI 可能每次都跑错命令。二是在记忆文件里记录下 Java 版本和编码规范比如项目使用 Java 17禁止使用 Java 8 的 Date这类描述能显著减少 AI 生成过期 API 的概率。三是给 AI 设置一个编译慢的预期先生成代码、再一次性验证而不是改两行就跑一次 Maven否则等测试结果的时间比写代码还长。5. 踩坑实录安装失败、上下文爆掉与策略打架好东西也有脾气。我前后试了几天遇到的坑集中在这几类安装卡住、上下文窗口爆掉、策略之间互相冲突。逐个说清楚排查思路你遇到了能少走弯路。5.1 安装卡在npm install先查Node版本最典型的报错是 engine not satisfied。如果你的 node -v 显示 v18.x 或 v16.x基本就是这个原因。别急着升级系统 Node用 nvm 安装 Node 22然后在 Superpowers 目录下 nvm use 22 再重新 npm install。如果 npm install 网络慢尝试换 npm 镜像源但注意不要全局替换建议在项目级 .npmrc 里配置。装完以后一定要跑一次自检命令确认所有技能文件都被正确注册到了 Codex CLI 配置里很多奇怪问题其实都出在装上了但没挂上。5.2 上下文爆掉精简策略和记忆Superpowers 的代价是每次会话要加载一堆策略文档和记忆。项目一大、策略一多对话刚开始就可能提示上下文超过限制。具体表现为AI 开始忽略你后半句的指令或者回答明显简短走样。排查思路分三步先看加载了哪些文档把不常用的策略移到不加载目录再精简记忆文件只保留决策结论不要保留大段讨论过程最后调整 Codex CLI 的上下文设置或把任务拆分成更小的会话。我的原则是策略文档不超过10个每个不超过100行记忆不超过50条超过就合并删减。5.3 策略打架明确优先级和触发条件策略之间冲突是更隐蔽的坑。比如安全审计策略要求所有入参必须做校验快速原型策略又要求减少不必要的防御代码两条策略同时加载时AI 就会左右摇摆一会儿加校验一会儿删校验。解决办法是在策略文档里写明触发条件和优先级。比如给每条策略加一个适用范围开头说明本策略仅在包含认证逻辑时启用再给整体策略目录加一条总规则多条策略冲突时以更具体的策略为准。我改成这个写法之后AI 的决策明显稳定了不再出现自己推翻自己的怪现象。5.4 不要忽视版本更新带来的破坏性变更Superpowers 本身迭代很快某次 git pull 之后可能会发现配置结构变了、子代理命令名变了。我踩过一次版本更新后旧的策略文件名识别不到了AI 自动执行 TDD 的流程突然失效。排查半天才意识到是新版只读*.strategy.md后缀而我用的是*.md。所以强烈建议每次更新后留意 CHANGELOG 或者 release notes更新完跑一次基础的技能自检确保核心策略仍然被加载。别相信更新一定向前兼容这类快速迭代的工具经常不保证。6. 把它变成日常武器养成AI工作流的最佳实践到了这一部分假设你已经装好、也跑通了一个 demo。接下来是怎么把它真正用成日常开发的一部分。我实践下来的核心心法是不要一上来就追求大而全而是从一个痛点开始迭代出属于你自己的技能包。6.1 第一步先只加项目约定一个策略刚开始不用装一堆策略。我建议第一个策略就写项目的基本约定构建命令、测试命令、代码风格、目录结构、禁止事项。让 AI 每次会话都自动遵守这些约定你很快会感受到不用反复重复自己的爽感。这个策略的价值在于建立信任AI 的输出越来越贴近项目实际你才敢放心让它承担更复杂的任务。我在 Java 项目里做的第一件就是这个后续所有向导式的体验都建立在这个基础上。6.2 第二步引入TDD策略把质量关卡前置当项目约定稳定运行后再引入 TDD 策略。这一步的收益不是帮你写更多代码而是逼着 AI 把测试当成一等公民。实际使用中你会发现有了 TDD 约束之后AI 生成代码的错误率明显下降因为它在写实现之前已经先定义了预期行为相当于自己给自己规定了必须跑通才能交卷。我在两个项目里对比过没有 TDD 策略时AI 生成的代码会有一些看起来对但边界处理有问题的情况引入 TDD 策略后因为先写了失败测试AI 的实现会被测试牵着走边界情况反而处理得更好。6.3 第三步逐步沉淀项目记忆让它越用越懂你随手记是记忆系统最好的使用方式。每次对话中出现了以后不要用 X 这种写法这个模块的 Y 是核心逻辑这类信息都可以让 AI 写入记忆。时间长了你的记忆文件会形成一幅项目知识的活地图。我个人最喜欢的操作是让 AI 在完成一个大任务后主动把本次决策原因 未来可能影响追加到记忆文件。这样每完成一个模块项目知识就沉淀一层。三个月下来AI 对本项目的理解深度远超任何新建会话的冷启动效果。6.4 第四步把子代理变成可复用的团队编制子代理不要随意堆我建议按角色划分稳定维护几个需求分析代理、测试设计代理、实现代理、审查代理。每个代理的职责边界要清晰避免内容重叠。代理不在多在于每个都好用。用生活类比自己你带的团队有明确分工你才敢把任务往下派。子代理也一样清晰的职责描述决定了它在复杂任务里能不能扛住压力独立产出高质量内容。最后分享一个我实测下来的体会装上 Superpowers 后我最大的变化不是 AI 一次能写完多少代码而是 AI 的行为模式从快问快答变成了按工作流推进。它开始会自己跑测试了会自己写记忆了会自己找自己代码的毛病了。这种体验升级比单纯换一个更强的模型来得实在。 如果你也打算在 Java 项目里试我的建议很简单先装好 Codex CLI再套一层 Superpowers然后从一份项目约定策略开始。跑两周回头对比一下你会明显感觉到AI 编程助手从一个需要时刻盯着的实习生变成了一个讲规矩、记得住、还能自己验收的靠谱同事。