很多人第一次听到 superpowers 这个名字第一反应是又一个花里胡哨的 CLI 工具但我在实际用了一个月之后看法完全变了。它解决的是 AI 编程时代一个非常现实的问题Codex 这类 AI 编码工具很强但如果你只是丢给它一句 prompt它写出来的代码往往没有项目规范、缺乏上下文、甚至反复踩你已经踩过的坑。superpowers 的核心思路是把你的开发能力、项目约定、常用代码模板全部打包成技能包在调用 Codex 或其他 AI 工具时自动注入上下文让 AI 从会写代码变成按你的方式写代码。对 Java 后端、WordPress 插件、前端工程这类有固定套路的场景尤其好用适合每天要跟 AI 协作写代码、又不想在调试上浪费时间的人。1. superpowers 的整体设计思路它到底在解决什么问题1.1 从一次痛苦的 Codex 会话说起我最早接触 superpowers是因为受够了 Codex CLI 的半吊子表现。第一次用 Codex 改一个老 Java 项目的接口我在 prompt 里写了给 UserService 加一个分页查询方法。结果它给我生成了一坨用 PageHelper 却忘了引入依赖、参数校验风格和项目完全不一致的代码。我当时的想法是不是 Codex 不行而是它根本不了解这个项目的潜规则——Controller 层要统一返回 Result 、分页参数要用 PageQuery 对象、Mapper 要继承 BaseMapper。这些约定散落在文档、代码 review 记录和每个人的记忆里AI 工具根本拿不到。superpowers 的设计灵感就在这里把项目里所有值得让 AI 知道的事情结构化地组织起来在每次会话开始时自动喂给 AI。你可以把技能包理解成一个给 AI 看的项目入职手册里面写清楚了技术栈、代码风格、必用的依赖版本、常见业务写法的示例代码。这样一来Codex 不再是一个只会接话的聊天框而是真正懂你项目的结对编程搭档。这里有一个关键点必须说清楚superpowers 不是调试工具也不是包管理器它更像是开发流程的上下文管理器。它管理的对象是技能包——一组 markdown 文档、代码模板和校验规则的集合。当你在项目里执行superpowers use java时它会把 Java 技能包里预置的规范说明、模板文件、常见坑位整理成当前项目可以消费的上下文文件同时生成对应的目录结构和代码骨架。这套机制不局限于某一种 AI 工具理论上只要支持读取系统提示或带上下文文件的工具都能接进去。1.2 核心设计技能包不是配置是可执行的上下文我最早踩过的一个误区是把 superpowers 的配置文件当成一个简单的 JSON 来写以为把依赖列表放进去就完事了。后来我才理解技能包的核心价值在于上下文结构化。一个真正好用的技能包至少包含三层内容第一层是规则层比如所有对外接口返回 Result 包装类数据库表名使用下划线命名日志统一用 SLF4J。这些规则不是给人看的文档而是会被拼接到 AI 提示词里的约束条件。第二层是示例层提供一段高质量的参考代码比如一个标准的 Controller 增删改查怎么写、一个 WordPress 自定义 Gutenberg 区块的骨架长什么样。AI 在生成代码时会优先模仿示例层的风格这比你在 prompt 里写一百遍请保持代码风格一致都管用。第三层是校验层它不是一个独立的 linter而是一组自查清单比如是否处理了参数为空的情况是否加了事务注解是否引入了未声明的依赖。这些清单会放在会话上下文的末尾让 AI 在输出前自己过一遍。我在给团队搭建这套机制的时候发现很多人容易把技能包当成一次性的提示词模板这是对它的最大浪费。提示词模板解决的是怎么说的问题技能包解决的是AI 需要知道什么的问题。举个例子你可以在 prompt 里写请写一个符合项目规范的分页查询但如果你不告诉它项目规范具体是什么这句话就是空话。而技能包会把规范内容实打实地放进上下文里让 AI 真正看到你的 Controller 基类、异常处理类和分页对象的定义效果完全不同。1.3 为什么选择 CLI 本地文件这种轻量方案现在很多同类产品都做成了 SaaS 平台把技能包放到云端通过网页编辑、多人协作。superpowers 选择 CLI 本地文件的方式并非技术落后而是有非常实际的考量。对我这种频繁在终端里工作的人CLI 的启动成本几乎为零打开终端、执行命令、技能包生效整个过程不需要切窗口、不需要打开浏览器。而本地文件意味着所有内容都存储在项目仓库里跟着 Git 走团队评审时可以像 review 代码一样 review 技能包的内容这比在云端平台上做权限管理要直观得多。它的配置格式选择了 YAML 和 Markdown 混排而不是纯 JSON。原因也很朴素描述规则的时候Markdown 的可读性远超 JSON 和 YAML。你可以直接在一个.md文件里写所有对外接口的返回值必须使用ResultT包装配上示例代码块AI 解析起来毫无压力人也看得懂。命令层面superpowers 保持了 Unix 哲学里的克制命令数量不超过 15 个每个命令只做一件事。比如add负责安装技能包、use负责在当前项目激活技能包、codex负责将技能包装载进 Codex 会话。我实测下来一个新人从零开始到跑通整个流程二十分钟内完全能做到。2. 安装与初始化从零开始跑通 superpowers2.1 环境准备其实就三样东西安装 superpowers 之前先确认环境是否满足要求。以我常用的 Node 环境为例需要的依赖非常少Node.js 18 或更高版本、Git 2.30 以上以及如果你要对接 AI 编码工具官方 Codex CLI。Node.js 版本的硬性要求我没法绕过因为 superpowers 用到了 Node 18 才稳定支持的 Fetch API 和部分流式处理特性。验证环境这一步很多人会跳过其实非常值得花三十秒做一下node -v # 需要输出 v18.0.0 或更高 git --version # 需要输出 2.30.0 或更高 codex --version # 如果尚未安装可以先跳过后面配置时再装Codex CLI 装好之后建议先单独跑一次codex完成设备认证和 API key 配置。这个步骤和 superpowers 本身没关系但提前确认 Codex 能独立工作可以避免后面排查问题时搞不清是 superpowers 的问题还是 Codex 的问题。我在帮同事配置的时候发现至少有一半的superpowers 没反应最终都追溯到 Codex 本身没登录好。2.2 安装命令与权限问题安装 superpowers 本身很简单一条 npm 命令就够了npm install -g superpowers但如果你用的是 macOS 或 Linux经常会在这一步遇到权限报错错误信息通常是EACCES: permission denied。这是 npm 全局安装目录权限不足导致的。我个人的建议是不要去sudo npm install因为这会把全局包目录的权限搅乱后面装别的包也会遇到问题。正确解法是修复 npm 全局目录权限执行下面这两行命令mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后记得把~/.npm-global/bin加进 PATH 环境变量否则会提示command not found: superpowers。这一步我一般写在.zshrc里export PATH$HOME/.npm-global/bin:$PATH配置完成后重新打开终端运行superpowers --version看到版本号说明安装成功。安装过程中如果遇到网络超时在国内尤其常见可以临时切换 npm 镜像源但这里不展开——按照 npm 官方的建议使用量比较大的公共镜像或者在公司自建镜像里操作都可以重点是装完记得把源切回来避免后续发布包时报错。2.3 项目初始化生成 .superpowers 目录安装只是第一步真正让 superpowers 发挥作用的是在项目里初始化。假设你已经有一个项目目录名叫my-java-service进入项目根目录后执行cd my-java-service superpowers init这个命令会生成一个.superpowers/目录里面默认包含三个文件一个config.yaml用于声明当前项目启用的技能包和全局变量一个AGENTS.md用于存放给 AI 看的项目说明还有一个skills/目录用于放本地自定义技能包。初始化结束时的输出会提示你项目上下文已准备完毕使用superpowers list查看可用技能包。我这里要特别说明一下AGENTS.md这个文件的作用。它其实是 Codex 等工具约定俗成会主动读取的项目说明文件。superpowers 初始化时生成的AGENTS.md已经预置了一个基本骨架包含了项目名称、技术栈、构建命令和目录结构几项占位符。你可以手动编辑它也可以等激活某个技能包之后让 superpowers 自动往里面追加内容。我自己习惯的做法是手动把项目的启动命令、测试命令、部署方式写进去因为这些内容其它工具也会用到放在AGENTS.md里算是一份通用的机器可读文档。初始化完成之后项目里多出来的.superpowers/目录建议直接提交到 Git 仓库。技能包本质上是团队的工程资产应该跟着代码一起走。我在实际项目中还发现一个好处新人克隆仓库后只要执行一次superpowers sync就能把所有团队级技能包拉下来完全不用手动复制。3. 核心实操技能包管理、Codex 协作与 Java 场景实战3.1 技能包管理安装、激活、移除技能包的获取方式有三种直接使用内置包、从 npm 仓库安装、从 Git 仓库拉取。先看看 superpowers 内置了哪些技能包执行superpowers list输出会按分类列出常见的有java、java-spring、wordpress、react、nodejs、python、database等。这里有个细节值得注意java和java-spring是两回事前者只包含 Java 语言层面的编码约束比如命名规范、异常处理、Optional 使用后者额外包含 Spring Boot 的场景Controller 写法、MyBatis 集成、配置类管理。如果你只是写一个纯 Java 工具类装java就够了强行装java-spring反而会因为上下文太庞杂而让 AI 生成一些和项目无关的内容。安装技能包的命令是superpowers add java-spring装好之后并不是立即生效还需要激活superpowers use java-spring这个安装 激活两步走的机制最初让我觉得很繁琐后来才理解它的合理性安装只是把技能包内容下载到本地库激活才会把技能包的规则、示例、校验清单写入当前项目的上下文文件。一个技能包可以被多个项目共用但激活状态是和具体项目绑定的。你可以同时激活三四个技能包比如java-springdatabaselogging每个技能包关注一个维度组合起来覆盖整个开发链条。这种做法比把全部规则塞进一个巨型技能包要容易维护得多——因为技能包本质上遵循高内聚低耦合的原则互相之间不干扰。移除技能包就更简单了superpowers remove java-spring执行完以后AGENTS.md里相关的上下文内容会自动回滚到之前的状态。我一开始担心这个回滚会不会误删我手动写的内容实测了几次发现它的机制是只删除自己插入的段落你手动维护的段落会被保留。这背后是因为它会在插入的内容周围打上标记注释回滚时按标记精确删除还算靠谱。3.2 与 Codex CLI 协作加载会话的完整流程安装和激活只是准备工作真正让 superpowers 显出价值的是和 Codex CLI 的配合。我平时的工作流固定在终端里先用编辑器改代码然后切换到终端让 Codex 干活。具体操作是这样的superpowers codex --session my-task这个命令干了两件事首先把当前项目激活技能包中的所有规则、示例、校验清单整理成一个上下文文件然后启动 codex 会话并通过配置机制让 Codex 自动加载这个上下文文件。你不需要手动复制粘贴大段内容直接开始输入需求就行。举个例子我在一个 Spring Boot 项目里激活了java-spring和database技能包然后对 Codex 说帮我写一个根据用户 ID 分页查询订单的接口Codex 会自动知道返回值是统一响应ResultPageResultOrderVO而不是裸的PageOrder请求参数要继承PageQuery而不是直接写pageNum和pageSize两个孤立参数Service 层要加Transactional且抛出的异常要统一转成BizException而不是直接抛RuntimeExceptionMapper 层继承BaseMapperOrder分页用内置的selectPage方法而不是自己去写 limit 拼接这一系列规则不是你在 prompt 里面写的而是技能包在后台注入的。我第一次跑通的时候Codex 生成的代码几乎可以直接跑起来只有一处因为版本号没对上需要手动改。这体验和我之前全靠 prompt 人工描述规范差了不止一个量级。superpowers codex命令还支持几个常用参数。--model可以指定模型版本--temperature可以控制输出随机性但我不建议随手调它默认值在大多数场景下已经够用。真正值得说的是--focus参数它允许你临时追加一段本次会话的重点提示比如你想让 AI 只关注单元测试而不要改业务代码可以写成superpowers codex --focus 本会话仅编写单元测试不要修改 src/main 目录下的任何代码这个参数会把你的临时提示放在上下文文件的末尾优先级高于技能包里的常规规则优先级设定的逻辑是后注入的覆盖先注入的。我做过实验技能包规则写命名使用驼峰但只要--focus里指定本次生成 SQL 使用大写关键字SQL 部分的输出就会按照临时优先策略执行。想要全局调整就不用删技能包直接临时覆盖即可。3.3 Java 场景实战标准化接口开发接下来用一个完整的 Java 场景把上面的流程串起来。假设你现在要在项目里新增一个通过手机号查询用户积分的接口而且项目已经配置好了java-spring、database、logging三个技能包。激活技能包之后我习惯先执行一次superpowers status看当前的技能包组合有没有冲突。它会列出每个技能包的生效状态、注入的上下文文件大小、以及最后的修改时间。有一种情况要特别小心技能包注入的内容太多超过 Codex 的上下文窗口时诊断输出会给出警告。遇到这种情况不是去删规则而是应该把技能包拆分得更细。比如把database拆成database-sql只关注 SQL 写法和database-mybatis只关注 MyBatis 的 mapper 规则分场景激活。确认状态正常后执行superpowers codex --focus 新增用户积分查询接口先读 UserPoints 表结构再写 Controller、Service、Mapper 三层Codex 在技能包上下文的引导下生成的代码是一个基于现有基类的标准三层结构。关键差异在于生成的 Service 方法会拿到UserId参数后先做空值校验再走userPointsMapper.selectByUserId()最后把实体转换为UserPointsVO包在Result.success()里返回。日志方面它会自动加一行log.info(query user points, userId{}, userId)而且知道在返回值前记录耗时。这里有个细节技能包里预置的示例代码有最佳实践和最小可用两种模式。默认使用哪一种取决于你初始化项目时的选项。我在工程团队里推荐选最佳实践因为 Codex 生成的代码风格会直接对齐团队的 senior 工程师写法如果你只是写一次性脚本选最小可用就够了代码量更少、上下文占得更小。生成代码之后superpowers 还提供了一个非常实用的能力校验模式。执行superpowers check src/main/java/com/example/controller/UserController.java它会把校验清单里的规则逐条对着新生成的代码打勾输出哪些规则通过、哪些警告。比如是否使用统一响应结果这一条如果你的 Controller 直接返回了UserPointsVO而不是ResultUserPointsVO它就会标红警告。这个check功能本质上是维护一个规则清单还没到真正的静态分析工具那么智能但用来兜底已经很够用了至少在提交代码之前能逼着 AI 自己过一遍规范。3.4 WordPressworbuddy场景的集成实践除了 Java我在 WordPress 插件开发里也试过 superpowers效果同样出乎意料。热词里提到的 worbuddy 我理解是一套 WordPress 环境的本地管理工具它和 superpowers 的集成方式很典型通过双方都支持的持文件接口协作而不是在内部互相调用 API。这个场景的需求痛点非常明确WordPress 插件开发最烦人的是按规范组织目录结构、写标准的插件头注释、挂正确的 action/filter 钩子。我用superpowers use wordpress激活技能包后对 Codex 说写一个支持短代码显示最新文章列表的插件它会自动生成符合 WordPress 官方规范的插件文件结构主文件头部包含 Plugin Name、Description、Version 等标准注释把短代码注册放在init钩子而不是直接在文件主体执行前端模板文件放在templates/目录类名按 WordPress 习惯加前缀避免冲突这里真正难的是上下文如何跨工具传递。Codex 生成代码时并不认识 worbuddy 管理的本地站点配置你必须在技能包里明确告诉它站点的 PHP 版本是 8.2插件目录在/wp-content/plugins/my-plugin调试模式已开启。这些信息写进技能包后Codex 生成的代码才会规规矩矩地避开 PHP 8.2 已经废弃的dynamic properties用法。我搭配 worbuddy 使用时最喜欢一个小技巧在 worbuddy 恢复站点环境之后先跑一次superpowers sync确保技能包里的模板文件版本和当前站点环境匹配。因为 WordPress 主题或插件升级会导致某些函数接口变化如果技能包里的示例代码还是老版本写法AI 生成的代码就容易出问题。养成这个习惯之后我几乎没有再遇到AI 写出来的代码在本地环境直接报 fatal error的情况。4. 编写与维护自己的技能包让团队经验可传承4.1 技能包目录结构解析内置技能包再好也不可能覆盖每个团队的特殊约定。我在正式使用 superpowers 第三周就开始琢磨这件事把团队里最常见的代码约定做成自己的技能包。superpowers的本地创建命令是这样的superpowers new --name my-team-java这会在.superpowers/skills/my-team-java/下生成一个标准目录结构my-team-java/ ├── skill.yaml # 技能包元信息声明名称、版本、依赖关系 ├── rules.md # 规则层全部是对 AI 的约束性描述 ├── examples/ # 示例层存放可参考的代码范式 │ ├── controller.md │ ├── service.md │ └── mapper.md └── checklists/ # 校验层放自查清单文件 ├── code-review.md └── sql-review.mdskill.yaml是整个技能包的入口最关键的是depends字段和context-length字段。depends声明该技能包依赖哪些基础技能包比如my-team-java依赖内置的java-spring激活前者时后者的规则会自动一并生效。context-length是一个我个人觉得非常有用的参数它表示这个技能包最多允许占用的上下文 token 数超出的内容会被截断。我一般按每个规则条约 50 token、每段示例代码约 200 token 来做预算如果总预算超过 8000 token就会提醒自己精简内容。因为 Codex 的上下文窗口虽然越来越宽但塞满低价值内容会拉低 AI 的注意力集中度得不偿失。4.2 变量与模板让技能包里的代码更智能如果你只是把固定内容写死在技能包里它的灵活性会严重受限。superpowers 支持在示例代码里使用变量在激活技能包时通过config.yaml注入具体值。比如团队统一使用io.example作为包名前缀正常情况下每个新项目的包名都不一样的你可以在项目的.superpowers/config.yaml里写variables: package_base: com.yourcompany.order app_name: order-service然后在技能包的service.md示例代码里这样写package {{ package_base }}.service; public class UserService extends BaseService{{ app_name | upper_camel }} { // ... }这个模板变量的设计思路其实和 Svelte、Vue 里的模板插值非常像程序员理解起来没有任何门槛。实测中我发现变量还有一个隐藏的好处它能够在下游做版本对齐。比如你在项目里升级了 Spring Boot 版本只要把spring_boot_version这个变量改了所有依赖示例模板里自动出现新版本的依赖坐标不需要逐个文件修改。当然过度使用变量也会带来麻烦。我踩过一个坑在模板里嵌套了超过两层的变量引用比如{{ {{ project_name }}_base }}结果在代码生成时出现了空值而且报错信息非常耐心几乎给不出有效定位。后来我把所有变量都摊平到一层不再做动态嵌套代码生成就稳定多了。这个问题的教训是模板引擎的能力边界就在那里不要把技能包当成编程语言来用。4.3 团队共享技能包让它跟着 Git 走技能包写完之后如果只有你一个人用价值是有限的。真正的价值在于让整个团队共享。我推荐的共享方式是建立一个独立的 Git 仓库比如叫做team-superpowers-skill目录结构按技能包分类组织team-superpowers-skill/ ├── java/ # Java 相关技能包 ├── wordpress/ # WordPress 相关技能包 ├── ci/ # CI 相关技能包 └── README.md # 技能包索引团队成员在各自项目里可以通过 Git 仓库直接添加superpowers add my-team-java --source https://git.company.com/team/team-superpowers-skill.git这里有一个要注意的工程问题技能包仓库和业务项目仓库的更新节奏不同所以 superpowers 会缓存已安装的技能包版本。团队成员执行superpowers update才会拉取新版本。这是合理的设计避免业务代码构建被技能包的变化意外打断。但如果团队正处于规范起草阶段技能包变化频繁我建议在 README 里写清楚每次提交代码前先执行superpowers update不然容易出现在真代码中使用旧规则、AI 生成新规则代码的混乱情况。团队共享带来的另一个好处是代码 review 变得更顺畅。以前 reviewer 需要逐行盯代码风格现在可以直接 review 技能包里的规则定义——规则对了生成的代码就对了Review 从微观检查变成了宏观检查。不过这只在团队真正愿意维护技能包的前提下成立。如果技能包长期没人更新它就会变成僵尸资产反而不如没有。我自己会定期翻看技能包仓库的提交记录至少保证每两周有一次活跃提交内容可以是新增规则、补充示例或者修正模板。5. 常见问题与排查技巧实录5.1 安装与激活阶段的排查先说说安装后最常见的现象命令找不到。如果你已经正确安装但终端提示superpowers: command not found大概率是 PATH 没配好。这种情况我见得太多特别是用npm config set prefix自定义了全局目录之后忘记把bin目录加到PATH。排查命令很简单which superpowers # 如果没有任何输出说明 PATH 里没找到 ls ~/.npm-global/bin/superpowers # 如果能列出文件说明安装成功只是 PATH 配置没生效确认之后就修改 shell 配置文件把export PATH$HOME/.npm-global/bin:$PATH加进去再source一下。如果ls之后连文件都看不到那就是安装过程被中断了重装一次即可。还有一个情况是初始化时报错信息类似ENOENT: no such file or directory。这一般是因为当前目录不是项目根目录superpowers 找不到.git文件。它设计上要求必须在 Git 仓库里运行init因为技能包状态要和版本控制绑定。我在一个尚未git init的目录里尝试过确实直接报错。解决方式是先git init或者进入已有仓库目录再执行。顺带提一句superpowers init本身不会自动执行git init它假定你在一个有版本控制的项目里工作这个假定在大多数时候是合理的。5.2 运行时症状与解法的两张大表技能包激活但不生效是另一个高频问题。最典型的表现是你已经superpowers use java-spring但在 Codex 生成的代码里完全没有体现技能包里的规则。我先按严重程度做一个排查顺序表排查步骤操作预期结果异常时的原因1执行superpowers status列出已激活的技能包技能包未激活或config.yaml被误改2打开.superpowers/AGENTS.md查看末尾能看到技能包注入的规则段落且带有标记注释Codex 启动时未按约定读取AGENTS.md3手动执行一次superpowers codex --dry-run输出拼接好的上下文内容变量注入失败常涉及模板变量和config.yaml不匹配4检查 Codex 会话的上下文长度没有超过模型限制上下文被截断技能包内容靠前的规则失效这张表最常用到的其实是第 3 步。--dry-run是我发现的一个隐藏好用的参数它不会真的启动 Codex而是把即将注入的上下文内容完整打印出来。一次我在模板变量配置错误时靠它定位到了问题配置里写的是package_base: com.example.api但模板里使用的是{{ group_id }}这种预期之外的变量名系统注入了空值却不报错。看到输出之后才意识到原来是变量名对不上。运行时错误的另一大类是 Java 开发中很典型的编码问题。技能包里的模板示例文件包含中文注释如果文件编码和系统默认编码不一致Inject 进上下文后会出现乱码AI 读到的规则就是一堆乱码自然生成不出符合要求的代码。排查时看AGENTS.md里中文是否正常显示即可。解决方式是把所有技能包文件统一保存为 UTF-8并且对 Git 设置*.md text eollf working-tree-encodingUTF-8这类属性确保跨平台协作时编码稳定。我所在的团队的技能包文件全通过 Git 管理在 Windows 和 macOS 上混编靠这个属性避免了很多乱码问题。5.3 我用的几个独家避坑技巧最后分享几个我不太常见别人写进文档但实测很有用的技巧。第一个技巧技能包宁小勿大。不要试图把项目里所有规范一股脑塞进一个技能包。每次会话注入的上下文过多Codex 的注意力会被稀释关键规则反而没有在生成代码时起作用。我经验上的安全阈值是单技能包上下文量控制在 3000 token 以内整个项目激活的技能包总量不超过 8000 token。超过了就拆分成多个技能包按场景激活。第二个技巧在技能包示例代码里刻意留一点小错误的注释。简单说示例层不一定要全部是最佳实践。我会在示例代码里写入一两行带有// TODO: check null here之类的注释这会让 Codex 在生成代码时也保留类似的严谨注释习惯生成的代码质量反而更高。这个技巧源自我的观察AI 会大量模仿示例代码的风格包括注释习惯。如果示例代码里注释寥寥无几它生成的代码也往往缺少关键说明如果在注释里写出思考过程生成的代码就有了人味儿。第三个技巧每次运行superpowers codex之后检查一下AGENTS.md的末尾内容。不是每次打开而是每次怀疑技能包不生效时。因为一个很容易被忽略的事实是AGENTS.md会被多种工具读取不只 Codex还有其它一些 AI 编码工具而不同工具的读取顺序和更新策略可能互相影响。如果另一个工具偷偷修改了AGENTS.md的内容superpowers 插入的规则段可能会被挤到文件更靠后的位置甚至被清掉。及时发现这一点能省下大量对着 Codex 猜谜的时间。结尾一些来自实操的体会上面这些内容算是我用了一个多月 superpowers 之后的完整心得。我想负责任地说这个工具一开始的学习曲线不算特别陡峭真正难的是养成把团队规范沉淀成技能包的意识和习惯。我刚入手时也犯过错误——试图在一个技能包里解决所有问题结果 Codex 生成代码时反而变得束手束脚上下文被各种无关规则填满。后来把技能包拆成小而专的模块按 Java、数据库、日志、WordPress 等场景区分协作效率才真正提上来。如果你也想引入这套玩法我建议从一个小项目开始别急着把所有项目都接入 superpowers先挑一个你最熟的 Java 服务或 WordPress 插件从安装内置技能包开始跑通一次superpowers codex会话再逐步把自己手动维护的代码规范整理进自定义技能包。等这套流程在你脑子里形成了肌肉记忆再推广到团队。最后想提醒一句任何工具都只是放大器核心还是你对项目的理解和规范的沉淀。技能包里的每条规则都应该是团队在代码 review、Bug 排查中留下的真实经验而不是从别处抄来的漂亮话。这样积累出来的 superpowers才真正配得上它的名字。