最近在折腾 Codex CLI 的时候我把 superpowers 这套技能包正式装进了日常开发流程。先说结论它解决的不是“AI 会不会写代码”的问题而是“AI 会不会像工程师一样干活”的问题。如果你早就受够了让 AI 改个 bug 却顺手把你的接口签名也改了或者让它写个功能却完全无视项目里已有的封装那这套东西值得你花一个下午好好试试。superpowers 本质上是一套建立在 AI 编程助手之上的技能增强层。它不替代 Codex、不替代 Claude Code也不替代你手里的编辑器而是通过结构化的技能文件给这些工具补齐规划、测试、调试、重构这些本该属于工程师的基本功。这篇文章我从安装、机制、实战到踩坑完整过一遍重点用 Java 项目演示一次全流程跑通也会聊到和 Worbuddy 这类配套工具组合使用的思路。不吹不黑全是实测。1. 先说清楚superpowers 到底解决了 Codex 生态里的什么问题如果你只是偶尔让 AI 帮你写个正则、补个单元测试那默认的 Codex CLI 体验其实还行。但一旦进入真实项目问题立刻暴露AI 拿到需求就开写不先看项目结构写完代码不跑测试全凭“我觉得应该行”出 bug 了也不先判断根因而是哪里不对改哪里经常修一个 bug 引出三个新 bug。我自己的体会是默认状态下的 Codex 像一个聪明但极其缺乏职业习惯的实习生。智力够用经验为零。而 superpowers 要做的就是把这套“经验”用技能包的形式塞给它。1.1 它的核心不是“更多提示词”而是一套可复用的工作流定义市面上很多增强工具的做法是给你一堆精选 Prompt让 AI 在对话里扮演“资深工程师”“代码审查官”之类的角色。这种方案的问题在于角色扮演只影响语气不影响行为。你说自己是资深工程师但 AI 并不知道资深工程师接到需求之后第一步应该做什么。superpowers 换了个思路把工作流拆成一个个独立技能每个技能都有明确的前置条件、执行步骤、输出格式和质量标准。比如“写代码之前先写测试计划”“改 bug 之前先复现并定位根因”“大规模重构之前先铺安全网”。AI 调用某个技能时不是在“扮演”一个角色而是在“执行”一套流程。1.2 它和 Codex 是什么关系从实际使用看superpowers 更像是 Codex CLI 上游的一层“决策层”。Codex 负责的是“理解自然语言并生成代码”superpowers 负责的是“决定这段自然语言应该触发哪个技能流程”。两者不是竞争关系而是上下游配合。打个比方Codex 是一台性能强悍的发动机superpowers 是变速箱。只踩油门让 Codex 直接干活也能走但碰上复杂路况就会顿挫、熄火装好变速箱之后同样的发动机才能在不同场景里切换合适的档位。1.3 适合谁不适合谁适合的读者有两类一类是重度使用 AI 编程工具、已经在真实项目里吃过亏的人另一类是团队里负责引入 AI 工具链、需要统一团队协作方式的工程师。不适合的也有两类一类是只想“多快好省生成几段代码”的临时需求者装这套东西属于杀鸡用牛刀另一类是完全没有编程基础、只想用自然语言把一个完整应用从零写到上线的人superpowers 解决的是工程化问题而不是替你从零搭系统的问题。2. 安装与初始化从零到跑通第一个技能安装过程不算复杂但有不少细节值得单独说。因为网上大部分教程只会告诉你“clone 下来就能用”实际跑的时候会发现各种版本、权限、路径问题。2.1 环境准备我的本地环境是 macOS Node.js 20 GitCodex CLI 已经装好并能正常运行。如果你还没装 Codex先去把 Codex CLI 跑通再回来。因为 superpowers 的所有技能最终都是通过 Codex 的对话能力执行的它本身不是独立的代码执行引擎。另外建议把 Node.js 升到 18 以上太老的版本在处理技能文件里的异步逻辑时会有兼容性问题。我第一次装的时候用的是 Node 16加载技能时偶尔报SyntaxError: Unexpected token ?升级 Node 之后这个问题再没出现过。2.2 安装路径我实测的三种方式第一种是直接从 GitHub 把仓库 clone 到本地。这是最稳的方式因为你能清楚看到所有技能文件的实际内容后面自定义技能也方便。克隆完成后仓库里会用目录把不同功能的技能分开比如规划类、测试类、重构类每个目录里有对应的 MARKDOWN 文件。第二种是通过 npm 全局安装。好处是命令统一、升级方便坏处是技能文件藏在 node_modules 深处你想改点东西还得先找到路径。npm 包名和仓库里的名字一致装完可以用superpowers --version验证是否成功。第三种是手动复制关键技能文件到你的 Codex 配置目录。这种方式适合已经有自己技能库的人只挑你需要的技能导入不搞全家桶。缺点是后续官方更新时你得自己跟进同步。2.3 初始化激活一个容易忽略的步骤很多人 clone 完之后直接在对话里喊“使用 superpowers”结果 AI 一脸懵于是断定这个项目是吹出来的。问题出在技能文件就位只是第一步你还需要告诉 AI 这些技能的存在和触发方式。典型的做法是在 Codex CLI 的配置里加一条对技能目录的引用或者在每次对话开始时给一句类似“请先阅读 superpowers 技能目录中的 README了解可用技能后再开始任务”这样的初始化指令。我习惯把初始化指令固化到配置里省得每次手动打。这里分享一个自查技巧初始化完成后随便问 AI“你现在有哪些技能可用”如果它能把技能列表准确说出来说明加载成功如果它开始编造你根本没装过的技能名说明加载失败检查引用路径和权限去了。2.4 验证安装是否真正的标准你装的 superpowers 是否生效不是看命令能不能跑而是看 AI 的行为有没有质变。我装完之后做了一个小实验让 Codex 实现一个带缓存的 Fibonacci 函数并且明确要求“不要直接写实现先告诉我你的计划”。装之前它会直接甩一段代码给我装之后它会先问你边界条件、考虑缓存策略、写测试用例最后才动手。这个行为差异就是技能包生效的信号。如果装了之后 AI 还是老样子大概率是配置没加载成功别急着怀疑工具。3. 核心机制拆解技能文件如何改变 AI 的行为轨迹理解了安装还得理解这套系统为什么能改变 AI 的行为。否则你遇到问题都不知道去哪儿排查。3.1 一切皆 SKILLS.md技能文件的标准形态superpowers 里的每个技能都是一个独立的 Markdown 文件文件名就是技能名文件内部用清晰的目录结构描述这个技能的用途。你可以把它理解为一份“操作规程”告诉 AI 这个技能在什么场景下用、用之前要满足什么条件、执行时按什么顺序做、做完之后提交什么成果。关键在于这份操作规程不是写给人看的而是写给模型看的。模型通过解析 Markdown 的结构化描述来“理解”流程并通过系统提示词的引用把它们挂载到自己的思维链里。3.2 技能的分层从规划到复盘覆盖完整生命周期我在实际使用中会把技能分成四层规划层、执行层、验证层、复盘层。规划层的技能负责把模糊需求拆解成可执行的任务清单执行层的技能负责具体的编码实现、接口联调验证层的技能负责测试编写、代码审查、问题复现复盘层的技能负责回顾过程中出现的坑、沉淀经验。这种分层的直接收益是AI 不再“一步到位”地写代码而是像人一样有节奏地推进。需求再复杂它也会先走规划流程把大任务拆成小步骤而不是一头扎进某个细节里出不来。3.3 AI 如何决定当前该用哪个技能这是整个机制里最巧妙、也最容易被误解的部分。很多人以为需要手动指定“你现在用测试技能”其实不用。技能文件的头部会写明触发条件AI 会根据当前任务的描述自动匹配最合适的技能。比如任务里包含“写测试”“验证行为”这类关键词时AI 会倾向选择测试相关技能包含“重构”“优化结构”时会倾向选择重构相关技能。这种自动匹配不是百分百准确所以技能文件里的触发条件写得越具体越好否则 AI 很容易选错。3.4 自定义技能的写法与注意事项superpowers 的一大优点是你可以往里面塞自己的技能。比如我给自己团队写了一个“Spring Boot 接口开发规范”技能内容就五段项目结构约定、DTO/VO 分层要求、异常处理方式、单元测试覆盖标准、接口文档格式。写自定义技能时最重要的不是格式花哨而是把“执行触发条件和最终交付物”写清楚。否则 AI 学会了流程但不知道交付标准照样产出不合格的结果。我踩过的坑是第一版技能只写了步骤没写质量标准AI 是照着流程走了但产出的代码连公司的代码风格都没遵守。4. 实战记录用 Java 项目完整跑一次需求开发说了这么多原理该上实战了。我选了一个真实的 Java 项目场景给一个已有的订单服务新增“订单取消”接口取消后要退还库存、记录日志、发消息通知。表面看是个 CRUD 需求实际牵扯到事务、库存并发、消息可靠性好几个环节足够检验 superpowers 的效果。4.1 需求输入越“脏”越好别自己先加工很多人用 AI 编程有个坏习惯生怕 AI 不理解需求自己先花半小时把需求翻译成技术方案。这恰恰是反模式。superpowers 的规划技能会自己完成需求拆解你只需要提供原始需求。我直接把产品经理的原话丢给了 Codex“用户下单后可以取消取消要退库存还要记录一下谁取消的最好通知运营。”没提事务、没提幂等、没提接口设计。AI 接到需求后先启动了规划流程把需求拆成了六项任务查询订单状态、校验取消条件、回退库存、写取消日志、发通知、处理事务边界。4.2 规划阶段拆任务的效果直接决定了后面成功的概率AI 拆完任务后并没有直接写代码而是先把任务清单展示给我确认。这一步我非常喜欢因为我能提前发现它理解偏差的地方它把“通知运营”理解成了“发短信”而我们的实际需求是“推送到运营后台的消息队列”。我把它纠正过来后AI 更新了任务清单才开始动工。整个过程和真实团队里“先对齐需求再开发”的流程几乎一致。这里也体现了几分钟前说的分层优势规划层先把路走对执行层才不会被带偏。4.3 测试先行TDD 流程在技能包里的落实superpowers 在执行阶段会自动引入“测试先行”的逻辑。它不是只让你补几个测试用例做做样子而是真的先写失败测试、再写实现、再到测试转绿。AI 生成的测试包括订单不存在时抛异常、重复取消时幂等返回、库存不足时取消失败、通知发送失败时不回滚订单主状态毕竟是异步通知。这些测试虽然谈不上多优雅但覆盖了核心业务规则。实现代码是在测试定义之后才动手的。4.4 调试循环当测试第一次跑挂时 AI 的处理方式没有任何一次开发是不出 bug 的关键是 AI 怎么面对失败。我故意在需求描述里留下一个坑库存表里加了乐观锁版本号但需求原文没提。AI 写的更新语句没带版本条件并发下会出现超卖超退风险但单测跑不出来。我提醒它“并发场景你考虑一下”之后它没有急着改代码而是先走了调试技能的流程写了一个并发模拟的小测试复现问题确认是版本号缺失导致更新丢失然后才修复实现并补上并发测试用例。这种“先复现、再定位、后修复”的顺序和高级工程师的排查路径是一致的。4.5 项目结构一致性AI 有没有遵守已有约定这个项目之前已经有一套 Controller-Service-Mapper 三层结构返回结果统一走ApiResponseT。superpowers 的技能里如果已经写入了“遵守现有项目结构”的约束AI 新生成的接口就会自动套用这层结构而不是自己另搞一套。我这里补一句如果你的项目有很明确的代码规范建议在自定义技能里写清楚比在需求描述里反复强调有效得多。因为这个信息不依赖每次对话的临时上下文而是每次都会加载的稳定技能。5. 工具协同把 superpowers 挂到 Codex CLI 和 Worbuddy 上组合用单用 superpowers Codex 已经很顺手了但很多人的实际工作流里不止一套工具。热词里反复出现的 Worbuddy 我也特意去试了试这里聊聊组合玩法。5.1 Codex CLI 作为执行引擎最简组合我的日常用法是终端打开 Codex CLI通过配置加载 superpowers 技能目录。这样每次对话我不用重复粘贴技能说明AI 自己知道该按什么流程走。这里有个不算坑但很值得注意的点Codex CLI 的配置加载是全局的你在这个项目里装的技能到了另一个项目也可能被加载。如果你的两个项目技术栈差异很大建议在技能文件里写上适用范围条件免得 Java 项目的技能跑到了 Python 项目里捣乱。5.2 Worbuddy 的角色任务编排与入口统一有关 Worbuddy 和 superpowers 的组合我的理解是Worbuddy 这类工具负责的是“任务编排和对话管理”这层它可以把多个 AI 工具收拢成一个入口再把拆解后的子任务分发给不同的执行引擎superpowers 则负责给这些引擎提供统一的技能底座。我实测的组合方式是把 superpowers 的技能目录作为共享资源Worbuddy 负责调度Codex CLI 负责执行。复杂需求先由 Worbuddy 的任务规划层拆解成子任务清单每个子任务交给 Codex CLI 执行时superpowers 的技能会自动约束执行方式。5.3 组合使用时的配置持久化技巧多工具组合最怕的是什么怕配置散落各处、升级后失联。我习惯把 superpowers 技能目录统一放在一个独立目录里所有工具都通过引用这个目录来加载而不是各自复制一份副本。这样做的直接好处是修改一个技能文件所有工具下次加载时都生效升级 superpowers 时只替换这一个目录不影响其他工具的配置。如果你现在正在折腾多工具组合强烈建议采用“单一技能源”这个思路。6. 真实使用中的坑与调优建议最后这部分是干货中的干货。以下问题我在使用中都真实遇到过也花了不少时间排查写出来给大家省点时间。6.1 上下文窗口消耗明显增大长会话容易“失忆”技能文件本身要占用上下文空间尤其当你加载的技能很多、每个文件都很长时AI 的上下文预算会被吃掉不少。长会话跑到后面AI 会开始忘记前面的信息表现就是“前面刚统一的命名规范后面又用回了旧写法”。解决办法有两个一是精简技能文件把每一条都写成“触发条件核心步骤交付标准”三段式删掉那些文艺的解释性文字二是把大任务拆成多个短会话每个会话只开一个技能而不是一个会话里塞四种技能轮换用。6.2 技能太多导致决策混乱AI 不知道该选哪个技能文件超过二十个之后AI 的“自动选技能”功能会开始出问题。我见过 AI 在同一个任务里连续切换三个技能每个都执行到一半最后产出一个四不像的结果。经验法则是生产环境里的激活技能控制在十个以内。不常用的技能可以保留文件但通过配置把它们排除在默认加载列表之外需要用的时候手动触发。这就像人的工具箱常用的放外面不常用的收抽屉里而不是全部摊在桌面上。6.3 和编辑器内 AI 插件叠用时的行为冲突我有一段时间同时开着 VS Code 的 Copilot 插件和终端里的 Codex CLI两边都挂着 superpowers。结果发现编辑器内的 AI 经常重复完成一些本来已经由终端的 Codex 完成的工作比如自动补全已经生成的注释块。后来我明确划分了分工编辑器内 AI 只负责实时补全和短对话问答所有完整流程开发规划、测试、重构都放到 Codex CLI 里跑。划分清楚之后冲突基本消失体验也顺滑了很多。6.4 升级时机别追新先看兼容性superpowers 迭代速度不慢我自己曾经手痒第一时间升级结果新版本改了技能文件的内部结构我的自定义技能全部失效。那次之后我就学乖了升级前先看变更记录确认没动我这边的接口再把新版本拉下来。如果你也写了不少自定义技能建议在大版本升级前先备份技能目录并在升级后跑一个最小验证任务确认核心技能正常再切换。7. 写在最后的经验之谈这套东西我用到现在也有几个月了最大的感受是它不能让你从“不会写代码”变成“会写代码”但能把一个“会用 AI 写代码的人”变成“会用 AI 写生产级代码的人”。如果你已经受够了 AI 给出正确但毫无工程素养的答案不妨先从一个技能开始——比如只加载“规划”技能跑一个需求感受一下它如何改变你和 AI 的协作方式。我的个人建议是第一周先什么都别改用默认技能包跑三到五个真实需求记录 AI 的行为变化第二周再开始尝试写自定义技能从你最痛的那个环节切入比如代码审查、并发调试、接口规范。一次只改一个点比一次搭建整套工作流更容易出成果。另一个心得是无论你用什么工具组合核心思路都是把“一次性提示词”沉淀成“可复用技能”。今天你在这里花时间装的不是一套软件而是一套让 AI 变得更像同事的行为模式。这个投资长期看是货真价实的复利。
superpowers技能包实战：让Codex CLI像工程师一样开发
最近在折腾 Codex CLI 的时候我把 superpowers 这套技能包正式装进了日常开发流程。先说结论它解决的不是“AI 会不会写代码”的问题而是“AI 会不会像工程师一样干活”的问题。如果你早就受够了让 AI 改个 bug 却顺手把你的接口签名也改了或者让它写个功能却完全无视项目里已有的封装那这套东西值得你花一个下午好好试试。superpowers 本质上是一套建立在 AI 编程助手之上的技能增强层。它不替代 Codex、不替代 Claude Code也不替代你手里的编辑器而是通过结构化的技能文件给这些工具补齐规划、测试、调试、重构这些本该属于工程师的基本功。这篇文章我从安装、机制、实战到踩坑完整过一遍重点用 Java 项目演示一次全流程跑通也会聊到和 Worbuddy 这类配套工具组合使用的思路。不吹不黑全是实测。1. 先说清楚superpowers 到底解决了 Codex 生态里的什么问题如果你只是偶尔让 AI 帮你写个正则、补个单元测试那默认的 Codex CLI 体验其实还行。但一旦进入真实项目问题立刻暴露AI 拿到需求就开写不先看项目结构写完代码不跑测试全凭“我觉得应该行”出 bug 了也不先判断根因而是哪里不对改哪里经常修一个 bug 引出三个新 bug。我自己的体会是默认状态下的 Codex 像一个聪明但极其缺乏职业习惯的实习生。智力够用经验为零。而 superpowers 要做的就是把这套“经验”用技能包的形式塞给它。1.1 它的核心不是“更多提示词”而是一套可复用的工作流定义市面上很多增强工具的做法是给你一堆精选 Prompt让 AI 在对话里扮演“资深工程师”“代码审查官”之类的角色。这种方案的问题在于角色扮演只影响语气不影响行为。你说自己是资深工程师但 AI 并不知道资深工程师接到需求之后第一步应该做什么。superpowers 换了个思路把工作流拆成一个个独立技能每个技能都有明确的前置条件、执行步骤、输出格式和质量标准。比如“写代码之前先写测试计划”“改 bug 之前先复现并定位根因”“大规模重构之前先铺安全网”。AI 调用某个技能时不是在“扮演”一个角色而是在“执行”一套流程。1.2 它和 Codex 是什么关系从实际使用看superpowers 更像是 Codex CLI 上游的一层“决策层”。Codex 负责的是“理解自然语言并生成代码”superpowers 负责的是“决定这段自然语言应该触发哪个技能流程”。两者不是竞争关系而是上下游配合。打个比方Codex 是一台性能强悍的发动机superpowers 是变速箱。只踩油门让 Codex 直接干活也能走但碰上复杂路况就会顿挫、熄火装好变速箱之后同样的发动机才能在不同场景里切换合适的档位。1.3 适合谁不适合谁适合的读者有两类一类是重度使用 AI 编程工具、已经在真实项目里吃过亏的人另一类是团队里负责引入 AI 工具链、需要统一团队协作方式的工程师。不适合的也有两类一类是只想“多快好省生成几段代码”的临时需求者装这套东西属于杀鸡用牛刀另一类是完全没有编程基础、只想用自然语言把一个完整应用从零写到上线的人superpowers 解决的是工程化问题而不是替你从零搭系统的问题。2. 安装与初始化从零到跑通第一个技能安装过程不算复杂但有不少细节值得单独说。因为网上大部分教程只会告诉你“clone 下来就能用”实际跑的时候会发现各种版本、权限、路径问题。2.1 环境准备我的本地环境是 macOS Node.js 20 GitCodex CLI 已经装好并能正常运行。如果你还没装 Codex先去把 Codex CLI 跑通再回来。因为 superpowers 的所有技能最终都是通过 Codex 的对话能力执行的它本身不是独立的代码执行引擎。另外建议把 Node.js 升到 18 以上太老的版本在处理技能文件里的异步逻辑时会有兼容性问题。我第一次装的时候用的是 Node 16加载技能时偶尔报SyntaxError: Unexpected token ?升级 Node 之后这个问题再没出现过。2.2 安装路径我实测的三种方式第一种是直接从 GitHub 把仓库 clone 到本地。这是最稳的方式因为你能清楚看到所有技能文件的实际内容后面自定义技能也方便。克隆完成后仓库里会用目录把不同功能的技能分开比如规划类、测试类、重构类每个目录里有对应的 MARKDOWN 文件。第二种是通过 npm 全局安装。好处是命令统一、升级方便坏处是技能文件藏在 node_modules 深处你想改点东西还得先找到路径。npm 包名和仓库里的名字一致装完可以用superpowers --version验证是否成功。第三种是手动复制关键技能文件到你的 Codex 配置目录。这种方式适合已经有自己技能库的人只挑你需要的技能导入不搞全家桶。缺点是后续官方更新时你得自己跟进同步。2.3 初始化激活一个容易忽略的步骤很多人 clone 完之后直接在对话里喊“使用 superpowers”结果 AI 一脸懵于是断定这个项目是吹出来的。问题出在技能文件就位只是第一步你还需要告诉 AI 这些技能的存在和触发方式。典型的做法是在 Codex CLI 的配置里加一条对技能目录的引用或者在每次对话开始时给一句类似“请先阅读 superpowers 技能目录中的 README了解可用技能后再开始任务”这样的初始化指令。我习惯把初始化指令固化到配置里省得每次手动打。这里分享一个自查技巧初始化完成后随便问 AI“你现在有哪些技能可用”如果它能把技能列表准确说出来说明加载成功如果它开始编造你根本没装过的技能名说明加载失败检查引用路径和权限去了。2.4 验证安装是否真正的标准你装的 superpowers 是否生效不是看命令能不能跑而是看 AI 的行为有没有质变。我装完之后做了一个小实验让 Codex 实现一个带缓存的 Fibonacci 函数并且明确要求“不要直接写实现先告诉我你的计划”。装之前它会直接甩一段代码给我装之后它会先问你边界条件、考虑缓存策略、写测试用例最后才动手。这个行为差异就是技能包生效的信号。如果装了之后 AI 还是老样子大概率是配置没加载成功别急着怀疑工具。3. 核心机制拆解技能文件如何改变 AI 的行为轨迹理解了安装还得理解这套系统为什么能改变 AI 的行为。否则你遇到问题都不知道去哪儿排查。3.1 一切皆 SKILLS.md技能文件的标准形态superpowers 里的每个技能都是一个独立的 Markdown 文件文件名就是技能名文件内部用清晰的目录结构描述这个技能的用途。你可以把它理解为一份“操作规程”告诉 AI 这个技能在什么场景下用、用之前要满足什么条件、执行时按什么顺序做、做完之后提交什么成果。关键在于这份操作规程不是写给人看的而是写给模型看的。模型通过解析 Markdown 的结构化描述来“理解”流程并通过系统提示词的引用把它们挂载到自己的思维链里。3.2 技能的分层从规划到复盘覆盖完整生命周期我在实际使用中会把技能分成四层规划层、执行层、验证层、复盘层。规划层的技能负责把模糊需求拆解成可执行的任务清单执行层的技能负责具体的编码实现、接口联调验证层的技能负责测试编写、代码审查、问题复现复盘层的技能负责回顾过程中出现的坑、沉淀经验。这种分层的直接收益是AI 不再“一步到位”地写代码而是像人一样有节奏地推进。需求再复杂它也会先走规划流程把大任务拆成小步骤而不是一头扎进某个细节里出不来。3.3 AI 如何决定当前该用哪个技能这是整个机制里最巧妙、也最容易被误解的部分。很多人以为需要手动指定“你现在用测试技能”其实不用。技能文件的头部会写明触发条件AI 会根据当前任务的描述自动匹配最合适的技能。比如任务里包含“写测试”“验证行为”这类关键词时AI 会倾向选择测试相关技能包含“重构”“优化结构”时会倾向选择重构相关技能。这种自动匹配不是百分百准确所以技能文件里的触发条件写得越具体越好否则 AI 很容易选错。3.4 自定义技能的写法与注意事项superpowers 的一大优点是你可以往里面塞自己的技能。比如我给自己团队写了一个“Spring Boot 接口开发规范”技能内容就五段项目结构约定、DTO/VO 分层要求、异常处理方式、单元测试覆盖标准、接口文档格式。写自定义技能时最重要的不是格式花哨而是把“执行触发条件和最终交付物”写清楚。否则 AI 学会了流程但不知道交付标准照样产出不合格的结果。我踩过的坑是第一版技能只写了步骤没写质量标准AI 是照着流程走了但产出的代码连公司的代码风格都没遵守。4. 实战记录用 Java 项目完整跑一次需求开发说了这么多原理该上实战了。我选了一个真实的 Java 项目场景给一个已有的订单服务新增“订单取消”接口取消后要退还库存、记录日志、发消息通知。表面看是个 CRUD 需求实际牵扯到事务、库存并发、消息可靠性好几个环节足够检验 superpowers 的效果。4.1 需求输入越“脏”越好别自己先加工很多人用 AI 编程有个坏习惯生怕 AI 不理解需求自己先花半小时把需求翻译成技术方案。这恰恰是反模式。superpowers 的规划技能会自己完成需求拆解你只需要提供原始需求。我直接把产品经理的原话丢给了 Codex“用户下单后可以取消取消要退库存还要记录一下谁取消的最好通知运营。”没提事务、没提幂等、没提接口设计。AI 接到需求后先启动了规划流程把需求拆成了六项任务查询订单状态、校验取消条件、回退库存、写取消日志、发通知、处理事务边界。4.2 规划阶段拆任务的效果直接决定了后面成功的概率AI 拆完任务后并没有直接写代码而是先把任务清单展示给我确认。这一步我非常喜欢因为我能提前发现它理解偏差的地方它把“通知运营”理解成了“发短信”而我们的实际需求是“推送到运营后台的消息队列”。我把它纠正过来后AI 更新了任务清单才开始动工。整个过程和真实团队里“先对齐需求再开发”的流程几乎一致。这里也体现了几分钟前说的分层优势规划层先把路走对执行层才不会被带偏。4.3 测试先行TDD 流程在技能包里的落实superpowers 在执行阶段会自动引入“测试先行”的逻辑。它不是只让你补几个测试用例做做样子而是真的先写失败测试、再写实现、再到测试转绿。AI 生成的测试包括订单不存在时抛异常、重复取消时幂等返回、库存不足时取消失败、通知发送失败时不回滚订单主状态毕竟是异步通知。这些测试虽然谈不上多优雅但覆盖了核心业务规则。实现代码是在测试定义之后才动手的。4.4 调试循环当测试第一次跑挂时 AI 的处理方式没有任何一次开发是不出 bug 的关键是 AI 怎么面对失败。我故意在需求描述里留下一个坑库存表里加了乐观锁版本号但需求原文没提。AI 写的更新语句没带版本条件并发下会出现超卖超退风险但单测跑不出来。我提醒它“并发场景你考虑一下”之后它没有急着改代码而是先走了调试技能的流程写了一个并发模拟的小测试复现问题确认是版本号缺失导致更新丢失然后才修复实现并补上并发测试用例。这种“先复现、再定位、后修复”的顺序和高级工程师的排查路径是一致的。4.5 项目结构一致性AI 有没有遵守已有约定这个项目之前已经有一套 Controller-Service-Mapper 三层结构返回结果统一走ApiResponseT。superpowers 的技能里如果已经写入了“遵守现有项目结构”的约束AI 新生成的接口就会自动套用这层结构而不是自己另搞一套。我这里补一句如果你的项目有很明确的代码规范建议在自定义技能里写清楚比在需求描述里反复强调有效得多。因为这个信息不依赖每次对话的临时上下文而是每次都会加载的稳定技能。5. 工具协同把 superpowers 挂到 Codex CLI 和 Worbuddy 上组合用单用 superpowers Codex 已经很顺手了但很多人的实际工作流里不止一套工具。热词里反复出现的 Worbuddy 我也特意去试了试这里聊聊组合玩法。5.1 Codex CLI 作为执行引擎最简组合我的日常用法是终端打开 Codex CLI通过配置加载 superpowers 技能目录。这样每次对话我不用重复粘贴技能说明AI 自己知道该按什么流程走。这里有个不算坑但很值得注意的点Codex CLI 的配置加载是全局的你在这个项目里装的技能到了另一个项目也可能被加载。如果你的两个项目技术栈差异很大建议在技能文件里写上适用范围条件免得 Java 项目的技能跑到了 Python 项目里捣乱。5.2 Worbuddy 的角色任务编排与入口统一有关 Worbuddy 和 superpowers 的组合我的理解是Worbuddy 这类工具负责的是“任务编排和对话管理”这层它可以把多个 AI 工具收拢成一个入口再把拆解后的子任务分发给不同的执行引擎superpowers 则负责给这些引擎提供统一的技能底座。我实测的组合方式是把 superpowers 的技能目录作为共享资源Worbuddy 负责调度Codex CLI 负责执行。复杂需求先由 Worbuddy 的任务规划层拆解成子任务清单每个子任务交给 Codex CLI 执行时superpowers 的技能会自动约束执行方式。5.3 组合使用时的配置持久化技巧多工具组合最怕的是什么怕配置散落各处、升级后失联。我习惯把 superpowers 技能目录统一放在一个独立目录里所有工具都通过引用这个目录来加载而不是各自复制一份副本。这样做的直接好处是修改一个技能文件所有工具下次加载时都生效升级 superpowers 时只替换这一个目录不影响其他工具的配置。如果你现在正在折腾多工具组合强烈建议采用“单一技能源”这个思路。6. 真实使用中的坑与调优建议最后这部分是干货中的干货。以下问题我在使用中都真实遇到过也花了不少时间排查写出来给大家省点时间。6.1 上下文窗口消耗明显增大长会话容易“失忆”技能文件本身要占用上下文空间尤其当你加载的技能很多、每个文件都很长时AI 的上下文预算会被吃掉不少。长会话跑到后面AI 会开始忘记前面的信息表现就是“前面刚统一的命名规范后面又用回了旧写法”。解决办法有两个一是精简技能文件把每一条都写成“触发条件核心步骤交付标准”三段式删掉那些文艺的解释性文字二是把大任务拆成多个短会话每个会话只开一个技能而不是一个会话里塞四种技能轮换用。6.2 技能太多导致决策混乱AI 不知道该选哪个技能文件超过二十个之后AI 的“自动选技能”功能会开始出问题。我见过 AI 在同一个任务里连续切换三个技能每个都执行到一半最后产出一个四不像的结果。经验法则是生产环境里的激活技能控制在十个以内。不常用的技能可以保留文件但通过配置把它们排除在默认加载列表之外需要用的时候手动触发。这就像人的工具箱常用的放外面不常用的收抽屉里而不是全部摊在桌面上。6.3 和编辑器内 AI 插件叠用时的行为冲突我有一段时间同时开着 VS Code 的 Copilot 插件和终端里的 Codex CLI两边都挂着 superpowers。结果发现编辑器内的 AI 经常重复完成一些本来已经由终端的 Codex 完成的工作比如自动补全已经生成的注释块。后来我明确划分了分工编辑器内 AI 只负责实时补全和短对话问答所有完整流程开发规划、测试、重构都放到 Codex CLI 里跑。划分清楚之后冲突基本消失体验也顺滑了很多。6.4 升级时机别追新先看兼容性superpowers 迭代速度不慢我自己曾经手痒第一时间升级结果新版本改了技能文件的内部结构我的自定义技能全部失效。那次之后我就学乖了升级前先看变更记录确认没动我这边的接口再把新版本拉下来。如果你也写了不少自定义技能建议在大版本升级前先备份技能目录并在升级后跑一个最小验证任务确认核心技能正常再切换。7. 写在最后的经验之谈这套东西我用到现在也有几个月了最大的感受是它不能让你从“不会写代码”变成“会写代码”但能把一个“会用 AI 写代码的人”变成“会用 AI 写生产级代码的人”。如果你已经受够了 AI 给出正确但毫无工程素养的答案不妨先从一个技能开始——比如只加载“规划”技能跑一个需求感受一下它如何改变你和 AI 的协作方式。我的个人建议是第一周先什么都别改用默认技能包跑三到五个真实需求记录 AI 的行为变化第二周再开始尝试写自定义技能从你最痛的那个环节切入比如代码审查、并发调试、接口规范。一次只改一个点比一次搭建整套工作流更容易出成果。另一个心得是无论你用什么工具组合核心思路都是把“一次性提示词”沉淀成“可复用技能”。今天你在这里花时间装的不是一套软件而是一套让 AI 变得更像同事的行为模式。这个投资长期看是货真价实的复利。
