如果你最近在折腾 Codex CLI 这类终端里的 AI 编程助手大概率已经发现一个现象同一个模型在别人手里能一个上午重构一个模块到你手里却经常答非所问、改东坏西。问题往往不在模型而在你没有给 AI 一套稳定的“超能力”。superpowers 就是这么个东西——它不是某个大模型而是围绕 Codex CLI 打造的一套技能增强方案。这篇文章不讲广告词只讲我在本地环境里把 superpowers 装好、跑通、真正用到 Java 项目里的全过程以及和 worbuddy 这类工作流工具搭配时踩过的坑和最终的组合方式。适合已经接触过 Codex CLI、想让输出质量再上一个台阶的开发者参考。1. superpowers 是为解决什么问题出现的1.1 裸 Codex CLI 的三大痛点先说结论不是 Codex CLI 不强是大多数人没用出它的上限。我在连续用了一个月“裸”Codex 之后发现它有三类非常典型的问题。第一上下文不稳定。同一个仓库、同一个需求今天问它是这个方案明天换一种措辞它可能给你另一种方案。不是模型抽风而是你对任务的描述没有形成一个稳定的“标准作业程序”每次对话的隐含约束不一样输出自然漂移。第二多步骤任务容易断档。让 AI 改一个方法很容易但让它“先梳理依赖、再设计重构方案、再动手改、最后补测试”就很容易在某一步丢失之前的上下文。尤其是代码量超过几百行的时候经常改到一半它忘了最初的目标约束开始自由发挥。第三输出质量不可控。裸 Codex 生成的代码像实习生写的能跑但边界条件处理不完整、命名不规范、异常路径缺失。你需要反复 review 再让它改一来一回耗掉大量时间。1.2 superpowers 的核心思路把灵光一现变成稳定输出superpowers 的解法其实很朴素把“你临时对 AI 说的话”变成“结构化的技能模板”。每个技能模板包含完整的任务目标、输入参数、执行步骤、质量检查清单和输出格式。AI 每次执行同一个技能时看到的是一套固定的“操作手册”而不是用户随口说的一句话。这样做的效果非常直接——输出漂移大幅减少多步骤任务的上下文也能通过模板里的阶段性检查点兜住。举个例子。你直接说“帮我重构一下这个订单服务”AI 只能猜。但如果你加载一个refactor-java技能它会自动按“分析现状→识别风险→拆分步骤→逐项实施→自测验证”的顺序执行并且在每个阶段强制输出中间结果。这就像同一个实习生你给他一份带检查点的任务单和他只听到一句“你去把这事办了”效率完全两回事。2. 安装与初始化半小时跑通基础环境2.1 前置依赖检查装 superpowers 之前我建议先确认三件事都就绪否则后面会绕弯路。第一Codex CLI 本身要能正常工作。不同版本对配置目录的约定有差异但基本都在~/.codex/下。先跑一句简单的代码补全确认终端里的 AI 助手已经能访问模型。第二电脑里有 git 和 curl因为技能包的获取和更新都依赖它们。第三终端最好支持 UTF-8 和较长的路径Windows 用户建议直接用 WSL别在 PowerShell 里硬折腾——我见过的绝大多数安装失败都发生在路径转义上。这一步没有太多捷径但有个小技巧安装之前先把 Codex CLI 的登录态确认好很多人在装完技能包之后才发现 AI 请求根本没发出去排查了半天才发现是认证早过期了。2.2 获取技能包与目录结构拿到 superpowers 技能包的方式有两种一种是直接从发布页克隆仓库另一种是如果它已经封装成了安装脚本用包管理器安装就好。我用的方式比较保守直接克隆到本地固定目录# 从官方发布页获取仓库地址后执行这里以通用位置为例 git clone superpowers技能包仓库地址 ~/.superpowers克隆完成后先别急着用花两分钟看一下目录结构。典型的技能包目录长这样~/.superpowers/ ├── README.md ├── config/ │ └── skills.json # 技能清单与加载规则 ├── skills/ │ ├── analyze-code/ # 代码分析技能 │ ├── plan-refactor/ # 重构方案设计技能 │ ├── implement-change/ # 编码实施技能 │ └── review-output/ # 代码审查技能 └── templates/ └── task-instruction.md # 通用任务指令模板这个结构本身就是设计思想的一部分“技能”不是一段死板的 prompt而是一个带元信息、带参考文件、带输出模板的完整目录。每个技能目录里通常还有一个SKILL.md描述该技能的触发条件、执行步骤和退出标准。2.3 初始化配置与验证技能包放好后需要把它告诉 Codex CLI。常见做法是在 Codex 的配置目录里增加一段全局指令让它每次运行时都去加载~/.superpowers/skills/下的技能定义。我的做法是在~/.codex/下新建一个CLAUDE.md或者直接修改全局指令文件不同版本文件名不同注意看 FAQ像这样# 全局指令 始终加载 ~/.superpowers/skills/ 下的技能定义。 当用户请求包含技能名称时必须严格按照对应 SKILL.md 中的步骤执行。改完后启动 Codex输入/help或/skills之类的命令看技能列表是否出现。如果能看到analyze-code、plan-refactor这些条目说明加载成功了。首次跑通之后记得把超级包目录加入自己的 dotfiles 管理方便多台机器同步。3. 把 superpowers 用起来从交互式会话到自定义技能3.1 在 Codex 会话里调用技能技能加载好之后调用方式非常自然直接在对话里点名即可。比如我会输入使用 analyze-code 技能分析 src/main/java/com/example/order/OrderService.java这时 AI 会进入“分析模式”先读文件、提取类结构和方法调用链然后按技能模板输出依赖清单、复杂度评估和潜在风险点。与传统随手提问最大的区别在于它每次都会输出固定的中间产物——依赖图、风险表、建议方案而不是给你一段泛泛而谈的“这段代码可以优化”。如果你只想要结果不想要过程也可以在技能名后面加/silent之类的参数看具体版本的实现但我个人建议前期不要关掉过程输出因为过程就是培养代码判断力的教材而且后续接入自动化工作流时这些中间产物能直接作为下一步的输入。3.2 写出你的第一个技能包看完自带的技能大多数人会想写自己的。这个一定要学会因为 superpowers 的灵魂就是“把你的团队规范固化下来”。我以“Java 接口设计检查”为例写一个最简单的技能包。先在~/.superpowers/skills/下建一个目录比如review-api-design/里面放一个SKILL.md--- name: review-api-design description: 检查Java接口设计是否符合团队规范识别REST接口的边界与兼容性问题 inputs: target: 接口类或方法路径 backward_compatible: 是否必须保持向后兼容默认 true --- ## 检查清单 1. 方法命名是否符合动词短语规范 2. 参数对象是否包含不必要的可空字段 3. 返回值是否暴露了内部实现细节 4. 异常是否做了边界转换是否泄露了底层异常 5. 接口版本策略是否明确 6. 响应结构是否具备扩展性是否直接返回裸Map/List ## 输出格式 按表格输出问题等级 / 位置 / 问题描述 / 修改建议 最后必须给出总体结论通过、有条件通过、不通过。就这么简单。AI 读到这个文件就会严格按清单执行。你不需要写复杂的代码技能的实质是“约束 AI 的行为边界”而不是教它怎么做某件事。3.3 一条能直接抄的完整指令模板有人会问技能包是一次性定义那临时任务怎么办我的习惯是结合模板文件使用。在templates/task-instruction.md里放一个通用任务模板每次手动套用### 任务背景 {一句话说明业务背景} ### 目标 {可验证的目标如实现XX功能满足YY边界条件} ### 约束 - 技术栈{如 Java 17 Spring Boot 3} - 不允许修改公共接口签名 - 必须处理超时与重试 ### 交付物 - 代码变更 - 变更说明为什么这么做 - 自测结果调用的时候直接把模板复制进对话或者封装成一个new-task技能。这样即使面对全新任务AI 也知道“公司要求我按什么格式交付”不会给你扔一堆毫无解释的代码就完事。4. 实战记录我用 superpowers 重构了一个 Java 订单服务4.1 为什么选 Java 场景来说明选 Java 不是因为 superpowers 只适合 Java而是 Java 项目的“结构化痕迹”最重类、接口、依赖注入、异常体系都摆在那特别适合展示技能编排如何降低重构风险。如果换成 Python 或 Go逻辑一样只是文件形态不同。我拿一个真实项目里的订单服务当例子。这个类的核心方法是createOrder大概 300 行里面揉杂了库存校验、库存预扣、支付回调、消息发送、优惠券核销五件事。每次改需求都心惊胆战因为五件事耦合在一起动一处可能连环炸。4.2 五步技能编排过程拆解我没有直接让它改代码而是按流程调了五个技能串成一条流水线。第一步analyze-code分析OrderService.java。AI 输出了一张依赖列表把createOrder里五个子流程每一条的调用链都列了出来标记了哪些是外部 IOC 依赖、哪些是私有方法、哪些是静态调用。这一步让我第一次清楚地看到了这个方法的完整扇出fan-out。第二步plan-refactor设计重构方案。AI 根据分析结果提出了“按业务子域拆分为五个策略类由订单领域服务编排”的方案并且标出了三个高风险点库存预扣不是原子的、消息发送失败会静默吞掉、优惠券核销依赖订单状态变更顺序。第三步implement-change按方案实施。这一步我设了硬约束不允许改变对外行为、不允许改动数据库表结构、不允许新增第三方依赖。AI 生成的代码基本符合要求拆分出来的五个类各司其职原有createOrder变成一段清晰的事件编排逻辑。第四步review-output做 AI 自审。它对照团队规范发现了两个问题一个类是纯工具方法却没有做成静态方法、一处异常被包装后丢失了原始错误信息。这些在人工 review 阶段也都是常见的点。第五步跑测试并让 AI 补齐缺失的单测用例。原本项目的单测覆盖只有 30%重构后我把关键路径的单测补到了 85% 左右。4.3 前后对比质量与效率的变化这次重构从开始分析到测试补齐总共花了一个下午其中我的有效参与时间大概一小时其余都是 AI 产出、我 review。对比以往纯手工重构同类模块的节奏——通常需要两天左右——提升是明显的。更重要的是整个过程有中间产物沉淀依赖清单和风险表直接成为了评审材料。这不是一次侥幸。后来我又用同样的流程处理了三四个模块每次都稳定产出高质量结果。我自己的感受是superpowers 最大的价值不是让 AI 一次写对而是让 AI 的“错”变得可见、可预期、可修正。5. 进阶玩法接入 worbuddy 这类工作流调度器5.1 worbuddy 解决了 AI 编程的另一个问题交互式会话再强终究是“人盯着它干”。当你希望 AI 定时巡检代码、自动生成每日报告、或者把一个多步骤任务完全交给机器跑的时候就需要另一层工具工作流调度器。worbuddy社区里也有人直接叫它 workflow buddy就是干这个的——它负责流程编排决定什么时间、以什么顺序、用什么输入去调用 AI 或调用某个技能。一句话总结区别superpowers 解决的是“单个任务做得好不好”worbuddy 解决的是“整个流程走不走得通”。两者天然互补。5.2 把 superpowers 技能注册成工作流节点大多数类似 worbuddy 的调度器都支持把命令或脚本注册成节点。我习惯把 Codex CLI 的调用封装成一个 shell 函数然后在调度配置里直接引用。一个典型的封装脚本run-skill.sh长这样#!/bin/bash # 用法: ./run-skill.sh 技能名 目标路径 额外参数 SKILL_NAME$1 TARGET$2 shift 2 codex exec --skill $SKILL_NAME --input $TARGET --params $如果调度器支持 YAML 配置注册节点就很简单nodes: - name: analyze-order-service command: ./run-skill.sh analyze-code src/main/java/com/example/order/OrderService.java - name: plan-refactor command: ./run-skill.sh plan-refactor order-service - name: implement-changes command: ./run-skill.sh implement-change order-service - name: review-changes command: ./run-skill.sh review-output order-service这样五个本来要在终端里手动输入的命令变成了可以被调度器自动排序执行的节点。每个节点的输出都会落在工作目录里下一个节点可以读取实现了真正意义上的“AI 流水线”。5.3 三条可以直接复用的工作流我实际用下来有三条工作流最值得搭。第一条是每日代码巡检。每天早上定时执行“分析所有最近变更文件→按规范检查→生成问题清单→发送到团队群”。以前靠人抽检现在全自动虽然不能完全替代人工 review但能把低级问题拦在第一道线外。第二条是重构流水线。就是上面订单服务的五步流程适合在业务低峰期批量处理历史技术债项目。第三条是新需求落地闭环。从需求描述开始先让 AI 用plan-refactor生成技术方案再进入implement-change编码随后review-output自审最后补测试。这条流水线跑通之后我接需求的速度明显变快因为 AI 产出的初稿质量已经很接近可评审状态。6. 避坑清单与我的真实感受6.1 高频问题排查表折腾这套东西两周我整理了一张排查表遇到问题先对号入座现象根因处理方式技能列表加载不出来全局指令里的路径写错或权限不对检查~/.superpowers是否可读路径是否用了~展开AI 执行技能时忽略步骤技能的SKILL.md里步骤描述过于模糊在技能文档里增加“必须输出中间产物”等强制约定多任务串联时上下文丢失每个节点重新启动了新进程使用输出文件传递中间产物或改用长会话模式Java 项目分析报错依赖没下载完整AI 拿不到全部类结构先让项目构建通过再运行分析与 worbuddy 集成后命令超时Codex CLI 需要交互式确认为命令添加非交互参数如--yes或等价配置生成代码不符合公司规范技能模板没写清楚规范细节把团队规范原文写进技能文档而不是只写一句“遵守规范”这张表里的内容看着简单但每一条都是我实际踩过的尤其是“AI 执行技能时忽略步骤”这个问题一度让我怀疑技能机制没用。后来才发现是技能文档里写了太多“考虑合理性”之类的模糊表述AI 的默认行为就是跳过它认为不重要的内容。给 AI 的指令必须像给新人的任务单一样明确、可验证、不留自由裁量空间。6.2 几条写在最后的心得第一不要一上来就追求全自动。先把交互式会话里的技能调用跑顺手让 AI 的产出风格稳定下来再考虑接入 worbuddy 做自动化。跳过中间步骤直接上全套出了问题很难分清是技能写得不好还是调度配置有误。第二技能包要当成团队资产来维护。最好的做法是把技能目录放进共享仓库每次复盘时把“这次 review 发现的高频问题”更新到对应技能的检查清单里。技能是活的定期迭代价值才会越来越大。第三AI 编程工具的上限取决于你把自己的工作流程想得多清楚。superpowers 本质上是一面镜子你能写出多细的技能模板说明你对自己业务的理解有多深。工具本身不神秘真正值钱的是沉淀下来的流程和规范。就我个人而言从裸 Codex 到全套 superpowers 加工作流调度最大的变化不是“代码写得快了”而是“代码评审的确定性提高了”——我可以更早地知道 AI 打算怎么做、做得对不对而不是等它写完再猜。如果你也在用 Codex CLI且觉得输出还不够稳真的建议从今天开始试着把你的下一个任务写成一份技能模板。 superpowers实战指南：稳定Codex CLI输出，打造AI编程工作流
如果你最近在折腾 Codex CLI 这类终端里的 AI 编程助手大概率已经发现一个现象同一个模型在别人手里能一个上午重构一个模块到你手里却经常答非所问、改东坏西。问题往往不在模型而在你没有给 AI 一套稳定的“超能力”。superpowers 就是这么个东西——它不是某个大模型而是围绕 Codex CLI 打造的一套技能增强方案。这篇文章不讲广告词只讲我在本地环境里把 superpowers 装好、跑通、真正用到 Java 项目里的全过程以及和 worbuddy 这类工作流工具搭配时踩过的坑和最终的组合方式。适合已经接触过 Codex CLI、想让输出质量再上一个台阶的开发者参考。1. superpowers 是为解决什么问题出现的1.1 裸 Codex CLI 的三大痛点先说结论不是 Codex CLI 不强是大多数人没用出它的上限。我在连续用了一个月“裸”Codex 之后发现它有三类非常典型的问题。第一上下文不稳定。同一个仓库、同一个需求今天问它是这个方案明天换一种措辞它可能给你另一种方案。不是模型抽风而是你对任务的描述没有形成一个稳定的“标准作业程序”每次对话的隐含约束不一样输出自然漂移。第二多步骤任务容易断档。让 AI 改一个方法很容易但让它“先梳理依赖、再设计重构方案、再动手改、最后补测试”就很容易在某一步丢失之前的上下文。尤其是代码量超过几百行的时候经常改到一半它忘了最初的目标约束开始自由发挥。第三输出质量不可控。裸 Codex 生成的代码像实习生写的能跑但边界条件处理不完整、命名不规范、异常路径缺失。你需要反复 review 再让它改一来一回耗掉大量时间。1.2 superpowers 的核心思路把灵光一现变成稳定输出superpowers 的解法其实很朴素把“你临时对 AI 说的话”变成“结构化的技能模板”。每个技能模板包含完整的任务目标、输入参数、执行步骤、质量检查清单和输出格式。AI 每次执行同一个技能时看到的是一套固定的“操作手册”而不是用户随口说的一句话。这样做的效果非常直接——输出漂移大幅减少多步骤任务的上下文也能通过模板里的阶段性检查点兜住。举个例子。你直接说“帮我重构一下这个订单服务”AI 只能猜。但如果你加载一个refactor-java技能它会自动按“分析现状→识别风险→拆分步骤→逐项实施→自测验证”的顺序执行并且在每个阶段强制输出中间结果。这就像同一个实习生你给他一份带检查点的任务单和他只听到一句“你去把这事办了”效率完全两回事。2. 安装与初始化半小时跑通基础环境2.1 前置依赖检查装 superpowers 之前我建议先确认三件事都就绪否则后面会绕弯路。第一Codex CLI 本身要能正常工作。不同版本对配置目录的约定有差异但基本都在~/.codex/下。先跑一句简单的代码补全确认终端里的 AI 助手已经能访问模型。第二电脑里有 git 和 curl因为技能包的获取和更新都依赖它们。第三终端最好支持 UTF-8 和较长的路径Windows 用户建议直接用 WSL别在 PowerShell 里硬折腾——我见过的绝大多数安装失败都发生在路径转义上。这一步没有太多捷径但有个小技巧安装之前先把 Codex CLI 的登录态确认好很多人在装完技能包之后才发现 AI 请求根本没发出去排查了半天才发现是认证早过期了。2.2 获取技能包与目录结构拿到 superpowers 技能包的方式有两种一种是直接从发布页克隆仓库另一种是如果它已经封装成了安装脚本用包管理器安装就好。我用的方式比较保守直接克隆到本地固定目录# 从官方发布页获取仓库地址后执行这里以通用位置为例 git clone superpowers技能包仓库地址 ~/.superpowers克隆完成后先别急着用花两分钟看一下目录结构。典型的技能包目录长这样~/.superpowers/ ├── README.md ├── config/ │ └── skills.json # 技能清单与加载规则 ├── skills/ │ ├── analyze-code/ # 代码分析技能 │ ├── plan-refactor/ # 重构方案设计技能 │ ├── implement-change/ # 编码实施技能 │ └── review-output/ # 代码审查技能 └── templates/ └── task-instruction.md # 通用任务指令模板这个结构本身就是设计思想的一部分“技能”不是一段死板的 prompt而是一个带元信息、带参考文件、带输出模板的完整目录。每个技能目录里通常还有一个SKILL.md描述该技能的触发条件、执行步骤和退出标准。2.3 初始化配置与验证技能包放好后需要把它告诉 Codex CLI。常见做法是在 Codex 的配置目录里增加一段全局指令让它每次运行时都去加载~/.superpowers/skills/下的技能定义。我的做法是在~/.codex/下新建一个CLAUDE.md或者直接修改全局指令文件不同版本文件名不同注意看 FAQ像这样# 全局指令 始终加载 ~/.superpowers/skills/ 下的技能定义。 当用户请求包含技能名称时必须严格按照对应 SKILL.md 中的步骤执行。改完后启动 Codex输入/help或/skills之类的命令看技能列表是否出现。如果能看到analyze-code、plan-refactor这些条目说明加载成功了。首次跑通之后记得把超级包目录加入自己的 dotfiles 管理方便多台机器同步。3. 把 superpowers 用起来从交互式会话到自定义技能3.1 在 Codex 会话里调用技能技能加载好之后调用方式非常自然直接在对话里点名即可。比如我会输入使用 analyze-code 技能分析 src/main/java/com/example/order/OrderService.java这时 AI 会进入“分析模式”先读文件、提取类结构和方法调用链然后按技能模板输出依赖清单、复杂度评估和潜在风险点。与传统随手提问最大的区别在于它每次都会输出固定的中间产物——依赖图、风险表、建议方案而不是给你一段泛泛而谈的“这段代码可以优化”。如果你只想要结果不想要过程也可以在技能名后面加/silent之类的参数看具体版本的实现但我个人建议前期不要关掉过程输出因为过程就是培养代码判断力的教材而且后续接入自动化工作流时这些中间产物能直接作为下一步的输入。3.2 写出你的第一个技能包看完自带的技能大多数人会想写自己的。这个一定要学会因为 superpowers 的灵魂就是“把你的团队规范固化下来”。我以“Java 接口设计检查”为例写一个最简单的技能包。先在~/.superpowers/skills/下建一个目录比如review-api-design/里面放一个SKILL.md--- name: review-api-design description: 检查Java接口设计是否符合团队规范识别REST接口的边界与兼容性问题 inputs: target: 接口类或方法路径 backward_compatible: 是否必须保持向后兼容默认 true --- ## 检查清单 1. 方法命名是否符合动词短语规范 2. 参数对象是否包含不必要的可空字段 3. 返回值是否暴露了内部实现细节 4. 异常是否做了边界转换是否泄露了底层异常 5. 接口版本策略是否明确 6. 响应结构是否具备扩展性是否直接返回裸Map/List ## 输出格式 按表格输出问题等级 / 位置 / 问题描述 / 修改建议 最后必须给出总体结论通过、有条件通过、不通过。就这么简单。AI 读到这个文件就会严格按清单执行。你不需要写复杂的代码技能的实质是“约束 AI 的行为边界”而不是教它怎么做某件事。3.3 一条能直接抄的完整指令模板有人会问技能包是一次性定义那临时任务怎么办我的习惯是结合模板文件使用。在templates/task-instruction.md里放一个通用任务模板每次手动套用### 任务背景 {一句话说明业务背景} ### 目标 {可验证的目标如实现XX功能满足YY边界条件} ### 约束 - 技术栈{如 Java 17 Spring Boot 3} - 不允许修改公共接口签名 - 必须处理超时与重试 ### 交付物 - 代码变更 - 变更说明为什么这么做 - 自测结果调用的时候直接把模板复制进对话或者封装成一个new-task技能。这样即使面对全新任务AI 也知道“公司要求我按什么格式交付”不会给你扔一堆毫无解释的代码就完事。4. 实战记录我用 superpowers 重构了一个 Java 订单服务4.1 为什么选 Java 场景来说明选 Java 不是因为 superpowers 只适合 Java而是 Java 项目的“结构化痕迹”最重类、接口、依赖注入、异常体系都摆在那特别适合展示技能编排如何降低重构风险。如果换成 Python 或 Go逻辑一样只是文件形态不同。我拿一个真实项目里的订单服务当例子。这个类的核心方法是createOrder大概 300 行里面揉杂了库存校验、库存预扣、支付回调、消息发送、优惠券核销五件事。每次改需求都心惊胆战因为五件事耦合在一起动一处可能连环炸。4.2 五步技能编排过程拆解我没有直接让它改代码而是按流程调了五个技能串成一条流水线。第一步analyze-code分析OrderService.java。AI 输出了一张依赖列表把createOrder里五个子流程每一条的调用链都列了出来标记了哪些是外部 IOC 依赖、哪些是私有方法、哪些是静态调用。这一步让我第一次清楚地看到了这个方法的完整扇出fan-out。第二步plan-refactor设计重构方案。AI 根据分析结果提出了“按业务子域拆分为五个策略类由订单领域服务编排”的方案并且标出了三个高风险点库存预扣不是原子的、消息发送失败会静默吞掉、优惠券核销依赖订单状态变更顺序。第三步implement-change按方案实施。这一步我设了硬约束不允许改变对外行为、不允许改动数据库表结构、不允许新增第三方依赖。AI 生成的代码基本符合要求拆分出来的五个类各司其职原有createOrder变成一段清晰的事件编排逻辑。第四步review-output做 AI 自审。它对照团队规范发现了两个问题一个类是纯工具方法却没有做成静态方法、一处异常被包装后丢失了原始错误信息。这些在人工 review 阶段也都是常见的点。第五步跑测试并让 AI 补齐缺失的单测用例。原本项目的单测覆盖只有 30%重构后我把关键路径的单测补到了 85% 左右。4.3 前后对比质量与效率的变化这次重构从开始分析到测试补齐总共花了一个下午其中我的有效参与时间大概一小时其余都是 AI 产出、我 review。对比以往纯手工重构同类模块的节奏——通常需要两天左右——提升是明显的。更重要的是整个过程有中间产物沉淀依赖清单和风险表直接成为了评审材料。这不是一次侥幸。后来我又用同样的流程处理了三四个模块每次都稳定产出高质量结果。我自己的感受是superpowers 最大的价值不是让 AI 一次写对而是让 AI 的“错”变得可见、可预期、可修正。5. 进阶玩法接入 worbuddy 这类工作流调度器5.1 worbuddy 解决了 AI 编程的另一个问题交互式会话再强终究是“人盯着它干”。当你希望 AI 定时巡检代码、自动生成每日报告、或者把一个多步骤任务完全交给机器跑的时候就需要另一层工具工作流调度器。worbuddy社区里也有人直接叫它 workflow buddy就是干这个的——它负责流程编排决定什么时间、以什么顺序、用什么输入去调用 AI 或调用某个技能。一句话总结区别superpowers 解决的是“单个任务做得好不好”worbuddy 解决的是“整个流程走不走得通”。两者天然互补。5.2 把 superpowers 技能注册成工作流节点大多数类似 worbuddy 的调度器都支持把命令或脚本注册成节点。我习惯把 Codex CLI 的调用封装成一个 shell 函数然后在调度配置里直接引用。一个典型的封装脚本run-skill.sh长这样#!/bin/bash # 用法: ./run-skill.sh 技能名 目标路径 额外参数 SKILL_NAME$1 TARGET$2 shift 2 codex exec --skill $SKILL_NAME --input $TARGET --params $如果调度器支持 YAML 配置注册节点就很简单nodes: - name: analyze-order-service command: ./run-skill.sh analyze-code src/main/java/com/example/order/OrderService.java - name: plan-refactor command: ./run-skill.sh plan-refactor order-service - name: implement-changes command: ./run-skill.sh implement-change order-service - name: review-changes command: ./run-skill.sh review-output order-service这样五个本来要在终端里手动输入的命令变成了可以被调度器自动排序执行的节点。每个节点的输出都会落在工作目录里下一个节点可以读取实现了真正意义上的“AI 流水线”。5.3 三条可以直接复用的工作流我实际用下来有三条工作流最值得搭。第一条是每日代码巡检。每天早上定时执行“分析所有最近变更文件→按规范检查→生成问题清单→发送到团队群”。以前靠人抽检现在全自动虽然不能完全替代人工 review但能把低级问题拦在第一道线外。第二条是重构流水线。就是上面订单服务的五步流程适合在业务低峰期批量处理历史技术债项目。第三条是新需求落地闭环。从需求描述开始先让 AI 用plan-refactor生成技术方案再进入implement-change编码随后review-output自审最后补测试。这条流水线跑通之后我接需求的速度明显变快因为 AI 产出的初稿质量已经很接近可评审状态。6. 避坑清单与我的真实感受6.1 高频问题排查表折腾这套东西两周我整理了一张排查表遇到问题先对号入座现象根因处理方式技能列表加载不出来全局指令里的路径写错或权限不对检查~/.superpowers是否可读路径是否用了~展开AI 执行技能时忽略步骤技能的SKILL.md里步骤描述过于模糊在技能文档里增加“必须输出中间产物”等强制约定多任务串联时上下文丢失每个节点重新启动了新进程使用输出文件传递中间产物或改用长会话模式Java 项目分析报错依赖没下载完整AI 拿不到全部类结构先让项目构建通过再运行分析与 worbuddy 集成后命令超时Codex CLI 需要交互式确认为命令添加非交互参数如--yes或等价配置生成代码不符合公司规范技能模板没写清楚规范细节把团队规范原文写进技能文档而不是只写一句“遵守规范”这张表里的内容看着简单但每一条都是我实际踩过的尤其是“AI 执行技能时忽略步骤”这个问题一度让我怀疑技能机制没用。后来才发现是技能文档里写了太多“考虑合理性”之类的模糊表述AI 的默认行为就是跳过它认为不重要的内容。给 AI 的指令必须像给新人的任务单一样明确、可验证、不留自由裁量空间。6.2 几条写在最后的心得第一不要一上来就追求全自动。先把交互式会话里的技能调用跑顺手让 AI 的产出风格稳定下来再考虑接入 worbuddy 做自动化。跳过中间步骤直接上全套出了问题很难分清是技能写得不好还是调度配置有误。第二技能包要当成团队资产来维护。最好的做法是把技能目录放进共享仓库每次复盘时把“这次 review 发现的高频问题”更新到对应技能的检查清单里。技能是活的定期迭代价值才会越来越大。第三AI 编程工具的上限取决于你把自己的工作流程想得多清楚。superpowers 本质上是一面镜子你能写出多细的技能模板说明你对自己业务的理解有多深。工具本身不神秘真正值钱的是沉淀下来的流程和规范。就我个人而言从裸 Codex 到全套 superpowers 加工作流调度最大的变化不是“代码写得快了”而是“代码评审的确定性提高了”——我可以更早地知道 AI 打算怎么做、做得对不对而不是等它写完再猜。如果你也在用 Codex CLI且觉得输出还不够稳真的建议从今天开始试着把你的下一个任务写成一份技能模板。