1. 从“superpowers”这个热词说起它到底指什么最近一段时间“superpowers”这个词在技术社区和效率工具圈子里被反复提起。很多人第一次看到它会以为是某个超级英雄题材的游戏或者影视作品但在我们讨论的语境里它指的是一套围绕 AI 编程助手构建的技能扩展体系——你可以把它理解成给 AI 助手装上一套“外挂技能包”让它在处理具体开发任务时不再只是泛泛地给建议而是能按照预设的专业流程一步步把活干完。这个词之所以能成为热词核心原因在于它切中了一个非常普遍的痛点大多数人用 AI 编程助手的方式还停留在“问一句答一句”的阶段。你问它“帮我写个登录接口”它给你一段代码你问它“这段报错怎么修”它给你一个可能对也可能不对的答案。整个过程高度依赖你提问的水平以及你自己对问题的理解程度。而 superpowers 这套东西想解决的就是把这种“随缘式对话”变成“流程化作业”。具体来说superpowers 提供了一组被称为skills技能的模块。每个 skill 本质上是一段结构化的指令集它定义了 AI 助手在面对某类任务时应该遵循的步骤、应该检查的要点、应该输出的格式。比如有一个 skill 专门负责“代码审查”它会让 AI 按照固定的检查清单逐项过一遍代码而不是随便看两眼就给个“看起来没问题”的结论。再比如有一个 skill 负责“调试排查”它会引导 AI 先复现问题、再定位根因、最后验证修复而不是一上来就猜哪里错了。这套体系适合什么人如果你平时用 AI 助手写代码、改 bug、做代码审查但总觉得它的输出质量不稳定、有时候很惊艳有时候很敷衍那 superpowers 就是为你准备的。它不要求你懂什么高深的提示词工程你只需要把技能装好然后在合适的场景下调用对应的 skill剩下的交给流程去保证质量。对于团队来说它还有一层价值可以把团队内部的开发规范、审查标准固化到 skill 里让每个成员用 AI 助手时都遵循同一套标准减少“各写各的”带来的不一致。接下来我会从技能体系的核心构成、安装引入的完整流程、实际使用中的调用方式、以及我踩过的几个坑这几个角度把 superpowers 这套东西讲透。文章会尽量说人话不堆术语目标是让你看完之后能自己动手把它跑起来并且知道在什么场景下该用哪个技能。2. superpowers 的技能体系拆解到底有哪些 skills2.1 技能的分类逻辑按开发阶段划分superpowers 里的 skills 并不是一堆杂乱无章的指令集合它的组织方式有比较清晰的逻辑。我梳理下来大致可以按软件开发的阶段来分类每个阶段对应一组技能。这种划分方式的好处是你在做某件事的时候能快速定位到该用哪个技能而不需要把整个列表翻一遍。第一类是规划与设计阶段的技能。这类技能主要用在动手写代码之前帮你把需求理清楚、把方案想明白。比如有一个技能叫“需求拆解”它会引导 AI 把一句模糊的需求描述拆成具体的功能点、边界条件、输入输出定义。还有一个技能叫“方案对比”你给它两三个技术选型它会按照固定的维度性能、维护成本、学习曲线、社区活跃度等做对比分析输出一张结构化的对比表。这类技能的价值在于它强迫你在动手之前先想清楚避免写到一半发现方向错了。第二类是编码实现阶段的技能。这类技能直接参与代码生成和修改。比如“接口实现”技能它会要求 AI 先确认接口的输入输出格式、错误处理策略、鉴权方式然后再生成代码而不是上来就写。还有一个“重构”技能它会按照“先补测试、再小步修改、每步验证”的流程来操作降低重构引入 bug 的风险。这类技能的特点是流程感很强每一步都有明确的检查点。第三类是质量保障阶段的技能。代码写完之后这类技能负责把关。最典型的是“代码审查”技能它会按照一份检查清单逐项过代码包括命名规范、异常处理、边界条件、性能隐患、安全风险等维度。还有一个“测试用例生成”技能它会根据代码逻辑自动推导出应该覆盖哪些测试场景包括正常路径、异常路径、边界值。这类技能是我个人用得最多的因为它确实能发现一些我自己写代码时忽略的问题。第四类是调试与排错阶段的技能。这类技能专门处理“东西坏了”的场景。“问题定位”技能会引导 AI 按照“收集信息、缩小范围、提出假设、验证假设”的流程来排查而不是随机猜测。“日志分析”技能则会教 AI 如何从一堆日志里提取关键线索定位到出错的环节。这类技能在处理线上问题时特别有用因为线上问题往往信息量大、时间紧有一个结构化的排查流程能省很多事。2.2 几个高频技能的具体能力边界上面说的是分类这里挑几个我实际用下来觉得最有价值的技能具体说说它们能干什么、不能干什么。代码审查技能是我用得最频繁的一个。它的工作方式是你把一段代码或者一个 diff 丢给它它会按照预设的检查清单逐项分析。清单里包括变量命名是否清晰、函数职责是否单一、异常处理是否完整、是否有明显的性能问题、是否有潜在的空指针或越界风险、日志打点是否合理。每一项它都会给出具体的行号和修改建议而不是笼统地说“代码质量不错”。但要注意它不能替代人工审查。有些业务逻辑层面的问题比如“这个折扣计算规则是否符合最新的运营策略”它判断不了因为它不懂你的业务背景。所以我的做法是先用它过一遍技术层面的问题人工再重点看业务逻辑。调试排查技能的边界也值得说清楚。它的强项是帮你理清排查思路比如它会问你“这个问题是必现还是偶现”“最近有没有改过相关代码”“错误日志里有没有堆栈信息”。它会把你的回答组织成一个排查路径然后一步步缩小范围。但它不能直接连到你的服务器上看日志也不能帮你复现问题。它更像是一个有经验的同事坐在你旁边引导你思考而不是替你动手。所以用这个技能的时候你手头得有足够的现场信息否则它也只能给一些泛泛的建议。测试用例生成技能有一个容易被误解的地方。很多人以为它能自动生成一套完整的测试套件直接跑就能用。实际情况是它生成的是测试用例的骨架和思路包括应该覆盖哪些场景、每个场景的输入输出是什么、边界值在哪里。具体的断言逻辑和 mock 数据还是需要你自己补。但即便如此它也能帮你省掉大量“想测试场景”的时间。我通常的做法是让它先生成场景列表我确认没有遗漏之后再让它针对每个场景生成具体的测试代码框架最后我自己填充细节。2.3 技能之间的组合调用关系单独用一个技能已经能带来效率提升但 superpowers 真正有意思的地方在于技能可以组合使用。我举一个实际的例子来说明这种组合是怎么工作的。假设你要给一个已有的项目加一个新功能。你可以先调用“需求拆解”技能把需求文档或者一句话描述变成具体的功能点列表。然后调用“方案对比”技能针对实现方式做技术选型。选型确定后调用“接口实现”技能生成代码框架。代码写完后调用“代码审查”技能过一遍。审查通过后调用“测试用例生成”技能补充测试。最后如果测试发现问题调用“调试排查”技能定位。这一套流程走下来你会发现每个环节都有对应的技能在支撑而且技能之间的输出可以作为下一个技能的输入。比如“需求拆解”输出的功能点列表可以直接喂给“方案对比”作为分析对象。这种组合方式让整个开发过程变得更有节奏感而不是东一榔头西一棒子。不过要注意不是每个任务都需要走完整流程。小改动可能只需要“代码审查”过一下就行没必要把全套技能都调一遍。技能组合的价值在于当你面对复杂任务时有一个清晰的路径可以遵循而不是凭感觉乱撞。3. 把 superpowers 装进你的工作流安装与引入的完整步骤3.1 安装前的环境确认别急着敲命令在动手安装之前有几个环境层面的东西需要先确认清楚。我见过不少人一上来就照着教程敲命令结果卡在某个依赖缺失或者版本不兼容上折腾半天。提前花五分钟检查能省掉后面半小时的排查。首先确认你的 AI 助手客户端版本。superpowers 这套技能体系通常是以插件或者扩展的形式挂载到现有的 AI 编程助手上的所以你的客户端得支持这种扩展机制。不同客户端的支持程度不一样有的原生支持技能目录扫描有的需要手动配置加载路径。你需要先查一下你用的客户端有没有相关的扩展接口文档。如果没有那可能得换一个支持扩展的客户端或者用命令行版本。其次确认运行环境。大部分技能本质上是一组 Markdown 格式的指令文件加上一些可选的脚本。所以理论上只要有文件系统读写权限就能用。但有些技能会调用外部工具比如代码格式化、静态分析、测试运行器这些工具需要提前装好并且能在命令行里直接调用。我的建议是先把项目里常用的工具链跑通确保npm test、eslint、prettier这类命令能正常执行再去装技能。最后确认目录结构。superpowers 的技能通常放在一个统一的目录下每个技能一个子目录里面包含技能描述文件、指令文件、可选的脚本和资源。你需要知道你的客户端默认从哪个路径加载技能然后把技能目录放到正确的位置。有的客户端支持配置多个技能路径这种情况下你可以把技能放在项目目录里跟着项目走方便团队共享。3.2 获取技能包的几种途径技能包的获取方式取决于你用的具体实现。目前常见的有几种途径我分别说一下各自的特点和注意事项。第一种是从官方仓库直接克隆。这是最直接的方式你能拿到最新的技能集合也能看到每个技能的更新记录。克隆的时候建议用浅克隆因为技能仓库通常不大但历史记录可能比较多浅克隆能省点时间和磁盘空间。克隆下来之后把技能目录复制或者软链接到客户端能识别的路径下。软链接的好处是更新方便你只需要在仓库里拉取最新代码客户端那边自动就能看到新版本。第二种是通过包管理器安装。有些实现会把技能包发布到 npm 或者类似的包管理平台上你可以像装普通依赖一样安装。这种方式的好处是版本管理清晰升级回滚都方便。但要注意包管理器安装的技能通常放在node_modules下面客户端不一定能直接扫描到可能需要额外配置路径映射。第三种是手动下载压缩包。这种方式适合网络环境受限或者需要固定版本的场景。下载下来解压到指定目录就行缺点是更新麻烦每次都得手动操作。如果你只是临时试用一下可以用这种方式如果打算长期用还是建议用前两种方式。不管用哪种方式拿到技能包之后第一件事是看一眼目录结构确认技能文件都在。通常每个技能目录下会有一个SKILL.md或者类似名称的文件里面写了这个技能的用途、调用方式、依赖条件。花几分钟翻一翻能帮你快速了解手头有哪些技能可用。3.3 配置加载路径与验证安装结果技能包放好之后需要告诉客户端去哪里加载。这一步的配置方式因客户端而异我描述几种常见的情况。如果客户端支持配置文件通常会在配置里有一个skills或者extensions字段你需要在里面填上技能目录的绝对路径或者相对于项目根目录的路径。有的客户端支持通配符比如./skills/*这样每个子目录会被识别为一个独立的技能。配置完之后重启客户端让它重新扫描。如果客户端是通过环境变量控制的你需要设置一个指向技能目录的环境变量。这种方式在命令行场景下比较常见。设置完之后在同一个终端会话里启动客户端它就能读到。验证安装是否成功的方法很简单在客户端里问一句“你有哪些可用的技能”或者“列出所有 skills”。如果配置正确它应该能列出一个技能清单每个技能附带简短描述。如果它说“没有找到任何技能”或者只列出了一部分那说明路径配置有问题或者某些技能的描述文件格式不对。还有一个验证方法是直接调用一个技能试试。比如你选一个最简单的技能按照它的调用方式触发一下看它有没有按照预期输出。如果触发了但输出不对可能是技能文件的内容有问题比如指令格式不兼容当前客户端版本。这种情况下你可以打开技能文件看看它的结构对照客户端的技能编写规范检查一下。提示配置路径的时候尽量用绝对路径相对路径在不同工作目录下启动客户端时容易出问题。如果非要用相对路径确保你每次都在同一个目录下启动。3.4 团队场景下的技能分发策略如果你是在团队里推广这套东西安装方式就需要考虑分发的便利性。我试过几种做法各有优劣。一种是把技能目录直接放进项目仓库跟着代码一起版本管理。这样每个成员拉下代码就自带技能不需要额外安装步骤。好处是版本一致大家用的都是同一套技能坏处是技能更新会混在代码提交里有时候会干扰代码审查。我的做法是单独开一个目录放技能并且在提交规范里约定技能更新单独提交不和业务代码混在一起。另一种是维护一个内部的技能仓库成员通过包管理器或者脚本安装。这种方式适合技能比较多、更新比较频繁的团队。你可以写一个简单的安装脚本自动把技能包拉取到正确位置并配置好路径。新成员入职的时候跑一下脚本就行省去手动配置的麻烦。还有一种做法是把技能配置写进开发环境的容器镜像或者虚拟机模板里。这样连安装步骤都省了环境一启动就自带技能。适合对开发环境一致性要求比较高的团队。但缺点是更新技能需要重新构建镜像灵活性差一些。不管用哪种方式建议在团队里指定一个人负责技能的维护和更新。技能这东西跟代码一样也需要有人管否则用着用着就乱了。4. 实际调用技能从触发到拿到结果的完整链路4.1 技能是怎么被触发的搞清楚触发机制是用好 superpowers 的前提。不同客户端的触发方式不太一样但大体上可以归为两类显式触发和隐式触发。显式触发就是你明确告诉 AI 助手“用某个技能来做这件事”。比如你说“用代码审查技能看一下这段代码”它就会加载对应的技能指令按照技能定义的流程来执行。这种方式的好处是可控你知道它在用什么技能也知道它会按照什么流程走。缺点是每次都得手动指定稍微有点繁琐。隐式触发则是 AI 助手根据你的请求内容自动判断该用哪个技能。比如你贴了一段报错日志说“帮我看看这个问题”它可能会自动调用调试排查技能。这种方式用起来更自然但前提是技能的描述文件写得足够清晰让 AI 能准确匹配到合适的技能。如果描述写得太模糊它可能匹配错技能或者干脆不匹配。我个人的习惯是对于重要任务用显式触发确保流程正确对于日常小问题用隐式触发图个方便。你也可以在客户端的配置里调整触发策略比如设置成“总是询问”或者“自动选择”。4.2 一次完整的技能调用过程拆解我拿“代码审查”这个技能做例子把一次完整的调用过程拆开来看这样你能清楚每个环节发生了什么。第一步是准备输入。代码审查技能的输入通常是一段代码或者一个 diff。你可以直接把代码粘贴到对话里也可以指定一个文件路径让它自己去读。如果是指定文件路径确保客户端有读取该文件的权限。我通常会把要审查的代码单独放在一个文件里然后告诉它“审查这个文件”这样比粘贴大段代码更清晰。第二步是技能加载。当你触发技能后客户端会去技能目录里找到对应的技能文件读取里面的指令内容然后把指令和你的输入一起发给 AI 模型。这个过程你通常看不到但你能感觉到它的行为模式变了——它不再是一上来就给结论而是开始按照检查清单逐项分析。第三步是执行过程。代码审查技能会按照预设的检查维度逐项过代码。你会看到它分点列出每个发现的问题包括问题所在的行号、问题描述、修改建议。有些实现还会给每个问题标注严重程度比如“必须修改”“建议修改”“仅供参考”。这个阶段是技能价值最直观的体现因为它确实在按照一套标准做事而不是随机发挥。第四步是结果输出。审查完成后它会给出一个总结包括发现的问题数量、按严重程度分类的统计、以及一个整体的质量评估。有的技能还会给出一个“审查通过”或“审查不通过”的结论方便你决定下一步怎么做。第五步是后续处理。你可以针对它提出的某个问题继续追问比如“你提到的这个空指针风险能给我一个修复示例吗”。这时候它会在当前技能的上下文里继续回答保持审查的连贯性。4.3 调用时的参数与上下文传递很多技能支持传入参数用来控制执行的范围和深度。这些参数通常写在技能描述文件里你在调用的时候按照约定的格式传进去就行。以代码审查技能为例常见的参数包括审查范围只审查新增代码还是审查整个文件、严格程度宽松模式只报严重问题严格模式连命名风格都管、输出格式纯文本还是结构化 JSON。你可以在调用的时候指定这些参数比如“用严格模式审查这个文件”。上下文传递是另一个需要注意的点。技能执行的时候AI 能看到多少上下文取决于你怎么传。如果你只贴了一段代码它就只能基于这段代码做判断。如果你把相关的配置文件、接口定义、调用方代码也一起传进去它就能做出更准确的判断。我的经验是对于复杂的审查任务多传一点上下文比少传好宁可让它多看一些也不要让它因为信息不足而漏掉问题。但上下文也不是越多越好。传太多无关内容会稀释它的注意力反而影响审查质量。我通常的做法是传目标代码、传相关的接口定义、传最近的变更记录这三样基本够用。如果它需要更多信息它会主动问你要。4.4 技能输出的解读与二次加工技能输出的结果不是终点而是起点。你需要对输出做解读和二次加工才能真正把价值落地。解读的时候要注意区分“事实”和“建议”。事实类的问题是客观存在的比如“第 15 行没有处理空值”这个你直接改就行。建议类的问题则带有主观判断比如“建议把这个函数拆成两个”你需要结合实际情况决定要不要采纳。不要盲目照搬技能的所有建议它不了解你的业务约束和团队习惯。二次加工是指把技能输出转化成可执行的行动。比如代码审查技能列出了十个问题你可以把它们整理成一个待办列表按严重程度排序逐个处理。测试用例生成技能给出了场景列表你可以把它导入到测试管理工具里作为测试计划的输入。调试排查技能给出了排查路径你可以把它打印出来贴在显示器旁边一步步跟着做。我还会做一件事把技能输出里反复出现的问题记录下来作为团队规范改进的输入。如果代码审查技能总是报同一类问题那说明团队在这个方面有系统性的欠缺值得专门做一次分享或者更新编码规范。5. 我踩过的坑安装和使用 superpowers 的常见问题5.1 技能加载失败路径和权限的排查链路我第一次装 superpowers 的时候配置完路径重启客户端问它有哪些技能结果它说一个都没有。当时第一反应是技能包没下载对重新下载了一遍还是不行。后来一步步排查发现是路径配置的问题。排查过程是这样的先确认技能目录确实存在用ls命令看了一下目录在文件也在。然后确认客户端读的是哪个路径翻了一下客户端的配置文件发现我配的是相对路径而客户端启动时的工作目录跟我以为的不一样导致相对路径解析到了别的地方。改成绝对路径之后技能就正常加载了。还有一个坑是权限问题。技能目录如果放在系统保护的位置客户端可能没有读取权限。这种情况在 Linux 和 macOS 上比较常见。解决办法是把技能目录放到用户目录下或者手动改一下目录权限。Windows 上则要注意路径里的反斜杠和空格有时候路径里有空格会导致解析失败建议技能目录路径不要带空格。注意每次修改路径配置后一定要完全重启客户端而不是只刷新或者重开对话窗口。有些客户端会缓存技能列表不重启的话读不到新配置。5.2 技能触发了但行为不符合预期技能加载成功之后下一个坑是触发了但行为不对。我遇到过几种情况分别说一下原因和解决办法。一种是技能触发了但它没有按照技能定义的流程走还是像普通对话一样直接给答案。这种情况通常是技能文件的内容没有被正确注入到对话上下文里。可能的原因是技能文件格式不对比如缺少必要的元信息字段导致客户端解析失败但没报错。解决办法是打开技能文件对照客户端文档检查格式确保所有必填字段都在。另一种是技能触发了但执行到一半停了或者输出不完整。这通常是因为输入内容太长超出了模型的上下文窗口。技能指令本身占了一部分上下文你的输入又占了一部分留给输出的空间就不够了。解决办法是精简输入只传必要的信息或者把任务拆成几步分次执行。还有一种是技能匹配错了。你明明想用代码审查技能它却调用了调试排查技能。这是因为隐式触发时AI 根据你的描述做了错误的判断。解决办法是改用显式触发明确指定技能名称或者优化技能描述文件让每个技能的适用场景写得更清晰减少误匹配。5.3 多个技能同时生效时的冲突处理当你装了多个技能之后可能会遇到技能冲突的情况。比如你同时触发了代码审查和测试用例生成两个技能都在往输出里塞内容结果输出变得很乱分不清哪部分是哪部分。这种情况的根源在于技能之间没有协调机制每个技能都按照自己的流程走互不知道对方在干什么。解决办法有几个一是避免同时触发多个技能一次只用一个用完再换下一个二是如果确实需要组合使用在调用的时候明确指定执行顺序比如“先做代码审查审查完再做测试用例生成”三是检查技能描述文件里有没有定义互斥关系有些实现支持在技能里声明“本技能与其他技能同时使用时需要特别注意什么”。我个人的做法是尽量串行使用技能一个做完再做下一个。虽然多花几轮对话但输出清晰不容易乱。只有在非常明确两个技能可以协同工作时才会并行触发。5.4 技能更新后旧配置失效的问题技能包更新之后有时候旧的配置会失效。我遇到过一次更新完技能包原来能用的技能突然报错了。查了半天发现是新版本的技能文件里增加了一个必填字段而我的客户端版本比较旧不认识这个字段解析就失败了。这种问题的解决办法有两个方向要么升级客户端到支持新字段的版本要么回退技能包到旧版本。我建议是尽量保持客户端和技能包的版本匹配不要一个太新一个太旧。如果你用的是包管理器安装的技能可以在配置里锁定版本号避免自动升级到不兼容的版本。另外技能更新后之前保存的调用参数或者自定义配置可能会失效。比如你之前设置过某个技能的默认严格程度新版本可能改了参数名称或者取值范围。更新之后最好把常用技能都试一遍确认行为符合预期。6. 让技能真正融入日常一些实用的组合与心得6.1 日常开发中的高频技能组合用了一段时间之后我慢慢固定下来几套技能组合对应不同的日常场景。这些组合不是官方推荐的纯粹是我自己用下来觉得顺手的。场景一接手陌生代码。先用“代码审查”技能过一遍目标文件了解代码的整体质量和潜在问题。然后用“需求拆解”技能根据代码逻辑反推它实现了什么功能。最后用“测试用例生成”技能看看现有测试覆盖了哪些场景、遗漏了哪些。这一套走下来对陌生代码的理解会快很多。场景二修 bug。先用“调试排查”技能理清排查思路定位到问题代码。然后用“代码审查”技能检查修复方案有没有引入新问题。最后用“测试用例生成”技能补一个针对这个 bug 的回归测试。这套组合能确保修完 bug 之后不会引入新的坑。场景三写新功能。先用“需求拆解”把需求理清楚再用“方案对比”做技术选型然后用“接口实现”生成代码框架接着用“代码审查”过一遍最后用“测试用例生成”补测试。这套流程走完基本能保证新功能的质量。这些组合不是死的你可以根据自己的习惯调整顺序或者增减技能。关键是找到一套适合自己的节奏让技能成为习惯而不是负担。6.2 把团队规范写进技能里superpowers 有一个我觉得被低估的用法把团队内部的开发规范固化到技能里。每个团队都有自己的编码习惯和审查标准与其每次口头强调不如写进技能文件里让 AI 助手在审查代码时自动按照团队标准来。具体做法是复制一份官方的代码审查技能然后修改它的检查清单把团队特有的规范加进去。比如你们团队要求所有公开函数必须有 JSDoc 注释那就在检查清单里加一条“检查公开函数是否有 JSDoc 注释”。再比如你们要求日志必须包含 traceId那就加一条“检查日志打点是否包含 traceId”。这样做的好处是新成员用 AI 助手审查代码时会自动按照团队标准来减少了很多沟通成本。而且技能文件本身也是一份文档新成员读一遍技能文件就能了解团队的编码规范。6.3 技能不是银弹什么时候该放下它最后说一个我自己的体会技能这东西虽然好用但不是所有场景都适合。有些时候放下技能直接跟 AI 对话反而更高效。比如探索性的任务你还没想清楚要做什么只是想跟 AI 聊一聊找找灵感。这时候用技能反而会限制它的发挥不如放开让它自由回答。再比如非常简单的任务改个变量名、调个格式直接用编辑器的批量替换比调技能快得多。还有需要创造性输出的场景比如写技术方案文档的初稿用技能可能会让它过于拘泥于流程输出显得死板。我的判断标准是如果任务有明确的流程和标准用技能如果任务需要灵活发挥直接对话。技能的价值在于把重复性的、有固定套路的工作标准化而不是替代所有思考。另外技能本身也需要维护。用了一段时间之后你会发现有些技能很少用到有些技能需要根据实际情况调整。定期清理和更新技能列表保持它精简有效比装一大堆用不上的技能要好。我现在保持常用的技能在十个左右每个都清楚它什么时候该用、什么时候不该用。这个数量对我来说刚好再多就记不住了。提示如果你刚开始用建议先从两三个核心技能入手比如代码审查和调试排查用熟了再逐步增加。一次性装太多技能反而容易在调用时犹豫该用哪个降低效率。