如果你试过让 AI 编程助手一口气完成一个完整功能大概率会遇到这种情况让它写个函数又快又准让它按需求把项目从零搭起来它就开始东一榔头西一棒子代码能跑但心态崩了。我一度以为这是模型能力不够直到我认真用了 superpowers 这个技能包才发现问题出在流程上——助手缺的不是智能是一套资深工程师的做事流程。superpowers 就是用来补上这一环的工具它把规划、测试驱动开发、系统重构、调试这些能力封装成 AI 编程助手比如 Codex CLI可以主动调用的超能力让助手从代码片段生成器变成会干活的工程搭档。这篇东西不讲官方文档里有的废话只说我实际使用后的真实体验怎么装、怎么用、怎么配合 Java 项目落地以及我踩过的几个坑。1. superpowers 解决的是AI 编程助手不会干活的问题先说清楚它到底解决什么问题因为很多人装完以后用了一下觉得这不就是让 AI 多写点字吗然后卸载。这是没搞懂它的设计逻辑。1.1 从代码片段生成器到项目工程师的距离单独让 AI 写一个冒泡排序、一个 REST 接口它表现很好。但一个真实的项目任务往往涉及多个文件、有依赖关系、有边界条件、有执行顺序。模型在单点上是强的但在一长串任务上容易只见树木不见森林——它不知道先改哪个后改哪个改完这个会不会破坏那个更不懂写任何代码之前应该先把需求想清楚。superpowers 的思路不是给模型加更多参数而是把工作流程外置。它用一批定义好的技能skill引导 AI 按照稳定、可复用的步骤干活。这就好比一个新人程序员本身脑子不差但第一次进团队没人告诉他怎么提测、怎么写测试、怎么走 review他会乱superpowers 就是那个把流程写成白纸黑字的团队规范。1.2 核心思路把资深工程师的做事流程变成可触发的技能在我实际使用过程中superpowers 的触发方式非常接近自然语言。你在对话里说帮我规划一下这个需求它就会调用规划技能先输出目标、约束、任务拆解你说用 TDD 的方式实现这个功能它就会按照先写失败测试、再实现、再重构的顺序执行。这和普通插件的区别在于普通插件是给 IDE 加按钮superpowers 是给 AI 加思考模板。你教 AI要规划它可能只是嘴上答应你给它一套规划技能它就会真的按步骤产出可检查的中间产物。这个区别非常关键也是它值得折腾安装的原因。1.3 它到底能做什么我整理一下我常用的几类能力项目规划把需求拆成有依赖关系的任务产出实现顺序和验收条件。设计共识在写代码前先描述系统边界、模块划分、数据流防止后期大改。TDD 工作流强制先写失败测试再写最小实现最后重构。系统级重构基于测试保障做代码整理而不是拍脑袋改结构。调试辅助要求 AI 先复现问题、提出假设再定位和修复。不同版本提供的技能细节会有差异但骨架基本是围绕让 AI 按工程流程产出可审查的中间产物来设计的。理解了这一点你才知道该在什么场景下去用它而不是装完跑个 demo 就丢一边。2. 安装与接入让 Codex CLI 认识 superpowers这部分直接上干货。以我当前在用的版本来讲我是在 macOS 上操作的用了 Node.js 20 LTS 和 Git。superpowers 本质是个技能包不挑语言但你需要有一个能调用它的 AI 编程助手。我这边主力是 Codex CLI所以下面都以它为例。2.1 环境准备安装前先确认三件事你的 Codex CLI 能正常跑起来至少成功登录过、能完成一次简单对话。Node.js 版本别太老建议 18 以上我用的是 20。网络环境能正常访问代码仓库即可很多安装异常其实出在访问仓库不稳定先检查网络配置再动手不要一上来就怀疑工具本身。2.2 获取 superpowers克隆到本地还是用包管理器社区里常见的获取方式有两种一种是直接克隆仓库另一种是通过包管理器安装。我首选克隆方式因为 superpowers 的更新频率不算低git pull拉一下就能升级也方便你改里面的技能模板。我当时是把它放到了~/.superpowers这个固定目录git clone https://github.com/obra/superpowers.git ~/.superpowers这个目录位置不是死的你可以放到任何地方但建议选一个固定路径因为后面配置文件里要反复引用它。用包管理器安装的方式我也试过好处是依赖自动装好坏处是升级路径不直观对想改模板的人来说不太友好。提示如果你用的是 Codex CLI 以外的 AI 编程工具安装路径和声明方式可能略有出入但核心思路一样——把技能目录暴露给 AI 助手。2.3 在 Codex 的配置里声明技能目录这一步是关键。很多人装完 skill 包发现 AI 完全没反应就是因为 AI 助手根本不知道这个目录存在。Codex CLI 会读取项目里的codex.md或者全局的~/.codex/config.toml。我当时是在项目的codex.md里加了这样一段说明# 项目说明 本项目使用 superpowers 技能集。在以下目录可以找到技能定义 ~/.superpowers/skills 当你需要规划、设计、TDD、重构、调试时请主动使用这些技能。写清楚以后每次开启新会话Codex 就会在上下文中看到这些信息知道在什么场景下调用什么技能。这一步很啰嗦但极其重要它决定了 AI 有没有技能意识。2.4 激活与验证怎么确认安装真的成功了激活不是跑一条命令那么简单。你要做的是在一个新对话里故意让 AI 触发某个技能比如用项目规划技能帮我拆解一个登录功能的实现步骤。如果 AI 真的按步骤输出目标、约束、任务、验收条件并且每一步都征求你的确认那说明技能加载成功如果它只是普通地回答说明它可能没看到你的声明。我第一次验证时就翻车了直接在旧会话里测试AI 完全没有技能感知。后来乖乖开新会话马上正常。这个细节很重要——旧会话里没有新的codex.md上下文AI 自然感知不到技能包别在这个问题上浪费半小时。3. 核心技能拆解规划、TDD、调试这些超能力到底怎么触发安装只是开始真正值钱的是搞清楚每个技能怎么触发、输出什么、能帮你省哪一段力气。我来逐个拆。3.1 规划技能的触发与输出结构规划技能是我最常用的。它要求先把需求转成目标、约束、任务清单、验收标准四件套。比如你说做一个用户注册接口要求邮箱验证目标提供注册 API支持邮箱验证后激活账号。约束使用已有的用户表密码加密用 bcrypt。任务建表、写密码哈希工具、写注册接口、写验证邮件、写激活接口。验收注册后账号状态为未激活邮箱点击链接后变为激活重复激活有明确报错。AI 会每个任务都停下来和你确认而不是一口气写完。这一点很反直觉但对实际开发是好事——它让你在写代码之前先把需求漏洞补上而不是写完再返工。3.2 TDD 工作流先红灯再绿灯最后重构TDD 技能是我认为 superpowers 最值钱的部分。它强制执行的顺序是写一个失败的测试红灯。用最少代码让测试通过绿灯。在测试保护下重构。它不会一次性生成完所有代码而是测试一个接一个地变绿。这带来的好处是如果某个实现把前面的测试搞挂了能立刻定位到是哪一步引入的。我第一次用的时候有点不耐烦觉得一个简单函数何必这么折腾。后来在一个订单状态流转的逻辑上TDD 技能帮我一次性覆盖了 11 个边界场景我才意识到自己手写根本想不到那么全。这个技能适合用在有复杂状态、多分支、或者你不太想手动补测试的模块上。3.3 调试技能先复现再定位而不是上来就改我以前让 AI 帮忙看 bug它经常猜一个原因就让我改十次里八次不对。superpowers 的调试技能要求 AI 按流程走先要求复现步骤再要求提供错误日志然后列出可能的假设最后才提出修复建议。这个流程看起来慢实际反而快。因为它避免了你和 AI 陷入瞎改、报错、再瞎改的循环。而且它还会要求你在改完后验证原来的复现步骤避免修了 A 坏了 B。3.4 为什么用自然语言触发而不是命令有人问为什么这些技能不设计成/plan、/tdd这样的斜杠命令非要让 AI 理解自然语言我的理解是技能本身是给 AI 的思维模板而不是给你做的 UI。斜杠命令最终还是需要解析成提示词自然语言触发反而更灵活。你可以说帮我规划一下也可以说这个需求有点复杂先帮我理理思路AI 都能落到同一个技能上。缺点是偶尔会误触发但总体利大于弊。4. 一次完整的 Java 项目实战从零到可用的 superpowers 工作流与其空谈概念不如看一次完整的实战。我挑了一个典型的后端小需求做一个任务管理 REST 服务支持创建任务、列表查询、标记完成。技术栈Spring Boot 3、Java 17、内存存储。整个过程中我刻意让 superpowers 按规划、TDD、审查三个阶段来驱动。4.1 需求场景与准备这个项目不大但涉及到模型定义、业务逻辑、接口层、异常处理足够体现流程价值。开始之前我把项目结构和依赖要求写成一段需求描述然后让 AI 调用规划技能。注意这里我没有让它直接写代码。先让它规划是为了让后续每一步都有明确依据。4.2 规划阶段任务清单被拆成什么样我输入需求后AI 调用了规划技能输出大概如下任务 1初始化 Spring Boot 工程添加 web 依赖。任务 2定义 Task 数据模型和状态枚举。任务 3实现 TaskService 业务逻辑。任务 4实现 TaskController REST 接口。任务 5统一异常处理和参数校验。任务 6编写集成测试。每个任务都带验收条件。我逐项确认后它才开始进入编码。这个环节帮我提前发现了两个需求漏洞一是标记完成需要校验任务是否存在二是列表接口需要排除已删除任务。如果一上来就写代码这些点很可能是测试时才暴露改起来更费劲。4.3 TDD 阶段测试先行的实际体验进入编码后我让它用 TDD 方式实现任务 3。它先写了一个TaskServiceTest测试创建任务时状态默认为 TODO再写最小实现让测试通过然后继续加列表查询只返回未删除任务的测试。Java 领域有一个很实际的问题Spring 容器启动慢、测试上下文重如果每次小测试都拉整个 Spring 上下文开发体验会非常痛苦。superpowers 在这个点上处理得比较聪明它区分了单元测试和集成测试纯逻辑放 JUnit 单元测试里不进 Spring 容器只有真正要验证接口时才写SpringBootTest的集成测试。这个细节省了我大量时间。如果你自己在用 AI 编程一定要盯住这一点不要让 AI 把所有测试都写成重量级的 Spring 测试否则你会等得想砸电脑。4.4 代码审查阶段让 superpowers 反过来查代码代码全部写完以后我让它用代码审查技能过一遍。它找出了几个我差点忽视的问题任务状态流转没有校验已完成的任务不能重新打开这个约束没做。列表接口直接返回了实体对象字段暴露过多应该用 DTO。创建任务时 title 为空会直接抛 500而不是 400。这些问题在 AI 生成的代码里很典型因为它专注于让测试过而不是让代码体面。有了审查技能兜底等于多了一双眼睛而且这双眼睛还知道团队规范。4.5 复盘哪些地方真的省时间这次实战下来我的感受是规划技能最省心TDD 技能最省 bug审查技能最省 review 的人力。最费时间的反而在需求确认环节——AI 会反复停下来问细节但你一旦给出清晰约束后面就非常顺。Java 项目里特别适合用 TDD 技能因为类型系统和测试框架都比较成熟AI 生成的测试大多能一次跑通相比之下动态类型语言里测试的假绿问题会更明显这个我在下一部分细说。5. 和 worbuddy 这类外部工具配合时的编排思路有人问过我superpowers 能不能和 worbuddy 这类流程编排工具一起用。我的答案是能而且配合好以后开发节奏会清晰很多。下面说说我实际搭过的配合模式。5.1 worbuddy 在流程里扮演的角色worbuddy 这类工具本质上是个开发流程编排器它能把提需求、拆任务、写代码、自测、提交串成一条可视化的流程。你可以理解成它是项目的状态机告诉团队当前进行到哪一步下一步该做什么。那么它和 superpowers 什么关系我的理解是worbuddy 管流程状态机superpowers 管每一步怎么干。worbuddy 告诉你现在该做任务 3superpowers 告诉 AI 任务 3 应该用 TDD 的方法做而不是直接写。5.2 一种适合小团队的配合方式我试过一种比较顺的配合全程是这样跑的在 worbuddy 里创建任务卡片描述写清楚需求。把任务描述粘贴给接入了 superpowers 的 Codex让它先输出规划。规划确认后让 Codex 按 TDD 技能实现功能。提交之前让 Codex 跑审查技能把问题列表回填到 worbuddy 的评论里。这么做的核心价值是每一次状态变化都有据可查AI 生成的每一步中间产物都沉淀下来了不是黑箱。别人接手任务时能看到规划文档、测试过程、审查意见而不只是一句做完了。5.3 上下文管理的细节这里有个特别要注意的点worbuddy 卡片里的描述越结构化superpowers 的规划输出越靠谱。如果任务描述只有一句话把登录修一下AI 拿到手根本没法规划——它只能猜而猜的结果就是乱。我一般会在卡片里写清楚四要素现状、期望、边界、已知约束。这四样写全AI 的规划质量会天差地别。同样一段需求写成用户反馈登录有时会失败期望任何情况下都有明确报错移动端和 PC 端行为一致目前已知超时时间是 5 秒AI 就能拆出超时处理、错误码、前端提示、日志埋点四个明确任务。5.4 什么时候别硬上这套工具链也不是所有任务都值得过一遍完整流程。改个文案、调个样式、加个日志这种原子级小改动直接让 AI 改了提交就行非要走 TDD 和规划就是杀鸡用牛刀。我给自己定的标准是凡是涉及多文件、多状态、有业务约束的改动走完整流程单点小改动直接写。工具链的价值在于让复杂的事情不失控而不是给简单的事情添堵。6. 我踩过的坑和配置建议到最后这部分说点实在的踩坑经历。superpowers 用起来不是没有坑而且有些坑不踩一遍光看文档根本想不到。6.1 坑一大项目里一次性规划导致上下文爆炸我第一次在稍大的项目里用规划技能AI 一口气拆出了 30 多个任务输出非常详细。当时觉得挺爽结果后续对话里上下文直接撑爆AI 开始忘记前面确认过的约束甚至出现前后矛盾的任务描述。解决办法是明确要求 AI 分层规划。第一层只出大阶段控制在 5 个以内每个阶段再单独展开细任务。就像做项目先有里程碑再排甘特图不能上来就把所有明细摊开。6.2 坑二TDD 模式下生成的测试假绿动态类型语言或者依赖注入写得太重时测试容易出现假绿——测试里用的是 mock 的对象真实代码路径根本没跑到。Java 里相对少见但我也遇到过AI mock 了 TaskRepository然后断言repository.save 被调用了一次这根本验证不了业务逻辑。后来我养成了检查测试代码的习惯如果大量测试只有Mockito.verify没有真实断言就提醒 AI 改用真正的集成测试。注意看到测试全部通过先别高兴先看它到底在测什么。假绿比真红更可怕因为你完全察觉不到。6.3 坑三技能之间的状态覆盖有一次我先让 AI 做规划它输出到一半我又让它先写个接口结果 AI 把规划状态打断了后面输出的任务列表和前面完全对不上。原因是我在同一个会话里频繁切换技能。后来我养成了习惯一个会话只跑一个技能流程必须切换时先明确说结束当前规划进入编码模式让 AI 重置状态。这个细节说起来简单但实际用的时候很容易手滑。6.4 配置建议清单我把目前觉得顺手的配置方式整理一下技能目录放~/.superpowers固定路径不做软链。项目里codex.md写明技能目录和触发场景用固定措辞避免 AI 理解偏差。Java 项目里明确告诉 AI单元测试不要启动 Spring 容器。每次开始新任务都开新会话避免旧状态污染。升级技能包后开新会话验证一次别在旧会话里直接测。6.5 一个小技巧让 superpowers 记住团队规范superpowers 的技能模板是可以改的。我把团队的一些规范写进了技能说明里比如所有对外接口必须返回 DTO 而不是实体日志必须带 traceId。这样 AI 每次触发相关技能时都会看到这些规则输出的代码风格会主动贴近团队习惯。这个做法等于把团队规范变成了模板的一部分比每次在对话里重申一遍靠谱得多。遇到不同的项目也可以按项目维度维护不同的技能说明灵活性很高。最后说句实在话superpowers 不是魔法它不会让 AI 突然从能跑变成完美它只是把工程方法论绑到了 AI 的调用链上。对我个人而言最大的改变不是代码量变多而是 AI 的产出变得更可预期、可审查。如果你手头正好有一个总是局部聪明、全局犯傻的编程助手不妨按上面的思路给它装一套 superpowers先从小功能试起慢慢你就知道哪些环节它能帮你省心哪些环节你还是要自己拍板。工具这东西用顺了就是超能力用不顺就是另一个吃灰的仓库。
superpowers：给AI编程助手装上资深工程师的做事流程
如果你试过让 AI 编程助手一口气完成一个完整功能大概率会遇到这种情况让它写个函数又快又准让它按需求把项目从零搭起来它就开始东一榔头西一棒子代码能跑但心态崩了。我一度以为这是模型能力不够直到我认真用了 superpowers 这个技能包才发现问题出在流程上——助手缺的不是智能是一套资深工程师的做事流程。superpowers 就是用来补上这一环的工具它把规划、测试驱动开发、系统重构、调试这些能力封装成 AI 编程助手比如 Codex CLI可以主动调用的超能力让助手从代码片段生成器变成会干活的工程搭档。这篇东西不讲官方文档里有的废话只说我实际使用后的真实体验怎么装、怎么用、怎么配合 Java 项目落地以及我踩过的几个坑。1. superpowers 解决的是AI 编程助手不会干活的问题先说清楚它到底解决什么问题因为很多人装完以后用了一下觉得这不就是让 AI 多写点字吗然后卸载。这是没搞懂它的设计逻辑。1.1 从代码片段生成器到项目工程师的距离单独让 AI 写一个冒泡排序、一个 REST 接口它表现很好。但一个真实的项目任务往往涉及多个文件、有依赖关系、有边界条件、有执行顺序。模型在单点上是强的但在一长串任务上容易只见树木不见森林——它不知道先改哪个后改哪个改完这个会不会破坏那个更不懂写任何代码之前应该先把需求想清楚。superpowers 的思路不是给模型加更多参数而是把工作流程外置。它用一批定义好的技能skill引导 AI 按照稳定、可复用的步骤干活。这就好比一个新人程序员本身脑子不差但第一次进团队没人告诉他怎么提测、怎么写测试、怎么走 review他会乱superpowers 就是那个把流程写成白纸黑字的团队规范。1.2 核心思路把资深工程师的做事流程变成可触发的技能在我实际使用过程中superpowers 的触发方式非常接近自然语言。你在对话里说帮我规划一下这个需求它就会调用规划技能先输出目标、约束、任务拆解你说用 TDD 的方式实现这个功能它就会按照先写失败测试、再实现、再重构的顺序执行。这和普通插件的区别在于普通插件是给 IDE 加按钮superpowers 是给 AI 加思考模板。你教 AI要规划它可能只是嘴上答应你给它一套规划技能它就会真的按步骤产出可检查的中间产物。这个区别非常关键也是它值得折腾安装的原因。1.3 它到底能做什么我整理一下我常用的几类能力项目规划把需求拆成有依赖关系的任务产出实现顺序和验收条件。设计共识在写代码前先描述系统边界、模块划分、数据流防止后期大改。TDD 工作流强制先写失败测试再写最小实现最后重构。系统级重构基于测试保障做代码整理而不是拍脑袋改结构。调试辅助要求 AI 先复现问题、提出假设再定位和修复。不同版本提供的技能细节会有差异但骨架基本是围绕让 AI 按工程流程产出可审查的中间产物来设计的。理解了这一点你才知道该在什么场景下去用它而不是装完跑个 demo 就丢一边。2. 安装与接入让 Codex CLI 认识 superpowers这部分直接上干货。以我当前在用的版本来讲我是在 macOS 上操作的用了 Node.js 20 LTS 和 Git。superpowers 本质是个技能包不挑语言但你需要有一个能调用它的 AI 编程助手。我这边主力是 Codex CLI所以下面都以它为例。2.1 环境准备安装前先确认三件事你的 Codex CLI 能正常跑起来至少成功登录过、能完成一次简单对话。Node.js 版本别太老建议 18 以上我用的是 20。网络环境能正常访问代码仓库即可很多安装异常其实出在访问仓库不稳定先检查网络配置再动手不要一上来就怀疑工具本身。2.2 获取 superpowers克隆到本地还是用包管理器社区里常见的获取方式有两种一种是直接克隆仓库另一种是通过包管理器安装。我首选克隆方式因为 superpowers 的更新频率不算低git pull拉一下就能升级也方便你改里面的技能模板。我当时是把它放到了~/.superpowers这个固定目录git clone https://github.com/obra/superpowers.git ~/.superpowers这个目录位置不是死的你可以放到任何地方但建议选一个固定路径因为后面配置文件里要反复引用它。用包管理器安装的方式我也试过好处是依赖自动装好坏处是升级路径不直观对想改模板的人来说不太友好。提示如果你用的是 Codex CLI 以外的 AI 编程工具安装路径和声明方式可能略有出入但核心思路一样——把技能目录暴露给 AI 助手。2.3 在 Codex 的配置里声明技能目录这一步是关键。很多人装完 skill 包发现 AI 完全没反应就是因为 AI 助手根本不知道这个目录存在。Codex CLI 会读取项目里的codex.md或者全局的~/.codex/config.toml。我当时是在项目的codex.md里加了这样一段说明# 项目说明 本项目使用 superpowers 技能集。在以下目录可以找到技能定义 ~/.superpowers/skills 当你需要规划、设计、TDD、重构、调试时请主动使用这些技能。写清楚以后每次开启新会话Codex 就会在上下文中看到这些信息知道在什么场景下调用什么技能。这一步很啰嗦但极其重要它决定了 AI 有没有技能意识。2.4 激活与验证怎么确认安装真的成功了激活不是跑一条命令那么简单。你要做的是在一个新对话里故意让 AI 触发某个技能比如用项目规划技能帮我拆解一个登录功能的实现步骤。如果 AI 真的按步骤输出目标、约束、任务、验收条件并且每一步都征求你的确认那说明技能加载成功如果它只是普通地回答说明它可能没看到你的声明。我第一次验证时就翻车了直接在旧会话里测试AI 完全没有技能感知。后来乖乖开新会话马上正常。这个细节很重要——旧会话里没有新的codex.md上下文AI 自然感知不到技能包别在这个问题上浪费半小时。3. 核心技能拆解规划、TDD、调试这些超能力到底怎么触发安装只是开始真正值钱的是搞清楚每个技能怎么触发、输出什么、能帮你省哪一段力气。我来逐个拆。3.1 规划技能的触发与输出结构规划技能是我最常用的。它要求先把需求转成目标、约束、任务清单、验收标准四件套。比如你说做一个用户注册接口要求邮箱验证目标提供注册 API支持邮箱验证后激活账号。约束使用已有的用户表密码加密用 bcrypt。任务建表、写密码哈希工具、写注册接口、写验证邮件、写激活接口。验收注册后账号状态为未激活邮箱点击链接后变为激活重复激活有明确报错。AI 会每个任务都停下来和你确认而不是一口气写完。这一点很反直觉但对实际开发是好事——它让你在写代码之前先把需求漏洞补上而不是写完再返工。3.2 TDD 工作流先红灯再绿灯最后重构TDD 技能是我认为 superpowers 最值钱的部分。它强制执行的顺序是写一个失败的测试红灯。用最少代码让测试通过绿灯。在测试保护下重构。它不会一次性生成完所有代码而是测试一个接一个地变绿。这带来的好处是如果某个实现把前面的测试搞挂了能立刻定位到是哪一步引入的。我第一次用的时候有点不耐烦觉得一个简单函数何必这么折腾。后来在一个订单状态流转的逻辑上TDD 技能帮我一次性覆盖了 11 个边界场景我才意识到自己手写根本想不到那么全。这个技能适合用在有复杂状态、多分支、或者你不太想手动补测试的模块上。3.3 调试技能先复现再定位而不是上来就改我以前让 AI 帮忙看 bug它经常猜一个原因就让我改十次里八次不对。superpowers 的调试技能要求 AI 按流程走先要求复现步骤再要求提供错误日志然后列出可能的假设最后才提出修复建议。这个流程看起来慢实际反而快。因为它避免了你和 AI 陷入瞎改、报错、再瞎改的循环。而且它还会要求你在改完后验证原来的复现步骤避免修了 A 坏了 B。3.4 为什么用自然语言触发而不是命令有人问为什么这些技能不设计成/plan、/tdd这样的斜杠命令非要让 AI 理解自然语言我的理解是技能本身是给 AI 的思维模板而不是给你做的 UI。斜杠命令最终还是需要解析成提示词自然语言触发反而更灵活。你可以说帮我规划一下也可以说这个需求有点复杂先帮我理理思路AI 都能落到同一个技能上。缺点是偶尔会误触发但总体利大于弊。4. 一次完整的 Java 项目实战从零到可用的 superpowers 工作流与其空谈概念不如看一次完整的实战。我挑了一个典型的后端小需求做一个任务管理 REST 服务支持创建任务、列表查询、标记完成。技术栈Spring Boot 3、Java 17、内存存储。整个过程中我刻意让 superpowers 按规划、TDD、审查三个阶段来驱动。4.1 需求场景与准备这个项目不大但涉及到模型定义、业务逻辑、接口层、异常处理足够体现流程价值。开始之前我把项目结构和依赖要求写成一段需求描述然后让 AI 调用规划技能。注意这里我没有让它直接写代码。先让它规划是为了让后续每一步都有明确依据。4.2 规划阶段任务清单被拆成什么样我输入需求后AI 调用了规划技能输出大概如下任务 1初始化 Spring Boot 工程添加 web 依赖。任务 2定义 Task 数据模型和状态枚举。任务 3实现 TaskService 业务逻辑。任务 4实现 TaskController REST 接口。任务 5统一异常处理和参数校验。任务 6编写集成测试。每个任务都带验收条件。我逐项确认后它才开始进入编码。这个环节帮我提前发现了两个需求漏洞一是标记完成需要校验任务是否存在二是列表接口需要排除已删除任务。如果一上来就写代码这些点很可能是测试时才暴露改起来更费劲。4.3 TDD 阶段测试先行的实际体验进入编码后我让它用 TDD 方式实现任务 3。它先写了一个TaskServiceTest测试创建任务时状态默认为 TODO再写最小实现让测试通过然后继续加列表查询只返回未删除任务的测试。Java 领域有一个很实际的问题Spring 容器启动慢、测试上下文重如果每次小测试都拉整个 Spring 上下文开发体验会非常痛苦。superpowers 在这个点上处理得比较聪明它区分了单元测试和集成测试纯逻辑放 JUnit 单元测试里不进 Spring 容器只有真正要验证接口时才写SpringBootTest的集成测试。这个细节省了我大量时间。如果你自己在用 AI 编程一定要盯住这一点不要让 AI 把所有测试都写成重量级的 Spring 测试否则你会等得想砸电脑。4.4 代码审查阶段让 superpowers 反过来查代码代码全部写完以后我让它用代码审查技能过一遍。它找出了几个我差点忽视的问题任务状态流转没有校验已完成的任务不能重新打开这个约束没做。列表接口直接返回了实体对象字段暴露过多应该用 DTO。创建任务时 title 为空会直接抛 500而不是 400。这些问题在 AI 生成的代码里很典型因为它专注于让测试过而不是让代码体面。有了审查技能兜底等于多了一双眼睛而且这双眼睛还知道团队规范。4.5 复盘哪些地方真的省时间这次实战下来我的感受是规划技能最省心TDD 技能最省 bug审查技能最省 review 的人力。最费时间的反而在需求确认环节——AI 会反复停下来问细节但你一旦给出清晰约束后面就非常顺。Java 项目里特别适合用 TDD 技能因为类型系统和测试框架都比较成熟AI 生成的测试大多能一次跑通相比之下动态类型语言里测试的假绿问题会更明显这个我在下一部分细说。5. 和 worbuddy 这类外部工具配合时的编排思路有人问过我superpowers 能不能和 worbuddy 这类流程编排工具一起用。我的答案是能而且配合好以后开发节奏会清晰很多。下面说说我实际搭过的配合模式。5.1 worbuddy 在流程里扮演的角色worbuddy 这类工具本质上是个开发流程编排器它能把提需求、拆任务、写代码、自测、提交串成一条可视化的流程。你可以理解成它是项目的状态机告诉团队当前进行到哪一步下一步该做什么。那么它和 superpowers 什么关系我的理解是worbuddy 管流程状态机superpowers 管每一步怎么干。worbuddy 告诉你现在该做任务 3superpowers 告诉 AI 任务 3 应该用 TDD 的方法做而不是直接写。5.2 一种适合小团队的配合方式我试过一种比较顺的配合全程是这样跑的在 worbuddy 里创建任务卡片描述写清楚需求。把任务描述粘贴给接入了 superpowers 的 Codex让它先输出规划。规划确认后让 Codex 按 TDD 技能实现功能。提交之前让 Codex 跑审查技能把问题列表回填到 worbuddy 的评论里。这么做的核心价值是每一次状态变化都有据可查AI 生成的每一步中间产物都沉淀下来了不是黑箱。别人接手任务时能看到规划文档、测试过程、审查意见而不只是一句做完了。5.3 上下文管理的细节这里有个特别要注意的点worbuddy 卡片里的描述越结构化superpowers 的规划输出越靠谱。如果任务描述只有一句话把登录修一下AI 拿到手根本没法规划——它只能猜而猜的结果就是乱。我一般会在卡片里写清楚四要素现状、期望、边界、已知约束。这四样写全AI 的规划质量会天差地别。同样一段需求写成用户反馈登录有时会失败期望任何情况下都有明确报错移动端和 PC 端行为一致目前已知超时时间是 5 秒AI 就能拆出超时处理、错误码、前端提示、日志埋点四个明确任务。5.4 什么时候别硬上这套工具链也不是所有任务都值得过一遍完整流程。改个文案、调个样式、加个日志这种原子级小改动直接让 AI 改了提交就行非要走 TDD 和规划就是杀鸡用牛刀。我给自己定的标准是凡是涉及多文件、多状态、有业务约束的改动走完整流程单点小改动直接写。工具链的价值在于让复杂的事情不失控而不是给简单的事情添堵。6. 我踩过的坑和配置建议到最后这部分说点实在的踩坑经历。superpowers 用起来不是没有坑而且有些坑不踩一遍光看文档根本想不到。6.1 坑一大项目里一次性规划导致上下文爆炸我第一次在稍大的项目里用规划技能AI 一口气拆出了 30 多个任务输出非常详细。当时觉得挺爽结果后续对话里上下文直接撑爆AI 开始忘记前面确认过的约束甚至出现前后矛盾的任务描述。解决办法是明确要求 AI 分层规划。第一层只出大阶段控制在 5 个以内每个阶段再单独展开细任务。就像做项目先有里程碑再排甘特图不能上来就把所有明细摊开。6.2 坑二TDD 模式下生成的测试假绿动态类型语言或者依赖注入写得太重时测试容易出现假绿——测试里用的是 mock 的对象真实代码路径根本没跑到。Java 里相对少见但我也遇到过AI mock 了 TaskRepository然后断言repository.save 被调用了一次这根本验证不了业务逻辑。后来我养成了检查测试代码的习惯如果大量测试只有Mockito.verify没有真实断言就提醒 AI 改用真正的集成测试。注意看到测试全部通过先别高兴先看它到底在测什么。假绿比真红更可怕因为你完全察觉不到。6.3 坑三技能之间的状态覆盖有一次我先让 AI 做规划它输出到一半我又让它先写个接口结果 AI 把规划状态打断了后面输出的任务列表和前面完全对不上。原因是我在同一个会话里频繁切换技能。后来我养成了习惯一个会话只跑一个技能流程必须切换时先明确说结束当前规划进入编码模式让 AI 重置状态。这个细节说起来简单但实际用的时候很容易手滑。6.4 配置建议清单我把目前觉得顺手的配置方式整理一下技能目录放~/.superpowers固定路径不做软链。项目里codex.md写明技能目录和触发场景用固定措辞避免 AI 理解偏差。Java 项目里明确告诉 AI单元测试不要启动 Spring 容器。每次开始新任务都开新会话避免旧状态污染。升级技能包后开新会话验证一次别在旧会话里直接测。6.5 一个小技巧让 superpowers 记住团队规范superpowers 的技能模板是可以改的。我把团队的一些规范写进了技能说明里比如所有对外接口必须返回 DTO 而不是实体日志必须带 traceId。这样 AI 每次触发相关技能时都会看到这些规则输出的代码风格会主动贴近团队习惯。这个做法等于把团队规范变成了模板的一部分比每次在对话里重申一遍靠谱得多。遇到不同的项目也可以按项目维度维护不同的技能说明灵活性很高。最后说句实在话superpowers 不是魔法它不会让 AI 突然从能跑变成完美它只是把工程方法论绑到了 AI 的调用链上。对我个人而言最大的改变不是代码量变多而是 AI 的产出变得更可预期、可审查。如果你手头正好有一个总是局部聪明、全局犯傻的编程助手不妨按上面的思路给它装一套 superpowers先从小功能试起慢慢你就知道哪些环节它能帮你省心哪些环节你还是要自己拍板。工具这东西用顺了就是超能力用不顺就是另一个吃灰的仓库。
