最近在折腾命令行AI编程工具试了一圈下来Codex CLI是我目前用得最顺手的。但用久了也会觉得它差点意思——模型很强代码写得快但碰到稍微复杂一点的任务它容易“快手乱打”不写测试就改代码改完不回归验证全凭一股冲劲遇到重构或者多文件改动时翻车概率直线上升。这恰好是superpowers这个开源项目要解决的问题。superpowersGitHub 上的 obra/superpowers本质上是一套“AI 技能包”它不是模型不是 IDE而是一组标准化的操作规范和提示词策略专门给 Codex CLI、Gemini CLI 这类命令行 AI 编程工具用的。装上它之后AI 在动手之前会先跟你确认需求边界把方案讲清楚然后写测试、再实现、再回归每一步都有章法。它解决的核心痛点很直接模型能力不缺缺的是工程纪律。这篇文章我把自己的安装过程、日常用法和踩过的坑都整理出来了给想给 AI 编程助手“立规矩”的朋友做个参考。1. 项目概述与设计思路拆解1.1 superpowers 到底是什么先给还不了解的朋友说个大概。superpowers 是一套开源项目作者是 Jesse VincentGitHub 账号 obra他本人是资深 Perl 和开源社区的老兵写过多年的基础设施软件。这个项目最初是从他使用 Codex CLI 的亲身经历中长出来的——他发现模型本身已经很强了但如果缺少一套清晰的工作指引AI 很容易在复杂的编码任务里“自嗨”写出看起来很合理、实际上没经过验证的代码。它的形态很有意思不碰模型权重不做独立 App而是用一组 Markdown 格式的“技能文件”skills来约束 AI 的行为。这些技能文件被放到 Codex CLI 能读到的目录里Codex 在每次对话时会把相关技能的规则注入到上下文里让 AI 在回答前先“读过”这批操作手册。装完之后你可以在 Codex 的配置里看到插件列表也能在对话中要求 AI 遵循某个具体的技能文件来工作。这就像给一个天赋很好但没受过系统训练的工程师发了一整套团队 SOP需求阶段先写清楚验收标准动手前先讲方案写完代码先补测试发现问题按流程排查而不是瞎猜。模型本身的知识面和处理能力仍然是核心superpowers 做的事情是把“正确的工作方式”前置到每一次交互里给 AI 一个可复用的方法论框架。1.2 为什么需要给 AI 编程助手装“技能包”我个人的体感是现在的对话式 AI 编程工具有一个通病它们天然是“顺从型”的。你让它改一个函数它会立刻给你新版本你让它重构模块它会欢快地动手。问题在于它很少反驳你也很少主动说“等等这里需求还没定义清楚”。在大型代码库里这种顺从会变成灾难——AI 改了一个核心函数的入参结果调用方们谁也没被更新编译一跑红了一片。superpowers 针对的就是这个问题。它通过显式的规则把 AI 从“问你一句答一句的实习生”改造成“先思考再动手的高级工程师”。装完这套技能包之后最明显的变化是 Codex 在动手前会主动向你确认理解甚至反过来追问需求边界。我第一次用的时候有点不习惯这种“变啰嗦”的 AI但几次下来发现返工率确实低了因为很多歧义在写代码之前就被澄清了。另一个价值是它把测试的地位提到了几乎最高的优先级。过去我让 Codex 写功能它可能写完核心逻辑就认为自己“完成”了现在它会把测试当作交付的一部分甚至在实现之前就先写好测试。这个转变对我们这种习惯了 TDD 的开发者来说非常对味对还在观望的人也能直观感受到“测试先行”在 AI 协作里的价值——AI 自己写的测试可以充当反复修改时的安全网后续你再让它改功能回归用例就在那里兜底。2. 安装部署与前置环境准备2.1 安装前需要准备什么先说环境。superpowers 不是独立软件它是 Codex CLI 的插件集所以你的机器上必须先装好 Codex CLI。如果你用的是 Trae Work CN 这类支持 skills 的编辑器也可以走另一条路径但核心前提一样得有一个能识别技能文件的 AI 编程环境。安装前建议确认几样东西Codex CLI 版本superpowers 的新特性通常会跟随 Codex CLI 的更新建议把 Codex 升级到比较新的版本再装。老版本可能解析不了插件配置或者行为差异很大。Node.js 环境Codex CLI 本身基于 Node.js装个 LTS 版本比较稳妥。如果你之前装过 CodexNode 环境通常已经有了。Git 命令行虽然不强制但在拉取 superpowers 仓库和后续更新时用得上。OpenAI API 访问权限或 Codex 订阅权限Codex CLI 需要连接后端模型这个前提没满足的话工具本身就跑不起来。这些准备项都满足后再动手安装 superpowers。我自己的环境是 macOS Node 20 LTSCodex CLI 已经用了一段时间整个安装过程大概十分钟以内能完成。2.2 通过 Codex CLI 安装 superpowersCodex CLI 的插件机制在早期版本里是通过配置文件管理的后来版本增加了更方便的插件安装命令。你可以先打开终端运行 Codex 的交互界面然后直接用/plugin指令查看当前插件状态或者用命令行直接安装。我实测过的路径大致如下# 先确认 codex 已安装 codex --version # 安装 superpowers 插件 codex plugins add superpowers如果当前版本的 Codex CLI 还不支持plugins add子命令也可以手动改配置文件。Codex CLI 的配置文件一般在~/.codex/config.tomlmacOS/Linux或%USERPROFILE%\.codex\config.tomlWindows。打开后找到[plugins]部分添加如下内容[plugins] superpowers github:obra/superpowers保存后重启 Codex CLI插件就会被加载。你可以输入类似“请列出你当前可用的技能”这种话看 AI 是否会提到 bootstrapping、tdd、design 等技能名称。能提到就说明 superpowers 已经生效了。提示部分版本对插件路径比较敏感如果你用的是本地 clone 的仓库可以把地址指向本地目录。比如superpowers file:///Users/yourname/superpowers这样可以随时手动改动技能文件来调试。2.3 在 Trae Work CN 中安装 superpowers skill如果你主力编辑器是 Trae Work CN也可以把 superpowers 作为 skill 装进去。Trae 支持自定义技能导入路径一般是设置 → 技能Skills→ 导入技能。source 选择本地目录或 Git 仓库把 superpowers 仓库 clone 下来后直接选中skills目录导入即可。# 先拉取项目 git clone https://github.com/obra/superpowers.git # 进入项目目录确认技能文件列表 cd superpowers ls skills在skills目录里你会看到一组子目录比如bootstrapping、test-driven-development、design等。Trae 导入时一般识别的是单个技能文件夹所以你需要逐个导入或者看你的版本是否支持整个目录批量导入。装完后在 Trae 的对话侧边栏里应该能看到这些技能出现在可用技能列表里使用效果和 Codex CLI 里的差别不大。有一点要注意Trae 的技能机制和 Codex 的插件机制不是一回事两者对技能文件的解析规则可能略有差异。遇到个别技能在 Trae 里不生效不用太纠结优先保证核心的 bootstrapping 和 tdd 两个技能能用就足够改善主力工作流了。3. 核心技能盘点与实际工作方式3.1 核心技能文件一览superpowers 仓库里的技能文件是这套工具的灵魂。不同版本技能清单会有些出入我目前版本里看到的几个核心技能技能名称核心作用使用场景bootstrapping向 AI 注入项目背景和整体工作原则开启新会话时先让它理解身份与使命test-driven-development强制测试先行红绿循环写新功能、修 bug 时最常用design编码前先讨论设计方案与备选方案复杂功能、模块设计、技术选型implementing-changes按计划逐步实现变更多文件改动、较大重构troubleshooting系统化排查问题避免乱试测试失败、运行报错、行为异常除了这五个仓库里还有一些更细粒度的技能比如写提交信息、做代码审查、处理安全问题的规则等。作者的思想挺清晰每一个技能都是在模拟真实团队里某种“角色规范”。bootstrapping 相当于入职培训test-driven-development 相当于质量红线design 相当于技术评审会implementing-changes 相当于开发计划troubleshooting 相当于故障排查手册。3.2 最常用的 TDD 技能到底怎么工作test-driven-development 是我用得最多的技能。没装 superpowers 之前我让 Codex 写个函数它常常直接生成完整实现看起来很方便但一旦逻辑分支稍微多点边界条件经常漏。装上 TDD 技能后Codex 会按一个固定节奏来推进先写一个最小失败测试跑一次确认是红的根据测试写最小实现让测试变绿再补下一个失败测试循环往复全部通过后做一轮简单重构。这个流程单独看并不稀奇奇的是由 AI 来执行时“先写测试再写实现”这个顺序会极大影响代码结构。AI 在写测试的过程中相当于提前做了一遍需求分析它会主动把“输入是什么、输出是什么、异常怎么办”想清楚再动手。我遇到过几次Codex 写完测试后停下来问我“这个方法的边界行为没定义是先抛异常还是返回空值”这种问题在过去直接写实现时它几乎不会提。如果你以前没有 TDD 习惯用这套技能会打开新世界——它把“安全修改代码”变成了一种可重复的操作模式。后续你再让 AI 改功能回归测试就在那里AI 每次跑完测试才知道自己有没有改坏东西比过去“改完凭感觉”靠谱太多。3.3 从“一问一答”到“项目协作”的体验变化装上 superpowers 后Codex 给我的观感更像一个拿着任务清单的协作者而不是一个等待指令的问答机器。举一个我最近的例子我要给一个内部工具加一个“批量导入用户”的功能。过去我直接说“帮我写批量导入”AI 吭哧吭哧生成一大段代码跑起来一堆异常。现在它先会根据 design 技能问我“导入文件的格式是什么字段校验失败是跳过还是中止重复用户怎么处理”这些问题会有一些繁琐但回答完之后它写出来的代码命中率非常高基本就是一版过。这种变化背后有一个很实在的设计逻辑AI 模型对自然语言歧义非常敏感同一句话在不同上下文里会有完全不同的理解。superpowers 通过技能文件强制 AI 在动手前做需求澄清相当于从流程上消灭歧义。实践证明多花两分钟对话能省下几十分钟的调试时间这笔账非常划算。4. 实操过程与典型任务拆解4.1 新会话启动后的标准操作流程我现在的习惯是每次用 Codex 处理一个新任务都会先让 AI 加载 bootstrapping 技能再进入具体任务。你可以直接对 Codex 说请加载 bootstrapping 技能然后我们开始处理一个任务。这时候 AI 通常会回复一段项目原则说明表示它理解了如何协作。接下来我再描述具体需求。它很有可能会反过来确认几件事项目背景、验收标准、修改范围、现有测试状态。这些确认动作都是 superpowers 注入的不用嫌烦把它当成 Team Leader 在开工会时做的信息拉齐就好。描述完需求后根据任务类型选择技能路径。小改动就直接走 implement 流程新功能或复杂逻辑就要求它先用 design 技能给出方案修复 bug 则建议它先写一个失败测试复现问题再开始改。这套组合拳打下来每次会话的节奏都会比较稳不太容易出现“AI 写了一堆代码、最后发现方向错了”的尴尬局面。4.2 一个典型任务的完整推进过程我拿一个真实任务来演示这样比较直观。任务是给一个 Python 脚本增加“从 CSV 导入用户并返回导入结果统计”的函数。第一步我启动 Codex让它加载 bootstrapping我请加载 bootstrapping 技能我们有一个新功能要开发。 AI已加载。我理解自己的工作方式先明确需求边界再设计方案测试先行小步实现。请描述任务。第二步我描述需求。因为 superpowers 的引导AI 主动问了我三个问题CSV 的必填列有哪些、重复用户如何处理、导入结果是否需要包含失败原因。我回答之后它给出了设计方案分两步先解析文件再批量写入写一个parse_csv和一个import_users函数。第三步在 design 技能引导下它列出了一个简短的接口定义和数据格式示例并说明异常处理策略。这里我不需要写任何代码它已经做了明确的拆解待我确认后才进入实现阶段。第四步进入 TDD 流程。AI 先生成测试文件覆盖三个场景正常导入、重复用户跳过、必填字段缺失报错。然后跑测试确认失败再逐个实现功能让测试变绿。整个过程它都在小幅操作每完成一个测试就跑一次 pytest。全部通过后它会做个极简重构然后汇报结果。这个过程比我以前直接用 Codex 写代码要慢一点点但完成质量明显高很多测试文件随需求一起交付函数边界清晰代码里几乎没有多余的“模型幻觉”。对于把稳定性和可维护性看得很重的项目这个慢是值得的。4.3 让 AI 遵循技能的执行细节日常使用中还有一个实用技巧你不需要每次手动指定技能。装好 superpowers 后Bootstrapping 技能会在新会话的默认上下文里被自动注入AI 会在合适的场景自动调用其他技能。但由于不同版本的 Codex 行为略有差异建议在一个任务的开头显式说一句请在所有步骤中遵循 TDD 技能的要求。这句话的效果是给当前会话设置一个强制优先级。实测下来加了这句之后AI 会更坚持先写测试。如果你连这句都不想输入也可以把这句话写进 Codex CLI 的用户自定义指令system prompt 或 AGENTS.md做成全局默认规则。这个思路我在两个项目里试过都挺稳的。注意如果任务本身是一次性探索或原型验证强行套 TDD 流程反而繁琐。此时你可以明确告诉 AI“不需要写测试只做快速原型”。superpowers 的规则是可覆盖的你的显式指令优先级更高。5. 常见问题与排查技巧实录5.1 安装后 AI 不识别技能怎么排最常遇到的问题就是插件配置完了Codex 却像没装一样完全不提技能。这时先别急着怀疑项目有问题从三处排查配置文件格式检查config.toml里插件路径有没有写错。常见错误是仓库地址带上了.git后缀以外的多余字符或者路径写成了https://github.com/obra/superpowers.git这种完整 URL有些版本只认github:obra/superpowers这种简写。Codex 版本过旧旧的 Codex CLI 对插件支持不完整最直观的验证方式是运行codex --version然后去项目 README 或更新日志里对一下要求的版本号。技能文件权限如果你是用本地 clone 的方式配置插件需要确认技能文件所在的目录有读取权限。权限不对时Codex 会静默跳过加载不报任何错误看起来就像没装一样。排完这三个点绝大多数情况都能解决。还有一个不常见的坑如果你同时开了多个终端窗口旧窗口里的 Codex 进程可能还持有旧配置改完配置后务必新开一个终端再试。5.2 测试先行遇到“遗留代码”怎么办装了 superpowers 之后AI 会默认要求先写测试。但如果你负责的是老项目一堆遗留代码连测试框架都没有这时候 TDD 流程会卡住。我的处理办法是分两步第一步先引入一个最轻量的测试框架比如 Python 的 pytest 或 Node 的 vitest只要能让 AI 跑起来即可不需要追求覆盖率。第二步遇到具体 bug 时让 AI 先针对这个 bug 写一个“复现性测试”也就是先证明问题存在再修改代码让测试通过。这个过程成本很低效果立竿见影——不仅修了 bug还留下了一个防止回归的测试。在 Codex 里可以这样表述这是遗留项目目前没有测试框架。先帮我引入 pytest 并写一个最小配置然后针对这个 bug 先写复现测试再修复。AI 在 superpowers 的规则下会很配合地执行这个两步方案。其实这也是所有改造老项目的好姿势不要幻想一步到位先给关键路径加安全网再逐步推广测试。5.3 常见问题速查表问题可能原因处理方法安装后技能不生效配置路径错误检查 config.toml 的插件路径AI 不写测试直接给代码任务没有明确遵循 TDD 技能显式要求“必须 TDD 流程”新会话里 AI 又“变笨”Bootstrapping 未自动加载手动要求加载 bootstrapping技能文件找不到本地仓库未拉取完整重新 clone 并确认 skills 目录内容老项目跑不了测试测试框架缺失先引入 pytest/vitest 再走 TDD配置改完不生效旧终端进程缓存了配置重启终端或重启 Codex5.4 我对这套工作方式的一些实操心得最后分享几个我自己的使用心得。第一个是关于“技能不是越多越好”。superpowers 默认会带不少技能文件但对多数日常任务来说bootstrapping 加 TDD 两个已经能覆盖大部分收益。我一开始试图让 AI 在每个任务里都把 design、implement、troubleshooting 全套走一遍结果对话变得冗长反而拖慢节奏。现在我按任务复杂度灵活选择小改动用 TDD 就够大功能才进 design只有排查疑难杂症时才上 troubleshooting。第二个心得是“AI 生成的测试也有质量问题”。superpowers 虽然让 AI 写测试但它写的测试有时会只覆盖正向路径对异常输入的断言不够。我现在的做法是AI 写完测试后我会扫一眼断言逻辑补上我认为关键的边界场景。它不是万能药但它提供了一个非常好的起点让我把精力花在补充关键用例上而不是从零搭测试框架。第三个心得是关于团队协作。如果你和同事共享一个项目建议把 superpowers 的技能文件纳入仓库的AGENTS.md或文档目录让每个人都能看到 AI 的工作规则。这样不同成员用 Codex 时的行为模式更一致代码风格也会更统一某种意义上这也是一种“团队级别的工作协议”。我个人在实际操作中的体会是superpowers 真正值钱的地方不是那些炫酷的提示词模板而是它把“怎么写代码才能少返工”这件事从人的脑子搬到了 AI 的运行机制里。它不是什么银弹装了也不会让你的 AI 一夜之间变成架构师但它确实是目前我在命令行 AI 编程工具里见过的最务实、最接近“真实团队协作”的增强层。如果你正在用 Codex CLI而且有点受不了它那种“撞了南墙再回头”的编码方式非常建议花半小时把这个技能包装上亲自感受一次 TDD 流程下的 AI 写代码。
superpowers技能包：给Codex CLI立规矩，让AI编程遵循工程纪律
最近在折腾命令行AI编程工具试了一圈下来Codex CLI是我目前用得最顺手的。但用久了也会觉得它差点意思——模型很强代码写得快但碰到稍微复杂一点的任务它容易“快手乱打”不写测试就改代码改完不回归验证全凭一股冲劲遇到重构或者多文件改动时翻车概率直线上升。这恰好是superpowers这个开源项目要解决的问题。superpowersGitHub 上的 obra/superpowers本质上是一套“AI 技能包”它不是模型不是 IDE而是一组标准化的操作规范和提示词策略专门给 Codex CLI、Gemini CLI 这类命令行 AI 编程工具用的。装上它之后AI 在动手之前会先跟你确认需求边界把方案讲清楚然后写测试、再实现、再回归每一步都有章法。它解决的核心痛点很直接模型能力不缺缺的是工程纪律。这篇文章我把自己的安装过程、日常用法和踩过的坑都整理出来了给想给 AI 编程助手“立规矩”的朋友做个参考。1. 项目概述与设计思路拆解1.1 superpowers 到底是什么先给还不了解的朋友说个大概。superpowers 是一套开源项目作者是 Jesse VincentGitHub 账号 obra他本人是资深 Perl 和开源社区的老兵写过多年的基础设施软件。这个项目最初是从他使用 Codex CLI 的亲身经历中长出来的——他发现模型本身已经很强了但如果缺少一套清晰的工作指引AI 很容易在复杂的编码任务里“自嗨”写出看起来很合理、实际上没经过验证的代码。它的形态很有意思不碰模型权重不做独立 App而是用一组 Markdown 格式的“技能文件”skills来约束 AI 的行为。这些技能文件被放到 Codex CLI 能读到的目录里Codex 在每次对话时会把相关技能的规则注入到上下文里让 AI 在回答前先“读过”这批操作手册。装完之后你可以在 Codex 的配置里看到插件列表也能在对话中要求 AI 遵循某个具体的技能文件来工作。这就像给一个天赋很好但没受过系统训练的工程师发了一整套团队 SOP需求阶段先写清楚验收标准动手前先讲方案写完代码先补测试发现问题按流程排查而不是瞎猜。模型本身的知识面和处理能力仍然是核心superpowers 做的事情是把“正确的工作方式”前置到每一次交互里给 AI 一个可复用的方法论框架。1.2 为什么需要给 AI 编程助手装“技能包”我个人的体感是现在的对话式 AI 编程工具有一个通病它们天然是“顺从型”的。你让它改一个函数它会立刻给你新版本你让它重构模块它会欢快地动手。问题在于它很少反驳你也很少主动说“等等这里需求还没定义清楚”。在大型代码库里这种顺从会变成灾难——AI 改了一个核心函数的入参结果调用方们谁也没被更新编译一跑红了一片。superpowers 针对的就是这个问题。它通过显式的规则把 AI 从“问你一句答一句的实习生”改造成“先思考再动手的高级工程师”。装完这套技能包之后最明显的变化是 Codex 在动手前会主动向你确认理解甚至反过来追问需求边界。我第一次用的时候有点不习惯这种“变啰嗦”的 AI但几次下来发现返工率确实低了因为很多歧义在写代码之前就被澄清了。另一个价值是它把测试的地位提到了几乎最高的优先级。过去我让 Codex 写功能它可能写完核心逻辑就认为自己“完成”了现在它会把测试当作交付的一部分甚至在实现之前就先写好测试。这个转变对我们这种习惯了 TDD 的开发者来说非常对味对还在观望的人也能直观感受到“测试先行”在 AI 协作里的价值——AI 自己写的测试可以充当反复修改时的安全网后续你再让它改功能回归用例就在那里兜底。2. 安装部署与前置环境准备2.1 安装前需要准备什么先说环境。superpowers 不是独立软件它是 Codex CLI 的插件集所以你的机器上必须先装好 Codex CLI。如果你用的是 Trae Work CN 这类支持 skills 的编辑器也可以走另一条路径但核心前提一样得有一个能识别技能文件的 AI 编程环境。安装前建议确认几样东西Codex CLI 版本superpowers 的新特性通常会跟随 Codex CLI 的更新建议把 Codex 升级到比较新的版本再装。老版本可能解析不了插件配置或者行为差异很大。Node.js 环境Codex CLI 本身基于 Node.js装个 LTS 版本比较稳妥。如果你之前装过 CodexNode 环境通常已经有了。Git 命令行虽然不强制但在拉取 superpowers 仓库和后续更新时用得上。OpenAI API 访问权限或 Codex 订阅权限Codex CLI 需要连接后端模型这个前提没满足的话工具本身就跑不起来。这些准备项都满足后再动手安装 superpowers。我自己的环境是 macOS Node 20 LTSCodex CLI 已经用了一段时间整个安装过程大概十分钟以内能完成。2.2 通过 Codex CLI 安装 superpowersCodex CLI 的插件机制在早期版本里是通过配置文件管理的后来版本增加了更方便的插件安装命令。你可以先打开终端运行 Codex 的交互界面然后直接用/plugin指令查看当前插件状态或者用命令行直接安装。我实测过的路径大致如下# 先确认 codex 已安装 codex --version # 安装 superpowers 插件 codex plugins add superpowers如果当前版本的 Codex CLI 还不支持plugins add子命令也可以手动改配置文件。Codex CLI 的配置文件一般在~/.codex/config.tomlmacOS/Linux或%USERPROFILE%\.codex\config.tomlWindows。打开后找到[plugins]部分添加如下内容[plugins] superpowers github:obra/superpowers保存后重启 Codex CLI插件就会被加载。你可以输入类似“请列出你当前可用的技能”这种话看 AI 是否会提到 bootstrapping、tdd、design 等技能名称。能提到就说明 superpowers 已经生效了。提示部分版本对插件路径比较敏感如果你用的是本地 clone 的仓库可以把地址指向本地目录。比如superpowers file:///Users/yourname/superpowers这样可以随时手动改动技能文件来调试。2.3 在 Trae Work CN 中安装 superpowers skill如果你主力编辑器是 Trae Work CN也可以把 superpowers 作为 skill 装进去。Trae 支持自定义技能导入路径一般是设置 → 技能Skills→ 导入技能。source 选择本地目录或 Git 仓库把 superpowers 仓库 clone 下来后直接选中skills目录导入即可。# 先拉取项目 git clone https://github.com/obra/superpowers.git # 进入项目目录确认技能文件列表 cd superpowers ls skills在skills目录里你会看到一组子目录比如bootstrapping、test-driven-development、design等。Trae 导入时一般识别的是单个技能文件夹所以你需要逐个导入或者看你的版本是否支持整个目录批量导入。装完后在 Trae 的对话侧边栏里应该能看到这些技能出现在可用技能列表里使用效果和 Codex CLI 里的差别不大。有一点要注意Trae 的技能机制和 Codex 的插件机制不是一回事两者对技能文件的解析规则可能略有差异。遇到个别技能在 Trae 里不生效不用太纠结优先保证核心的 bootstrapping 和 tdd 两个技能能用就足够改善主力工作流了。3. 核心技能盘点与实际工作方式3.1 核心技能文件一览superpowers 仓库里的技能文件是这套工具的灵魂。不同版本技能清单会有些出入我目前版本里看到的几个核心技能技能名称核心作用使用场景bootstrapping向 AI 注入项目背景和整体工作原则开启新会话时先让它理解身份与使命test-driven-development强制测试先行红绿循环写新功能、修 bug 时最常用design编码前先讨论设计方案与备选方案复杂功能、模块设计、技术选型implementing-changes按计划逐步实现变更多文件改动、较大重构troubleshooting系统化排查问题避免乱试测试失败、运行报错、行为异常除了这五个仓库里还有一些更细粒度的技能比如写提交信息、做代码审查、处理安全问题的规则等。作者的思想挺清晰每一个技能都是在模拟真实团队里某种“角色规范”。bootstrapping 相当于入职培训test-driven-development 相当于质量红线design 相当于技术评审会implementing-changes 相当于开发计划troubleshooting 相当于故障排查手册。3.2 最常用的 TDD 技能到底怎么工作test-driven-development 是我用得最多的技能。没装 superpowers 之前我让 Codex 写个函数它常常直接生成完整实现看起来很方便但一旦逻辑分支稍微多点边界条件经常漏。装上 TDD 技能后Codex 会按一个固定节奏来推进先写一个最小失败测试跑一次确认是红的根据测试写最小实现让测试变绿再补下一个失败测试循环往复全部通过后做一轮简单重构。这个流程单独看并不稀奇奇的是由 AI 来执行时“先写测试再写实现”这个顺序会极大影响代码结构。AI 在写测试的过程中相当于提前做了一遍需求分析它会主动把“输入是什么、输出是什么、异常怎么办”想清楚再动手。我遇到过几次Codex 写完测试后停下来问我“这个方法的边界行为没定义是先抛异常还是返回空值”这种问题在过去直接写实现时它几乎不会提。如果你以前没有 TDD 习惯用这套技能会打开新世界——它把“安全修改代码”变成了一种可重复的操作模式。后续你再让 AI 改功能回归测试就在那里AI 每次跑完测试才知道自己有没有改坏东西比过去“改完凭感觉”靠谱太多。3.3 从“一问一答”到“项目协作”的体验变化装上 superpowers 后Codex 给我的观感更像一个拿着任务清单的协作者而不是一个等待指令的问答机器。举一个我最近的例子我要给一个内部工具加一个“批量导入用户”的功能。过去我直接说“帮我写批量导入”AI 吭哧吭哧生成一大段代码跑起来一堆异常。现在它先会根据 design 技能问我“导入文件的格式是什么字段校验失败是跳过还是中止重复用户怎么处理”这些问题会有一些繁琐但回答完之后它写出来的代码命中率非常高基本就是一版过。这种变化背后有一个很实在的设计逻辑AI 模型对自然语言歧义非常敏感同一句话在不同上下文里会有完全不同的理解。superpowers 通过技能文件强制 AI 在动手前做需求澄清相当于从流程上消灭歧义。实践证明多花两分钟对话能省下几十分钟的调试时间这笔账非常划算。4. 实操过程与典型任务拆解4.1 新会话启动后的标准操作流程我现在的习惯是每次用 Codex 处理一个新任务都会先让 AI 加载 bootstrapping 技能再进入具体任务。你可以直接对 Codex 说请加载 bootstrapping 技能然后我们开始处理一个任务。这时候 AI 通常会回复一段项目原则说明表示它理解了如何协作。接下来我再描述具体需求。它很有可能会反过来确认几件事项目背景、验收标准、修改范围、现有测试状态。这些确认动作都是 superpowers 注入的不用嫌烦把它当成 Team Leader 在开工会时做的信息拉齐就好。描述完需求后根据任务类型选择技能路径。小改动就直接走 implement 流程新功能或复杂逻辑就要求它先用 design 技能给出方案修复 bug 则建议它先写一个失败测试复现问题再开始改。这套组合拳打下来每次会话的节奏都会比较稳不太容易出现“AI 写了一堆代码、最后发现方向错了”的尴尬局面。4.2 一个典型任务的完整推进过程我拿一个真实任务来演示这样比较直观。任务是给一个 Python 脚本增加“从 CSV 导入用户并返回导入结果统计”的函数。第一步我启动 Codex让它加载 bootstrapping我请加载 bootstrapping 技能我们有一个新功能要开发。 AI已加载。我理解自己的工作方式先明确需求边界再设计方案测试先行小步实现。请描述任务。第二步我描述需求。因为 superpowers 的引导AI 主动问了我三个问题CSV 的必填列有哪些、重复用户如何处理、导入结果是否需要包含失败原因。我回答之后它给出了设计方案分两步先解析文件再批量写入写一个parse_csv和一个import_users函数。第三步在 design 技能引导下它列出了一个简短的接口定义和数据格式示例并说明异常处理策略。这里我不需要写任何代码它已经做了明确的拆解待我确认后才进入实现阶段。第四步进入 TDD 流程。AI 先生成测试文件覆盖三个场景正常导入、重复用户跳过、必填字段缺失报错。然后跑测试确认失败再逐个实现功能让测试变绿。整个过程它都在小幅操作每完成一个测试就跑一次 pytest。全部通过后它会做个极简重构然后汇报结果。这个过程比我以前直接用 Codex 写代码要慢一点点但完成质量明显高很多测试文件随需求一起交付函数边界清晰代码里几乎没有多余的“模型幻觉”。对于把稳定性和可维护性看得很重的项目这个慢是值得的。4.3 让 AI 遵循技能的执行细节日常使用中还有一个实用技巧你不需要每次手动指定技能。装好 superpowers 后Bootstrapping 技能会在新会话的默认上下文里被自动注入AI 会在合适的场景自动调用其他技能。但由于不同版本的 Codex 行为略有差异建议在一个任务的开头显式说一句请在所有步骤中遵循 TDD 技能的要求。这句话的效果是给当前会话设置一个强制优先级。实测下来加了这句之后AI 会更坚持先写测试。如果你连这句都不想输入也可以把这句话写进 Codex CLI 的用户自定义指令system prompt 或 AGENTS.md做成全局默认规则。这个思路我在两个项目里试过都挺稳的。注意如果任务本身是一次性探索或原型验证强行套 TDD 流程反而繁琐。此时你可以明确告诉 AI“不需要写测试只做快速原型”。superpowers 的规则是可覆盖的你的显式指令优先级更高。5. 常见问题与排查技巧实录5.1 安装后 AI 不识别技能怎么排最常遇到的问题就是插件配置完了Codex 却像没装一样完全不提技能。这时先别急着怀疑项目有问题从三处排查配置文件格式检查config.toml里插件路径有没有写错。常见错误是仓库地址带上了.git后缀以外的多余字符或者路径写成了https://github.com/obra/superpowers.git这种完整 URL有些版本只认github:obra/superpowers这种简写。Codex 版本过旧旧的 Codex CLI 对插件支持不完整最直观的验证方式是运行codex --version然后去项目 README 或更新日志里对一下要求的版本号。技能文件权限如果你是用本地 clone 的方式配置插件需要确认技能文件所在的目录有读取权限。权限不对时Codex 会静默跳过加载不报任何错误看起来就像没装一样。排完这三个点绝大多数情况都能解决。还有一个不常见的坑如果你同时开了多个终端窗口旧窗口里的 Codex 进程可能还持有旧配置改完配置后务必新开一个终端再试。5.2 测试先行遇到“遗留代码”怎么办装了 superpowers 之后AI 会默认要求先写测试。但如果你负责的是老项目一堆遗留代码连测试框架都没有这时候 TDD 流程会卡住。我的处理办法是分两步第一步先引入一个最轻量的测试框架比如 Python 的 pytest 或 Node 的 vitest只要能让 AI 跑起来即可不需要追求覆盖率。第二步遇到具体 bug 时让 AI 先针对这个 bug 写一个“复现性测试”也就是先证明问题存在再修改代码让测试通过。这个过程成本很低效果立竿见影——不仅修了 bug还留下了一个防止回归的测试。在 Codex 里可以这样表述这是遗留项目目前没有测试框架。先帮我引入 pytest 并写一个最小配置然后针对这个 bug 先写复现测试再修复。AI 在 superpowers 的规则下会很配合地执行这个两步方案。其实这也是所有改造老项目的好姿势不要幻想一步到位先给关键路径加安全网再逐步推广测试。5.3 常见问题速查表问题可能原因处理方法安装后技能不生效配置路径错误检查 config.toml 的插件路径AI 不写测试直接给代码任务没有明确遵循 TDD 技能显式要求“必须 TDD 流程”新会话里 AI 又“变笨”Bootstrapping 未自动加载手动要求加载 bootstrapping技能文件找不到本地仓库未拉取完整重新 clone 并确认 skills 目录内容老项目跑不了测试测试框架缺失先引入 pytest/vitest 再走 TDD配置改完不生效旧终端进程缓存了配置重启终端或重启 Codex5.4 我对这套工作方式的一些实操心得最后分享几个我自己的使用心得。第一个是关于“技能不是越多越好”。superpowers 默认会带不少技能文件但对多数日常任务来说bootstrapping 加 TDD 两个已经能覆盖大部分收益。我一开始试图让 AI 在每个任务里都把 design、implement、troubleshooting 全套走一遍结果对话变得冗长反而拖慢节奏。现在我按任务复杂度灵活选择小改动用 TDD 就够大功能才进 design只有排查疑难杂症时才上 troubleshooting。第二个心得是“AI 生成的测试也有质量问题”。superpowers 虽然让 AI 写测试但它写的测试有时会只覆盖正向路径对异常输入的断言不够。我现在的做法是AI 写完测试后我会扫一眼断言逻辑补上我认为关键的边界场景。它不是万能药但它提供了一个非常好的起点让我把精力花在补充关键用例上而不是从零搭测试框架。第三个心得是关于团队协作。如果你和同事共享一个项目建议把 superpowers 的技能文件纳入仓库的AGENTS.md或文档目录让每个人都能看到 AI 的工作规则。这样不同成员用 Codex 时的行为模式更一致代码风格也会更统一某种意义上这也是一种“团队级别的工作协议”。我个人在实际操作中的体会是superpowers 真正值钱的地方不是那些炫酷的提示词模板而是它把“怎么写代码才能少返工”这件事从人的脑子搬到了 AI 的运行机制里。它不是什么银弹装了也不会让你的 AI 一夜之间变成架构师但它确实是目前我在命令行 AI 编程工具里见过的最务实、最接近“真实团队协作”的增强层。如果你正在用 Codex CLI而且有点受不了它那种“撞了南墙再回头”的编码方式非常建议花半小时把这个技能包装上亲自感受一次 TDD 流程下的 AI 写代码。
