AI编程技能包Skills全解析：从安装到实战，提升AI编程效率

我最早注意到“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、MCP（Model Context Protocol）和普通提示词。我帮你在概念上理清：

一个完整的 AI 编程工作流里，三者其实是配合的：MCP 负责给 AI “接上外部系统”的能力（比如查数据库、调 API），skills 负责给 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. 动手写第一个 skill：AI 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.py

SKILL.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 lang="ts"> // 必需：defineProps 全部使用 type 声明 // 必需：事件通过 defineEmits 声明 </script> <template> <!-- 根节点必须保留，且带>