先说个真实的场景。最近好几个朋友跑来问我同一个AI编程工具为什么在别人手里能自动写单测、主动做代码审查、甚至按照一套固定流程把需求从拆解做到验收在我这里却只会“聊天”问一句答一句根本不像传说中的那么能干。我后来仔细看了一圈发现差距往往不在模型本身而在有没有一套技能系统。最近社区里热度很高的开源项目 superpowers 解决的就是这个问题——它把“让AI干活”从一次性提示词变成了一组可安装、可复用、可维护的结构化技能skills。这篇文章我不打算复读官方文档纯粹以实际使用者的角度讲清楚 superpowers 到底是什么、有哪些核心技能、怎么安装、怎么把技能真正引入自己的项目以及我在折腾过程中踩过的坑。不管你是刚听说这个名字还是已经装上却发现不生效这篇文章应该都能覆盖到。1. superpowers是什么它不是插件而是一套“技能操作系统”1.1 从“会聊天”到“会干活”的关键一步先聊一个很多人忽略的问题大模型本身能力很强但它默认状态下更像一个“知识丰富的顾问”而不是一个“执行力强的员工”。你问它“这段代码哪里有问题”它能回答你让它“把这个问题修了”它也能修。但如果你让它“按照完整的开发规范先写测试、再写实现、最后做重构验证”它往往做着做着就飘了步骤乱了规范丢了。superpowers 这个项目的思路很直接把复杂的工程方法固化成一个一个的技能文件每个技能都有明确的触发条件、执行步骤、输出标准和检查清单。AI在对话中读到这些技能文件之后就相当于拿到了一份“操作手册”知道在什么场景下应该按什么流程干活。它由 Jesse VincentGitHub 用户 obra发起核心是一套纯文本的 Markdown 技能集合不依赖某个特定平台因此可以适配多种支持自定义技能的 AI 编程环境。我理解它更像一个“技能操作系统”——本身不生产能力而是把能力组织成模块让AI按需调用。1.2 一个技能包的标准结构superpowers 里的每个技能都存放在skills/技能名/SKILL.md这样一个目录结构里核心文件就是SKILL.md。我拆开看过几个典型技能它们的 Markdown 结构大致是下面这样--- name: debugging description: 当代码出现异常、功能行为不符合预期、或测试失败时使用。通过系统性排查定位根因并修复。 --- # Debugging ## 何时使用 - 代码报错但原因不明 - 功能结果与预期不一致 - 新增修改后原有功能回归 ## 排查步骤 1. 复现问题记录复现路径 2. 缩小范围定位可疑模块 3. 提出假设并用最小实验验证 4. 修复并补充回归测试 ## 输出要求 - 说明根因 - 列出修改文件与改动点 - 提供验证方式和结果开头三行---包裹的部分叫 frontmatter里面最关键的是name和description。description决定了AI在什么情况下会自动想起这个技能——我在后面会详细讲触发不触发全靠它。1.3 和普通提示词库的本质区别很多人会问这不就是一堆提示词吗我自己写过那么多prompt有什么不一样区别在三个地方。第一提示词是一次性的技能是可沉淀的。你把一段提示词发给AI它用完就结束了但技能文件可以长期躺在项目的技能目录里每次会话都会被加载或按需读取形成项目级的“团队规范”。第二提示词是零散的技能是成体系的。superpowers 里的技能之间可以接力头脑风暴产出方案规划把方案拆成任务TDD 驱动实现代码审查做最后把关。这个链路本身就是一套完整的工程方法。第三提示词不校验结果技能内置检查清单。好的技能文件末尾几乎都带一排“完成标准”或“自查清单”AI干完活之后要逐项确认自己真的做完了而不是答完就跑。这一点在工程场景尤其重要。提示如果你只把 superpowers 当成“更长的 prompt”那大概率用不好。真正要理解的是它的编排方式——技能是拿来组合和复用的。2. 安装前必须想清楚的三件事环境、挂载方式和版本认知2.1 它寄生在哪个环境里动手安装之前先搞清楚一个前提superpowers 不是一个独立的软件它需要寄生在你已有的 AI 编程环境中。最典型的是 Claude Code 这类支持技能目录skills和插件市场plugin marketplace的命令行工具。也就是说如果你目前只在网页版聊天窗口里用AI那是没法直接“安装”superpowers 的——你需要的不是一个技能包而是一个支持技能机制的终端工具。这也是很多人卡在第一步的真正原因环境不对装什么都装不上。我自己用的是 Claude Code 的插件方式。这类工具通常支持两类技能来源一是官方插件市场里现成的技能包二是你自己写在项目目录里的自定义技能。superpowers 两者都占它本身作为一个插件发布同时它内部的技能文件又完全开放你随时可以复制出来改造。2.2 全局挂载还是按项目挂载安装前还要想清楚一个问题这个技能集是装到全局生效还是只挂到某个项目里这两者的区别很实际。全局挂载的优点是省事所有项目都能用缺点是技能数量多了之后AI 的上下文会被大量技能描述占用反而影响响应质量和速度。按项目挂载的好处是精准——前端项目只需要前端相关技能后端服务只需要后端技能AI 每次读取的都是高相关度的内容。superpowers 的技能库里既有通用技能调试、代码审查、技术写作也有偏重工程流程的技能TDD、系统设计、重构。我目前的习惯是全局只装最通用的几个重流程的技能放在具体项目里按需挂载。这样既不会什么都用不了也不会让上下文爆炸。2.3 一个常见误区不要手动从GitHub复制单个技能文件刚开始折腾的时候我干过一件蠢事看到技能库列表觉得这个好那个也好直接从 GitHub 仓库里把某个技能目录复制到本地项目的 skills 文件夹里结果格式不对、frontmatter 缺失AI 根本读不出来。后来我才明白superpowers 的技能文件看起来是纯 Markdown但它对SKILL.md的 frontmatter 有约定要求目录结构也要对不是随便扔一个.md进去就能生效的。这也是为什么官方推荐用插件市场安装——安装过程会帮你把目录结构、依赖关系都处理好。如果你非要手动维护请务必按官方文档的目录规范来skills/技能名/SKILL.md且 frontmatter 中必须有合法的name和description。3. 完整安装流程从零到跑通3.1 第一步确认你的终端工具和版本在安装之前先执行一条命令确认当前环境your-ai-cli --version这里your-ai-cli指代你使用的AI编程终端工具不同的工具命令不同。以我常用的 Claude Code 为例执行后如果能正常输出版本号说明命令行环境没问题。如果提示命令不存在先解决终端工具的安装再继续后面所有步骤。这一步很容易被跳过但恰恰是最值得花一分钟确认的。superpowers 的技能机制依赖较新的版本太老的版本可能压根不识别技能目录。3.2 通过插件市场安装 superpowers以插件方式安装是最省心的路径。在 AI 终端工具的对话窗口里依次执行两条命令不同工具指令可能略有差异以你所用工具当前版本的官方说明为准/plugin marketplace add obra/superpowers /plugin install superpowerslatest第一条命令是把 superpowers 的仓库添加为插件市场源第二条命令是安装最新版本。安装完成后工具通常会提示你重启会话或重载配置。如果你更习惯命令行操作有些环境也支持直接在终端里执行plugin install之类的指令。装完后的核心验证标准只有一个能不能在技能列表里看到它。3.3 在项目里配置技能入口插件装好之后还差一步把技能“暴露”给当前项目。这一步在不同环境里做法不同但底层逻辑是一致的——让AI在读取项目上下文的时候知道去哪里找这些技能文件。我需要同步一个我自己的经验安装插件和技能生效是两回事。很多人在全局装完 superpowers但在某个项目里发现AI压根不调用任何技能就是因为项目的工作目录里缺少技能入口配置。在多数支持技能机制的环境中你需要在项目的配置文件里显式声明技能路径。例如在项目根目录的CLAUDE.md或等同文件中加入一行superpowers/skills或者把技能目录显式引入path/to/superpowers/skills这样一来AI 每次在这个项目里启动时就能通过配置找到技能文件并按需加载。3.4 验证安装跑一个技能试试安装完成后建议做两个验证动作。第一步在对话里直接问AI“你现在可用的技能有哪些”如果安装成功AI会列出 superpowers 里包含的技能清单比如 brainstorming、planning、tdd、debugging、code-review 等。第二步挑一个最简单的技能用一个最小场景触发它。比如故意抛出一个简单的代码问题然后说出技能名看AI是否会切换到对应的工作方式。我习惯用 debugging 做验证——准备一段有明显 bug 的小代码要求AI按 debugging 技能的流程排查。如果它按“复现问题、缩小范围、定位根因、修复验证”的步骤走完说明引入成功。提示验证时不要用“你会不会调试”这种问题直接给一个真实的坏代码让AI用实际行动证明技能被加载了。嘴上说会和实际按流程走完差别很大。4. 技能仓库全解析主要skills到底能干什么我已经把 superpowers 技能库里的核心技能梳理了一遍按功能分成几类。下面这个表格可以帮你快速建立全局认知后面再逐类展开。技能名类别核心作用典型触发场景brainstorming规划/设计多方案头脑风暴收敛需求需求模糊、方案不确定planning规划/设计把目标拆成可执行步骤收到一个较大的开发任务system-design规划/设计输出系统/模块设计方案新增模块、架构决策tdd编码工程测试驱动开发流程需要高质量实现新功能debugging编码工程系统化定位并修复问题代码报错、行为异常refactoring编码工程安全重构保持行为不变代码腐化、可读性差code-review质量审查从多维度审查代码变更提交PR前、代码合并前security-review质量审查排查安全漏洞与风险涉及认证、支付、数据接口database-design数据/架构设计表结构、索引与关系新建存储模型technical-writing内容/文档输出结构化技术文档写README、接口文档这张表只是常用的一部分技能库本身是持续更新的。我下面挑几个使用频率最高的展开说。4.1 规划与设计类brainstorming、planning、system-design我最早用起来的其实是 planning因为它解决的是最实在的问题——“把一个大需求扔给AI结果它东一榔头西一棒槌”。触发 planning 技能之后AI会先把目标拆成阶段、再拆成任务每个任务带验收标准。它输出的不是一个泛泛的“实现步骤”而是一份可以直接照着执行的工程计划。这个技能在接中型以上功能的时候特别好用比如“给现有系统加一个缓存层”AI会先列出前置分析、改造点、风险点、回滚方案再开始动手。brainstorming 则适合需求还不清楚、方案还没定的阶段。比如你只知道“想让搜索更快”但不确定走缓存、走索引优化、还是走异步预计算这个技能会强迫AI不急着下结论而是先铺开多个方案逐个分析优缺点最后给出推荐。system-design 更偏架构层面。它会引导AI输出模块划分、接口定义、数据流、异常处理路径等设计产物。这个技能适合在写代码之前用能明显减少后续返工。4.2 编码工程类tdd、debugging、refactoringTDD测试驱动开发是 superpowers 里含金量非常高的技能。我坦率说自己以前写代码并不算严格的 TDD 信徒但用 AI 干活的时候就不一样了——模型直接写实现代码往往“看起来合理但缺少验证”而 tdd 技能强制先写失败测试、再写实现、最后重构。这个顺序在 AI 协作场景里反而特别合理因为测试就是给AI的“验收标准”有了标准它不容易跑偏。debugging 刚才已经提过核心价值是把“瞎猜式修 bug”变成“系统化排雷”。它有一步给我印象很深要求AI在动手修之前先写清楚“根因假设”再做最小实验验证。这个习惯治好了我用AI修bug时最常见的毛病——改完这里坏那里因为AI跳过了定位直接改代码。refactoring 技能最大的特点是“安全重构”。它要求先确认现有行为再小步修改每一步都能通过测试验证。我把它和 tdd 搭配使用效果最好重构完跑一遍全量测试绿了就收工。4.3 质量与审查类code-review、security-reviewcode-review 是我在团队协作时用得越来越多的技能。它让AI站在审查者视角从正确性、性能、可读性、边界条件、测试覆盖等维度逐项检查代码改动输出结构化审查意见。跟你直接说“帮我看看这段代码有没有问题”比起来用了 code-review 技能之后AI 知道要按什么维度看、每个维度看到什么程度、意见怎么写才便于开发者处理。本质上这又是一个“有流程和没流程”的差别。security-review 则更垂直。它适用于涉及登录、权限、支付、外部输入等敏感逻辑的场景。AI 会重点检查注入风险、权限绕过、敏感信息泄露、越权访问等问题。我不是安全专家但用这个技能做第一道防线确实能拦下不少低级漏洞。4.4 数据与文档类database-design、technical-writingdatabase-design 在需要设计表结构的时候特别好用。它会先分析实体关系再设计表、字段、索引、外键还会指出查询模式和数据增长可能带来的问题。比直接让AI“建几张表”要严谨得多。technical-writing 适合用来写README、接口文档、架构说明。它的输出通常带清晰的结构背景、用法、参数说明、示例、注意事项。如果你维护的开源项目缺文档让AI按这个技能跑一遍能省下大量时间。5. 把技能真正用起来引入、触发与工作流整合5.1 两种触发方式显式调用与自动激活技能装好之后怎么让它工作我总结下来有两条路。第一种是显式调用。你在对话里明确说出技能名比如“用 tdd 技能实现这个函数”“按 debugging 流程排查这个报错”。这种方式最可靠AI 不会理解错立即进入对应工作模式。第二种是自动激活。AI 根据对话内容自动匹配技能的描述信息判断“当前场景适合用哪个技能”。这依赖技能的description写得够不够精准。比如你描述“这段代码跑起来报错但我不确定原因”如果 debugging 技能的描述里包含“代码异常、行为不符合预期”这类关键词AI 就可能自动调动它。我的建议是前期多用显式调用用熟了之后再看自动激活的命中率。显式调用能帮你理解每个技能的能力边界也能检验技能是否真的被加载。5.2 在项目配置中做“按需挂载”装完所有技能不等于要用完所有技能。我踩过一次性把几十个技能全部挂到项目里的坑——结果 AI 前后行为不一致同一个问题这次按这套流程走下次又按那套流程走因为上下文里塞了太多相互干扰的技能描述。后来我改成按项目性质做“技能裁剪”Web 前端项目挂 brainstorming、planning、debugging、code-review、refactoring后端服务项目挂 system-design、tdd、debugging、security-review、database-design文档维护项目挂 planning、technical-writing这样一个项目里同时活跃的技能控制在五个以内AI 的选择压力小很多行为也稳定得多。5.3 一个完整的工作流示例从0开发一个带测试的小功能理论说多了容易飘我拿一个实际例子说明技能组合怎么用。需求是一个简单的用户注册接口要求带密码强度校验。我把它拆成四轮对话每轮对应一个或多个技能第一轮用brainstorming明确方案。AI 给出两三种校验策略正则强度校验、常见弱密码黑名单、重复字符检测我选其中一种。第二轮用planning拆任务。AI 把功能拆成定义数据模型、编写校验工具函数、写接口逻辑、补测试用例、更新文档。每个子任务带验收标准。第三轮用tdd驱动实现。AI 先为校验函数写测试覆盖弱密码、长度不足、包含用户名字段等边界情况然后写实现代码让测试转绿。第四轮用code-review做收尾。AI 审查刚才的改动指出测试用例里有个边界漏了——密码恰好等于用户名的情况没有覆盖。我再迭代一轮补齐。整个过程下来AI 不再是一个一个接口去“问一句写一句”而是像一个小团队一样按流程交付。这就是 superpowers 最大的价值——把 AI 的工作方式组织起来了。5.4 技能组合的模式用了一段时间之后我总结出三套常用的组合模式直接分享给大家作为参考简单任务看板planning → refactoring。适合小改动先规划再动手最后顺手整理代码结构。标准功能开发brainstorming → planning → tdd → code-review。适合新功能从方案到测试到审查一条龙。问题修复链路debugging → tdd → code-review。适合线上问题先定位根因再补测试防回归最后审查改动是否引入新问题。这三套模式不需要死记硬背重要的是理解技能之间是“接力”关系可以按场景自由编排。6. 排错实录安装和引用技能时最容易踩的坑6.1 装完却看不到技能市场同步与路径问题我最早遇到的问题是明明执行了安装命令也提示成功了但问AI“有哪些技能”时它列出的清单里就是没有 superpowers。排查链路是这样的第一步检查市场源是否添加成功。重新执行plugin marketplace list之类的命令看 superpowers 是否在列表里。不在就重加一次市场源。第二步检查安装状态。确认 superpowers 显示为已安装而不是“available”或“未安装”。第三步也是最容易载跟头的地方——路径声明。前面提到过插件装好了但如果项目配置文件里没有引用技能目录AI 根本不会主动去扫描插件的技能文件。加了引用再重载会话一般就能看到。6.2 技能不生效description 触发条件没写对还有一个非常隐蔽的问题技能在列表里AI 也知道但就是不调用。我仔细对比过几次之后发现问题出在技能的description和用户实际需求之间的匹配度上。AI 是靠 description 判断“什么时候用这个技能”的如果描述里写的全是技术术语而用户提问是口语化的匹配就会失败。举一个具体例子某个技能描述写“当需要执行代码审查时使用”但用户实际说的是“帮我看看这段代码靠不靠谱”。AI 很可能不把“靠不靠谱”理解为“代码审查”于是技能没被激活。解决办法有两个一是用户侧显式说出技能名二是技能维护者把 description 写得更口语化、覆盖更多常见问法。我在自己维护技能文件时会把“用户可能怎么说”的常见句式直接写进 description。6.3 技能文件没被加载上下文里根本没有它另一个坑是技能存在配置也对了但 AI 的行为完全没变化。这个问题的根源多半是技能文件没有被包进当前会话的上下文。技能系统通常有两种加载策略一是启动时把所有技能内容都读进上下文二是按需读取。如果你用的是按需读取而 AI 没有判断出当前场景需要该技能那它从头到尾都不会去读那个文件行为自然不变。这类问题的排查方法是直接问AI“你会用哪些技能处理这个问题”或者干脆显式点名调用。如果点名之后 AI 表现出完全不同的工作方式说明技能文件本身没问题是触发机制的问题如果点名之后依然没变化那才需要检查文件格式和路径。我把常见的现象、原因和排查方向整理成一张表现象可能原因排查方向技能列表里没有 superpowers市场源未添加或未安装重查插件市场与安装状态列表里有但AI不调用description 与用户说法不匹配调整描述关键词或显式调用点名调用也没反应路径引用缺失或文件格式错误检查项目配置与 SKILL.md 结构多个技能行为冲突全局挂载技能过多按项目裁剪技能减少上下文干扰6.4 技能之间互相打架全局挂载带来的上下文污染最后一个坑比较隐蔽但影响很大技能装上得越多AI 的行为反而越不稳定。原因是每个技能的 description 都会占用上下文。技能超过一定数量之后AI 在判断“当前该用哪个技能”时会出现犹豫甚至混着来——前半段像在跑 tdd后半段又跳成 refactoring 的做法流程乱了输出自然不稳。这个问题的解法就是我在第5章说的“按需挂载”。把技能当成项目依赖来管理而不是当成收藏夹。全局只保留最通用的两三个其余的放到具体项目的技能配置里。我第一次做完裁剪之后AI 行为的稳定性肉眼可见地提升了一个档次。7. 进阶动手写一个自己的 SKILL.md7.1 基本结构与命名约定用久了别人的技能总会想写自己的。毕竟每个团队的开发规范都不一样把团队规范固化成技能文件比每次口头交代给 AI 高效得多。一个合格的技能文件需要包含以下要素name技能名简短用英文连字符比如deploy-checklistdescription何时使用写清楚触发条件包含用户可能的口语化说法正文结构建议包含“何时使用”“执行步骤”“完成标准”三块检查清单最后列出自查项让 AI 交付前逐项确认下面是我自己的一个最小示例目标是让 AI 在修改数据库迁移文件时按规范走流程--- name: migration-checklist description: 当修改数据库迁移、新增表、变更字段时使用。用户可能说“加个字段”“改表结构”“写迁移”。 --- # Migration Checklist ## 执行步骤 1. 检查是否存在未提交的旧迁移 2. 新迁移必须包含 up 与 down 操作 3. 对已有表结构变更评估数据兼容性 4. 更新对应实体定义与文档 ## 完成标准 - [ ] 迁移文件命名符合规范 - [ ] up/down 成对且可回滚 - [ ] 数据兼容性已说明 - [ ] 相关模型已同步更新写完之后放到项目的skills/migration-checklist/SKILL.md路径下重启会话即可。7.2 让技能真正好用的三个设计原则写过几个技能以后我自己总结了三个原则供大家参考。第一单一职责。一个技能只做一件事。不要写一个“全能开发助手”技能那是灾难。拆成调试、审查、部署检查这些单一职责的小技能每个都好维护AI 也更容易在合适场景激活。第二描述写“用户怎么说”而不是“技术叫什么”。我一直强调这一点。技术术语用户不一定会说但“帮我看看这个报错”“为什么这个页面打不开”这类口语才是日常对话的真实入口。写在 description 里触发率会显著提高。第三内置完成标准。没有完成标准的技能AI 容易“差不多就交差”。有了检查清单它会在交付前一遍遍确认。你别小看这个差别实际用起来输出质量完全两回事。7.3 个人体会别被“技能数量”迷惑最后说说我自己的体会。接触 superpowers 之后我一度陷入了“技能收集”的误区看到新的技能就想装上试试结果项目配置越来越臃肿AI 行为越来越乱。后来我狠心做了一次减法把全局技能砍到只剩两三个项目技能控制在五个以内整个体验才真正稳定下来。我现在的做法是每接到一个新项目先想清楚这个项目的核心工作流是什么再决定挂哪几个技能。技能不是越多越好而是越匹配越好。如果你正要开始折腾 superpowers我的建议是先装、先跑通、先用它完成一个小任务再慢慢扩充技能库。等你熟练了自然会走到自己动手写技能那一步——到那时候这套系统的真正威力才刚开始展现。