最近有个叫 superpowers 的项目在 AI 编程工具圈里传得很开我一开始以为是某个 IDE 插件结果仔细看了下它解决的问题远比插件两个字大得多。简单说这是一套围绕 AI 编程助手设计的技能管理方案——把散落在提示词、规则文件和脚本里的能力打包成可安装、可复用、可共享的技能包。如果你正在用 Claude Code、Cursor 这类工具又觉得每次都要重复叮嘱 AI先看哪几个文件、按什么步骤来、输出什么格式那 superpowers 大概率能帮你省掉这一大段口水。我花了一周时间把项目完整跑了一遍从一个只会往规则文件里堆提示词的新手到能自己写技能包、给团队搭共享技能库的状态。这篇文章不打算贴官方文档而是把我实际踩过的坑、看过的技能源码、改过的脚本逻辑全部捋一遍希望能让想接触这套体系的人少走弯路。1. 为什么很多人觉得 AI 工具越用越废从提示词仓库到技能体系先聊一个比较反直觉的观察。很多重度用户装了十几个 AI 编程助手Cline、Continue、Windsurf 换着用但产出的东西越来越像一次性用品——每次对话都要从头解释项目背景、架构约定、代码风格回答的质量完全看当天模型状态。问题的根源不在模型能力在于你给模型的那套工作环境太简陋了。普通的提示词仓库只能解决说什么的问题解决不了怎么做和做完后怎么验证的问题。superpowers 的切入点很有意思它把技能定义成一套结构化的能力包里面不仅有指令文本还包括触发条件、输入校验、脚本工具、输出格式约定甚至验收标准。你可以把它理解成把一道菜的菜谱升级成了标准化的作业指导书——菜谱告诉你放多少盐作业指导书还告诉你什么时候放、火候多大、出锅后怎么判断有没有熟。1.1 技能的本质不是提示词而是一整套可运行的结构我拆开项目里几个现成的技能包看过发现一个合格的技能包通常包含这几个部分描述文件声明这个技能叫什么、解决什么问题、在什么场景下被触发。核心指令给 AI 的做事步骤不是一句话而是一整套操作流程。脚本工具用于获取上下文、校验结果、执行本地命令的代码。资源模板输出产物的格式模板、示例、检查清单。元信息版本号、作者、依赖条件。举个例子一个代码审查技能包不会只写一句请审查这段代码它会先让 AI 读取 diff 文件然后按安全漏洞—性能问题—可读性问题—测试覆盖四个维度逐项检查每个维度对应一个检查脚本最后用固定模板输出报告。你会发现真正起作用的不只是那段指令文本而是整个包的执行逻辑。1.2 围绕superpowers的浏览器技能仓库与安装入口这个项目本身更像一个技能包管理器。安装完成之后你可以像逛应用商店一样浏览社区贡献的技能列表看到合适的技能就一键拉进自己的工作区。和常见的 MCP 市场、插件市场相比它有几个设计上的差异点技能包不是黑盒代码而是可读的 Markdown 加脚本你可以随时打开改。技能的触发依赖自然语言描述AI 会根据上下文自动选择合适的技能不需要手动切换。技能包的粒度偏场景化比如重构遗留代码生成数据库迁移脚本整理技术债清单这类完整任务而小到格式化代码这种操作则不需要技能。2. 把技能装进日常安装流程与第一轮踩坑实录安装阶段我遇到的问题比预期多但也正是这些坑让我对这套机制的理解上了一个台阶。先说结论安装本身不难难的是让技能在你当前使用的工具里真正生效。2.1 环境准备哪些依赖必须提前确认我建议先检查以下三点省得到时候排查半天你使用的 AI 编程工具是否支持读取本地技能目录比如 Claude Code 的 skills 机制或者 Cursor 的规则目录。开发机是否装了 Node.js 或 Python因为不少技能包里的脚本要依赖运行环境。是否初始化了项目的技能目录没有初始化的话安装命令会提示找不到位置。一个比较容易忽略的点是技能的加载机制通常基于文件目录约定。比如某个目录下每个子文件夹对应一个技能文件夹里的 SKILL.md 就是技能的入口文件。如果你之前手动建过同名目录安装时可能会覆盖或者冲突最好先备份。2.2 一次典型的安装演示从搜索技能到加载生效整个过程可以用几条命令走通但具体命令名以你安装的版本为准我用的版本大致是下面这个流程在项目根目录执行初始化命令生成技能目录骨架。调用技能列表命令拉取可用的技能清单屏幕上会显示技能名、描述、作者和下载量。按关键词过滤比如搜索测试或重构缩小范围。安装指定技能项目会自动把技能包下载到本地技能目录并输出安装日志。装完之后大多数工具并不会立刻识别——你需要重启会话或者执行一次技能刷新让 AI 重新扫描目录。这一步我一开始不知道装完直接在新会话里试结果发现 AI 完全感知不到新技能的存在。2.3 安装后面临的三个常见坑及解决思路这里把我实际遇到的坑和排查思路整理成一张表现象可能原因怎么处理技能装了但 AI 完全没反应技能目录没被当前工具读取检查路径配置确认目录层级必要时执行刷新命令AI 知道技能存在但触发不了描述文件里的触发场景写得太模糊打开技能描述文件补充更明确的关键词和触发条件技能能触发但执行报错依赖的脚本环境缺失查看技能包内的脚本目录逐个确认依赖是否已安装第三个坑最隐蔽。有一个技能包里写了 Python 脚本做代码统计我本机默认只有 Python 3.12但它要求的是 3.10 的某个库跑起来直接中断。后来我把脚本里的依赖声明单独拆出来输出警告而不是直接报错技能才恢复正常。3. 安装包里有哪些高价值技能核心技能盘点与适用场景如果你刚接触这套体系建议从下面这几个方向入手。这些不是我凭空想出来的而是我在项目官方技能市场、社区贡献列表里翻了一圈后挑出最贴近日常开发工作流的几类。注意不同版本的技能市场内容会持续更新但分类思路是通用的。3.1 代码研发向技能从读代码到改代码的链路闭环这类技能数量最多也最值得优先安装。我实际用过体验最好的三个是代码库架构解析、遗留代码重构、测试用例生成。代码库架构解析技能的效果很惊艳。它会让 AI 先扫描整个项目目录树读取核心模块的入口文件生成一张依赖关系图文字版再按模块输出职责说明。以前我想让 AI 快速了解一个新项目通常要费劲地贴一堆文件路径现在只要触发这个技能它自己就会按固定顺序去探索输出的文档结构每次都一致这对后续生成任务特别有用。遗留代码重构技能的设计思路是把重构拆成小步先识别出可测试的边界再生成行为验证用例最后逐步替换实现。它不是让 AI 大改特改而是强调每一步都要有验证符合我在生产环境里对安全性的要求。测试用例生成技能则侧重覆盖率而非数量。它会先读取已有测试文件分析哪些分支没被覆盖然后针对缺口生成用例并自动跑一遍测试框架把失败用例的报错信息写回建议区。这个跑一遍验证的闭环比单纯生成测试代码实用得多。3.2 文档与协作向技能把经验沉淀成团队资产代码技能解决的是写代码的问题文档技能解决的是知识能不能留下来的问题。变更记录生成技能可以根据 Git 提交记录自动生成 CHANGELOG但它不只是机械拼接 commit message而是会识别提交类型新增、修复、破坏性变更、关联的模块、以及是否有 breaking change。我把这个技能接进 CI 流程后每个迭代版本的变更记录整理时间从半小时降到了两三分钟。技术评审清单技能也很有用。它会在你提交 PR 之前按需求是否可追溯实现是否最小化测试是否充分文档是否更新四个方面逐项检查输出一份 checklist。有同事反馈说有了这个技能PR 被打回的频率明显降低了因为低级遗漏在提交前就被 AI 拦住了。3.3 生活化场景向技能超级工具不只服务程序员可能有人觉得 superpowers 这个名字有点中二但它确实不局限于程序员场景。技能市场里有不少针对个人知识管理、写作和项目管理的技能包。比如有一个周报生成器技能会读取你这周的 Git 记录、任务清单和会议纪要按事实—进展—问题—计划的结构生成周报草稿。还有一个竞品分析技能输入几个竞品名它会调起一组信息收集脚本输出对比表格。这些技能的技术含量不一定多高但贵在把流程标准化了你不需要每次重新组织语言告诉 AI 怎么干活。4. 动手改造一个技能从能用到好用的必经之路用了几天现成技能包之后我开始不满足了。每个项目的代码风格、工程规范、工具链都不一样通用技能只能解决 70% 的问题剩下 30% 得自己改。这里把我的改造步骤和设计思路完整写出来。4.1 技能包的标准结构先看一个新技能包的标准目录结构my-skill/ SKILL.md scripts/ preprocess.sh verify.py assets/ template.md checklist.md config.json每个文件的作用SKILL.md技能的核心文件包含技能名、描述、触发条件和执行步骤。AI 靠读取这个文件来决定何时使用技能、怎么使用。scripts/放辅助脚本用于预处理输入、验证输出、调用本地工具。是否需要取决于你的技能复杂度。assets/放模板、示例、参考资料。固定输出格式时特别有用。config.json放技能自己的配置项比如输出语言、严格程度、依赖的命令列表。新建技能时从 SKILL.md 开始写先让它能跑通最小流程再补脚本和模板。4.2 一个示例技能代码提交信息生成器我的团队对 commit message 有比较严格的格式要求但成员经常忘。于是我做了一个技能让 AI 在提交代码前自动生成符合规范的提交信息并在 commit 前做校验。大致设计如下。SKILL.md 的核心部分是这样的--- name: generate-commit-message description: 根据 git diff 生成符合团队规范的提交信息 trigger: 当用户准备提交代码时或者用户要求生成提交信息时 --- ## 执行步骤 1. 运行 git diff HEAD 获取变更内容注意只关注代码变更忽略 .lock 和构建产物。 2. 按以下维度分析变更 - 新增功能: feat - 缺陷修复: fix - 重构改善: refactor - 文档更新: docs - 测试调整: test 3. 生成提交信息草稿按 scope(module): summary 格式编写。 4. 检查变更里是否有破坏性 API 变化若有在提交信息末尾追加 BREAKING CHANGE 说明。 ## 输出格式 提交信息以 code block 形式输出包含 type(scope): summary 和正文说明。这个技能设计的关键在哪里呢在于它把触发时机定义得很清楚——AI 需要判断什么时候该主动调用而不是要求用户每次手动输入技能名。我把项目的工程规范直接写进步骤里AI 的输出立刻带上了团队风格。然后配一个校验脚本跑在提交钩子里#!/bin/bash message$(head -1 $1) pattern^(feat|fix|refactor|docs|test)(\([a-z]\))?: . if [[ ! $message ~ $pattern ]]; then echo 提交信息不符合规范: $message exit 1 fi这个脚本是技能包的验证层跟 SKILL.md 里的生成逻辑互补——一个负责生成一个负责把关。4.3 迭代技巧用最小技能快速验证很多新手一上来就要写大而全的技能包结果步骤写了一大堆AI 执行到第三步就懵了。我的建议是先写一个最简版本描述三到五行指令不加脚本、不加模板只验证AI 能不能理解我的意图。跑通了再逐步补流程、补校验、补异常分支。举个例子我先给改提交信息技能写的是分析 git diff归类为新增、修复、重构并输出一行摘要跑了几次对话发现 AI 总是漏掉破坏性变更提示才在步骤里加上第四条。这种迭代方式能确保每个新增逻辑都是因为确有必要而加的而不是凭空堆上去的装饰。5. 关于安全边界与使用习惯高级玩家才会注意的事技能包本质上是让 AI 按你定义的方式调用本地命令和读取文件这意味着安全问题不能被忽略。5.1 第三方技能包的内容审计我在安装社区技能包之前会先扫一遍几个关键位置SKILL.md 里的指令部分看它是否要求 AI 读取敏感路径如 ~/.ssh、.env。scripts 目录下的脚本逐行看有没有 curl 上传数据、base64 解码、反向 shell 之类的操作。config.json 里有没有可疑的外部 URL 或 token 请求。有一次我装了一个自动提交日报技能打开脚本发现里面把 git 用户名的环境变量偷偷写进了一个日志文件还想上传到第三方服务。这让我意识到技能市场等同于代码托管平台包的质量和安全需要自己把关不能盲目信任。5.2 技能冲突与覆盖策略当你的技能数量超过两位数就要考虑冲突问题。比如两个技能都定义了在项目里查找 TODO 清单的职责AI 可能随机挑选一个触发导致输出格式不稳定。我的经验是在技能名的前缀上下功夫给团队内部的技能统一加 team-再在描述里写得更具体一点比如team-parse-todo 只扫描 src 目录。这样 AI 在触发时会优先匹配描述更精确的技能。另外同一技能在不同目录层级的管理容易出乱子。我建议把通用技能放在全局目录把项目相关技能放在项目目录。全局目录里的技能是所有人都能用的基线能力项目目录里则是这个项目特有的规范。改造时优先改项目目录里的副本不动全局基线。6. 我的真实体感与后续扩展方向折腾完这一圈最核心的体感是AI 输出的稳定性明显提高了。以前同一个问题换个问法答案就可能变形现在技能包把步骤和约束固化下来AI 的产出越来越接近预制菜流程固定、口味统一我再也不担心它自由发挥。第二个体感是技能的复制效应。我们组三个人一起维护一个技能库谁发现了更高效的处理流程直接改到技能包里其他人拉取更新后立刻受益。这种经验结构化的沉淀方式比在群里发提示词片段管用得多。后续我准备在几个方向上再深挖一是把团队的 code review 红线规则整理成技能包让 AI 在做初步审查时就按红线拦截二是把运维场景里的故障排查手册脚本化让 AI 拿到报错信息自动走排查链路三是尝试把技能包和 CI/CD 流水线结合在构建环境里跑技能包的校验脚本让技能不只在对话里生效更在流程里生效。说到底superpowers 这个名字虽然夸张但它指向的方向很实际不要每次都临时教 AI 怎么干活而是把干活的方法沉淀下来随取随用。如果你也在用 AI 编程工具建议挑一个小场景花半小时做一个最小技能包跑通之后你大概就能理解这套体系的价值了。