GitHub 上的“Skills”这几年被玩出了新花样，尤其是在 AI 编程助手圈子里，这个词已经不完全是我们常说的“技能栈”或者“软技能”了。现在很多人聊的 skills，指的是给 Claude Code、Codex、OpenCode 这类工具装上的一种“外挂能力包”——让 AI 不只是能聊天，还能直接调用某个领域的完整方法论、工作流，甚至帮你干完一整条流水线的活。
我最早接触这个玩法也是一脸懵，GitHub 上一搜 skills，出来的仓库几百个，有的叫 superpowers，有的叫 codex-skills，有的叫 cola，根本分不清谁是谁。后来自己装了几个、也手写了不少，才算理清楚这套东西的门道。这篇文章我就从一个实际动手折腾过的人角度，把“skills 到底是什么、怎么装、怎么写、怎么用”完整拆开讲一遍。适合想给 AI 编程工具提效的开发者，也适合正在准备数学建模、AI 漫剧这类特定场景项目、想用 skills 把重复劳动压缩掉的朋友。
1. 先搞懂 skills 到底是什么，别把概念玩混了
1.1 Skills 的本质是一份“可复用的能力说明书”
先说人话：一个 skill 本质上就是一个文件夹，里面有一份SKILL.md文件作为入口，配上一些参考文档、代码模板、脚本，甚至是一整套操作规范。AI 编程助手在执行任务的时候，会根据你写的提示词自动去匹配这个 skill，然后按照里面的说明来“调取相关知识、按步骤干活”。
你可以把它理解成给 AI 写了一份工作手册。平时你让 AI 帮你写一个 React 组件，它靠的是预训练的通用知识；但你让它“按照公司前端规范、用某个组件库、带测试和 Storybook 文档”地完成一整个需求，通用知识就不够用了。而 skill 做的事情，就是把“公司规范 + 组件库用法 + 测试要求 + 文档格式”全部封装进一个文件里，AI 一旦命中这个 skill，就会按你写的流程来执行。
从安装形态上看，主流的 AI 编程工具都支持通过“项目目录下的.claude/skills、.codex/skills或者.opencode/skills”这种隐式约定来加载。你从 GitHub 上把别人做好的仓库 clone 下来，放进对应目录，重启工具，就装好了。部分工具还支持通过命令行/skills直接查看和切换已安装的技能，相当于给 AI 助手做了一次“能力插拔”。
1.2 它和 prompt、插件、MCP 有什么区别
很多人一上来就会问：skills 不就是个提示词吗？我自己在 prompt 里写一段话也能达到类似效果，凭什么要单独搞个文件夹。差别其实挺大的。
Prompt 是“一次性”的。你写进 conversation 窗口里的提示词，AI 看得到，但它往往只在那一次对话里起作用，而且对话一长、上下文一挤，这些规则就容易被冲淡。而 skills 有更稳定的“视野”，它是在项目上下文层面被加载的，AI 在规划任务的时候就能感知到“这里有对应的 skill 可用”。两者像什么呢？Prompt 是你在开会前给临时工口头交代了两句，skills 是你给正式员工发了一本员工手册，前者靠脑子记，后者靠制度管。
插件和 MCP 解决的是“AI 能不能调用外部工具”，比如读数据库、调 API、操作浏览器。而 skill 解决的是“AI 知不知道活儿该怎么干、按什么标准干”。一个是手脚，一个是大脑里的知识库和流程库。实际项目中两者互补，但如果你只是想约束 AI 的输出质量和流程，skills 往往是最轻量、门槛最低的方案。
1.3 为什么最近这东西突然火了
以前我们调教 AI 全靠“在世界里写规则”，要么写一大段 system prompt，要么把工作流塞进项目文档。但这样做有两个问题：一是项目一复杂，这些规则就和业务代码混在一起、维护成本很高；二是不同的项目往往需要不同的规则，把全部规则塞进一个 prompt 里，又臭又长、还互相干扰。
skills 之所以能火起来，是因为它把“规则”做成了模块化、可插拔、可分享的东西。你想让 AI 帮你做前端开发，就装一个前端 superpower；你要参加华为杯数学建模，就装一个建模专用 skills 包；你在做 AI 漫剧，就装一个漫剧分镜脚本生成技能。写完一个高质量的 skill，还能传到 GitHub 上让整个社区复用，这很像当年“Vim 插件化”或者“VS Code 扩展生态”走过的路——一旦形成“库”，生态就活了。
2. 怎么手动安装 GitHub 上的 skills，三种主流工具都给你捋一遍
2.1 Claude Code 的手动安装路径
我先说 Claude Code，因为它的生态现在最完整，GitHub 上的很多 skills 也都是优先适配它的。安装的核心动作就是把仓库内容复制到指定目录，具体路径是：
~/.claude/skills/不同项目也可以放在项目的.claude/skills/目录下，这样只有当前项目能用到，适合团队内部共享规范。从 GitHub 手动装一个 skill 的流程我建议这样来：
# 1. 找到目标仓库，比如 tibo 的清理技能库 git clone https://github.com/xxx/skills-repo.git # 2. 进入仓库，看它的目录结构 cd skills-repo ls -la # 3. 找到真正包含 SKILL.md 的那个文件夹 # 假设它叫 cleanup-skill，复制到 Claude 的全局 skills 目录 cp -r cleanup-skill ~/.claude/skills/ # 4. 重启 Claude Code，输入 /skills 查看是否加载成功有几点实际操作中很容易踩坑，我单独拎出来说：
- 别把整个仓库一股脑全复制过去。很多仓库是“全家桶”，里面包含几十个 skill，全部复制进去会导致每次 AI 做意图识别的时候开销变大、甚至出现多个 skill 互相抢优先级的情况。我一般只挑当前真正用得上的。
- 注意仓库内如果还有嵌套的
skills/子目录，复制的时候要把那一层结构保留好，只复制最外层包含SKILL.md的目录，再往下的子目录不要动，AI 需要按相对路径去读取附件。 - 装完之后一定要重启终端或者重启 AI 会话，这个动作经常被忽略，结果装完了半天实际没生效，然后就开始怀疑人生。Claude Code 对 skills 目录的扫描是启动时做的，不重启就不会刷新。
2.2 Codex 和 OpenCode 的安装方式
Codex（主要指 OpenAI 的 Codex CLI 工具）现在也有自己的 skills 支持。它的思路是把 skills 放在~/.codex/skills/目录下，然后在config.toml里声明启用。安装命令差不多，只是目标目录换成：
cp -r xxx-skill ~/.codex/skills/然后编辑配置文件：
[skills] enabled = true注意 Codex 的 skills 规范目前和 Claude Code 大体相似，但部分 frontmatter 字段有细微差别，比如有的工具认name、有的要allowed-tools。安装前最好看一眼仓库 README 里写没写“Compatible with Codex”之类的说明，不然装进去可能识别不了。
OpenCode 是另一个很受命令行爱好者欢迎的 AI 编码工具，它的 skills 目录一般在~/.opencode/skills/，也支持项目级的.opencode/skills/。OpenCode 的优势在于配置文件比较直白，装完之后直接在 TUI 里用/skills就能触发选择器，体验很流畅。
2.3 装完之后先做“冒烟测试”
不管用哪个工具，我强烈建议装完 skill 后先做一次冒烟测试，不要直接一头扎进正式任务里。测试方法很简单：打开你的 AI 工具，输入类似“请列出你现在可用的 skills，并说明每个 skill 的适用场景”的指令，看它能不能准确说出刚装的那个技能。
如果它说不出来，别急着怀疑 skill 本身有问题，先检查这几个地方：
- 路径是不是放对了？大小写有没有写错？
- 目录名是不是和 SKILL.md 里的
name字段对应？ - 终端是不是重启过了？
- 如果是团队项目，是不是被项目级的
.gitignore把 skills 目录排除了？
我经历过最无语的一次就是把 skill 放在了~/.calude/skills/这种手误路径下，结果 AI 一直加载不到，排查了快二十分钟才发现是拼写错了。
3. 手把手教你写一个自己的 skills，前端、建模、漫剧场景通吃
3.1 SKILL.md 的结构与 frontmatter 写法
写一个 skill 没有想象中那么难，核心就是写好SKILL.md。这个文件由两部分组成：YAML frontmatter和Markdown 正文。
Frontmatter 是文件的“元信息”，我们拿一个最简单的例子来看：
--- name: frontend-review description: 用于前端代码审查，专注于 React 组件性能优化和可维护性。当用户要求 review 前端代码或优化组件性能时使用。 ---name是技能的唯一标识，description必须在开头就写清楚触发条件，因为 AI 主要就是靠读 description 来决定要不要调用这个 skill 的。很多人写 description 写得太模糊，比如“用于前端开发”，结果 AI 在几乎所有任务里都想用它，互相打架，效果反而差。
正文部分用中文或英文写皆可，但结构一定要清晰。我习惯的分段方式是：背景与目标→核心原则→执行流程→输出规范→参考示例。前面两段是告诉 AI“为什么存在这个技能”，中间是“怎么干”，后面是“干完要交什么活”。
这里有个很关键的细节：SKILL.md 尽量不要写成一本“百科全书”，信息量太大会导致 AI 读取的时候吃掉大量上下文。正确做法是正文里只写精炼的操作规范和流程，把真正的大块头内容（比如设计规范 PDF、模板代码、数据字典）放到同目录下的附件的文件里，在 SKILL.md 里用相对路径引用。AI 只有在需要的时候才会去读取附件，这样可以省下大量 token。
3.2 一个数学建模 skill 的实际拆解
华为杯、国赛这类数学建模比赛，其实非常适合用 skills 来提效。很多参赛队其实没意识到，建模工作流里有大量“套路化”的环节：数据预处理、探索性分析、模型选型、论文排版，这些几乎每道题都要做一遍。把这些环节沉淀成一个 skill，比赛的时候就能省下大量时间。
我参考社区里比较受欢迎的数学建模 skills 包，给一个最小可用结构：
math-modeling-skill/ ├── SKILL.md ├── templates/ │ ├── paper_template.md │ └── code_template.py └── references/ ├── model_selection.md └── data_checklist.mdSKILL.md里我会写明：拿到一道建模题后，第一步做数据清洗与缺失值检查、第二步做探索性可视化、第三步按题目类型（评价类、预测类、优化类）选择模型、第四步按模板撰写论文。这样 AI 就不需要“临场发挥”，而是像一个熟练的队员一样知道整个流程的先后顺序。
3.3 前端开发和 AI 漫剧场景的 skills 怎么写
前端方向，社区里最有名的思路之一是“superpower skills”，它强调的是把各种前端工程化的最佳实践拆成你可以直接给 AI 用的能力模块。比如我写过一个用于 React 性能优化的 skill，description写的是“当用户想要优化 React 组件渲染性能时使用，重点解决重复渲染、useEffect 依赖错误、大列表渲染卡顿问题”。正文里整理了 React.memo 的使用边界、useCallback 和 useMemo 的适用场景、React Profiler 的分析步骤。实测下来，AI 在接这类优化任务时输出变得非常稳定，不会东扯一句西扯一句。
AI 漫剧的 skills 就更有意思了。漫剧制作本身是一条完整流水线：剧本创作、分镜脚本、角色设定、画面提示词生成、配音文案、后期剪辑建议。哪怕是一个人在家做漫剧，也得把这几个环节全部跑一遍。把这些环节写进一个 skill 之后，你只需要说出故事梗概，AI 会按照 skill 里的流程一步接一步输出，省去了反复“引导 AI 理解业务”的时间。这种 skills 的核心是把“工作流”这种隐性知识显性化，它带来的效率提升往往是倍数级的。
3.4 写 skill 时最容易犯的四个错误
第一，description 写得像“简历”。我见过有人写“这是一个功能强大的技能，可以帮助用户解决很多问题”，没有任何实际触发词。AI 不是人，它不会去猜你的意思，它只看关键词匹配。写清楚触发条件，什么场景下用，比写一百句赞美词都强。
第二，一切都要 AI “自由发挥”。skill 是用来约束 AI 行为的，不是用来放飞它的。你写“请做出好看的视觉设计”这种话就等于没写，AI 依然会凭感觉来。比较好的做法是给明确标准，比如“正文字号不小于 14px、按钮圆角 8px、主色 #2563eb”。
第三，附件引用路径写错。我踩过一次，在 SKILL.md 里写了./attachments/report_template.docx，结果实际目录叫attachments/，文件在templates/下，AI 根本读不到附件，最后输出一份没按模板来的报告，前功尽弃。写完路径一定要自己验证一遍。
第四，不考虑“上下文预算”。SKILL.md 里放一个 10 万字符的 PDF 规范文档，AI 每次调用都要读，结果对话还没进入正题，上下文窗口就快满了。正确做法是：规范文档作为附件按需调用，SKILL.md 本身保持精炼。
4. 常用 skills 推荐清单：前端、建模、清理、漫剧，一次给你配齐
4.1 前端开发场景：superpower skills 和 typesafe ai skills
前端领域现在口碑比较稳的两个仓库，一个是superpower skills，一个是type-safe ai skills。前者主打“给 AI 装配超级工作流”，里面包含 React、Next.js、样式系统、状态管理等多个细分技能包；后者则更偏向 TypeScript 工程化，包含类型安全、API 设计约束、代码审查规范等。
我的建议是不要全套照搬，而是按需摘取。比如我只需要前端 review 能力，就从 superpower 里把frontend-review那个目录拿过来单独安装。这样既不影响其他任务的意图识别，又能精准控制 AI 的行为。
4.2 数学建模场景：几个高校团队维护的高质量技能包
每年华为杯前后，GitHub 上都会出现一批数学建模 skills 仓库，大多是往年参赛的学生团队把自己备赛过程沉淀下来的。内容包括数据预处理模板、常用模型对照表（回归、分类、聚类、时间序列）、论文写作框架等。这些仓库的普遍特点是“实战性强”，因为作者是真的拿它们在比赛里验证过的。
不过坑也比较多，很多仓库是临时建来交作业的，质量参差不齐。挑选的时候我建议看三个点：一是看更新时间，尽量选最近三个月内还在维护的；二是看 README 里有没有配使用说明和示例输出，配了的说明作者认真；三是看 SKILL.md 的 description 写没写清楚触发场景，写着“适用于各种建模任务”的基本可以先跳过。
4.3 系统清理和杂物管理：tibo 的清理方法论
热词里提到的“tibo 关于清理 skills 的方法推荐”，指的是一位叫 tibo 的开发者做的一套“系统清理与文件整理”技能包。它的核心思想不是简单地“删除垃圾文件”，而是按照“识别 → 分类 → 处置”的流程，把电脑里的冗余文件、重复下载、临时缓存统一治理。
我装过这套技能，里面最有价值的一个子技能是“项目目录瘦身”，它会让 AI 先扫描项目里的大文件、node_modules 磁盘占用、日志堆积情况，再给出清理建议。相比自己手动清理，这个技能最大的好处是“有章法”，AI 会先生成报告让你确认，再进行删除操作，不会误伤重要文件。
4.4 AI 漫剧和视频创作方向的技能包
漫剧类 skills 相对小众，但做的人输出的东西往往很实用。常见的子技能包括：分镜脚本生成（按景别、时长、台词、画面描述列成表格）、角色一致性设定（记录角色外貌特征、服装、性格关键词，保证后续画面提示词的连贯性）、画面提示词排版（针对 Midjourney 或 SD 的正向负向提示词模板）。
这类技能包装完之后，最大的感受是“AI 的产出终于不是黑箱了”。以前让它生成漫剧脚本，经常东一榔头西一棒槌；装上分镜生成技能后，它会一步步给你场景表、镜头表、台词表，后续做视频剪辑时只需要照着表格执行就行。
5. 常见问题与排查技巧实录
5.1 装了 skills 但 AI 完全没反应，先检查这四点
这个问题我在社区里被问过无数次，自己也踩过。经验下来，百分之九十的情况出在四个地方：
一是目录位置不对。不同工具有不同的默认目录，最常见的是把 Claude Code 的 skills 装到了 Codex 的目录里，两边各自认各自的，装错自然无效。
二是 SKILL.md 文件名大小写不对。Linux 和 macOS 的文件系统默认区分大小写，skill.md和SKILL.md是两个文件。AI 解析器找的是标准命名，名字不对就直接忽略了。
三是 AI 工具没有重启。前面反复强调过，这部分不能再多说了，就是不重启等于白装。
四是描述触发词和你的任务描述不匹配。比如你的 skill 描述里写的触发词是“前端代码审查”，你实际对话时说“帮我看看这段代码”，AI 没有建立起关联，自然不调用。改进方式是在描述里多写几个同义触发词。
5.2 多个 skills 互相打架怎么办
当你装了几十个 skills 之后，会遇到一个新问题：AI 觉得好几个技能都能处理当前任务，结果同时启用了，输出风格混乱、规则互相冲突。这个问题的根源不是 AI 笨，是技能之间的边界没划清楚。
解决思路有两个方向。第一个方向是从源头控制数量，只保留当前项目真正需要的技能，把暂时用不到的移出目录。第二个方向是优化每个 skill 的 description，强化“什么时候不该用”。比如某个专用技能描述里可以写明“仅当用户明确要求执行 XX 操作时使用，其他通用代码任务请勿调用”。
5.3 我在实际使用中的一点体会
最后说点掏心窝的话。Skills 这个东西的门槛真的不高，哪怕你完全不懂编程，也能按照模板写出一份像模像样的 SKILL.md。但它的上限很高，高到你给 AI 定义的能力边界越清晰、工作流越完整，AI 产出的稳定性就越强。这就像带新人——你只丢给他一句话，他做事全靠猜；你给他一套 SOP、几个模板、几条红线，他交付的水平立刻就不一样了。
我个人现在工作里的习惯是：每次完成一个有点重复性的任务，就顺手把它沉淀成一个 skill 存起来。一个月下来，等于给自己攒了一个懂行的 AI 专属助手团队。这种积累的感觉很好，推荐你也试试。不用追求一次写得多完美，从 15 分钟的“小技能”开始，慢慢迭代，你会看到自己的 AI 工具越来越好用。
