1. 从“superpowers”说起一个让 AI 编程助手真正长出“技能树”的框架第一次看到superpowers这个词是在几个折腾 AI 编程助手的群里。有人甩出一句“装了 superpowers 之后Claude Code 才算真正能干活了”底下立刻一堆人追问怎么装、装在哪、和原生 skill 有什么区别。我当时的第一反应是又一个包装层毕竟这两年围绕 AI 编程助手的“增强方案”太多了大部分是把提示词换个皮用两天就发现该不会的还是不会。但真正上手把superpowers跑通、并且拿它做了几个真实项目之后我的判断变了。它不是一个提示词合集而是一套agentic skills framework——翻译成人话就是“给 AI 智能体用的技能框架”。它要解决的问题非常具体原生的 AI 编程助手比如 Claude Code、Codex CLI能力很强但它的“技能”是散装的、隐式的、靠你每次对话临时喂的。你今天教它一套写测试的规范明天开个新会话它全忘了。superpowers做的事情就是把这些可复用的工作方法、领域知识、操作流程沉淀成一个个结构化的skill让 AI 助手在需要的时候能主动调用而不是每次从零开始。这套东西适合谁如果你只是偶尔让 AI 帮你改个函数、写个正则那确实用不上。但如果你已经把 Claude Code 或 Codex CLI 当成日常开发的主力工具每天要处理多文件重构、跨模块调试、按团队规范写代码这类任务那superpowers带来的差异是肉眼可见的。它把“软件开发的工程方法论”这件事从人的脑子里部分搬到了 AI 的工作流里。我写这篇东西的出发点很简单网上关于superpowers的中文资料太碎了要么是几句安装命令要么是概念吹捧真正讲清楚“它是什么、为什么这么设计、怎么落地、踩哪些坑”的内容几乎没有。下面我会按我自己的实操顺序把整套东西拆开讲。涉及 Claude Code、Codex CLI 的安装配置涉及 skill 的编写和调用也涉及那些官方文档不会写、但你不注意就会卡半天的细节。2. 先搞清楚 superpowers 到底解决什么问题2.1 原生 AI 编程助手的“失忆症”和“技能散装”困境要理解superpowers的价值得先承认一个事实Claude Code、Codex CLI 这类工具底层模型能力已经足够强但它们的“工作记忆”和“技能组织”是残缺的。我举个自己踩过的例子。有段时间我在做一个 Java 后端项目团队有一套固定的分层规范Controller 只做参数校验和转发Service 层负责业务编排Repository 层只碰数据访问异常统一走一个自定义的BizException。我每次让 Claude Code 写一个新接口它写出来的代码结构都对但细节总是飘有时候在 Controller 里直接调 Repository有时候抛RuntimeException而不是BizException。我得反复提醒提醒完这个会话有效换个会话又回到原点。这就是“失忆症”。AI 助手没有持久化的、可被主动检索的技能库。你教它的东西活在当前上下文的窗口里窗口一关就没了。另一个问题是“技能散装”。假设你想让 AI 遵循一套 TDD 流程先写失败测试再写最小实现再重构。这套流程本身是清晰的但你要怎么“告诉”AI大部分人是在对话里打一段长长的提示词。问题是这段提示词和你的项目代码、和你的工具链是割裂的。它不是一个可以被版本管理、被复用、被组合的“资产”。superpowers的核心洞察就在这里把工作方法变成一等公民。它引入了一个 skill 的概念每个 skill 是一个自包含的、有明确触发条件的、可被 AI 主动加载的能力单元。你可以把它理解成给 AI 助手装了一棵“技能树”每个节点是一个具体能力AI 在遇到对应场景时会自己去点亮它。2.2 skill 机制和传统提示词模板的本质区别很多人会把 skill 和“提示词模板”混为一谈我觉得这个误解得先澄清否则后面全乱。提示词模板是被动的。你写好一段话复制粘贴给 AIAI 执行。模板本身不知道什么时候该被用也不知道自己适不适合当前任务全靠人来判断和搬运。skill 是主动的。一个 skill 通常包含几个部分一段描述它“能干什么、什么时候该用”的元信息一段具体的操作指令或知识内容有时还有配套的脚本或资源文件。AI 助手在接到任务时会先看自己有哪些 skill 可用然后判断当前任务该调用哪个。这个“判断-调用”的过程就是 agentic 的部分。打个比方。提示词模板像是你桌上的一本本说明书你得自己翻到对的那本然后照着念给 AI 听。skill 像是 AI 自己随身带的一个工具箱它知道箱子里有什么工具遇到拧螺丝的活自己就去拿螺丝刀。这个区别带来的实际影响很大。用提示词模板你的工作流是“人判断场景 → 人找模板 → 人喂给 AI → AI 执行”。用 skill工作流变成“人给任务 → AI 判断场景 → AI 调用 skill → AI 执行”。中间那两步“人找模板、人喂”被省掉了而且 AI 的判断在多数常规场景下比你手动找更不容易漏。2.3 为什么是现在agentic skills framework 的时机superpowers这类框架能在这两年冒出来不是偶然。一方面是底层模型的能力到了。早期的模型你给它一个复杂的多步指令它执行到第三步就忘了第一步。现在 Claude 系列、GPT 系列在长上下文和指令遵循上进步明显才有条件让 AI 去“管理”一套技能体系。如果模型本身连一段中等长度的指令都跟不住谈 skill 编排就是空中楼阁。另一方面是 AI 编程助手的使用场景从“玩具”变成了“生产工具”。当人们开始用 Claude Code 处理真实项目、真实代码库、真实团队规范时“可复用、可管理、可组合的能力”就从锦上添花变成了刚需。你不可能每天对着 AI 重复同样的团队规范那太蠢了。superpowers恰好卡在这个时间点上模型能力够了用户需求也到了。它做的事情不复杂但方向是对的——把 AI 编程从“每次重新教”推进到“一次配置、长期复用”。3. 环境准备Claude Code 与 Codex CLI 的安装与配置3.1 Claude Code 的安装路径与常见卡点superpowers本身是框架它要挂载在具体的 AI 编程助手上跑。目前最主流的两个宿主是 Claude Code 和 Codex CLI。我先把这两个的安装讲清楚因为后面所有操作都建立在这个基础上。Claude Code 的安装官方推荐的方式是通过 npm 全局安装。在终端里执行npm install -g anthropic-ai/claude-code装完之后在项目目录下直接敲claude就能启动。第一次启动会引导你做认证按提示走就行。这里有几个我实际踩过的坑值得单独说。第一个是 Node 版本。Claude Code 对 Node 版本有要求太老的版本会直接报错。我建议至少 Node 18 以上稳妥点用 20 LTS。如果你机器上有多个 Node 版本用 nvm 切一下再装别用系统自带的那个老版本。第二个是权限问题。在 Linux 和 macOS 上全局安装 npm 包有时会遇到权限报错。我不建议用sudo npm install -g那样装出来的包归属 root后续更新和卸载都麻烦。正确做法是配置 npm 的全局目录到用户目录下或者用 nvm 管理 Node这样全局包天然就在用户空间里。第三个是网络相关的报错。有些朋友会遇到安装过程中卡住或者超时这通常是包源的问题。可以临时切到国内镜像源再装装完切回来。这个属于常规操作不多展开。Windows 用户要注意Claude Code 在 Windows 上的体验和 Linux/macOS 有差异。官方对 Windows 的支持是通过 WSL 或者 Git Bash 这类环境。如果你在纯 PowerShell 里跑可能会遇到路径分隔符、脚本执行策略之类的问题。我的建议是Windows 上要么用 WSL2要么用 Git Bash别硬刚原生 PowerShell。3.2 Codex CLI 安装与 “unable to locate the codex cli binary” 报错排查Codex CLI 是另一条路线。它的安装方式取决于你用的发行版和包管理器。常见的是通过 npm 或者直接下载二进制。用 npm 的话npm install -g openai/codex装完之后敲codex验证。这里有个高频报错我在群里见过不下十次unable to locate the codex cli binary or required runtime components. check...。这个报错的意思是系统找不到 codex 的可执行文件或者它依赖的运行时组件缺失。排查思路我整理成一张表按可能性从高到低排报错原因判断方法解决方式全局 bin 目录不在 PATH 里echo $PATH看有没有 npm 全局 bin 路径把 npm 全局 bin 目录加进 PATH安装其实失败了npm list -g看包在不在重新安装注意看安装日志Node 版本不兼容node -v看版本升级到符合要求的版本二进制被安全软件拦截看安装目录下有没有可执行文件加白名单或换目录多版本冲突which codex看指向哪个清理旧版本统一用一个我遇到最多的是第一种。很多人用 nvm 装了 Node但 npm 全局 bin 目录没进 PATH装是装上了敲命令就是找不到。解决办法是在 shell 配置文件里加上类似export PATH$HOME/.nvm/versions/node/vXX/bin:$PATH这样一行然后 source 一下。还有一种情况是 Windows 上的。Windows 的 PATH 配置和 Unix 系不一样而且有些安装脚本写的是 Unix 路径。如果你在 Windows 上遇到这个报错先确认你是在 WSL 里跑还是在原生环境跑。在 WSL 里跑的话按 Linux 的方式排查在原生环境跑检查环境变量里有没有对应的目录。3.3 让两个宿主都能识别 superpowers 的配置要点Claude Code 和 Codex CLI 都支持 skill 机制但它们的 skill 存放位置和加载方式略有不同。superpowers作为框架需要你把它的 skill 放到宿主能识别的位置。通用的做法是在项目根目录或者用户主目录下有一个约定的 skills 目录。Claude Code 通常认项目下的.claude/skills或者用户级的配置目录。Codex CLI 有它自己的约定。具体路径以你装的版本为准我建议装完之后先跑一次claude --help或者codex --help看看有没有关于 skill 路径的说明。配置的时候有个原则项目级 skill 和用户级 skill 分开管。项目级的 skill 跟着代码库走适合团队共享的规范用户级的 skill 放在主目录适合你个人的通用工作习惯。别把所有 skill 都堆在一个地方否则换个项目就乱套。我自己的做法是用户级只放那些跨项目通用的比如“写 commit message 的规范”“代码审查的检查清单”。项目级放这个项目特有的比如“这个项目的分层规范”“这个项目的测试约定”。这样切换项目时AI 加载的 skill 集合是干净的。4. superpowers 的核心机制拆解4.1 skill 的结构元信息、指令与资源一个 skill 到底长什么样这是理解整套框架的关键。从结构上看一个 skill 通常由三部分组成。第一部分是元信息也就是这个 skill 的“身份证”。它包含 skill 的名字、一句话描述、以及最重要的——触发条件。触发条件写的是“在什么情况下该用这个 skill”。这部分是给 AI 看的AI 靠它来判断当前任务要不要调用这个 skill。第二部分是指令内容也就是这个 skill 具体要 AI 做什么。可以是一段操作流程可以是一套规范可以是一组检查项。这部分是 skill 的主体。第三部分是配套资源这是可选的。有些 skill 需要附带脚本、模板文件、参考文档。比如一个“生成数据库迁移脚本”的 skill可能附带一个脚本模板一个“按团队规范写代码”的 skill可能附带一份规范文档。我拿一个具体的例子来说明。假设我要写一个“Java 分层规范”的 skill它大概是这样元信息部分写这个 skill 叫java-layering描述是“确保 Java 代码遵循 Controller-Service-Repository 分层规范”触发条件是“当任务涉及编写或修改 Java 后端代码时”。指令部分写Controller 层只做参数校验和请求转发不直接调用 RepositoryService 层负责业务编排可以调用多个 RepositoryRepository 层只做数据访问不包含业务逻辑所有业务异常统一抛BizException。资源部分可以附一份这个项目的分层示例代码。这样 AI 在写 Java 代码时会先加载这个 skill然后按里面的规范来。你不需要每次在对话里重复这些规则。4.2 触发机制AI 如何判断该调用哪个 skill触发机制是superpowers里最“聪明”的部分也是最需要你花心思设计的地方。AI 判断该不该调用一个 skill主要看两件事当前任务的性质和 skill 元信息里写的触发条件。如果匹配就加载不匹配就跳过。这里有个设计上的权衡。触发条件写得太宽AI 会在不相关的任务上也加载这个 skill浪费上下文还可能干扰判断。写得太窄该用的时候用不上skill 就形同虚设。我的经验是触发条件要写“任务类型”而不是“关键词”。比如“当任务涉及编写或修改 Java 后端代码时”就比“当出现 Java 这个词时”好。前者描述的是任务性质后者是字符串匹配容易误触发。还有一个技巧给 skill 写清楚“不适用场景”。有些 skill 的边界不明显你可以在描述里补一句“这个 skill 不适用于前端代码”。这样 AI 在判断时多一个排除条件准确率会高一些。实测下来触发条件的质量直接决定了整套 skill 体系好不好用。我一开始写的几个 skill触发条件都很模糊结果 AI 要么不调用要么乱调用。后来我把每个 skill 的触发条件都改成“任务类型 明确边界”的写法效果好很多。4.3 skill 的组合与优先级避免“技能打架”当你有多个 skill 时就会遇到组合和优先级的问题。组合是指一个任务可能同时触发多个 skill。比如你让 AI 重构一个 Java 文件可能同时触发“Java 分层规范”和“重构流程”两个 skill。这时候 AI 需要把两个 skill 的指令合起来用。优先级是指当两个 skill 的指令冲突时听谁的。比如一个 skill 说“所有异常都要捕获并记录日志”另一个 skill 说“异常要向上抛出由上层统一处理”。这两条就冲突了。superpowers处理这个问题的方式通常是靠 skill 的加载顺序或者显式的优先级标记。但说实话框架能做的有限真正避免“技能打架”的责任在人身上。我的做法是在写 skill 时就主动避免冲突。具体来说每个 skill 只负责一个维度的事情。分层规范只管代码结构异常处理规范单独一个 skill日志规范再单独一个。这样它们各管各的不容易打架。如果一个 skill 里塞了太多维度的规则冲突的概率就上去了。另外我会定期审查自己的 skill 集合把那些功能重叠的合并掉把那些过时的删掉。skill 不是越多越好一堆互相矛盾的 skill 比没有 skill 还糟糕。5. 从零搭建一套可用的 skill 体系5.1 第一步梳理你真正高频重复的工作方法搭 skill 体系第一步不是打开编辑器写文件而是先想清楚我到底有哪些工作方法是高频重复的我的做法是拿一张纸回忆过去两周我用 AI 编程助手做的所有任务然后归类。归类完之后看哪些类别反复出现。反复出现的就是值得做成 skill 的。我自己的归类结果大概是这几类写新接口涉及分层规范、改 bug涉及调试流程、写测试涉及测试规范、重构涉及重构流程、写 commit 和 PR 描述涉及格式规范。这五类占了我八成以上的使用场景。这个梳理过程很重要因为很多人一上来就想做一套“大而全”的 skill 体系结果做了一堆自己根本用不上的 skill维护成本还高。从高频场景入手先做三五个用起来再慢慢加这是我验证过的节奏。5.2 第二步把隐性经验写成显性指令梳理出高频场景之后第二步是把你在这些场景里的“隐性经验”写成显性指令。什么叫隐性经验就是那些你做得理所当然、但从来没写下来过的判断和习惯。比如你写接口时会下意识地先看有没有现成的 DTO 可以复用你改 bug 时会先复现再定位再修你写测试时会先写正常路径再写边界。这些经验在你脑子里是自动运行的但 AI 不知道。你要做的就是把它们一条条写出来。写的时候有个原则具体到可执行。“注意代码质量”这种话没用“方法长度不超过 50 行超过就拆分”才有用。“写好测试”没用“每个 public 方法至少一个正常路径测试和一个边界测试”才有用。我写第一个 skill 的时候写得太抽象AI 执行起来还是飘。后来我把每条指令都改成“动词 具体标准”的形式效果立刻不一样。比如把“保持函数简洁”改成“单个函数不超过 30 行参数不超过 4 个超过就考虑拆分或封装成对象”。5.3 第三步设计触发条件与边界第三步是给每个 skill 设计触发条件和边界。这部分我在 4.2 里讲过原则这里补充一些实操细节。触发条件的写法我总结了一个模板“当任务涉及 [任务类型] 且 [限定条件] 时”。比如“当任务涉及编写或修改 Java 后端代码且代码位于src/main/java目录下时”。限定条件的作用是缩小范围避免误触发。如果你的项目里既有 Java 又有 Kotlin限定条件就能防止这个 skill 在 Kotlin 代码上被调用。边界的设计我建议每个 skill 都显式写一句“不适用于什么”。这句话看起来多余但实际用起来能省很多事。AI 在判断时会参考这句话减少误判。还有一点触发条件不要写得太长。我见过有人把触发条件写成一大段结果 AI 反而抓不住重点。控制在两三句话以内把最核心的判断依据写清楚就行。5.4 第四步小步验证逐步迭代最后一步是验证和迭代。我的建议是每写完一个 skill立刻拿一个真实任务测一遍。测试的时候重点看两件事一是 AI 有没有在正确的场景下调用这个 skill二是调用之后输出是否符合预期。如果 AI 没调用说明触发条件有问题要么太窄要么描述不清楚。如果调用了但输出不对说明指令内容有问题要么不够具体要么有歧义。我自己的迭代节奏是一个新 skill 至少经过三轮真实任务验证才认为它“可用”。第一轮看触发第二轮看执行第三轮看边界情况。三轮下来基本就稳了。迭代的时候别怕改。skill 是活的随着你的项目和工作方式变化它也应该变。我有些 skill 改了七八版才定型这很正常。6. 实操写一个能真正跑起来的 skill6.1 一个 Java 分层规范 skill 的完整示例光讲原理不够我拿一个完整的 skill 示例来演示。这个 skill 是我自己在用的叫java-layering作用是确保 AI 写 Java 后端代码时遵循分层规范。先看元信息部分。我用的是类似 YAML 的格式具体格式以你用的宿主为准Claude Code 和 Codex CLI 略有差异name: java-layering description: 确保 Java 后端代码遵循 Controller-Service-Repository 分层规范。当任务涉及编写或修改 src/main/java 下的 Java 代码时使用。不适用于测试代码和配置类。这里description里同时写了触发条件和边界。“当任务涉及编写或修改 src/main/java 下的 Java 代码时使用”是触发条件“不适用于测试代码和配置类”是边界。然后是指令内容部分## 分层职责 - Controller 层只做参数校验和请求转发。不包含业务逻辑不直接调用 Repository。 - Service 层负责业务编排。可以调用多个 Repository可以调用其他 Service。业务异常在此层抛出。 - Repository 层只做数据访问。不包含业务逻辑不调用 Service。 ## 异常处理 - 所有业务异常统一抛 BizException不要抛 RuntimeException 或 Exception。 - BizException 的第一个参数是错误码第二个参数是错误信息。 ## 命名规范 - Controller 类名以 Controller 结尾。 - Service 接口以 Service 结尾实现类以 ServiceImpl 结尾。 - Repository 接口以 Repository 结尾。 ## 依赖注入 - 统一使用构造器注入不使用字段注入。 - 构造器注入的字段用 private final 修饰。这个指令内容不算长但每条都是可执行的、无歧义的。AI 拿到之后写出来的代码基本能符合规范。6.2 参数与格式的细节让 AI 不跑偏的关键写 skill 的时候格式和参数的细节决定了 AI 会不会跑偏。我总结了几条经验。第一条用列表而不是段落。段落里的规则容易被 AI 忽略列表里的规则它更容易逐条执行。我上面那个示例所有规则都是列表项就是这个原因。第二条给正例和反例。有些规则光说“要怎样”不够还得说“不要怎样”。比如“统一使用构造器注入”这条如果只写这一句AI 可能还是会用字段注入。补一句“不使用字段注入”它就知道要避开了。第三条关键参数写具体值。比如“方法长度不超过 50 行”这个 50 就是具体值。如果你写“方法不要太长”AI 就不知道多长算长。凡是能用数字量化的都写数字。第四条避免嵌套条件。“如果 A 则 B除非 C但如果 D 则 E”这种句式AI 很容易理解错。拆成多条独立的规则每条只讲一种情况。6.3 验证 skill 是否生效的三种方法写完 skill怎么确认它真的生效了我用三种方法交叉验证。第一种是直接问。启动 AI 助手问它“你现在有哪些 skill 可用”。如果配置正确它应该能列出你写的 skill。这一步验证的是 skill 有没有被正确加载。第二种是构造触发场景。给 AI 一个明确会触发这个 skill 的任务比如“帮我在 UserController 里加一个查询用户列表的接口”。然后看它的输出是否符合 skill 里的规范。这一步验证的是触发机制和指令执行。第三种是构造边界场景。给 AI 一个不该触发这个 skill 的任务比如“帮我改一下 UserServiceTest 里的一个断言”。然后看它有没有错误地加载分层规范。这一步验证的是边界设计。三种方法都过了这个 skill 才算真正可用。我见过有人只做了第一种验证结果 skill 加载了但触发条件写错了实际用起来该触发的时候不触发白搭。7. 常见问题与排查技巧实录7.1 skill 不生效的排查清单skill 不生效是最常见的问题。我把排查思路整理成一张表按顺序查下来基本能定位。排查项检查方法常见原因skill 文件位置确认放在宿主约定的 skills 目录放错目录宿主根本没扫描到文件格式检查 YAML/Markdown 语法缩进错误、冒号缺失导致解析失败元信息完整性确认 name 和 description 都有缺字段导致 skill 被跳过触发条件用触发场景测试条件写得太窄或描述不清宿主版本确认宿主支持 skill 机制老版本不支持需要升级缓存问题重启宿主或清缓存改了 skill 但宿主还在用旧的我遇到最多的是文件位置和格式问题。文件位置错了宿主压根不知道有这个 skill格式错了宿主解析失败skill 被静默跳过也不报错特别难查。提示改完 skill 之后养成重启宿主的习惯。有些宿主会缓存 skill 内容不重启的话你改的东西不生效会误以为 skill 写错了。7.2 触发条件写得太宽或太窄的调整方法触发条件写得太宽AI 会在不相关的任务上加载 skill浪费上下文。写得太窄该用的时候用不上。判断太宽还是太窄有个简单方法拿十个真实任务测一遍看触发率。如果十个任务里触发了七八个但其中一半是不相关的那就是太宽。如果十个任务里只触发了一两个但明明有好几个该触发的没触发那就是太窄。调整太宽的加限定条件。比如把“当任务涉及 Java 代码时”改成“当任务涉及 src/main/java 下的 Java 代码时”。调整太窄的放宽描述。比如把“当任务涉及编写新的 Java Controller 时”改成“当任务涉及编写或修改 Java 后端代码时”。调整完之后再拿十个任务测一遍。一般两三轮就能调到合适的范围。7.3 多个 skill 冲突时的处理策略多个 skill 冲突表现为 AI 的输出自相矛盾或者它干脆忽略其中一个 skill。处理策略分三步。第一步定位冲突。看 AI 的输出找出哪两条规则打架了。有时候冲突不明显需要你仔细比对输出和各个 skill 的指令。第二步判断谁对。冲突的两条规则哪条是你真正想要的通常有一条是更根本的原则另一条是特定场景的例外。第三步重构 skill。如果两条规则属于不同维度把它们拆到不同的 skill 里各自管各自。如果属于同一维度合并成一个 skill在内部用条件分支处理。我的经验是大部分冲突源于 skill 职责划分不清。一个 skill 管太多事就容易和别的 skill 撞车。一个 skill 只干一件事是避免冲突最有效的办法。7.4 性能与上下文占用的平衡skill 不是免费的。每个被加载的 skill 都会占用上下文窗口。如果你的 skill 又多又长AI 的可用上下文就被挤占了处理复杂任务时容易“忘事”。平衡的方法是按需加载。触发条件写得精准让 AI 只在真正需要时才加载 skill。那些低频的 skill宁可让它不加载也别让它常驻。另一个方法是精简 skill 内容。skill 里的指令能一句话说清就别写三句。我见过有人把 skill 写成几千字的长文结果加载之后 AI 反而抓不住重点。skill 是操作手册不是论文简洁比详尽重要。如果某个 skill 确实内容很多可以考虑拆成多个小 skill按场景分别触发。比如一个大的“代码规范”skill可以拆成“命名规范”“异常处理规范”“日志规范”三个小 skill各自独立触发。8. 把 superpowers 用出复利一些个人体会8.1 从“教 AI 做事”到“设计 AI 的工作环境”用superpowers一段时间之后我最大的观念转变是我不再是“教 AI 做事”而是在“设计 AI 的工作环境”。以前我的模式是遇到问题想一段提示词喂给 AI看结果不满意再调整提示词。整个过程是线性的、一次性的。每次任务都从零开始。现在我的模式是遇到问题先想“这个问题属于哪类任务我有没有对应的 skill”。如果有直接让 AI 处理它会自动加载 skill。如果没有我会想“这类任务以后还会不会遇到值不值得做成 skill”。如果值得我就花时间写一个。这个转变带来的复利效应很明显。前期写 skill 是投入但一旦写好后面同类任务的处理效率是成倍提升的。而且 skill 是可以积累的越用越多越用越顺手。8.2 团队协作场景下的 skill 共享superpowers在团队场景下的价值更大。个人用skill 是你自己的效率工具。团队用skill 就变成了团队规范的载体。新同事入职不用花一周时间读文档、看代码、问老人直接让 AI 加载团队的 skill 集合写出来的代码就符合规范。我们团队现在的做法是把项目级的 skill 放在代码库里跟着代码一起版本管理。谁改了规范就改对应的 skill提交 PR走代码审查。这样规范不再是文档里的一段话而是可执行、可验证的 skill。这里有个细节要注意团队 skill 的粒度要合适。太粗覆盖不了具体场景太细维护成本高。我们的经验是按“任务类型”划分一个任务类型一个 skill。比如“写接口”“写测试”“改 bug”各一个。8.3 后续可以扩展的方向superpowers这套东西我觉得还有不少可以扩展的方向。一个是 skill 的自动化测试。现在验证 skill 靠人工效率低。如果能写一套测试用例自动验证 skill 的触发和执行就能大幅降低维护成本。另一个是 skill 的版本管理和依赖管理。当 skill 多起来之后skill 之间的依赖关系、版本兼容性就成了问题。这块目前还比较原始靠人工维护。还有一个是跨宿主的 skill 复用。现在 Claude Code 和 Codex CLI 的 skill 格式不完全一样同一个 skill 要写两遍。如果能有统一的格式和转换工具会方便很多。这些方向我自己也在摸索有些已经在做有些还在想。等有成熟的经验了再单独写一篇分享。最后分享一个我自己的小习惯我每周会花半小时回顾这周用 AI 做的任务看哪些场景反复出现然后决定要不要为它写一个 skill。这个习惯坚持了几个月我的 skill 集合从最初的三个慢慢长到了十几个覆盖了我日常工作的绝大部分场景。这个过程不累但复利很明显。
