1. 话说superpowers这个给 Codex CLI 加 Buff 的开源项目到底是什么最近一周我的信息流里连续被同一个词刷屏——superpowers。点进去一看好家伙不是漫威电影也不是什么励志鸡汤而是一个给 OpenAI Codex CLI 注入超能力的开源项目。抱着让我看看你有多能打的心态我把它的源码、文档和社区讨论翻了个底朝天又在自己机器上连着试了两天今天这篇就把我的实操过程和真实感受完整记录下来。先说这项目解决的核心问题。用过 Codex CLI 的人应该都有同感它确实能读代码、改代码、跑命令但很多时候更像一个指哪打哪的执行工具。你给一句 prompt 让它重构某个模块很可能它只是机械地把方法 A 改成方法 B对项目历史、既有约定、团队规范、多文件连带影响全都不管不顾。说白了它能干但不会来事。Superpowers 的定位就是解决这个会来事的问题。它给 Codex 加了一层技能层内置一套声明式技能库、行为约束框架和上下文采集机制让 Codex 不再是一个纯粹的代码生成器而更像一个懂得开工前先看项目上下文、动手前先确认工作流程、改完后主动自查影响面的结对程序员。这项目是 Jesse Vincent 发起的名字直接致敬了编程界的superpowers传统——早期那本同名书籍作者 Erik Dietrich讲的是程序员通过强化核心技能获得超能力而这个项目把概念搬到了 AI 协作领域思路是一致的不是换更强的模型而是把现有模型的潜力通过工程化手段压榨到极致。有一点必须说清楚Superpowers 不是独立 IDE不是 GUI 工具也不是某个大厂的官方产品。它是一个开源 CLI 增强层跑在 OpenAI Codex CLI 之上用 shell 脚本、提示词和本地技能库的组合来实现增强。这也决定了它的安装和使用逻辑跟传统开发工具有本质差异——你要先有 Codex CLI然后克隆 Superpowers 仓库再通过配置文件的指向让它接管你的 Codex 会话。对谁最有价值我主观排个序一是每天高频使用 Codex CLI 的开发者尤其是做多语言项目维护的人二是研究 AI 协作工作流的团队想搞清楚提示词工程化到底能走多远三是好奇心驱动的技术爱好者愿意花一晚上折腾配置、读读别人的 shell 脚本。如果你只是偶尔用 Codex 生成个正则表达式那这项目对你意义不大——杀鸡用牛刀不说光配置环节就够你喝一壶的。我这两天实测下来最大的感受是这项目改变的不是 Codex 的回答质量而是它的行为模式。同样是帮我修复测试失败加了 Superpowers 之后它会先看 git diff、查历史提交、确认是否偏离了团队规范然后才动手——这个先调查后行动的流程本身就是最大的价值增量。接下来按我的操作顺序从原理到安装到实测一步步说。2. 三根支柱技能墙、Code Tattler 与协议守护者理解 Superpowers 之前必须先理解它内部的三层设计。这三层分别对应让 Codex 会什么、让 Codex 知道发生了什么、让 Codex 不该做什么。2.1 技能墙Skills Wall把能力变成可装载的模块Superpowers 的核心是一个本地技能库Jesse 管它叫技能墙。初次启动时它会在你的项目目录下生成一个.superpowers文件夹里面按目录组织了一堆技能文件。每个技能文件是一个固定格式的文档描述一个特定能力技能名称、适用场景、执行步骤、注意事项。比如内置的技能里有refactor-go-function、diagnose-bug-with-debugger这类针对具体编程场景的技能也有比较通用的code-review、write-unit-test。更关键的是这些技能文件可以被项目团队成员共享、修改、扩展——技能墙本质是一个团队的集体智慧沉淀库。我拉着看了几个技能文件的写法结构有点像菜谱一段前置检查列出动手前必须确认的条件一段执行步骤给出具体操作序列还有验收标准定义做完后如何自查。有意思的是这些文件刻意写得非常啰嗦理由后面说。2.2 Code Tattler让 AI 先看 Git 历史再动手第二层叫 Code Tattler我翻译成代码告密者。它的职责是给 Codex 一个侦察兵在每次会话开始自动去翻 git 状态——有没有未提交的改动、当前在哪个分支、最近几条提交信息是什么、有没有涉及变更的大文件。这套信息会作为会话的开场白注入给模型。这个设计有一个很现实的前提语言模型的上下文窗口不管多大都喂不进去一个完整仓库但你完全可以喂进去仓库的最近脉搏。一段 git log 和一纸 git diff 比让模型硬猜项目状态靠谱得多。实测后我发现这个机制最大的价值在于让 Codex 少说废话。如果没有 Code Tattler你问帮我看看这个模块为什么出错它可能从模块代码本身开始分析有了 Tattler它知道自己刚改过什么文件第一反应会是最近一次提交改动过 X可能是这个引入的问题。这个由近及远的归因顺序恰恰是经验丰富的程序员最常用的debug路径。2.3 协议守护者Protocol Enforcer给 AI 立规矩第三层是 Protocol Enforcer翻译成协议守护者。它的做法是在项目里维护一个AGENTS.md之类的协议文件里面记录团队的工作规范注释风格、代码组织方式、test 命令、commit 规范等。每次会话启动Superpowers 会要求 Codex 快速浏览这个文件并把必须遵守的事项压缩成几条明确约定持续约束本次会话。我当时看到这个设计的第一反应是这不就是把提示词工程里的system prompt 约束下沉到了项目级。但仔细想了想差别其实很大。普通 system prompt 是一次性的而协议守护者是持续性的——它不只在会话开头强调一次而是通过技能文件中的前置检查环节反复提醒相当于把规矩嵌入了每一步动作里。这个设计有个很聪明的点。它不依赖模型自觉而是靠流程强制。就像考驾照必须经历的上车前绕车一周Superpowers 把动手前先检查协议变成了一项必须执行的动作序列无论你用的是 GPT-4o 还是别的小模型都躲不过这一道程序。对于行为稳定性还不够好的模型来说这种强制流程确实比期望自觉可靠得多。三个机制的共同点也值得说一嘴它们本质上都是把工程师团队的隐性工作习惯翻译成了显式的文件、流程和约束。显而易见的工程价值之外其实对初学者的启发更大——看完这套设计你会意识到让 AI 高效工作这件事本身就是一个需要设计的系统。3. 安装实录从仓库克隆到第一次完整会话工具再怎么讲得天花乱坠装不上就是零。我把我的安装过程从头到尾记录一遍顺便标注容易踩坑的点。3.1 前置条件操作系统macOSLinux 行为类似Windows 建议走 WSL已安装 Node.js 18Codex CLI 本身依赖已安装并登录 OpenAI Codex CLI确认codex命令可用已安装 git如果你还没装 Codex CLI先去官网按正常流程装上、完成登录再回来。我测试时 Node 版本是 v20.11.0Codex CLI 是当时的最新版。3.2 克隆与安装安装分两步。第一步是克隆仓库第二步是通过一个安装脚本建立起 Codex 配置指向。第一步很简单git clone https://github.com/workswithautomation/superpowers.git cd superpowers第二步仓库里有一个scripts/install.sh直接执行bash scripts/install.sh脚本会做三件事在你的 Codex 配置目录通常是~/.codex/下写入一个增强配置让 Codex 启动时加载 Superpowers 的提示词和技能索引复制一份技能库到全局配置目录确保任何项目都能访问基础技能设置一个环境变量开关让你可以在普通 Codex 和 Superpowers 模式之间切换。装完以后我第一反应是看看它到底改了什么。在~/.codex/config.toml里能找到一个新增的配置块指向了 Superpowers 的技能目录和提示词文件。这一步其实很关键——它本质上是在 Codex 的官方后门里挂载了一个前置处理器所有进出的会话都会先经过 Superpowers 的引导逻辑。3.3 初始化项目环境装完不是马上就能用你需要在你要开发的具体项目目录里跑一条初始化命令codex exec 使用 superpowers 初始化当前项目就是这么一句人话。Codex 会调用 Superpowers 提供的技能库在项目下生成.superpowers/目录并把AGENTS.md等协议文件也初始化好。这一步有两点需要注意。第一初始化是项目级的换了新项目要重新跑一遍第二生成的.superpowers/目录不要提交到 git 忽略列表里——虽然它是本地生成的但团队协作时技能库文件本身就是维护对象提交了才能共享。3.4 首次启动后的对话式引导初始化完成后进入交互模式会有一段很独特的引导过程。Codex 会问几个问题这个项目用什么语言测试命令是什么代码风格有没有特殊要求有没有约定的 commit message 格式我当时以为这只是随便问问结果发现每个回答都会被写进AGENTS.md变成后续所有会话的硬约束。这个体验说实话有点震撼——它不是把规则烧死在代码里而是让你用自然语言配置项目规范这让非技术背景的参与者也能轻松维护团队约定。整体安装流程不算太长从零到第一次完整会话大概 20 分钟包含看文档和思考的时间。如果你跳过前面看文档的步骤直接跑大概率会卡在初始化项目环境这步因为很多细节依赖你理解了 AGENTS.md 的含义。4. 实测场景用 Java 项目试了试哪些场景真香哪些是坑只装不用是耍流氓。我找了个中型 Java 项目模拟日常开发场景做了三轮测试每轮都对比普通 Codex和Superpowers 模式的表现差异。4.1 场景一报错排查第一轮我故意把一个方法里抛出的异常类型改错然后丢给 Codex 一句我的服务启动时报 ClassCastException帮我看看为什么。普通 Codex 的处理方式是打开相关文件逐行扫看到 List 接口强转 ArrayList直接说这里类型不匹配。简单粗暴答案没错。Superpowers 模式的处理路径明显长了先跑git status和git diff看到这个文件的最近改动回溯 git log确认这个强转是哪次提交引入的检查AGENTS.md里有没有相关的编码规范重新启动服务复现报错给出修复建议并标注这个改动涉及两个调用方建议一并回归。说实话单看找到问题这一步两边差不多快。但 Superpowers 模式给到的附带信息量大得多——它指出这次改动影响了两个外部调用方这是普通模式没给的。多花十几秒拿到一个全景分析对代码维护来说值了。4.2 场景二重构函数第二轮我让它帮忙重构一个 80 行的私有方法拆成几个小函数。普通 Codex 拆得基本可以用但有个毛病拆分后的私有方法变量命名沿用了原方法的局部变量名有些名字和职责对不上号。Superpowers 模式拆完以后代码风格明显规整——方法名和变量名都更贴合新职责还有个细节它在重构完以后主动检查了所有调用点然后改了一处我在测试中故意遗留的调用引用。这个对比背后是机制差异。普通模式是给什么 answer 什么Superpowers 模式因为技能墙里有refactor相关技能它把重构拆成了识别职责-设计方法签名-迁移逻辑-更新调用点-跑测试五步每步独立检查。这跟有经验的人干活是一个套路——不是一口气改完再回头修而是边改边验证。4.3 场景三写单元测试第三轮我让它给一个新写的工具类补单元测试。普通模式写了 3 个测试用例覆盖了正常输入和两个边界值。Superpowers 模式这边先翻了这个包下其他测试的风格JUnit 5、AssertJ 断言风格然后按同样风格写了 7 个用例最后还主动加了 Mockito 来模拟一个外部依赖。这个差异让我确实眼前一亮。普通模式写测试就是按要求写Superpowers 模式会先去读别人怎么写的。文本生成模型本来就有 pattern-matching 的优势Superpowers 模式等于把这个优势前置激活了——让模型先看样本再模仿产出自然更贴合上下文。4.4 三个不友好的地方但我必须说点不好听的。不是所有场景都顺。第一多文件修改容易用力过猛。测试中它有一次为了满足某个技能文件的验收标准改动范围比预期大了不少。比如我让它修一个参数校验 bug它顺手把相关方法的参数命名都重构了理由写的是保持命名一致性。这种边界失控的问题在普通模式里反而少见——普通模式不会主动加戏而技能库的完整执行倾向有时候会矫枉过正。第二首次初始化较耗时。如果你项目有几十个模块初始化时会读取大量文件内容生成上下文首次会话的预热时间比较长我碰到过一次接近一分钟的等待。好消息是第二次会明显加快——它把项目结构信息缓存下来了。第三依赖 Codex 本身的行为稳定性。如果你用的底层模型本身不够稳定那么技能库再完善也可能翻车。Superpowers 能做的是提升平均行为水平但不保证每一次都正确。表格总结一下我的实测感受场景普通 CodexSuperpowers 模式我的评价报错排查快、准、浅慢一点、信息量大Superpowers 胜尤其在引发连带影响时函数重构能拆但风格一般拆得规范会修调用点Superpowers 明显胜写单测中规中矩风格匹配、覆盖更全Superpowers 胜简单问答高效直接绕、慢普通 Codex 胜这个工具适合「中等复杂度、需要结合项目上下文」的任务不适合「简单查询式」的任务。你拿它问这个正则啥意思它也会先给你套三层流程体验非常累赘。5. 深入机制为什么技能即文件这个设计值得抄前面安装和实测都跑通了但如果不理解这个项目在设计层面的巧思你很难在真实工作中用它用得出彩。这一节我聊深一点。5.1 提示词工程的物化从聊天到文件系统大多数开发者接触 AI 编程的方式停留在写 prompt 聊天的层面你这次让它怎么做下次还得再说一遍。团队协作时更痛苦——每个人跟 AI 交互的方式不一样A 的 prompt 写得细B 的 prompt 写得糙产出质量参差不齐。Superpowers 把好 prompt变成了仓库里的文件意味着什么意味着经验可以被版本管理可以被队友 review可以随项目迭代。技能库本质上就是一套经过了团队验证的 prompt 模板每个模板都被拆成可执行的步骤。你不再依赖某个人这次发挥得好的随机性而是把好表现变成了一致性的默认值。这种做法让我想到前端工程化里的代码风格统一——Prettier 刚出现时也有争议但它把代码长什么样从个人习惯里解放了出来。Superpowers 做的其实是同一件事把 AI 的协作风格从个人 prompt 习惯里解放出来。5.2 AGENTS.md 的项目宪法地位我重点研究了一下 AGENTS.md 这个文件它值得认真对待。它不是一个普通的说明文档而是 Superpowers 每次会话都会加载并压缩的项目宪法。它的厉害之处在于少而专。常见的 README 恨不得什么都有项目背景、架构说明、部署方式、API 文档、致谢名单……但 AGENTS.md 只需要写 AI 在操作代码时必须遵守的规则。我项目里写的 AGENTS.md 一共才 20 几行核心就四条新代码必须遵循现有模块的包结构和命名风格所有单元测试必须通过测试失败时不得用跳过注释把问题盖过去代码提交前必须跑一遍mvn test不得为了通过静态检查而给代码添加不必要的注解就这么四条但它把AI 最容易搞砸的几件事都框住了。比如测试失败不得跳过必须真修这一条就堵住了模型最常见的偷懒路径——很多模型在测试挂了之后会选择注释掉断言或者加 Disabled 注解有了这条约定之后它的行为会被拉回来。5.3 诚实语言让模型想清楚再说还是边说边做Superpowers 文档里反复提到一个概念叫honest language我第一次看到时没太理解后来从代码和实测里才算有了感觉。我的理解是这项目鼓励模型在关键决策点明确说出自己做了什么、没做什么、为什么这些做而不是用含糊的语言掩盖不确定。比如它改完代码后会说我已经修改了 Foo.java 中的方法签名但 Bar.java 中还有一处调用我没动因为它依赖另一个未合并的分支。这种坦白式的表达比我见过的大多数模型回答都清楚。这个概念的价值在于它把模型的不确定性变成了可交互的信息而不是靠猜。对于使用者来说知道它没做哪一步和知道它做了哪一步同等重要。这也是为什么技能文件总是要求在最后列出未完成事项。当然这里有个小质疑这种诚实到底是模型真的意识到了自己的局限还是只是遵循了提示词的输出格式我倾向后者——它是一种模拟诚实但即便只是模拟对使用者来说信息价值也是实打实的。形式即功能输出格式本身就在帮你规避模型幻觉。5.4 与 Claude Code 的关系不搞竞争搞互补搜这个项目的时候一定会看到它与 Claude Code 的关系。Jesse Vincent 在项目文档里明确说过灵感来自于 Steve Yegge 关于 Claude Code 的那篇著名文章而他决定为 Codex CLI 阵营做一套类似的增强。理解这层关系对判断项目前途很重要。Superpowers 不是要替代 Claude Code而是把给 AI 加 Buff的思路移植到 Codex 生态。现在的 AI 编码工具生态呈现分裂趋势Claude Code 自带的行为一致性被认为更高而 Codex CLI 更偏向挂了技能的生成器。Superpowers 这类项目的存在意义就是在模型能力天花板之外用工程手段逼近那批自带光环的工具。这一点在实测里有明证。我把同一个重构任务同时喂给 Claude Code 和Codex Superpowers结论是Claude Code 的开箱体验更顺滑Superpowers 配置后能达到的协作深度反而更可定制——因为技能库是开放的你可以按团队口味塞任何规则进去。选哪个取决于你更看重开箱即用还是深度定制。6. 踩坑实录配置 AGENTS.md 和技能库时我犯过的三个错任何一个真实项目在落地时都会遇到文档里没写的坑这里把我的踩坑过程完整复盘希望你能直接跳过。6.1 坑一把 AGENTS.md 写成了项目说明书一开始我搬了一大段 README 的内容进 AGENTS.md包含架构图文字描述、模块清单、部署流程。结果实测的表现很糟糕——Codex 每次会话都要浏览AGENTS.md这部分内容消耗大量上下文而且经常出现过度遵守它在处理一个小 bug 时会突然引用架构文档里的一句话作为决策依据让行为变得不可预测。后来我把 AGENTS.md 压缩到只剩AI 操作代码的约束诡异的现象立刻消失了。原因也很好理解模型的注意力是有限的当 AGENTS.md 里塞满无关信息时真正的规则反而会被稀释。AGENTS.md 不是给你自己看的文档是给 AI 看的操作手册越短越有效。我开始明白为什么 Superpowers 的技能文件都写得很啰嗦而 AGENTS.md 却要求精炼——两者职能完全不同。技能文件是做事时的详细菜谱可以让 AI 有一个完整参考框架AGENTS.md 是做每件事前都要遵守的底线规则精炼是为了降低每次会话的认知负担。6.2 坑二没有按团队实际流程定制技能库第二次坑是贪多。我把内置技能库全部保留了包括一些我根本用不上的技能比如针对 Ruby 的代码重构技能我根本不写 Ruby。表面上看没什么但技能多了以后Codex 在选择技能时会出现选择困难尤其是在多个技能边界模糊的情况下它经常走偏。比如有一次我让它处理一个 Python 函数拆分它竟然先去加载了一个通用的web-code-review技能导致回答角度完全偏向了前端规范还让我引入一些毫无必要的依赖。查了日志才知道技能选择器的优先策略里名称里包含关键词的优先级更高而通用 review类技能描述写得太泛没拦住错误匹配。解决方式是直接精简技能库删掉所有用不上的技能目录只留下refactor、write-tests、debug三个大类。实测的准确率明显回升。技能库跟工具箱一个道理全摆出来的工具箱反而找不到趁手的那把扳手。6.3 坑三忽略了会话开始时的一致性检查第三个坑最隐蔽。Superpowers 在每次会话开始时会跑前置检查但这个检查的结果是直接注入模型的并不是直观的用户界面提示。我一度以为它没跑于是重复做了好多初始化操作还把项目目录整乱了。后来我打开调试日志才明白它在后台已经确认过项目结构、读取过 AGENTS.md、检查过 git 状态只是这一切对用户来说不可见。这让我意识到使用 Superpowers 的最佳姿势是信任它的流程不要手动干预否则容易造成双重初始化。有一个经验值得提醒如果发现自己连续几次会话感觉它好像不知道项目背景先检查当前目录是不是项目根目录。Superpowers 的上下文注入是对当前工作目录生效的如果你从子目录启动 codex它读到的项目信息是不完整的行为会大幅退化。这个坑我栽了三次每次都以为是自己技能库配错了。6.4 修复与验证我的最终推荐配置踩完这些坑后我形成了一套自己用着很顺手的配置流程放这里给你参考AGENTS.md控制在 30 行以内只写 AI 必须遵守的硬约束技能库只保留与当前项目技术栈相关的技能其余全部删除或注释掉每次新会话前确认自己处于项目根目录遇到多文件修改场景时在 prompt 里手动加一句只修改与问题直接相关的文件不要顺手重构——这条能有效对冲技能库的过度执行倾向定期我是每两天一次查看 Codex 生成的提交记录审视 AI 是否偏离了既定规范。这套配置下来我的体验从还行提升到了真香。7. 扩展玩法把 Superpowers 接入团队工作流与 CI前面讲的都是单人使用体验。但如果你准备把这个工具带进团队协作有几个扩展场景值得考虑。7.1 技能库的 Git 化管理既然技能文件都是文本天然适合用 git 管理。我们的做法是在团队仓库里开一个superpowers/目录专门存放定制的技能文件并且约定新增技能必须经过 code review 合入。这个做法带来一个额外收益团队对AI 应该如何工作这件事有了统一的讨论载体。以前聊AI 写代码到底该注意什么是空对空现在可以直接 review 一个技能文件的变更 PR——具体哪一步写得不合适为什么测试要前置争论变得容易落地。建议在技能文件头部加一行version字段。我吃过没版本号的亏——有一次一个同事改了技能文件没标明改了哪版我跟他的 Codex 行为出现了 20 分钟的不一致排查了半天才发现是技能库不同步。7.2 与 CI 的结合让行为规范从被动变为自动更进阶的玩法是把 Superpowers 的协议守护机制与 CI 结合起来。具体做法是写一个简单的 shell 脚本在 CI 里跑codex exec来做代码生成和提交前检查。因为 CI 环境也加载了同一份 AGENTS.md 和技能库它执行的约束与本地完全一致能起到跨环境统一行为的效果。我自己验证过的一个场景是针对禁止在测试中使用 Disabled 跳过失败这条规则写了一个 CI 检查脚本一旦检测到新提交里出现该注解立即报警。这一步相当于把 AGENTS.md 里的规则从AI 自觉遵守升级为硬性拦截。对于把 AI 编码引入团队流程的团队来说这种规则自动化远比提示词约束可靠。7.3 私有技能的编写实践最后聊一下如何为团队写私有技能。我抄了一份内置技能的结构然后不断迭代出自己的一套模板# 技能名称safe-workspace-sync ## 适用场景 当需要把本地改动同步到远端分支前执行此技能。 ## 前置检查 - 确认当前分支名与需求单号匹配 - 确认工作区无未提交的临时文件 ## 执行步骤 1. 获取最近的 git commit 列表 2. 核对每个 commit 是否符合 AGENTS.md 的提交规范 3. 若存在不符合项修正后重新提交 ## 验收标准 - git status 干净 - 所有 commit 信息符合团队约定写技能文件的技巧是场景边界写得越窄越好。我一开始写了好几个大而全的技能发现 Codex 根本不会正确匹配——它宁可选择描述更具体的窄技能。后来我把每个技能的能力范围切得很细触发准确率才上来。7.4 使用边界与安全提醒这里必须强调一点无论 Superpowers 多强大它仍然是一个基于 LLM 的工具不可完全信任。技能文件里如果写了某些危险操作比如强制删除分支、push 到生产环境的命令模型有可能无条件执行。所以在给技能库添加高风险操作时一定要在前置检查里加人工确认环节比如该步骤执行前必须询问用户是否确认。这是所有 AI 编码工具使用者的底线意识。AGENTS.md 里也应该明确写一条禁止在未询问用户的情况下执行 push 到生产分支等操作。另外一个容易忽略的坑如果技能文件是从网上下载的使用前一定检查一遍内容防止被植入恶意指令。开源生态的好处是透明但坏处是任何人提交的代码都可能在看似无害的技能文件里藏东西。安全意识不能省。8. 客观评价Superpowers 适合谁不适合谁以及它透露的趋势写到这里应该给一个尽量客观的收尾评价。我用下来几天总体上认为这个项目代表了 AI 编码工具演进的一个重要方向。它的本质贡献确实不是某个具体功能——技能墙、Code Tattler、AGENTS.md 这些机制单独拎出来原理都不算复杂。但它把AI 协作需要工程化这件事变成了一套即插即用的系统这可能是很多团队一直想要但没时间做的。适合使用它的人已经在用 Codex CLI但觉得产出质量不稳定的开发者愿意花一点时间打磨提示词工程、而不是只关注模型选型的团队做长期维护型项目、对代码规范和提交纪律有要求的人不适合用它的人偶尔用 AI 写个小脚本、问个问题的人太重了完全没必要对行为不确定性零容忍的团队任何基于 LLM 的工具都无法做到 100% 确定希望开箱即用、不愿折腾配置的人从行业层面看Superpowers 真正值得关注的信号是AI 增强的战场正在从模型能力转向工作流设计。当大家用的模型差不多时决定产出质量的将是你怎么编排它。技能库、上下文注入、协议约束这些概念正在成为 AI 时代的新基础设施就像十年前 Git 分支模型改变了团队协作方式一样。对我个人来说这次尝试最大的启发反而是给 AI加 buff这件事最好的方式不是找更强的模型而是把项目的隐性知识变成显式规则。这思路不只适用于 Codex用在 Claude、Gemini 甚至以后的任何模型上都不会过时。工具是壳方法论才是核心——Superpowers 这个名字起得是真贴切。