我最早注意到“skills”这个概念还是在逛 GitHub 的时候看到某个开源仓库的 README 写着“Superpowers for Claude Code”。当时第一反应是这不就是给 AI 写的一套“技能包”吗后来自己动手装了几个、写了一个、又给朋友排了几个坑才意识到这东西正在悄悄改变我们用 AI 编程的方式。简单说skills 就是给 Claude Code、Codex、OpenCode 这类 AI 编程工具准备的“专项能力包”。你把它放进指定目录AI 就能在对应场景下自动加载对应的操作流程、代码模板、检查清单相当于给通用大模型装上了“岗位说明书”。这篇文章不聊概念只聊实操怎么从 GitHub 手动装怎么写自己的 skills数学建模、前端、AI 漫剧这些场景哪些技能包最好用以及我踩过的那些坑。适合正在用 AI 编程、又觉得默认行为“不够专业”的人。1. 先搞清楚skills 到底是什么东西1.1 一句话定义和类比如果让我用一句话向朋友解释 skills我会说它是给 AI 的“SOP 文档”加“操作工具箱”。大模型本身什么都知道一点但“知道”和“会干活”之间隔着一条鸿沟。比如你让 Claude Code 帮你写一个 React 组件它会写但大概率写出来的东西没有遵循你团队的文件命名规范、没有统一的状态管理方案、也没有按你们习惯的注释风格。你反复纠正它它下次又忘了。skills 解决了这个问题。它本质上是一个目录里面放一个SKILL.md说明文件外加可选的参考文档、脚本和模板。当 AI 检测到当前任务匹配某个 skill 的描述时就会自动读取这份说明按照你定好的规则来干活。类比一下普通对话是“临时找来的实习生”装好 skills 的 AI 是“入职培训过三个月的正式员工”。1.2 为什么突然火起来Superpower Skills 现象大家搜“skills”的时候一定绕不开一个词superpower skills。这是社区里一个非常出名的技能包合集最初火起来就是因为作者把大量 ChatGPT 时代积累的 prompt 工程技巧、工作流模板全部转成了 Claude Code 的 skills 格式。为什么它这么受关注因为此前大家用 AI 写代码靠的是“临时对话调教”——每次都要在对话里写一堆背景、规则、示例费 token 不说效果还不稳定。Superpower Skills 这类项目把“调教”变成了“安装”你只要把技能包拖进目录AI 就自动具备了某种稳定能力。后来很多团队开始跟进逐渐形成了三个方向的生态通用技能库大而全、垂直领域技能包只做一件事、个人定制技能你自己写的。到这一步skills 已经不只是一个技术概念而是变成了一种“AI 能力分发”的方式。你可以把 skills 理解为 AI 时代的“插件市场”只不过目前这个市场还处于“大家各自摆地摊”的阶段。1.3 skills、MCP、提示词三者之间的关系新手最容易搞混的是 skills、MCPModel Context Protocol和普通提示词。我帮你在概念上理清维度skillsMCP普通提示词本质一套文档 可选脚本一种工具调用协议一段指令文本解决什么问题让 AI 按特定流程/标准干活让 AI 连接外部数据和服务临时告诉 AI 怎么做是否持久持久生效按需自动加载持久提供工具能力仅当次对话生效类比员工培训手册公司的各种系统接口老板口头交代一下一个完整的 AI 编程工作流里三者其实是配合的MCP 负责给 AI “接上外部系统”的能力比如查数据库、调 APIskills 负责给 AI “流程规范”的能力比如按某个规范写后端接口提示词则是在具体对话里做临时补充。之所以先说清楚这个区别是因为后面安装和编写 skills 时你会反复遇到“这个技能不生效”的问题——很可能不是 skill 写错了而是它压根没被触发或者和 MCP 工具冲突了。2. 从 GitHub 手动装 skills保姆级实操2.1 Claude Code 的 skills 目录到底长什么样我以 Claude Code 为例因为它的 skills 机制目前最完善社区资料也最多。装之前先找到你的 skills 目录全局目录所有项目可用~/.claude/skills/项目级目录仅当前项目.claude/skills/如果没有这个目录手动创建就行。目录结构如下~/.claude/skills/ ├── code-review/ │ ├── SKILL.md │ └── rules/ │ └── review-checklist.md ├── frontend-react/ │ ├── SKILL.md │ └── templates/ │ └── component.tsx └── latex-writing/ ├── SKILL.md └── scripts/ └── format_check.py每个子目录就是一个完整的 skill。关键点是那个SKILL.md文件AI 靠它的文件名和元信息来识别这个技能。没有这个文件的目录AI 会完全无视。2.2 手动安装的两种方式git clone 和环境变量从 GitHub 装一个 skill我试过几种方式最直接的就是git clone进目录# 安装全局 skills cd ~/.claude/skills git clone https://github.com/某个用户/某个技能仓库.git # 如果仓库里有子目录把子目录复制进来 cp -r 某个技能仓库/skills/xxx-skill ~/.claude/skills/有些仓库结构比较特殊比如superpower skills这类大型合集clone 下来后根目录可能不是 skills 的格式需要你手动把里面的子模块复制到指定位置。这时候我一般用第二招修改环境变量让 Claude Code 去读额外的目录。# 在 ~/.bashrc 或 ~/.zshrc 里设置 export CLAUDE_SKILLS_DIRS/path/to/你的技能库:/path/to/另一个技能库这个环境变量是你自定义的 skills 搜索路径多个路径用冒号分隔。设好之后重启终端AI 就能在原有基础上额外加载这些目录里的技能。我强烈建议用环境变量而非把所有人的技能都堆进~/.claude/skills/因为你装得越多AI 误触发其他技能的概率越大管理成本越高。2.3 常用 skills 源网站和仓库推荐接下来是大家最关心的“去哪里找”。目前还没有一个类似 npm 一样统一的官方市场但几个主流渠道已经形成GitHub 直接搜claude skills或codex skills最可靠能看到源码也能知道维护是否活跃。awesome-claude-skills 这类聚合仓库社区有人维护推荐清单适合起步。各类 AI 编程工具官方文档的 skills 页面Claude Code 官方文档里对 skills 格式有规范说明最好先看一遍。TypeSafe AI Skills 这类组织仓库不少企业级团队已经把内部沉淀的技能开源格式规范说明文档齐全适合当作学习范本。我个人的筛选标准就三条一看最近提交时间超过半年没更新的直接 pass二看SKILL.md里的 description 写得好不好用中文混杂、描述含糊的说明作者自己都没想清楚三看有没有配套的脚本和测试。一个只写了概念说明没有可执行脚本的 skill大概率是“纸老虎”。2.4 装完怎么确认生效装完之后第一件事就是验证。我常用的方法是打开 Claude Code直接输入一句和该技能场景相关的指令比如刚装完code-review技能就让 AI “review 一下当前分支的改动”。如果 skill 生效AI 的输出里会带上明显的步骤痕迹比如“根据 code-review 检查清单我先逐项核对”。注意有个容易误判的地方AI 提到“我可以用某个技能”不等于“已经加载了该技能”。有时候它只是根据对话内容猜你希望它用某个技能。真正可靠的验证方式是看SKILL.md里的关键指令是否体现在输出中。比如技能里定义了“每个 review 建议必须标注严重级别” AI 输出没标那大概率是没加载成功。3. 动手写第一个 skillAI skills 开发入门3.1 SKILL.md 的结构和格式规范光会安装不算本事能自己写才算入门。我拆解一个最小的SKILL.md给你看--- name: frontend-code-review description: 在前端项目 review 代码时使用重点检查 React 组件性能、状态管理和可访问性 --- # Frontend Code Review 执行代码审查时必须遵循以下步骤 1. 先阅读项目的 package.json确认技术栈和依赖版本 2. 按顺序检查props 类型定义、组件渲染性能、Hooks 依赖、a11y 属性 3. 每条建议必须给出问题代码位置、风险等级高/中/低、修改后的代码片段 ## 禁止事项 - 不要只给批评不给方案 - 不要建议引入未安装的第三方库 - 不要忽略现有代码风格约束 ## 核查清单 - [ ] state 更新是否有不必要的重复渲染 - [ ] 事件处理是否做了防抖/节流 - [ ] 图片是否懒加载先看最上面的 YAML frontmatter两个字段是关键name和description。description写得好不好直接决定技能能不能被触发它是 AI 判断“当前任务是否匹配该技能”的依据。建议写成“当……时使用重点做……”这种格式准确率最高。正文就是给 AI 的“操作 S.O.P.”用 Markdown 写。你可以写步骤、规则、示例、禁止事项。AI 会把它当权威规范来执行。早期我犯过的错误是把这里的文字写得像“建议”AI 就当成了参考意见执行起来完全看心情。要用祈使句、规则式语言不要用商量语气。3.2 写 description 的技巧决定你的技能会不会被触发这是整个 skill 开发里最重要、也最容易被忽视的部分。我见过很多人费半天劲写了技能内容结果 description 就一句话“用于代码审查”结果 AI 从来不在正确的场景触发它。description 触发有几个原则主语要明确直接写“review 代码时”比“进行代码质量检查”触发率高。包含触发场景的动词“在创建 React 组件时”、“在排查网络请求报错时”、“在计算数学模型的灵敏度分析时”——这些动词给 AI 提供了明确的触发锚点。注明使用的具体对象如果技能只针对 Vue 项目就写明 “Vue 3 TypeScript”否则 AI 可能把它用在 React 项目上。自定义变量部分实现支持在 description 中用{variable}占位让 AI 在触发时动态填充上下文比如审查 {file_path} 中的安全漏洞。我用一个经验值来形容如果你写完 description 后自己读一遍都觉得“这个描述像给搜索引擎写的关键词”那就对了。太抽象、太宽泛的描述等于没写。3.3 支持脚本和参考文档让 skill 不只是“纸面规则”只含SKILL.md的 skill 能做的事有限。当你需要 AI 跑某种自动化检查或者查某些固定的知识内容时就应该给 skill 配上脚本和参考文档。我自己写过一个数学建模用的 skill目录结构是这样的~/.claude/skills/math-modeling/ ├── SKILL.md ├── references/ │ ├── model-selection.md │ └── sensitivity-analysis.md └── scripts/ ├── check_data.py └── format_table.pySKILL.md里定义主流程references/放参考资料AI 在需要时自行读取scripts/放可执行工具AI 通过命令行调用。比如check_data.py就是一个检查数据是否缺失、格式是否统一的脚本建模前先让 AI 跑一遍。这里有个安全提醒AI 会执行 skill 中的脚本所以不要随便装网上的技能包尤其那些要联网下载东西的。我见过有技能包里带了一串 curl 命令下载某些二进制你的机器就等于把执行权交了出去。装技能就跟装软件一样先看许可证、再看内容、确认没有可疑命令再上。实在有顾虑就建个独立容器或虚拟机来跑。3.4 从零写一个前端开发 skill 的完整案例为了让你有直观参考我贴一个我实际在用的前端组件生成技能的核心部分--- name: vue3-component-generator description: 创建 Vue 3 组件时使用按团队规范生成带完整测试和文档的组件 --- # Vue 3 组件生成 当需要创建新的 Vue 3 组件时遵循以下规范 ## 1. 目录与文件约定 - 组件目录放在 src/components/{组件名}/ - 必须包含 {组件名}.vue、{组件名}.spec.ts、README.md 三个文件 - 组件名使用 PascalCase ## 2. 组件模板 vue script setup langts // 必需defineProps 全部使用 type 声明 // 必需事件通过 defineEmits 声明 /script template !-- 根节点必须保留且带>