1. 从“超能力”到可复用技能superpowers 到底在解决什么问题第一次听到 “superpowers” 这个词很多人会以为是某个超级英雄题材的游戏或者影视项目。但在开发者圈子里它指的是一套面向 AI 编程助手的技能扩展体系——你可以把它理解成给 AI 助手安装的一批“专业插件”让它在特定任务上从“泛泛而谈”变成“真正能干活”。我最初接触这个概念的时候最直接的感受是终于有人把“怎么让 AI 按我的方式做事”这件事给标准化了。superpowers 的核心价值在于它把零散的提示词、工作流程、领域知识打包成一个个独立的 skill技能每个 skill 聚焦一件事比如代码审查、提交信息生成、测试用例编写、文档整理等等。你不需要每次都在对话里重复交代“你要先看我的代码风格再按这个格式输出”而是把这些规则固化到技能里用的时候直接引入就行。这解决的是一个非常现实的痛点AI 助手很强但它的默认行为往往不符合你的项目规范每次都要手动纠正效率极低。这套东西适合谁我认为三类人最应该关注。第一类是日常用 AI 辅助写代码的开发者尤其是团队协作场景下需要统一输出规范的第二类是技术团队的负责人想把团队的最佳实践沉淀成可复用的资产第三类是对 AI 工作流感兴趣、喜欢折腾工具链的效率爱好者。哪怕你只是偶尔用 AI 写写脚本了解 superpowers 的组织思路也能帮你更好地管理自己的提示词库。需要说明的是superpowers 本身不是一个具体的软件产品而更像一套约定和框架。它的具体形态可能因平台而异但核心思想是一致的把“怎么做一件事”的知识从对话中抽离出来变成可安装、可引入、可组合的技能单元。接下来我会从整体设计、核心技能拆解、安装引入流程、常见问题排查几个维度把我在实际使用中积累的经验完整地分享出来。2. 整体设计思路为什么是“技能”而不是“提示词”2.1 提示词的天花板在哪里用了几年 AI 辅助工具之后我越来越明显地感觉到纯提示词方案的局限。你精心写了一段提示词效果很好但换一个对话窗口就失效了你想把它分享给同事对方复制过去发现效果打了折扣因为上下文不一样你想在多个任务里复用同一套规则只能反复粘贴维护成本极高。更麻烦的是当规则变多之后提示词之间会互相干扰你改了一处另一处又出问题。这就像你每次做饭都要从头写一遍菜谱而不是把菜谱印成卡片放在厨房里。提示词是“一次性”的而技能是“可复用”的。superpowers 的设计思路正是看到了这个瓶颈与其不断优化单条提示词的长度和措辞不如把知识结构化、模块化让每个技能只负责一个明确的职责。2.2 技能化的三个核心优势第一个优势是边界清晰。一个 skill 只做一件事比如“生成符合 Conventional Commits 规范的提交信息”它的输入、输出、触发条件都是明确的。这样你在引入的时候不会产生歧义也不会因为技能之间的职责重叠导致行为混乱。第二个优势是可组合。你可以同时引入多个技能让它们协同工作。比如一个技能负责分析代码变更另一个技能负责根据分析结果生成提交信息第三个技能负责检查提交信息是否符合团队规范。这种组合能力是单条提示词很难做到的。第三个优势是可维护。技能是独立文件你可以用版本控制管理它可以 review 变更可以回滚到之前的版本。团队里谁改了什么规则一目了然。这一点对于需要长期维护的项目来说非常关键。2.3 技能的分类逻辑从我接触到的 superpowers 体系来看技能大致可以分为几类。一类是流程类技能比如代码审查流程、发布流程、问题排查流程它们定义的是“做事的步骤”。另一类是规范类技能比如代码风格规范、提交信息规范、文档格式规范它们定义的是“输出的标准”。还有一类是知识类技能比如某个框架的最佳实践、某个 API 的使用注意事项它们提供的是“领域知识”。这种分类方式的好处是当你想扩展能力的时候先想清楚你要加的是流程、规范还是知识然后按对应的模式去写技能不会混在一起。我在实际使用中最大的体会是流程类技能最容易被低估很多人只关注规范类技能觉得把格式定好就行了但实际上流程类技能对效率的提升更明显因为它减少的是“思考下一步做什么”的认知负担。3. 核心技能拆解superpowers 里到底有哪些值得用的 skill3.1 代码审查类技能代码审查是我用得最多的技能类型。在没有技能之前我让 AI 审查代码它往往会给出一些泛泛的建议比如“建议增加错误处理”“可以考虑提取公共方法”听起来有道理但不够具体。引入代码审查技能之后情况完全不一样了。技能里会定义审查的维度、每个维度的检查项、问题的严重程度分级以及输出的格式。我常用的一个审查技能会把问题分成三个等级阻塞性问题必须改、建议性问题可以改、风格性问题看情况改。每个问题都会附带具体的代码位置和修改建议。这样一来审查结果直接可以当成任务列表来用不需要我再二次整理。这里的关键在于技能里预置了“什么算阻塞性问题”的判断标准比如空指针风险、资源泄漏、并发安全问题属于阻塞性而命名不够清晰、注释缺失属于建议性。这些标准是根据团队实际情况定制的不是通用模板。注意代码审查技能的判断标准一定要结合你所在项目的技术栈来定。比如在 Java 项目里空指针是高频阻塞性问题在 Rust 项目里这个问题基本不存在但所有权和生命周期的误用需要重点关注。3.2 提交信息与版本管理类技能提交信息生成是我认为投入产出比最高的技能之一。以前团队成员提交代码提交信息五花八门有的写“fix bug”有的写“update”过几个月回头看根本不知道改了什么。引入提交信息技能之后AI 会根据代码变更自动生成符合规范的提交信息包括类型feat/fix/refactor/docs 等、影响范围、简短描述和详细说明。这个技能的实现逻辑并不复杂但有几个细节值得注意。第一技能需要能读取到代码变更的内容所以它通常和版本控制工具配合使用。第二技能里要定义好类型的映射规则比如什么情况下用 feat、什么情况下用 fix边界要清晰。第三技能要能处理多文件变更的情况当一次提交涉及多个不相关的改动时应该建议拆分成多次提交而不是硬凑成一条信息。我踩过的一个坑是早期版本的技能没有处理“变更内容为空”的情况导致在只修改了配置文件但内容没变的时候生成了一条毫无意义的提交信息。后来在技能里加了前置检查如果变更内容为空或者只有空白字符变化就直接提示不需要提交。3.3 测试相关技能测试技能分为两类一类是测试用例生成一类是测试结果分析。测试用例生成技能会根据代码逻辑自动推导出需要覆盖的场景包括正常路径、边界条件、异常路径。这个技能的价值在于它能把开发者容易忽略的边界情况给补上。比如一个处理数组的函数开发者可能只测了正常数组技能会提醒你测空数组、单元素数组、包含重复元素的数组、超大数组等。测试结果分析技能则是在测试失败时帮你快速定位问题原因。它会读取失败信息、相关代码和最近的变更记录给出可能的原因和排查方向。这个技能在持续集成环境里特别有用因为很多时候测试失败是环境问题或者偶发问题技能可以帮你快速判断是“真 bug”还是“假警报”。3.4 文档与知识管理类技能文档类技能解决的是“代码写了但没人知道怎么用”的问题。我常用的一个技能会根据代码的公开接口自动生成 API 文档草稿包括参数说明、返回值说明、使用示例。草稿生成后我再人工补充一些背景信息和注意事项效率比从零写高很多。知识管理类技能则更偏向于团队协作场景。比如有一个技能专门用来把会议纪要或者讨论记录整理成结构化的决策文档提取出“决定了什么”“为什么这么决定”“谁负责”“什么时候完成”这几个要素。这个技能看起来简单但实际用起来能省不少整理时间。3.5 技能选择速查表技能类型典型用途使用频率上手难度代码审查检查代码质量、发现潜在问题高低提交信息生成规范化版本管理记录高低测试用例生成补充边界测试场景中中测试结果分析快速定位测试失败原因中中API 文档生成减少文档编写工作量中低决策文档整理沉淀团队讨论结论低低这张表是我根据自己半年多的使用记录整理的使用频率和上手难度都是主观评价仅供参考。我的建议是先从代码审查和提交信息这两个技能入手因为它们几乎每天都会用到而且效果立竿见影。4. 安装与引入怎么把 superpowers 技能接入你的工作流4.1 安装前的环境确认在安装任何技能之前有几项环境信息需要先确认清楚。首先是你的 AI 助手平台支持哪种技能格式不同平台的技能定义方式可能不一样有的用 Markdown 文件有的用 JSON 配置有的用专门的 DSL。其次是确认技能的存放位置通常平台会有一个默认的技能目录你需要知道这个目录在哪里才能把技能文件放进去。我建议在安装之前先做一个简单的测试手动创建一个最简单的技能比如一个只包含“输出 hello”的技能看看能不能被正确加载和触发。这个测试能帮你快速验证环境配置是否正确避免后面装了一堆技能发现根本不生效还要回头排查环境问题。4.2 技能文件的获取与组织技能文件的来源主要有三种。第一种是官方或社区提供的现成技能直接下载使用。第二种是团队内部沉淀的技能从团队的知识库里获取。第三种是自己编写的技能根据个人需求定制。不管来源是哪种我都建议在本地建立一个清晰的目录结构来管理技能文件。比如按类别分目录skills/review/放审查类技能skills/commit/放提交类技能skills/testing/放测试类技能。每个技能一个独立文件文件名用能说明用途的英文短语比如code-review.md、commit-message.md。这样做的好处是当技能数量多起来之后你还能快速找到想要的技能也方便做版本管理。4.3 引入技能的具体步骤引入技能的操作本身通常很简单但有几个细节容易出错。以常见的 Markdown 技能文件为例基本流程是这样的把技能文件放到平台的技能目录下。确认技能文件的元信息名称、描述、触发条件填写正确。重启或刷新 AI 助手让技能被加载。在对话中通过特定的指令或关键词触发技能。这里最容易出问题的是第二步和第四步。元信息里的触发条件如果写得太宽泛技能会被频繁误触发写得太窄又可能该触发的时候不触发。我的经验是触发条件里要包含明确的动作词比如“审查这段代码”“生成提交信息”而不是只写“代码”“提交”这样的名词。第四步的触发方式也需要注意。有的平台是通过斜杠命令触发有的是通过自然语言触发有的是自动匹配。你需要先搞清楚你的平台用哪种方式然后在技能里做对应的配置。我遇到过有人把技能写好了但一直触发不了最后发现是触发方式配置错了改成正确的触发词之后立刻就生效了。4.4 技能引入后的验证方法技能引入之后不要假设它一定能正常工作一定要做验证。验证的方法很简单构造一个该技能应该处理的输入看输出是否符合预期。比如引入了代码审查技能就找一段有明显问题的代码让它审查看它能不能准确识别出问题并给出合理的建议。验证的时候要特别注意边界情况。比如提交信息技能除了测试正常的代码变更还要测试空变更、只有格式变化的变更、涉及多个不相关改动的变更看技能能不能正确处理这些情况。我自己的习惯是每引入一个新技能至少构造三个测试用例一个正常用例、一个边界用例、一个异常用例。三个都通过了才算这个技能可以正式使用。4.5 多技能共存时的优先级管理当你引入多个技能之后可能会遇到技能之间“打架”的情况。比如一个技能说提交信息要用中文另一个技能说要用英文一个技能说代码审查要严格另一个技能说要以鼓励为主。这时候就需要管理技能的优先级。大多数平台会提供优先级配置数字越小优先级越高或者列表里越靠前优先级越高。我的做法是把“规范类”技能的优先级设得高一些因为规范是硬性要求“建议类”技能的优先级设得低一些因为建议是可以灵活处理的。另外如果两个技能的功能有重叠尽量合并成一个技能而不是靠优先级来协调因为优先级只能决定谁先执行不能解决逻辑冲突。5. 实操过程从零搭建一套可用的技能组合5.1 第一步梳理你的高频任务不要一上来就想着装一堆技能先花点时间梳理你日常工作中最高频的任务是什么。我的做法是连续记录一周的工作内容把重复出现的任务标记出来。比如我发现“审查同事的代码”“写提交信息”“整理会议结论”这三件事几乎每天都要做那它们就是最值得技能化的任务。梳理的时候要注意区分“高频”和“高价值”。有些任务虽然频繁但每次花的时间很短技能化带来的收益有限有些任务频率不高但每次都很耗时也值得技能化。我的判断标准是如果一件事每周至少做三次或者每次做超过十分钟就值得考虑做成技能。5.2 第二步为每个任务定义输入输出确定要技能化的任务之后下一步是明确定义每个任务的输入和输出。这一步看起来简单但实际做的时候会发现很多模糊地带。比如“审查代码”这个任务输入是什么是代码片段、文件路径还是代码仓库地址输出是什么是问题列表、修改建议还是审查报告这些都要想清楚。我的经验是输入输出定义得越具体技能实现起来越顺利。以提交信息生成为例我最终定义的输入是“版本控制工具中的暂存区变更”输出是“符合 Conventional Commits 规范的提交信息文本”。这个定义足够具体实现的时候就不会有歧义。5.3 第三步编写技能内容技能内容通常包含几个部分技能描述、触发条件、执行步骤、输出格式、注意事项。技能描述用一两句话说明这个技能是做什么的触发条件定义什么时候应该使用这个技能执行步骤是核心详细说明每一步做什么输出格式定义最终结果的样子注意事项列出容易出错的地方。写执行步骤的时候我建议用编号列表每一步都写清楚“做什么”和“为什么这么做”。比如不要只写“检查代码风格”而要写“检查代码风格重点关注命名规范、缩进一致性和注释完整性因为这些是团队代码规范里明确要求的”。把“为什么”写进去一方面帮助自己理清逻辑另一方面在技能需要修改的时候能快速判断哪些步骤可以调整、哪些不能动。5.4 第四步测试与迭代技能写完之后一定要在实际工作中使用一段时间收集反馈再迭代。我通常会给自己定一个“试用期”比如两周。试用期内每次使用技能都记录一下效果哪些地方符合预期哪些地方需要改进有没有误触发或者漏触发的情况。试用期结束后根据记录的问题集中修改一次。修改的时候要注意不要一次改太多每次只改一两个点改完再试用几天确认没问题了再改下一个。这样能避免一次改动引入新问题却不知道是哪个改动导致的。我见过有人一次性大改技能结果效果反而变差了又找不到原因只能全部回滚重来。5.5 第五步团队共享与版本管理如果你是在团队里使用技能共享和版本管理就很重要。我的做法是把技能文件放在团队的代码仓库里和项目代码一起做版本管理。每次修改技能都走正常的代码审查流程确保改动是经过确认的。技能文件里可以加一个变更记录简单记一下每次改了什么、为什么改。团队共享还有一个好处是不同的人可以贡献不同的技能。比如前端同学写一个组件审查技能后端同学写一个接口设计审查技能测试同学写一个测试用例生成技能。大家把自己擅长的领域知识沉淀下来整个团队都能受益。这比每个人各自维护一套提示词要高效得多。6. 常见问题与排查技巧实录6.1 技能不生效的排查思路技能不生效是最常见的问题排查的时候可以按这个顺序来。先确认技能文件是否放在了正确的目录下文件名和扩展名是否符合平台要求。然后检查技能文件的格式是否正确特别是元信息部分有没有语法错误或者必填字段缺失。接着确认技能是否被正确加载有的平台需要手动启用技能有的需要重启才能生效。最后检查触发条件是否匹配你用的触发词和技能里定义的触发条件是否一致。我遇到过一次很隐蔽的问题技能文件里有一个看不见的特殊字符导致解析失败。这种问题很难用肉眼发现后来是用编辑器的“显示不可见字符”功能才找到的。所以如果你确认其他都没问题但技能就是不生效可以试试把技能文件的内容复制到一个纯文本编辑器里再重新粘贴回去排除特殊字符的干扰。6.2 技能输出不符合预期的调整方法技能能触发但输出不对通常有几个原因。一是技能里的指令不够明确AI 理解成了别的意思。这时候需要把指令写得更具体把模糊的词替换成明确的描述。二是技能里的示例不够有代表性AI 照着示例的风格去输出了但示例本身就不符合你的要求。这时候需要更新示例确保示例就是你想要的效果。三是技能和其他技能产生了冲突需要检查是否有功能重叠的技能同时生效了。我的经验是调整技能输出的时候不要只改文字描述最好同时提供一个“正面示例”和一个“反面示例”。正面示例告诉 AI 应该输出成什么样反面示例告诉 AI 不要输出成什么样。这样比单纯用文字描述效果要好得多。6.3 技能之间冲突的解决策略技能冲突的表现形式有很多比如输出格式不一致、执行顺序混乱、同一个问题给出矛盾的建议。解决冲突的第一步是定位冲突源把可能相关的技能逐个禁用看问题是否消失从而确定是哪个技能导致的。确定冲突源之后有两种解决方式一种是调整优先级让其中一个技能覆盖另一个另一种是修改技能内容消除重叠部分。我倾向于第二种方式因为优先级只能决定谁生效不能解决根本问题。如果两个技能都在做代码审查那就应该合并成一个技能而不是让它们互相覆盖。合并的时候把两个技能里合理的部分保留冲突的部分讨论后取其一这样得到的技能比原来两个独立的技能更健壮。6.4 性能问题的优化建议技能数量多了之后可能会感觉到 AI 助手的响应变慢。这通常是因为每次对话都要加载和匹配所有技能技能越多匹配的开销越大。优化的思路有几个一是把不常用的技能禁用需要的时候再启用二是把功能相近的技能合并减少技能总数三是优化技能的触发条件让匹配更快更准。我自己的做法是维护一个“常用技能集”和“备用技能集”。常用技能集里放五到八个每天都会用到的技能始终保持启用状态。备用技能集里放其他技能需要的时候临时启用。这样既保证了日常效率又不会因为技能太多拖慢响应。6.5 常见问题速查表问题现象可能原因排查方法解决方式技能完全不触发文件位置错误或格式错误检查目录和文件格式修正位置或格式技能偶尔触发触发条件太窄检查触发词是否匹配放宽触发条件输出格式不对指令描述模糊对比技能指令和实际输出细化指令增加示例多个技能冲突功能重叠逐个禁用定位冲突源合并或调整优先级响应变慢技能数量过多统计启用技能数量禁用不常用技能技能效果不稳定缺少边界处理用边界用例测试补充边界处理逻辑这张表里的问题都是我实际遇到过的排查方法和解决方式也是经过验证的。如果你遇到的问题不在表里可以按照“先确认环境、再确认配置、最后确认内容”的顺序来排查大部分问题都能定位到。6.6 几个容易忽略的细节第一个细节是技能文件的编码格式。有些平台对文件编码有要求比如必须是 UTF-8 无 BOM 格式。如果编码不对技能可能加载失败或者出现乱码。建议统一用 UTF-8 无 BOM 格式保存技能文件。第二个细节是技能名称的命名规范。技能名称最好用英文小写字母加连字符比如code-review、commit-message。不要用空格、中文或者特殊字符避免在不同平台之间迁移时出现兼容问题。第三个细节是技能描述的准确性。技能描述不仅是给人看的也是给 AI 看的。描述里要包含技能的功能、适用场景和关键限制。比如“用于审查 Java 代码重点关注空指针和并发问题不适用于前端代码”这样 AI 在匹配的时候能更准确地判断是否应该使用这个技能。第四个细节是定期清理不再使用的技能。技能和代码一样也会有“技术债”。过时的技能不仅占用资源还可能产生误触发。我一般每季度清理一次技能库把三个月内没用过的技能归档或者删除。7. 我个人的使用体会与扩展思路用了半年多 superpowers 这套技能体系之后我最大的感受是它改变了我跟 AI 助手协作的方式。以前是我适应 AI 的默认行为现在是我定义 AI 的工作方式。这个转变看起来不大但实际体验差别很明显。以前每次让 AI 帮忙都要花时间解释背景和要求现在大部分常规任务都能直接触发对应的技能省下来的时间可以花在更有价值的事情上。如果要说有什么遗憾的话我觉得目前技能之间的组合能力还有提升空间。比如我希望能定义一个“发布流程”技能它自动调用代码审查技能、测试技能、提交信息技能和文档技能形成一个完整的流水线。目前这种组合还需要手动串联不够自动化。不过我相信随着这套体系的演进组合能力会越来越强。对于刚开始接触 superpowers 的人我的建议是从一个小技能开始不要贪多。先做一个你每天都会用到的技能把它打磨好体会到效率提升之后再逐步扩展。技能体系的价值在于长期积累而不是一次性装一堆然后放着不用。另外技能写得好不好关键不在于技术多复杂而在于你对要解决的问题理解得够不够深。把问题想清楚了技能自然就写好了。