最近经常被工作群里的朋友问到一个东西Superpowers。问法五花八门有问“这是不是又一个人工智能套壳应用”的有问“它和我现在用的编程助手有什么区别”的还有直接甩过来一句“安装教程发一下”。我一开始也以为又是哪个博主流行的名词包装直到自己动手在项目里用了一周才发现这玩意确实值得单独写一篇长文拆开讲。我个人理解Superpowers不是又一个聊天窗口也不是大模型本身而是一套运行在AI编码工具之上的“技能框架”。它解决的问题非常具体为什么AI编码助手有时候很强有时候又很蠢为什么同一个模型换个项目就仿佛失忆答案往往不在模型参数里而在我们怎么组织它的工作方式。Superpowers把“让AI先思考再动手”“让AI按测试驱动开发的节奏写代码”“让AI在动手前先做方案评审”这类工程纪律打包成可加载的“技能包”让你的编码助手像带上了完整的项目方法论而不是只会顺着你的话往下接。这篇文章会从定位、安装、技能机制、Codex和Java项目实战、踩坑经验这几个维度展开把我这一周多真实可复现的过程梳理出来。适合已经在用或准备用Claude Code、Codex CLI这类终端编码工具的开发者阅读。1. Superpowers是什么它把“随机的AI对话”变成“有章法的工程协作”1.1 从“万能生成器”到“可编排的执行者”很多人第一次接触AI编码工具时的体验是兴奋第二周体验下降一个月后变成“这模型怎么这么不听话”。原因不复杂大模型默认行为是“你说什么我回什么”它不具备稳定的工程流程意识。比如让它修个bug它可能直接改一行代码就收工不写测试不解释影响面也不知道要先把问题复现出来。看起来能干活但干活的方式非常随机。Superpowers的思路是用一套“技能包”把执行流程固定下来。你可以把技能理解为提前写好的、结构化的协作指令里面包含特定的思考步骤、输出格式和工作纪律。模型在收到任务时不再直接给结果而是先根据当前项目启用的技能走一套规定的动作。比如“先定义问题—再列出方案—然后写出最小复现—再进入修复循环”。这一套流程下来输出质量自然比“裸用”模型稳定得多。我把它理解为“给AI编码助手装了一套的SOP”。模型还是那个模型但工作方式变了。1.2 和MCP、插件、提示词工程的核心区别这里有三个概念容易被搅在一起MCP、插件、提示词工程还有Superpowers这种技能框架。我的理解如下表概念解决什么问题特点提示词工程在单次对话里让模型表现更好一次性、不稳定、靠经验插件给工具增加外部功能入口偏功能扩展不强制流程MCP让模型能够调用外部工具和数据源偏连接能力不管工程方法Superpowers在编码工具之上叠加多套工作方法强流程、可复用、按项目场景加载所以它不是替代MCP那种连接层也没有去重造一个IDE。它更像脚手架帮助你给同一个AI内核挂载不同的工作模式写新功能时进入“TDD工作流”改老代码时进入“评审优先工作流”需要设计时进入“头脑风暴工作流”。这种灵活性是普通插件给不了的。1.3 适合谁、不适合谁如果你已经在用命令行的AI编码工具觉得“能用但不够稳定”或者你希望团队里的AI协作方式有一个统一规范这很适合你。反过来如果你只是偶尔用AI写一段脚本不想维护任何流程和配置文件那现阶段完全不需要上Superpowers。它的收益建立在“高频使用项目复杂度足够高”之上。给个人玩具项目用反而会觉得繁琐。2. 安装与初始化让开发机第一次“获得超能力”的完整路径2.1 前置条件检查我建议你先确认以下几项免得装到一半卡住操作系统macOS或Linux最顺畅Windows下可以用WSL原生PowerShell环境可能会有路径问题。Node.js版本建议18以上。技能框架底层要跑不少JS脚本老版本容易报语法错。终端编码工具目前主流支持的是Claude Code像Codex CLI这一类也有接入方式。先确保其中一个能正常对话。Git某些技能模板会读取Git提交记录来生成变更日志没有Git的话部分功能会退化。我不建议你在还没搞清楚自己终端工具是否支持插件机制的情况下强行安装。先跑通一次对话再往上加技能框架排查起来会省事得多。2.2 在Claude Code中完成安装具体安装命令要以你拿到对应版本时的官方仓库为准因为这类框架迭代很快命令形式可能调整。我在实际环境里采用的是“插件目录挂载”的方式大致路径如下进入你的项目目录确认当前目录是Git仓库。在Claude Code对话窗口里执行插件安装指令指向Superpowers对应的插件标识。安装完成后重开对话窗口让它重新加载插件配置。执行初始化命令例如在对话中输入/init-superpowers或类似命令目的是为当前仓库创建技能目录。有一点必须提醒如果你在多个项目里重复安装它会为每个项目单独生成一套技能文件。这个设计很重要晚点我会详细说。2.3 初始化项目工作区时到底发生了什么安装完初始化时你会看到终端里多出一个带结构的工作区目录。以我常用的项目为例项目根目录下会出现一个隐藏配置目录里面划分了技能、记忆、模板等子目录。这实际上是在做一件事把AI的“长期记忆”和“临时对话”分离。普通对话里模型只能依赖上下文窗口里的信息窗口一滚动前面聊过的东西就忘了。Superpowers通过磁盘文件把关键的项目背景、技能选择、代码规范固定下来每次新开对话时AI会主动去读取这些文件而不是等你好心提醒它。这是它能保持工作一致性的根本原因。我在第一次初始化后做了个测试故意在一个新对话里不描述任何项目背景直接问它“我们项目现在的测试命令是什么”。它读取了工作区里的项目记忆文件准确给出了当前项目的测试命令。这体验确实比“每次都要重新交代背景”舒服太多。2.4 验证是否生效装完别急着干活先做三步验证在对话里故意输入一个模糊请求例如“看一下这个仓库的问题”看它是不是会先整理范围再动手而不是直接给结论。查看技能目录里是否已经生成了默认技能模板文件。再问一次“当前项目启用了哪些技能”正常情况它会列出几条技能名称和对应用途。如果以上都没反应大概率是插件没有正确加载。先检查安装命令是否在项目根目录执行再确认工具的插件权限是否允许访问文件系统然后重开窗口再试一次。3. 技能包机制拆解用Markdown给AI编码助手建立工作纪律3.1 一个技能文件的长相和语义技能本身不复杂本质是结构化的Markdown文档定义触发条件、执行步骤、输出格式。一打开技能文件你会看到几个核心段落元信息技能名称、适用场景、激活关键词。流程定义当技能被激活时AI应该依次执行哪些步骤。输出格式规定AI最终给出来的内容结构比如“问题描述—根因分析—修复方案—验证命令—影响评估”。边界条件什么情况下应该停止当前技能询问用户。我给一个简化的“bug修复技能”结构示例--- name: bug-fix description: 按步骤修复缺陷先复现再定位再修复 --- 当用户报告一个bug时按以下流程执行 1. 复现问题给出最小复现路径。 2. 定位问题检查调用链找到根因。 3. 提出修复方案至少给出两种方案并对比。 4. 实施修复优先采用风险最小的方案。 5. 验证运行相关测试附上验证命令。 边界 - 如果问题无法复现停止修复向用户索要更多日志。 - 如果修改涉及数据库结构必须提醒用户进行备份。这只是示例真实技能会写得更细致甚至会包含代码规范、测试命令、特定框架的约定。你完全可以自己写把团队里沉淀的工程经验转成技能文档。一旦做好一次后续所有AI对话都会自动遵守这套规矩。仔细想想这比整天复制粘贴同样的提示词高效多了。3.2 高频技能清单与适用场景参考目前社区和我自己的项目使用频率最高的几类技能包括技能名适用场景核心作用头脑风暴需求不清晰、方案设计阶段产出多方案并评估利弊规划任务拆解、里程碑安排把模糊目标分解成可执行步骤测试驱动开发新功能开发先写测试再写实现循环推进代码评审提交前自查或团队协作模拟资深工程师做严格的代码评审缺陷修复线上bug排查强制先复现再定位减少拍脑袋修复我最常用的是“代码评审”。以前用AI做评审经常得到“这个代码写得很清晰没有问题”这类废话。装了技能包后它会真的去检查边界条件、异常处理、命名一致性并且按严重程度输出问题列表。虽然不能完全代替人审但确实能挡住相当一部分低级问题。3.3 项目记忆如何与技能联动技能负责“怎么干”记忆负责“按什么背景干”。两者配合才是完整的。Superpowers会给项目建立一个项目记忆文件里面可以记录技术栈、目录结构、测试命令、已知注意事项。每次新开对话AI会先读取项目记忆再根据当前任务选择技能。这带来的改变很明显你不再需要每次解释“我们这个项目用的是Java17和Maven”“接口返回格式是统一的REST风格”。它已经知道了。我建议初始化之后花十分钟把项目记忆文件里那些默认占位内容替换成真实信息包括常用命令、环境变量说明、团队成员偏好等。这一步的收益会在后续每次对话中持续放大。4. 在Codex CLI里接上Superpowers并在Java项目中落地4.1 为什么选Codex CLI这条路不少朋友问“superpowers是不是只支持Claude Code”。早期确实如此但这类框架正在快速适配更多终端编码工具Codex CLI就是其中呼声很高的一个。选择Codex CLI还有一个现实原因有些人所在团队已经统一了Codex的工作流不希望为了个技能框架再切换工具。用Codex CLI接Superpowers说的直白点就是把技能文件变成Codex具备的“自定义指令”来源让它在每次对话前主动加载。这跟Claude Code的插件机制不完全一样但效果类似都是让模型在回复前参考技能文件里的流程规范。4.2 配置步骤实际操作时需要注意Codex CLI对自定义指令的读取方式且不同版本配置路径有差异。我建议按以下顺序操作从Superpowers的技能库中挑出你需要的技能文件放到项目级指令目录下。在Codex CLI的配置文件里把项目指令路径指向上面的目录。额外设置一个“全局指令”内容为“在回答用户任务前必须查看对应技能文件并按里面的流程执行”。重启Codex CLI输入一条测试请求确认技能是否加载成功。如果失败优先检查配置路径和目录权限。这里最容易犯的错是技能文件放对了但配置里没有明确要求模型“必须先读取技能文件”。不读模型就不知道有这套规范行为跟裸用没有差别。4.3 Java项目里的测试驱动开发实战我拿一个真实场景举例子。最近我在改一个Java服务需求是“给订单状态机增加一个取消状态”改动涉及状态流转判断和持久化逻辑。按照老的用法我大概率直接说“帮我实现取消状态”AI一顿输出改完跑一遍测试才知道哪里不对。用TDD技能后的流程完全不同。它先是读取了项目记忆里的技术栈信息确认这是基于Spring Boot和MyBatis的项目然后按技能要求进入TDD循环先问清楚现有状态枚举和数据库字段约束再写失败测试再写实现类接着跑单测最后补集成测试。整个过程并不是一次性把代码全扔给我而是一步步确认每到一个环节就让我验证结果。这个模式对Java项目尤其友好。Java的类型系统和构建链路比较复杂单元测试写得快跑得也快天然适合“测试先行”。过去让AI直接生成一大坨代码很容易出现编译错误满天飞现在拆成小块加测试验证出错范围小定位也容易。我实际测试下来一个中等复杂度的状态机改动效率比之前直接生成的方式稳了不少。4.4 代码评审和重构建议一次对话回放另一类高频场景是代码评审。我挑了一段改动较多的工具类提交让AI按评审技能过一遍。它没有给出“代码很整洁”这种空话而是列出几个点某个if分支存在逻辑冗余、某个catch块吞掉了异常、某个API调用点缺少超时设置。这些建议未必每条都对但确实提供了人来评审时容易遗漏的视角。我修改完后它还会主动检查测试覆盖率有没有明显下降并给出补充测试的建议。这一步以前要花不少时间手动准备现在能被提前触发体验是实打实的。5. 实测中的坑与应对上下文、冲突和版本升级5.1 技能模板把上下文窗口吃满了我在一个代码量很大的仓库里碰到过这个情况启用过多技能后每次对话都要加载一大堆技能说明和项目记忆文件上下文可用空间被压缩导致模型在处理长文件时出现“忘掉前文”的表现。解决思路是分层控制。全局技能只放少数几个基础技能项目级技能按当前迭代重点开启和当前任务无关的技能宁可不开。另外定期精简记忆文件删掉过时的内容避免里面堆满三个月前的旧决策。这个道理就像整理代码仓库没人愿意一直背负一堆历史包袱。5.2 多个AI工具共用同一项目目录的冲突我在一个项目里同时用过Claude Code和Codex CLI两者的记忆文件、技能标记都存在同一个项目目录下出现过配置互相覆盖的情况。后来我把两套技能配置分目录存放并在各自的配置里明确指定加载路径互不干扰。如果你和团队成员使用不同AI工具特别建议在项目文档里写清楚各自加载的是哪套技能目录不然新人加入时很容易把配置搞乱。5.3 自定义技能和版本升级的取舍Superpowers迭代速度很快每次升级可能会带来新的默认技能和配置结构调整。我踩过的坑是自定义技能文件如果深度依赖旧版内部格式升级后可能失效偶尔还会出现加载报错。我的建议是自定义技能尽量保持简单以“流程说明输出规范”为主不去依赖复杂的工具调用。这样即使底层框架改版你的技能文档依然能平滑迁移。至于默认技能随官方升级更新就好一般不用刻意维护。5.4 技能不是越多越好最后一条经验也是我觉得最重要的一条技能不是柴火堆得越多AI被束缚得越死。技能的本质是让AI按流程做事但流程如果过于死板在需要探索性和创造性的任务里反而会拖后腿。我现在只在需要强纪律的任务里显式加载技能比如测试驱动开发、代码评审、故障排查在头脑风暴和写技术方案时我会关掉一部分约束让AI有更大的表达空间。学会在“流程”和“自由度”之间切换这才是Superpowers真正值得研究的地方。6. 我把Superpowers沉淀成工作习惯后的几点体会6.1 一个可复制到团队的技能库维护方法如果团队要一起用我不建议每个人各装各的那样技能文件很快就分叉了。更好的做法是在仓库里建立一个共享技能目录由一两个人负责维护其他人通过版本管理同步。新需求出现时先在群里讨论一下要不要沉淀成技能再由维护者写进技能库。这样既避免重复造轮子也保证技能更新有迹可循。我目前自己维护的只是几个核心技能它所带来的重复劳动减少非常明显所以很推荐有时间的人把这项成本投入进去。6.2 我坚持的三条工作流原则第一每次新项目初始化后先花十分钟补全记忆文件。这是性价比最高的一步。第二遇到反复出现的问题先想“能不能沉淀成技能”而不是每次都临时提醒。第三保持技能目录可读性所有技能文件都要求有描述性名称禁止出现只有自己能看懂的命名。这三条原则不复杂但长期坚持下来会让AI协作的整体稳定性越来越高。6.3 最后说一个实际操作中的细节如果你和我一样经常手滑开了太多技能导致对话变慢可以试着把一个最简单的“最小响应技能”设为默认技能它只规定“不闲聊、不重复、直接给结论”。这样大部分普通问答会被控制在很轻量的状态只有在需要深入流程的任务里再把重型技能打开。实测下来日常对话的响应速度和简洁度都有明显改善。Superpowers这类工具还在快速演进功能边界也在不断变化。我不会说它是终极解决方案但至少现在它是我用过的最能改变AI工作方式的一层脚手架。你可以从一个小项目开始先装一个“代码评审”技能感受一下差别再决定要不要全面引入。