把代码交给AI来写的朋友大概率都遇到过同一个让人抓狂的问题上一秒它还能有条不紊地帮你重构一整个模块下一秒换个对话窗口它就连你项目的目录结构都记不住更别提你之前反复强调过的代码规范。我最近在折腾superpowers这个开源项目时最大的感受就是终于有人开始系统性地解决这个痛点了——它不追求让AI“更聪明”而是像给AI编程助手配上了一套完整的“肌肉记忆”和“工作SOP”。这篇文章就围绕superpowers的安装、核心机制和实际落地效果展开写给正在用或准备用 Codex CLI、Claude Code 这类AI编程工具并且希望让AI真正稳定干活的开发者。1. 先搞清楚superpowers是什么它不是又一个AI工具而是AI的能力外挂1.1 打破每次对话都从零开始的困局如果你用过几周AI编程工具应该会有一个很明显的体感AI在单个对话上下文里表现惊人但在跨会话、跨项目的长期协作里表现极其不稳定。今天你让它写了一个带详细注释的工具函数明天换个会话它可能又写出风格完全不同的另一版甚至把昨天的约定忘得一干二净。问题不在于模型本身变笨了而在于我们给AI提供的工作环境太贫瘠。就像一个经验丰富的新员工如果第一天入职没有组织手册、没有代码规范文档、没有历史决策记录他再聪明也只能靠猜。superpowers做的事情很朴素在AI编程助手启动的时候注入一套结构化的技能包和工作流程让AI每次动手前先规划、先读项目记忆、先写测试而不是上来就生成一大堆自以为是但其实跑不起来的代码。1.2 它不是单体软件而是一套技能包的集合很多第一次接触superpowers的人会误以为它是个命令行工具或者IDE插件其实都不是。它的本质是一批按规范组织的 Markdown 文档、脚本和配置文件通过 AI 编程工具的插件机制加载进去。我打个比方如果把 Codex CLI 或 Claude Code 比作一个刚刚毕业的工程师那superpowers就是这位工程师入职后拿到的员工手册、代码规范、架构文档、测试模板和复盘模板。工具本身不提供“写代码”的能力它提供的是“让AI写代码时的行为方式更专业”的一整套标准。这套标准里最核心的一点是强制AI在动手改代码之前先执行规划流程。比如它会要求AI先阅读项目里已有的记忆文件MEMORY.md、TASKS.md之类的再根据任务写出一份实施计划等你确认之后才真正动工。这一个步骤就能把AI从想到哪写到哪的状态拉回到有节奏、有跟踪、有检查的工程状态。1.3 适合谁用Codex CLI 和 Claude Code 用户目前superpowers主要面向两类宿主工具OpenAI 的 Codex CLI以及 Anthropic 的 Claude Code。前者偏命令行场景后者对项目文件系统、交互式操作的支持更丰富。两个工具都能通过各自的插件机制加载superpowers提供的技能包。如果你的日常工作流已经依赖AI来写代码、改bug、做代码审查并且你经常觉得AI输出质量忽高忽低那superpowers大概率对你是有价值的。它并不改变你写提示词的方式而是改变AI接到提示词之后的行为路径。换句话说它是一个流程治理层不是模型能力层。2. 安装superpowers两条路线对比以及最初容易踩的坑2.1 路线一通过插件系统一键安装如果你已经在用 Claude Code安装方式比较友好。Claude Code 支持从 marketplace 安装插件superpowers官方也提供了对应的插件包。基本流程是# 在 Claude Code 的配置目录下添加插件源 claude plugin add superpowers装完之后重启 Claude Code让它重新扫描插件目录就能在对话里通过/superpowers这样的斜杠命令唤起技能面板。Codex CLI 侧的安装类似不过需要你把superpowers仓库克隆到本地然后在 Codex CLI 的配置文件里把它注册为自定义技能目录git clone https://github.com/someuser/superpowers.git ~/.codex/superpowers然后在~/.codex/config.toml里加入[skill_dirs] superpowers ~/.codex/superpowers2.2 路线二手动克隆到宿主工具的技能目录如果嫌插件市场不顺手或者你想直接看源码、自定义技能手动克隆的方式更推荐。superpowers的仓库结构很清晰核心目录大概是这样的superpowers/ ├── skills/ # 技能包主目录 │ ├── planning/ # 规划类技能 │ ├── test-driven-dev/ # TDD 技能 │ ├── memory/ # 记忆管理技能 │ └── ... ├── scripts/ # 支撑技能运行的脚本 ├── commands/ # 宿主工具的命令定义 └── README.md把整个仓库克隆到你的宿主工具对应的插件目录之后superpowers里的技能就会被自动扫描到。注意一定要看仓库根目录的 README因为不同宿主工具对技能目录的层级要求不完全一样有的要求克隆到.claude/skills/下有的要求注册绝对路径这个细节很容易被忽略。2.3 安装阶段最容易翻车的三件事第一权限没开够。无论是 Claude Code 还是 Codex CLI默认对AI能访问哪些目录、能执行哪些命令都是受限的。如果未授权AI读取skills/目录里的文件那技能包加载了也和没加载一样。需要在配置文件里把技能目录加入白名单。第二版本和宿主工具不匹配。superpowers迭代挺快的某些技能文件用到了特定版本的 Claude Code 才支持的插件特性。遇到命令无效、技能不触发的现象先别怀疑自己配置错了去看一眼宿主工具的插件API版本和superpowers仓库的 Release 说明。老版本宿主工具加载新版技能包大概率会静默失败。第三克隆位置搞错。很多人习惯把仓库克隆到任意目录然后试图通过加环境变量的方式让工具找到它但两个宿主工具对这种外部路径的支持其实很挑剔。我折腾下来最省事的做法就是把仓库直接克隆到工具默认的插件目录下不要自作聪明改路径。3. 核心机制拆解技能是怎么被AI真正调用的3.1 从SKILL.md到AI_ROUTES技能包的触发逻辑superpowers里的每一个技能本质上是一个包含SKILL.md文件的目录。这个文件不是给人看的文档而是给AI读的行为指令卡。我最初以为里面会写很多抽象的规则打开后发现每个SKILL.md都写得非常具体像一份带步骤的作业指导书。以 test-driven-dev 这个技能为例它的 SKILL.md 大概会包含以下内容何时触发当AI被要求实现一个新功能或修复bug时。执行步骤先写测试 → 运行测试到失败 → 再写最小实现 → 让测试变绿 → 重构。输出规范每一步必须给用户展示执行了什么、结果如何。禁止事项不允许跳过测试直接写实现代码。触发逻辑上宿主工具会先把这些技能文件的内容放进系统提示词的上下文里AI在规划回答时看到了这批技能库再结合你任务里的措辞判断该调用哪个技能。所以你会发现装了superpowers之后AI的行为模式确实变了——它会在回答开头说根据技能库中的TDD流程我先编写测试用例然后才动手。3.2 记忆类技能让AI跨对话记住项目上下文单看规划技能还不足以理解superpowers的完整价值它做的另一件关键事情是结构化记忆。要知道AI对话本身是有上下文窗口限制的而superpowers利用宿主工具提供的文件读写能力让AI把重要的项目决策、待办事项、架构约束持续写入项目内的记忆文件。具体机制是项目里会生成MEMORY.md、TASKS.md、DECISIONS.md这类文件AI在完成任务后会把关键信息追加进去。下一次新对话AI启动时会主动读取这些文件就像老员工翻看工作笔记一样瞬间找回之前的上下文。我曾经很不解为什么不直接让AI把关键信息写在对话里呢因为对话窗口几个月后早就不存在了而文件是永久的。这也是superpowers最对标核心痛点的地方——AI的记忆被物化成了项目里可读可改的文档而不是依赖上下文窗口的临时缓存。3.3 常用的技能包清单planning、test-driven-dev、orchestration目前社区里比较成熟、我也实际用过的技能包主要有以下几个技能名称作用适用场景planning强制AI先写实施计划拆任务步骤再动工大型重构、新功能开发test-driven-dev按照先测试后实现的顺序写代码Java、Python等单元测试覆盖率有要求的项目orchestration让AI自主拆分子任务并跨文件协同多文件、多模块的改动memory项目记忆文件的写入与读取跨会话长期维护同一个项目review对AI输出代码进行系统化审查代码审查、MR Review每个技能的目录下除了 SKILL.md往往还带了若干辅助脚本。比如 test-driven-dev 技能会带一些运行测试并捕获输出的脚本AI在执行测试命令时可以直接调用这些脚本而不需要每次临场发挥。4. 让技能真正跑起来用Java模块改造当实例验证TDD和planning的实际效果4.1 给AI下达一个会被超级能力接管的任务理论说再多不如跑一次真实任务。我这次搞了个小场景在本地一个 Spring Boot 项目里让AI帮我给老代码补充一个分页查询用户列表的接口。如果没有superpowers最常见的结局是AI直接生成一坨 Controller Service Mapper 代码我复制粘贴后编译报错来回修三轮。装好superpowers之后同样的需求完全不一样的路径。我故意在提示词里加了一句请按照项目现有技能流程处理这个任务。 结果AI第一轮回复里没有给我写接口代码而是说我先读取项目的 MEMORY.md 和 TASKS.md确认当前架构约定然后制定实施计划。4.2 观察AI如何执行TDD流程测试先行、失败再实现在确认过计划之后AI开始写测试用例。它先写了一个UserControllerTest验证分页参数、排序字段、空结果的分页行为。运行测试理所当然地失败了——因为实现类还不存在。失败之后它才进入实现阶段。有意思的是这个阶段的代码生成质量明显比平时高。原因也简单因为测试用例已经规定了方法的输入输出、返回结构、异常行为AI写实现代码时有了明确的验收标准不再自由发挥。实现代码写完再次运行测试全绿。接着AI主动执行了重构逻辑把硬编码的分页大小抽成了配置项并且在代码里补上了边界条件的注释。全程我几乎没有干预。4.3 这份运行机制给我的三点具体体会第一AI产出稳定性高了很多。不是偶尔稳定而是每条提交基本都能通过测试。因为先写测试再写实现这个流程天然过滤了大部分低级逻辑错误。第二我对AI的信任感变强了。没有测试兜底时AI生成的代码我总要人肉Review一遍做完接口测试还要担心边界场景。有了测试用例我可以直接看测试覆盖了哪些场景来判断AI是否理解了需求省去了很多无效Review。第三改需求时不容易改出bug。以前让AI改一个功能经常改了A就破坏B因为它只盯着你当前这句话不知道B的存在。但现在它有项目记忆文件改完会自己运行全量测试发现B被破坏后会主动修复。这种行为模式的改变远远超出生成代码这个层面。5. 经验干货配置建议、适用边界以及已知的限制5.1 权限模型是超级能力能不能生效的前提superpowers里大量技能需要AI主动读写文件、执行命令所以宿主工具的权限配置直接决定体验。之前我把权限配得太严AI的planning技能说要读取MEMORY.md却被工具拦截了结果整个流程卡在一半非常尴尬。我建议的配置底线是允许AI读写项目根目录下的 Markdown 文档。允许AI执行 test、build 相关的命令。对AI执行 shell 命令建议逐条确认不要直接全放行尤其是涉及依赖安装和清理操作的命令。5.2 技能包不是越多越好按项目按需加载superpowers默认装了十来个技能但并不代表每个项目都要全部启用。比如长期维护的老项目不需要每一步都走完整的TDD流程但需要把决策记录写进记忆文件而一个新的微服务模块可能TDD流程更重要。我的做法是在AGENTS.md或者项目级的配置里显式声明当前项目要启用哪些技能。这样AI进入项目时会自动筛选技能库避免所有技能一股脑涌进上下文既占token又容易让AI行为变得冗长繁琐。5.3 已知限制不是所有任务都适合交给超级能力用了大半个月superpowers我摸索出几个不适合硬套技能包的场景。一次性临时脚本比如你只是想跑个正则表达式验证、快速算个日期没必要求AI先写测试再写实现那是反生产率的。探索性任务比如让AI帮你调研某个不熟悉的库怎么用。这种任务的核心是信息收集不是代码变更套用TDD技能只会让AI变得不敢开口。对代码规范约束极强的大厂仓库技能包的默认行为未必符合你们团队内部的提交规范需要先改 SKILL.md 里的流程描述而不是强行让所有AI输出对齐行内标准。5.4 给新人的排障建议技能不生效时按这四个地方查最近我在折腾过程中遇到过技能包看得见但触发不了的情况排查路径记录在这里可以省去你很多时间先确认宿主工具版本是否过旧升级到最新再试。再确认技能目录权限查看工具的日志输出有没有读取 SKILL.md 的记录。然后在对话里显式询问你的技能库里有哪几个技能看AI能不能正确列出。列不出来就是加载失败。最后如果superpowers和项目的自定义技能文件存在同名冲突宿主工具通常优先加载项目内的导致superpowers被静默跳过。遇到这种情况把项目里自定义技能改名即可。就我个人而言superpowers带来的最大改变不是某一次代码写得有多漂亮而是让AI从一个惯于即兴发挥的新手慢慢变成了有自己工作纪律的同事。它不完美的部分也很多比如默认技能描述可能和你的实际开发流程不太匹配需要花点时间去改比如过度依赖记忆文件会让项目里多出很多需要维护的 Markdown对洁癖型开发者不太友好。但如果你已经被AI给一段代码就改了别的模块折磨过几次我建议下一个项目就装上它用一个功能请求体感一下先规划、再测试、后实现、最后记一笔的完整链路然后再决定要不要长期用下去。