你有没有遇到过这种情况同一个 AI 编程助手别人用起来像团队里的资深工程师一小时能搞定重构、补测试、修 Bug 全套流程你却要反复调整提示词才能让它不跑偏、不自由发挥。我最近在 GitHub 社区挖到一个叫 superpowers 的开源技能包重度使用了近一个月它几乎改变了我对“AI 编程助手”的认知。简单来说superpowers 是一套预制的 Agent Skills 集合专门给 Claude Code、Cursor 这类支持 Skills 机制的 AI 编程工具使用。你可以把它理解成提前给 AI “实习生”准备好的标准作业手册遇到哪类需求就自动调用对应的操作流程不用每次都把长篇提示词重新手敲一遍。这篇文章我用自己的实操经验把它们有什么 skills、怎么安装、怎么引入以及我踩过的坑一次讲清楚。如果你正在折腾 AI 编程工作流这东西值得花半小时试一试。1. superpowers 的核心思路把“提示词”升级成“技能包”1.1 先搞清楚 Skills 和 Plugin 到底有什么区别很多人第一次看到 superpowers会下意识觉得它是一个 Plugin但要理解它的精妙之处得先区分两个概念Plugin 和 Skill 不是一回事。Plugin 是真正能跑起来的代码可以接管文件系统、调用外部 API、改变工具行为而 Skill 从本质上看是一份结构化的 Markdown 文档里面写清楚“在什么场景下做什么事、按什么步骤做、有什么注意事项”。superpowers 选的是后者。它的每个技能都是一个 SKILL.md 文件AI 在对话过程中根据你的请求识别出应该触发哪份文档再按照文档里的指令去执行。这跟普通人理解的“插件”完全不一样——它不写死逻辑而是靠文档驱动模型行为。为什么这种设计更聪明因为大模型的强项本来就是指令跟随真正失控的往往是“指令不清晰”。你直接说“帮我测试这段代码”AI 只能靠自己的默认习惯去猜但如果你让它加载一个 TDD 技能它就会先列测试用例、再写失败测试、再写实现一步步来。superpowers 把“如何思考、如何工作”沉淀成可复用文档等于把高手的经验固化下来了。1.2 为什么 superpowers 会在开发者圈子里火起来它能火我觉得有几个现实原因。首先是透明每个 SKILL.md 都是纯文本你可以随时打开看里面写了什么不会像黑盒插件那样出问题只能干瞪眼。其次是轻量装一个技能不需要编译、不需要依赖复制一份 Markdown 进去就生效。第三是易定制我发现很多项目甚至不需要改动 superpowers 自带技能直接照它的格式写自己的技能也能被 AI 正确识别。还有一个常被忽略的优势它对新手极其友好。普通插件从安装到配置通常会劝退一批人但 superpowers 的安装过程几乎是“把文件夹放到指定位置”这么简单。我后面会讲到即便你从来没有配置过 AI 工具链按步骤走也能完成。从另一个角度说superpowers 是“提示词工程”的升级版。以前我们用提示词是写在对话框里每次都要重复现在技术社区把这些提示词按场景封装成了结构化文件让 AI 在需要的时候自己翻手册。这种思路不局限于编程如果你的 AI 工具支持 Skills你完全可以给客服、写作、数据分析场景各写一套技能。superpowers 只是给我们提供了一个成熟可靠的起点。2. superpowers 到底有哪些 skills一张表给你说清2.1 核心技能清单与适用场景我先后把 superpowers 仓库里的技能全部过了一遍这里挑最常用、我实际触发过的几个列出来。不同版本仓库里的技能数量可能会有差异但核心的这几类基本都稳定存在。技能名核心作用我实际使用的场景brainstorming在写代码前发散思路生成多个候选方案并收敛设计新模块接口时避免拿第一个想法就开干planning把一个模糊需求拆成阶段、任务、验收标准接到一个“做个后台管理页”这种需求时task-breakdown把大任务继续拆成小粒度执行步骤规划完功能后让 AI 逐条实现tdd按“先写测试、再看失败、再写实现”节奏开发写工具函数和核心业务逻辑时保证正确性debugging定位 Bug 时按系统化流程排查而不是瞎猜线上告警、逻辑异常时减少无效翻代码code-review以审查者视角读代码输出问题清单提交 Pull Request 前让 AI 把第一道关refactoring在不改变行为前提下调整结构降低耦合清理历史烂代码、拆分超大函数documentation自动把代码行为沉淀成 README、注释、变更记录项目交接、写维护文档的时候这个表只是我筛选出来的核心项。让我印象最深的是 TDD 技能它不会只丢给你一段测试代码而是会严格按“Red-Green-Refactor”节奏推进先让你看到测试失败再驱动实现。如果你一直觉得 AI 写代码是“玄学”用了这个技能之后会明显感觉到流程是可以控制的。2.2 技能在实际对话中怎么被触发很多人装完技能后最迷惑的一点是我到底怎么让 AI 用上这些能力在 superpowers 的机制里你不需要先输入一条什么咒语。它更常见的用法是在对话中自然提出比如你直接说“用 code-review 技能帮我看一下这个文件”AI 就会读取对应技能文档并按照里面的流程执行。另一种触发方式更自动化。当你的需求足够明确比如“帮我写一个防抖函数要求先写测试”AI 会根据它的系统提示词判断你涉及了多个技能老规矩是 testing 加 implementation于是自动加载对应的技能文件串起来用。这也是为什么技能描述部分一定要写得精准描述的越好模型越容易识别。我自己比较推荐的做法是开工第一句话就把技能点明确说出来。与其让 AI 猜不如直接说“先用 brainstorming 技能给这个功能列两个方案再用 planning 技能把任务拆好”。你会发现当模型知道自己要扮演哪个工作流时整个输出质量会提升一个档。2.3 一个技能文件到底长什么样既然 superpowers 的灵魂是 SKILL.md那我就把内部结构拆给你看。一个标准的技能文件通常分为两部分头部 YAML 元数据和正文 Markdown 指令。--- name: code-review description: 用于对代码变更进行系统化审查检查逻辑、安全、性能与可维护性问题 --- # Code Review 工作流 1. 先读取指定文件或 diff理解变更意图 2. 对照检查清单逐项审查 - 是否有关键逻辑遗漏 - 是否存在明显安全问题 - 是否有性能隐患 - 命名与结构是否清晰 3. 按严重程度输出问题列表每个问题给出修改建议 4. 不直接修改代码除非用户明确要求这个设计看起来很朴素但它利用了模型的指令跟随能力头部 description 用于让模型判断何时触发正文里的步骤则把“高质量 Code Review”这件事从依赖模型直觉变成依赖流程。我看到很多团队把内部代码规范直接写进类似文档效果比口头提醒好得多。我补充一句技能文件不要求多长关键是描述要具体、步骤要可执行。写得天花乱坠还不如几条清晰的检查项。superpowers 仓库里很多技能文档都很精炼这一点特别值得学习。3. 新手实操8 步把 superpowers 安装到你的 AI 编程环境3.1 安装前需要先准备什么在真正动手之前最好确认你的 AI 编程工具支持 Agent Skills。目前我验证过 Claude Code 和 Cursor 这两个主流环境都能正常识别名字里包含 Claude 或 Cursor 的配置方式基本通用。如果你用的工具比较特殊建议先去官方文档确认有没有“Skills”或“Skills Directory”的目录设置。另外需要确定的就是基础环境。既然要从 GitHub 拉仓库Git 肯定要装好部分一键安装脚本会依赖 Node.js我建议 Node 18 以上避免跑脚本时报错。其实最原始的方法只需要一个能解压压缩包的文件管理器就够了所以门槛并不高。3.2 标准安装流程克隆仓库 指定技能目录我以最常见的 Claude Code 为例走一遍完整流程。第一步打开终端把 superpowers 仓库克隆到本地技能目录git clone https://github.com/your-account/superpowers.git ~/.superpowers如果你只想体验核心技能不想把整个仓库都拉到 home 目录也可以克隆到项目目录下比如.superpowers。随后需要告诉你的 AI 工具去哪里读取技能。在 Claude Code 中一般通过设置skills路径来完成。echo export CLAUDE_CODE_SKILLS_DIR$HOME/.superpowers/skills ~/.zshrc source ~/.zshrc如果你用的是 Cursor则通常在项目根目录创建.cursor/skills目录然后把技能文件夹复制或者软链过去。原理都一样让 AI 工具知道到哪里找 SKILL.md。注意不同工具的配置变量名会有差异。最稳妥的方式是先打开工具的 Settings搜索“skills”关键词找到对应的目录配置项再手动填写路径。3.3 验证是否安装成功安装完成后别急着直接开干先花一分钟验证技能有没有被正确加载。最直观的方式是直接在对话里问一句“你能使用哪些 skills”。如果配置正确AI 会列出一串技能名称比如 code-review、tdd、planning 等。还有一种更可靠的方式是使用工具自带的技能管理命令。在 Claude Code 里尝试输入/skills如果能看到技能列表说明安装路径正确如果提示找不到说明技能目录还没被读进去。这时候别急着重启先去检查路径拼写和配置文件里有没有多余的空格。我遇到过最离谱的一次是配置文件里的注释符把路径整行注释掉了导致怎么加载都失败。3.4 我推荐的目录组织方式superpowers 的默认技能目录结构大致是这样的~/.superpowers/ ├── skills/ │ ├── brainstorming/SKILL.md │ ├── planning/SKILL.md │ ├── tdd/SKILL.md │ └── code-review/SKILL.md └── README.md每个技能一个目录目录名是技能 ID里面必须有且只有一个 SKILL.md这样才能被识别。我自己的习惯是保留一个~/.superpowers/skills/team/目录把团队内部规范技能单独放跟公共技能隔离开避免升级 superpowers 仓库时把自己的配置冲掉。这个做法是我踩过坑之后总结的后面还会细说。如果你希望多个项目共用同一套技能把技能目录放在 home 目录再全局引用即可如果你希望不同项目有不同技能建议放在项目里的.superpowers下这样还能把技能文件一起提交到 Git 仓库方便团队统一。4. 踩过坑以后我总结了一份 superpowers 常见问题速查表4.1 为什么 AI 总说“我没有这个技能”这个是我见过最多的问题通常有三个原因路径没对上、技能文件格式不对、或者配置改了但工具没重启。先说路径AI 工具不会递归扫描你的整个文件系统它只会读取配置里指定的那个目录。所以哪怕你把技能文件夹放在桌面上并觉得“很明显”配置里没写就是找不到。其次是格式SKILL.md 文件头部的 YAML 元数据必须至少包含name和description如果这两项缺失很多工具会直接跳过该文件。最后是重启很多工具在启动时才加载技能目录修改配置后不重启等于白改。排查顺序我建议是先执行/skills看列表再检查配置文件路径最后确认 SKILL.md 语法。把这三步做完90% 的“找不到技能”都能解决。4.2 技能执行到一半中断怎么办技能文档是一步步指引模型执行但执行过程中仍可能因为对话上下文太长或外部命令失败而中断。我遇到过最典型的场景是用 TDD 技能写测试时AI 连续跑了多次测试命令输出结果把上下文塞满然后它突然停下来告诉你“上下文不够了”。处理思路分两步。第一优化任务粒度不要在一个对话里让 AI 同时处理十个小任务拆成多次对话效率反而更高。第二如果是测试工具本身报错导致的流程中断先检查测试命令能否在终端中独立运行排除环境问题后再让 AI 重试。注意superpowers 本身不会替你执行终端命令它只是把“应该怎么做”告诉 AI真正的执行还是靠 AI 的工具调用能力。4.3 自定义技能容易踩的格式坑我看到太多人热衷于自己写技能结果写出来 AI 完全不触发。最典型的问题是 description 写得太模糊。比如你写“用于优化代码”模型就很难判断什么时候该用改成“当用户请求优化现有函数的性能时使用重点关注循环、重复计算和不必要的请求”就有效得多。还有 front matter 的引号和冒号中英文混用也是大坑。YAML 对中英文标点要求很严格一个中文冒号就可能导致整个文件解析失败。我的建议是写完后打开编辑器看有没有 YAML 语法高亮报错或者直接运行一个简单的解析脚本验证一下。4.4 一张速查表解决绝大多数问题现象可能原因快速解决技能列表为空目录配置错误或技能文件缺失检查 CLAUDE_CODE_SKILLS_DIR 环境变量与目录是否存在列表有技能但调不起来description 写得太泛精简并明确触发条件重启工具技能执行不规范正文步骤不够具体对照 superpowers 自带技能补全步骤自定义技能不生效YAML 语法错误检查冒号、引号是否中英文混用多项目技能串了全局技能目录包含所有仓库用项目级 .superpowers 目录隔离升级后自定义内容丢失技能目录跟仓库在同一个目录把自定义技能放独立目录避免被覆盖这张速查表是我自己用的现在基本踩过的坑都能在上面找到对应项。你如果遇到表里没有的问题优先看官方仓库的 Issues很多时候社区里已经有人给出解决方案了。5. 从“能用”到“好用”我的 superpowers 使用心得与扩展思路5.1 我最常用的三个技能组合用了一段时间后我总结出一套个人高频工作流接到新需求先brainstorming出方案再用planning拆解任务开发过程中穿插tdd和code-review。这套组合看起来基础但它是目前我用下来最稳的。举个真实例子有次我需要在老项目中加一个缓存模块。我没直接让 AI 写代码而是先让它用 brainstorming 给三种缓存策略做对比它很快列出了本地内存、Redis、进程级缓存各自的适用场景和风险。我选定方案后它又用 planning 把模块拆成接口定义、核心实现、单元测试、接入调用几个阶段。整个过程中 AI 的输出不再是零散代码片段而是一条能落地的执行路线。5.2 怎么写一个团队专属技能superpowers 最有价值的地方是它给你提供了一个模板你完全可以照葫芦画瓢写自己的团队规范。比如前端团队可以把代码提交规范、命名规范、组件设计规范写进一个frontend-standards技能里后端团队可以把日志规范、异常处理规范写成一个技能。我建议从高频重复场景开始不要一上来就想做一个覆盖所有开发流程的“超级技能”。先拿一个小场景写三到五条检查项放在项目技能目录里试用跑通之后再逐步增加内容。团队所有人都能从这个技能文档里获得一致的标准远比把规范放在人家记不住的 Wiki 里有效。5.3 把 superpowers 融入团队协作流程如果你所在团队已经建立了比较完善的代码评审和发布流程可以把 superpowers 的技能和这些流程接上。比如在提交 Merge Request 之前要求 AI 先跑一遍 code-review 技能输出问题清单在发布之前让 AI 跑一遍安全检查技能防止密钥泄漏或依赖漏洞被忽略。我觉得这里最大的价值不是让 AI 替代人工而是把重复性、机械性的检查自动化让人把时间集中在真正需要判断力的地方。superpowers 作为一个开源项目给了每个团队一个低成本把经验沉淀到 AI 工作流里的机会。最后再分享一个小技巧我建议你在项目根目录创建一个SKILLS.md索引文件把自己最常用的十几个技能以及触发场景写进去。当 AI 读到这个文件后它在整个项目上下文里都能更好地判断什么时候该调用哪些技能。这算是我折腾 superpowers 以来收获最大的一条经验也希望你今天装上之后能少走点弯路。