先直接说结论superpowers这个项目是今年上半年我见过最“懂开发者”的一个开源辅助工具。它是给OpenAI Codex CLI这类AI编程助手做的技能扩展包让AI不再只是“你问我答”的代码生成器而变成一个自带工作方法论、能主动规划任务的结对工程师。我第一次在GitHub上刷到它是在Steve Yegge那篇《Superpowers: How Coding Assistants are Changing the World》的讨论帖里。文章里有句话说得特别准大多数人不会用AI编程问题不在于AI不够强而在于AI没有一套“资深工程师该有的干活顺序”。superpowers就是把这句话做成了代码。这个项目适合谁主要是正在用Codex CLI、或者准备把AI编程落地到真实项目的开发者/团队负责人。如果你只是拿AI写点脚本、补个函数那它对你帮助有限但如果你要处理的是那种几千个文件的遗留代码库、要维护一套有测试有CI的工程体系它会让你明显感觉到AI“开窍了”。往下读之前提醒一句这不是一个开箱即用的插件它需要你理解它的设计思路然后花十分钟做一次配置。但这点投入换来的是AI从“小学生”到“工程师”的跨越。1. superpowers到底是什么一个装在AI助手脑子里的“工程方法论”1.1 从“会写代码”到“会干工程”的跳跃先明确一个定义superpowers不是编程框架也不是独立运行的命令行工具。它是一个以Markdown文件和目录结构为核心的知识库专门给AI编程助手读取。你把它配置到Codex CLI之后助手每次启动都会先读一套“工作手册”里面包含分析代码库、写测试、做重构、审计依赖、搭建新项目等几十种技能的详细流程。关键词是“流程”。举个例子普通情况下你让AI“帮我重构这个模块”它大概率是直接给你抛一段重写后的代码看起来好像没问题但一跑测试就挂。superpowers的模式是它先要求AI分析代码库结构生成模块依赖图列出重构风险点然后建议你从风险最低的模块开始改每改一处跑一遍测试。这个“先分析、再拆解、小步走、时时验证”的顺序就是资深工程师和AI的最大区别。1.2 项目想解决的问题AI编程的三个痛点我在实际用Codex CLI的过程中遇到过三个特别典型的问题superpowers基本就是冲着它们去的。第一AI缺乏全局视野。你让它改一个函数它只看得到这个函数看不到谁在调用它、改了之后会影响哪条链路。superpowers里的“代码库分析”技能强制AI先建立全局地图再动手。第二AI容易“自信地胡说”。不少AI生成的代码看着工整逻辑一推敲全是洞。superpowers的TDD工作流能让AI先写测试、再写实现用可运行的测试用例来约束它的幻觉这个理念对AI编程来说太关键了。第三AI的“手感”不稳定。同一个问题今天问和明天问可能给你两种完全不同的方案。superpowers用统一的技能模板把AI的输出拉到一个稳定的水平线上不会因为模型的微调而飘忽不定。1.3 它和普通Codex插件的本质区别市面上给Codex做增强的工具不少比如各种MCP服务器、提示词合集。superpowers的独特之处在于它的结构整个项目就是一个AGENTS.md加上一个skills目录。AGENTS.md是总纲告诉AI“你是一个有经验的工程师遇到问题先想清楚再动手”skills目录里每个Markdown文件是一个技能AI会根据你的请求自动“召唤”对应的技能模板。这种设计带来的好处是你可以像搭乐高一样自由组合技能而且整个流程对用户是完全透明的。换句话说它不是黑盒不是“装了就魔法生效”而是把AI的思考过程变成了可以阅读、可以修改、可以自定义的文档。这一点对我这种喜欢掌控细节的人来说是致命的吸引力。2. 安装与配置十分钟让Codex CLI背上技能包2.1 安装前的准备条件老规矩先说环境要求。superpowers本质上是一堆Markdown文件技术上没有任何依赖但对运行环境有两个要求第一你必须安装了Codex CLI并且能正常使用这个不用多解释第二建议你的项目里已经有Git管理因为superpowers的好几个技能比如重构、代码分析会依赖Git历史来评估变更影响范围。完整准备工作就三步安装Node.js 18以上版本虽然技能执行不依赖Node但Codex CLI本身是Node生态环境太老容易出诡异问题确认Codex CLI已经初始化完毕运行codex --version能看到版本号准备一个你想尝试的项目目录最好是那种结构稍微复杂一点、有多个模块的仓库效果直观2.2 下载与核心配置步骤安装方式很简单直接把仓库克隆到本地目录git clone https://github.com/obra/superpowers.git ~/superpowers克隆完成后核心工作变成“告诉Codex CLI去读这份工作手册”。Codex CLI的全局配置文件在~/.codex/config.toml你需要编辑它加上一段指向superpowers的指令。具体配置方法官方README推荐的是创建一个Profile把superpowers作为独立配置加载。我用的是这种[profiles] [profiles.superpowers] extra_instructions /Users/你的用户名/superpowers/AGENTS.md保存之后启动Codex CLI时用codex --profile superpowersAI就会带着这套技能包工作了。如果你用的Codex版本较老配置文件里还没有Profile功能也可以把指令直接写在[experimental]段落[experimental] extra_instructions ~/superpowers/AGENTS.md这两种方式的效果是一样的区别只在于Profile更适合多套配置切换。我把两套都写出来你就知道自己该用哪种了。2.3 验证技能是否生效配置完之后别急着开工先做一个30秒的验证。启动Codex后随便找个项目问它一句“请用一句话介绍你自己并列出你现在能做的主要任务类型。”如果配置成功它不会像以前那样回答“我是AI助手”而是会开始给你罗列“我可以进行代码库结构分析、按TDD流程编写测试、审计项目依赖安全性、制定重构计划……”读到这些关键词就说明AGENTS.md已经被加载了。不过这里我要提一个容易踩的坑如果你在某个Git仓库里启动了Codex而仓库本身也带了一个AGENTS.md文件那么两份工作手册会同时生效指令可能会有冲突。我在初期使用时就遇到过AI突然变“啰嗦”的情况排查了半天才意识到是项目级别和全局级别的指令叠在一起了。解决方法是优先级要心里有数项目根目录的AGENTS.md覆盖范围更聚焦全局配置管兜底两者冲突的时候以项目级为准。3. 核心技能拆解它能帮AI工程师做哪些正经事3.1 代码库分析让AI先画地图再动手这是所有技能里我用得最频繁的。以前的AI编程是“盲人摸象”你让它改大象的耳朵它不知道大象长什么样。superpowers里的analyze_codebase技能解决了这个问题。触发方式也很简单你只需要在对话里说一句“请分析这个代码库的结构输出一份总体概览。”AI会按技能模板执行一系列动作扫描目录树、统计文件分布、识别主框架和入口文件、绘制模块依赖关系、标注测试覆盖情况。最后它会输出一份结构化的分析报告包括技术栈总结、架构分层、潜在的技术债点。我特别推荐在接手一个陌生项目时第一件事就是让它跑这个技能。之前我接手一个内部后台系统两万多个文件以前靠人肉翻代码至少得两三天才能理出头绪。现在五分钟一份报告哪些模块能碰、哪些是祖传代码不能动心里大概就有数了。3.2 严格TDD工作流用测试约束AI的想象力这个技能是我认为superpowers最核心的资产名字叫TDD或者write_tests。AI编程最大的痛点就是生成代码质量不稳定而这个技能的思路非常朴素让AI遵循测试驱动开发的节奏来写代码用测试用例卡住它。执行流程是这样的AI先写一个失败测试运行它确认红然后写最小实现代码让测试通过确认绿最后进行重构再跑一遍全量测试确认没有回归。整个过程里它还会自己记录哪些文件修改了、测试结果是什么、还有哪些边界情况没覆盖。我的实测感受是这个模式有得有失。代价是速度变慢以前让AI一把梭生成一个完整功能现在它要先磨测试再磨代码输出内容明显变多。但收益是代码质量大幅提升尤其是逻辑复杂的业务代码。有一次我用它给一个支付回调模块写处理逻辑它会主动提出“这个场景还缺少一个幂等性校验的测试用例。”这种思考深度是普通提示词模式很难激发出来的。3.3 依赖审计与安全扫描给项目做“体检”项目管理里最容易被忽视的就是依赖安全。superpowers里的audit_dependencies技能能把这件事变成AI的日常任务。它支持自动识别项目里的依赖清单文件比如Node项目的package.json、Python项目的requirements.txt、Java项目的pom.xml。识别之后AI会调用包管理器的安全查询接口把存在已知漏洞的依赖包拉出来标注风险等级并给出可升级的目标版本。这里我要多说一句很多开发者觉得“依赖审计”是CI/CD插件的事没必要在AI里做。但我的体会是插件只能告诉你“哪个包有漏洞”AI能帮你判断“升级这个包会影响哪些业务模块改动量大概多大”。这个决策信息在技术方案评审会上特别有说服力。3.4 新项目脚手架一键搭建标准工程这个技能适合“从零开始”的场景。以前用AI搭新项目你得反复描述需求它还经常给你一个结构残缺的样板。superpowers里的new_project技能内置了几种工程模板包括前端Vite/React、全栈Astro、Express后端等它会按照工程化标准一次性生成项目结构、写入基础配置、安装依赖并跑通构建。我试过让它生成一个企业级前端项目它不仅搭好了目录还自动配好了ESLint、Prettier、Husky这些工程化工具省了我大量重复劳动。不过有一点要注意它默认生成的是偏现代风格的项目结构如果你团队有自己固化的工程规范最好还是基于自己的模板让AI做自定义不要让AI自由发挥。3.5 日常代码审查第二个工程师帮你把关code_review技能同样很实用。它的工作方式不是“事后检查”而是让AI在开发过程中充当一个持续监督的角色。你可以把一段改动发给它它会从可读性、健壮性、安全性、可访问性四个维度给出审查意见。最有意思的是它能发现“非语法错误”的潜在问题——比如你在自己代码里可能根本注意不到的资源泄漏它会在审查报告里直接标注出来并建议修复方案。这对没有专职Code Review的团队来说相当有价值。4. 实操体验带着superpowers改造一个遗留项目4.1 用一个真实场景检验AI光讲功能显得空我拿一个实际项目来说说完整流程。五月份我把一个老项目交给了superpowers改造那是一套2018年左右写的用户管理微服务Spring Boot框架代码风格比较混乱测试覆盖几乎为零。第一步我启动Codex并加载superpowers配置让它先做代码库分析。大概过了不到一分钟它就给出了一个分层清晰的概览Controller层有哪些黑洞逻辑、Service层哪些类承担了过多职责、数据访问层哪些地方存在安全隐患。逐条翻下来惊讶的发现它不仅理解了代码结构还基本判断出了哪些模块是核心链路、哪些模块可以动刀。第二步我指示它选择其中一个service类起了一个重构计划。它的做法很标准先给出一份“当前问题列表”再列出一份“重构步骤地图”小步重构、每步保证编译通过、运行测试确认未破坏其他逻辑。这种风格的代码改动比直接重写一大段逻辑要安全得多。4.2 跟普通模式做的对比记录我特意做了一个对比同样一个功能改动分别用普通Codex模式和superpowers模式跑一遍测试结果差异在“及格分数线”之上拉得很开。普通模式下AI直接给了成品代码看起来大差不差但一翻边界场景就存在问题superpowers模式下它多花了一倍的时间写测试和校验最终代码也更符合团队规范。我统计过两个数字虽然不严谨但可以参考普通模式的代码回到测试环境跑一遍三五个小问题是常态superpowers模式生成的代码通常一遍就能通过。代价是耗时多了50%左右回答的字数也多出一大截。两者怎么选不取决于工具本身取决于你的场景——一次性任务脚本用普通模式就够了核心业务代码交给superpowers模式更稳妥。4.3 团队协作里的落地经验superpowers还有一个容易被忽略的价值它是可以被团队共享的。项目仓库克隆到本地后你完全可以把它提交到团队的Git仓库里所有人统一版本统一技能包AI的工作手册变成团队知识沉淀的一部分。我建议团队里指定一位成员专门维护这个技能包把团队自己的规范、模板、常见踩坑记录整理成新的skill文件丢进skills目录。这样AI在干活时会自动参考这些团队私有的方法论比传一个几百页的内部Wiki高效得多。我们团队就是这么干的把周会上反复强调的“代码提交规范”做成了一个技能文件AI每次生成提交信息时都会遵守。5. 常见问题与避坑我踩过的四次坑5.1 安装后AI不读技能包第一次配置完成后我满心期待地启动codex结果AI完全没有“新手艺”回答风格跟以前一模一样。排查了半天问题出在配置文件上我用的Codex版本比较新[experimental]段落已经被废弃了必须写在[profiles]里它才认。如果你的配置在旧版有效、升级后失效了大概率是这个原因。5.2 Token开销明显变大这个吓退了不少人。因为技能包要求AI先分析再动手输出内容会膨胀一次完整会话的token消耗可能翻倍。我的建议是不要对简单任务开superpowers日常语法问题、正则表达式这类工作直接普通模式只有面对复杂任务、有依赖关系或需要动架构时再切换到superpowers profile。养成这个习惯后成本其实在可控范围。5.3 多AGENTS.md冲突前面提到过项目根目录如果有自己的AGENTS.md会和全局的superpowers产生冲突。这种冲突不表现为报错而是AI行为变得混乱有时候遵循项目指令有时候遵循全局指令。我的排查思路是逐级查看先看项目根目录有没有工作手册再看全局有没有叠加。把这几个文件全检查一遍行为基本就能恢复正常。5.4 Windows路径导致读取失败如果你在Windows上工作配置路径里的斜杠方向很容易踩坑。Codex的配置解析器对Windows风格的反斜杠支持有限我建议路径一律用正斜杠写C:/Users/用户名/superpowers/AGENTS.md。另外一个冷门坑是如果路径中包含空格记得用引号把整段路径包起来。6. 自定义skills与后续玩法把方法论变成自己的武装6.1 如何写一个属于自己的技能文件superpowers的价值不止于开箱自带的技能更在于它的开放性。skills目录下每个技能都是独立的Markdown文件你要新增技能复制一个现有模板改几个关键字段就行。结构并不复杂四个部分技能名称、适用场景、执行步骤、返回格式。比如我给团队写过一个“数据库迁移规范”技能执行步骤是先对比Schema差异再生成迁移脚本然后预览影响行数最后询问确认。本质上就是把团队专家脑袋里的流程固化成一个文件让所有用AI的同事都享受到资深DBA的“外挂”。6.2 把它和团队规范深度绑定自定义技能文件可以直接提交到Git仓库变成团队工程资产。你甚至可以给它配置分支保护更新走Pull Request流程评审通过才能合入。这样做之后团队AI开发会越来越标准化任何一次代码变更都会遵循统一的质量门禁。我见过做得比较极致的团队把代码评审规范、日志格式、命名规范全部做进skill里然后强制所有AI辅助开发走这个profile。有新人入职先让他把AI配置好再去看项目文档——相当于给新人配了一个随身“资深代码导师”。6.3 进阶让它成为你的“项目记忆库”最后分享一个我的另类玩法把项目的业务背景和常见坑做成一个全局说明文件放进superpowers的AGENTS.md里。这样每次启动CodexAI都会先“回忆”这个项目的来龙去脉、之前踩过哪些坑而不是每次从零理解。这个做法用了之后效果很夸张AI对业务的理解会“持续积累”。不再是一台没有记忆的问答机而是一个越用越懂你的虚拟同事。如果你已经把项目玩透了我强烈建议你研究一下怎么把AI的“记忆”沉淀下来——这是比任何插件都有价值的一件事。说回这个项目本身很多人以为superpowers是给AI“加技能”我倒觉得它更像给AI立规矩。限制它乱发挥反而让它更可靠。这个思路值得每个搞AI编程的人试一试。
superpowers：为Codex CLI注入工程方法论的开源技能包
先直接说结论superpowers这个项目是今年上半年我见过最“懂开发者”的一个开源辅助工具。它是给OpenAI Codex CLI这类AI编程助手做的技能扩展包让AI不再只是“你问我答”的代码生成器而变成一个自带工作方法论、能主动规划任务的结对工程师。我第一次在GitHub上刷到它是在Steve Yegge那篇《Superpowers: How Coding Assistants are Changing the World》的讨论帖里。文章里有句话说得特别准大多数人不会用AI编程问题不在于AI不够强而在于AI没有一套“资深工程师该有的干活顺序”。superpowers就是把这句话做成了代码。这个项目适合谁主要是正在用Codex CLI、或者准备把AI编程落地到真实项目的开发者/团队负责人。如果你只是拿AI写点脚本、补个函数那它对你帮助有限但如果你要处理的是那种几千个文件的遗留代码库、要维护一套有测试有CI的工程体系它会让你明显感觉到AI“开窍了”。往下读之前提醒一句这不是一个开箱即用的插件它需要你理解它的设计思路然后花十分钟做一次配置。但这点投入换来的是AI从“小学生”到“工程师”的跨越。1. superpowers到底是什么一个装在AI助手脑子里的“工程方法论”1.1 从“会写代码”到“会干工程”的跳跃先明确一个定义superpowers不是编程框架也不是独立运行的命令行工具。它是一个以Markdown文件和目录结构为核心的知识库专门给AI编程助手读取。你把它配置到Codex CLI之后助手每次启动都会先读一套“工作手册”里面包含分析代码库、写测试、做重构、审计依赖、搭建新项目等几十种技能的详细流程。关键词是“流程”。举个例子普通情况下你让AI“帮我重构这个模块”它大概率是直接给你抛一段重写后的代码看起来好像没问题但一跑测试就挂。superpowers的模式是它先要求AI分析代码库结构生成模块依赖图列出重构风险点然后建议你从风险最低的模块开始改每改一处跑一遍测试。这个“先分析、再拆解、小步走、时时验证”的顺序就是资深工程师和AI的最大区别。1.2 项目想解决的问题AI编程的三个痛点我在实际用Codex CLI的过程中遇到过三个特别典型的问题superpowers基本就是冲着它们去的。第一AI缺乏全局视野。你让它改一个函数它只看得到这个函数看不到谁在调用它、改了之后会影响哪条链路。superpowers里的“代码库分析”技能强制AI先建立全局地图再动手。第二AI容易“自信地胡说”。不少AI生成的代码看着工整逻辑一推敲全是洞。superpowers的TDD工作流能让AI先写测试、再写实现用可运行的测试用例来约束它的幻觉这个理念对AI编程来说太关键了。第三AI的“手感”不稳定。同一个问题今天问和明天问可能给你两种完全不同的方案。superpowers用统一的技能模板把AI的输出拉到一个稳定的水平线上不会因为模型的微调而飘忽不定。1.3 它和普通Codex插件的本质区别市面上给Codex做增强的工具不少比如各种MCP服务器、提示词合集。superpowers的独特之处在于它的结构整个项目就是一个AGENTS.md加上一个skills目录。AGENTS.md是总纲告诉AI“你是一个有经验的工程师遇到问题先想清楚再动手”skills目录里每个Markdown文件是一个技能AI会根据你的请求自动“召唤”对应的技能模板。这种设计带来的好处是你可以像搭乐高一样自由组合技能而且整个流程对用户是完全透明的。换句话说它不是黑盒不是“装了就魔法生效”而是把AI的思考过程变成了可以阅读、可以修改、可以自定义的文档。这一点对我这种喜欢掌控细节的人来说是致命的吸引力。2. 安装与配置十分钟让Codex CLI背上技能包2.1 安装前的准备条件老规矩先说环境要求。superpowers本质上是一堆Markdown文件技术上没有任何依赖但对运行环境有两个要求第一你必须安装了Codex CLI并且能正常使用这个不用多解释第二建议你的项目里已经有Git管理因为superpowers的好几个技能比如重构、代码分析会依赖Git历史来评估变更影响范围。完整准备工作就三步安装Node.js 18以上版本虽然技能执行不依赖Node但Codex CLI本身是Node生态环境太老容易出诡异问题确认Codex CLI已经初始化完毕运行codex --version能看到版本号准备一个你想尝试的项目目录最好是那种结构稍微复杂一点、有多个模块的仓库效果直观2.2 下载与核心配置步骤安装方式很简单直接把仓库克隆到本地目录git clone https://github.com/obra/superpowers.git ~/superpowers克隆完成后核心工作变成“告诉Codex CLI去读这份工作手册”。Codex CLI的全局配置文件在~/.codex/config.toml你需要编辑它加上一段指向superpowers的指令。具体配置方法官方README推荐的是创建一个Profile把superpowers作为独立配置加载。我用的是这种[profiles] [profiles.superpowers] extra_instructions /Users/你的用户名/superpowers/AGENTS.md保存之后启动Codex CLI时用codex --profile superpowersAI就会带着这套技能包工作了。如果你用的Codex版本较老配置文件里还没有Profile功能也可以把指令直接写在[experimental]段落[experimental] extra_instructions ~/superpowers/AGENTS.md这两种方式的效果是一样的区别只在于Profile更适合多套配置切换。我把两套都写出来你就知道自己该用哪种了。2.3 验证技能是否生效配置完之后别急着开工先做一个30秒的验证。启动Codex后随便找个项目问它一句“请用一句话介绍你自己并列出你现在能做的主要任务类型。”如果配置成功它不会像以前那样回答“我是AI助手”而是会开始给你罗列“我可以进行代码库结构分析、按TDD流程编写测试、审计项目依赖安全性、制定重构计划……”读到这些关键词就说明AGENTS.md已经被加载了。不过这里我要提一个容易踩的坑如果你在某个Git仓库里启动了Codex而仓库本身也带了一个AGENTS.md文件那么两份工作手册会同时生效指令可能会有冲突。我在初期使用时就遇到过AI突然变“啰嗦”的情况排查了半天才意识到是项目级别和全局级别的指令叠在一起了。解决方法是优先级要心里有数项目根目录的AGENTS.md覆盖范围更聚焦全局配置管兜底两者冲突的时候以项目级为准。3. 核心技能拆解它能帮AI工程师做哪些正经事3.1 代码库分析让AI先画地图再动手这是所有技能里我用得最频繁的。以前的AI编程是“盲人摸象”你让它改大象的耳朵它不知道大象长什么样。superpowers里的analyze_codebase技能解决了这个问题。触发方式也很简单你只需要在对话里说一句“请分析这个代码库的结构输出一份总体概览。”AI会按技能模板执行一系列动作扫描目录树、统计文件分布、识别主框架和入口文件、绘制模块依赖关系、标注测试覆盖情况。最后它会输出一份结构化的分析报告包括技术栈总结、架构分层、潜在的技术债点。我特别推荐在接手一个陌生项目时第一件事就是让它跑这个技能。之前我接手一个内部后台系统两万多个文件以前靠人肉翻代码至少得两三天才能理出头绪。现在五分钟一份报告哪些模块能碰、哪些是祖传代码不能动心里大概就有数了。3.2 严格TDD工作流用测试约束AI的想象力这个技能是我认为superpowers最核心的资产名字叫TDD或者write_tests。AI编程最大的痛点就是生成代码质量不稳定而这个技能的思路非常朴素让AI遵循测试驱动开发的节奏来写代码用测试用例卡住它。执行流程是这样的AI先写一个失败测试运行它确认红然后写最小实现代码让测试通过确认绿最后进行重构再跑一遍全量测试确认没有回归。整个过程里它还会自己记录哪些文件修改了、测试结果是什么、还有哪些边界情况没覆盖。我的实测感受是这个模式有得有失。代价是速度变慢以前让AI一把梭生成一个完整功能现在它要先磨测试再磨代码输出内容明显变多。但收益是代码质量大幅提升尤其是逻辑复杂的业务代码。有一次我用它给一个支付回调模块写处理逻辑它会主动提出“这个场景还缺少一个幂等性校验的测试用例。”这种思考深度是普通提示词模式很难激发出来的。3.3 依赖审计与安全扫描给项目做“体检”项目管理里最容易被忽视的就是依赖安全。superpowers里的audit_dependencies技能能把这件事变成AI的日常任务。它支持自动识别项目里的依赖清单文件比如Node项目的package.json、Python项目的requirements.txt、Java项目的pom.xml。识别之后AI会调用包管理器的安全查询接口把存在已知漏洞的依赖包拉出来标注风险等级并给出可升级的目标版本。这里我要多说一句很多开发者觉得“依赖审计”是CI/CD插件的事没必要在AI里做。但我的体会是插件只能告诉你“哪个包有漏洞”AI能帮你判断“升级这个包会影响哪些业务模块改动量大概多大”。这个决策信息在技术方案评审会上特别有说服力。3.4 新项目脚手架一键搭建标准工程这个技能适合“从零开始”的场景。以前用AI搭新项目你得反复描述需求它还经常给你一个结构残缺的样板。superpowers里的new_project技能内置了几种工程模板包括前端Vite/React、全栈Astro、Express后端等它会按照工程化标准一次性生成项目结构、写入基础配置、安装依赖并跑通构建。我试过让它生成一个企业级前端项目它不仅搭好了目录还自动配好了ESLint、Prettier、Husky这些工程化工具省了我大量重复劳动。不过有一点要注意它默认生成的是偏现代风格的项目结构如果你团队有自己固化的工程规范最好还是基于自己的模板让AI做自定义不要让AI自由发挥。3.5 日常代码审查第二个工程师帮你把关code_review技能同样很实用。它的工作方式不是“事后检查”而是让AI在开发过程中充当一个持续监督的角色。你可以把一段改动发给它它会从可读性、健壮性、安全性、可访问性四个维度给出审查意见。最有意思的是它能发现“非语法错误”的潜在问题——比如你在自己代码里可能根本注意不到的资源泄漏它会在审查报告里直接标注出来并建议修复方案。这对没有专职Code Review的团队来说相当有价值。4. 实操体验带着superpowers改造一个遗留项目4.1 用一个真实场景检验AI光讲功能显得空我拿一个实际项目来说说完整流程。五月份我把一个老项目交给了superpowers改造那是一套2018年左右写的用户管理微服务Spring Boot框架代码风格比较混乱测试覆盖几乎为零。第一步我启动Codex并加载superpowers配置让它先做代码库分析。大概过了不到一分钟它就给出了一个分层清晰的概览Controller层有哪些黑洞逻辑、Service层哪些类承担了过多职责、数据访问层哪些地方存在安全隐患。逐条翻下来惊讶的发现它不仅理解了代码结构还基本判断出了哪些模块是核心链路、哪些模块可以动刀。第二步我指示它选择其中一个service类起了一个重构计划。它的做法很标准先给出一份“当前问题列表”再列出一份“重构步骤地图”小步重构、每步保证编译通过、运行测试确认未破坏其他逻辑。这种风格的代码改动比直接重写一大段逻辑要安全得多。4.2 跟普通模式做的对比记录我特意做了一个对比同样一个功能改动分别用普通Codex模式和superpowers模式跑一遍测试结果差异在“及格分数线”之上拉得很开。普通模式下AI直接给了成品代码看起来大差不差但一翻边界场景就存在问题superpowers模式下它多花了一倍的时间写测试和校验最终代码也更符合团队规范。我统计过两个数字虽然不严谨但可以参考普通模式的代码回到测试环境跑一遍三五个小问题是常态superpowers模式生成的代码通常一遍就能通过。代价是耗时多了50%左右回答的字数也多出一大截。两者怎么选不取决于工具本身取决于你的场景——一次性任务脚本用普通模式就够了核心业务代码交给superpowers模式更稳妥。4.3 团队协作里的落地经验superpowers还有一个容易被忽略的价值它是可以被团队共享的。项目仓库克隆到本地后你完全可以把它提交到团队的Git仓库里所有人统一版本统一技能包AI的工作手册变成团队知识沉淀的一部分。我建议团队里指定一位成员专门维护这个技能包把团队自己的规范、模板、常见踩坑记录整理成新的skill文件丢进skills目录。这样AI在干活时会自动参考这些团队私有的方法论比传一个几百页的内部Wiki高效得多。我们团队就是这么干的把周会上反复强调的“代码提交规范”做成了一个技能文件AI每次生成提交信息时都会遵守。5. 常见问题与避坑我踩过的四次坑5.1 安装后AI不读技能包第一次配置完成后我满心期待地启动codex结果AI完全没有“新手艺”回答风格跟以前一模一样。排查了半天问题出在配置文件上我用的Codex版本比较新[experimental]段落已经被废弃了必须写在[profiles]里它才认。如果你的配置在旧版有效、升级后失效了大概率是这个原因。5.2 Token开销明显变大这个吓退了不少人。因为技能包要求AI先分析再动手输出内容会膨胀一次完整会话的token消耗可能翻倍。我的建议是不要对简单任务开superpowers日常语法问题、正则表达式这类工作直接普通模式只有面对复杂任务、有依赖关系或需要动架构时再切换到superpowers profile。养成这个习惯后成本其实在可控范围。5.3 多AGENTS.md冲突前面提到过项目根目录如果有自己的AGENTS.md会和全局的superpowers产生冲突。这种冲突不表现为报错而是AI行为变得混乱有时候遵循项目指令有时候遵循全局指令。我的排查思路是逐级查看先看项目根目录有没有工作手册再看全局有没有叠加。把这几个文件全检查一遍行为基本就能恢复正常。5.4 Windows路径导致读取失败如果你在Windows上工作配置路径里的斜杠方向很容易踩坑。Codex的配置解析器对Windows风格的反斜杠支持有限我建议路径一律用正斜杠写C:/Users/用户名/superpowers/AGENTS.md。另外一个冷门坑是如果路径中包含空格记得用引号把整段路径包起来。6. 自定义skills与后续玩法把方法论变成自己的武装6.1 如何写一个属于自己的技能文件superpowers的价值不止于开箱自带的技能更在于它的开放性。skills目录下每个技能都是独立的Markdown文件你要新增技能复制一个现有模板改几个关键字段就行。结构并不复杂四个部分技能名称、适用场景、执行步骤、返回格式。比如我给团队写过一个“数据库迁移规范”技能执行步骤是先对比Schema差异再生成迁移脚本然后预览影响行数最后询问确认。本质上就是把团队专家脑袋里的流程固化成一个文件让所有用AI的同事都享受到资深DBA的“外挂”。6.2 把它和团队规范深度绑定自定义技能文件可以直接提交到Git仓库变成团队工程资产。你甚至可以给它配置分支保护更新走Pull Request流程评审通过才能合入。这样做之后团队AI开发会越来越标准化任何一次代码变更都会遵循统一的质量门禁。我见过做得比较极致的团队把代码评审规范、日志格式、命名规范全部做进skill里然后强制所有AI辅助开发走这个profile。有新人入职先让他把AI配置好再去看项目文档——相当于给新人配了一个随身“资深代码导师”。6.3 进阶让它成为你的“项目记忆库”最后分享一个我的另类玩法把项目的业务背景和常见坑做成一个全局说明文件放进superpowers的AGENTS.md里。这样每次启动CodexAI都会先“回忆”这个项目的来龙去脉、之前踩过哪些坑而不是每次从零理解。这个做法用了之后效果很夸张AI对业务的理解会“持续积累”。不再是一台没有记忆的问答机而是一个越用越懂你的虚拟同事。如果你已经把项目玩透了我强烈建议你研究一下怎么把AI的“记忆”沉淀下来——这是比任何插件都有价值的一件事。说回这个项目本身很多人以为superpowers是给AI“加技能”我倒觉得它更像给AI立规矩。限制它乱发挥反而让它更可靠。这个思路值得每个搞AI编程的人试一试。
