最近社区里聊 skills 聊得特别热闹，前端开发 skills、superpower skills、AI skills 怎么写这些热词到处刷屏，连数学建模比赛和 AI 漫剧圈都在找好用的 skills。Claude Code、Codex、OpenCode 这几个主流编程助手现在都支持这种玩法，很多人还专门整理了常用 skills 源网站清单，GitHub 上相关的技能库也越收越多。这套东西到底值不值得花时间研究，装完之后怎么用、怎么写、怎么清理，我按自己实际折腾过的经验从头到尾捋一遍。

先把话说清楚：skills 不是啥玄学，就是给大模型编程助手的一套“岗位说明书”。默认情况下你问 Claude 或 GPT 改代码，它懂通用编程，但不懂你的项目规范、不懂华为杯论文的排版套路、也不懂 AI 漫剧的分镜节奏。给它塞一个 skill，就等于临时给它补了一节专业课，让它按你提前写好的规则去思考和执行。这比每次对话都手打一长串提示词要稳定得多，也快得多。

我在自己常用的几个工具上都装过、写过、删过 skills，下面按“是什么、怎么装、怎么写、怎么选、怎么管、出了问题怎么排”的顺序，把完整流程和踩过的坑都写出来。

1. 先搞清楚：skills 到底是什么，为什么一夜之间这么火

1.1 用“浏览器插件”的思维去理解 skills

你平时用浏览器肯定装过插件，比如翻译插件、广告拦截插件。浏览器本身是个通用工具，插件给它加上了“外挂能力”。skills 对大模型编程助手做的事一模一样：Claude Code 是一个通用代码助手，装上某个 skill 之后，它就额外懂得怎么处理某类特定任务。

拿我自己试过的一个例子来说。我写过一个小型的前端代码审查 skill，里面规定了审查顺序：先看组件拆分，再看状态管理，最后查边界条件。没装之前，让助手审查代码，它想到哪儿看到哪儿，经常揪着格式化问题不放，真正致命的逻辑漏洞反而漏掉。装上之后它按我写的步骤执行，每一次审查顺序都一样，稳定性提升非常明显。

所以 skills 解决的核心问题不是“让模型变得更聪明”，而是“让模型的行为更可预期”。模型底层能力就那么强，但怎么调用、按什么顺序调、输出什么格式，这些都可以通过 skill 来约束。

还有一个很容易忽略的点：skills 不是每个人都必须用的功能。如果你只是随手让助手改几行代码，不装任何 skill 也没问题。但只要是重复性的复杂任务，比如每周做一次代码 Review、每次建模都要出摘要和可视化、每集漫剧都要保持角色一致，那 skills 就非常值得用。

1.2 一个 skill 的完整生命周期

一个 skill 从诞生到退休，大概走这么几个环节：编写、安装、加载、执行、清理。

编写指的是写一个 SKILL.md 文件，这个文件是 skills 的核心载体。安装是把它放进工具指定的目录，比如 Claude Code 是.claude/skills/<技能名>/SKILL.md，OpenCode 是.opencode/skills/下。加载发生在每次新对话开始时，助手会扫描目录自动加载索引。执行就是对话中触发这条 skill，开始按规则干活。清理则是删除不再用的 skill，避免互相干扰。

这里面最容易踩坑的是加载机制。不同工具加载的程度不一样，有的会把每个 skill 的完整描述都塞进上下文，有的只扫描文件名和 description 字段。如果你发现装了 skill 但是助手表现跟没装一样，大概率是加载这环出了问题，后面第 6 章我会细讲排查方法。

理解了生命周期，再看 GitHub 上那些标题带 skills 的仓库就不会懵了：它们大多是某个作者把自己日常用的技能文件整理成了可复制的目录结构，下载下来放到对应目录就能用。本质上就是一套现成的“岗位说明书”。

2. 怎么把别人写好的 skill 装进你的工具里

2.1 先到哪找靠谱的 skills

前面说了 GitHub 是最大的 skills 集散地，但直接搜 “skills” 会搜出一堆无关结果，关键词得稍微组合一下。常用的搜索姿势有这么几种：

• 搜claude code skills或codex skills，能看到专门给对应工具做的技能集合
• 搜awesome skills或skills collection，能翻到社区整理的总目录
• 直接搜项目名，比如superpower skills、typesafe ai skills、cola skills，这几个都是被讨论得比较多的项目

我的习惯是按热度排序，然后点进去重点看三样东西：README 里的目录说明、SKILL.md 的实际内容、最近更新时间和 star 数。star 数只能参考，真正决定一个 skill 值不值得用的是前两样。

另外很多 skill 集合是英文的，如果你主要在中文环境用，装上之后最好自己把规则改成中文，否则助手产出的注释、命名风格可能跟你团队的规范对不上。这不是 bug，是描述文件本身带有的语言倾向。

2.2 手动安装的完整流程（Claude Code / Codex / OpenCode 通用思路）

先说明一点：市面上已经有一些自动化安装工具，但手动安装其实非常简单，而且能让你搞清楚文件结构。建议至少手动装一次，后面出了问题也好排查。

以从 GitHub 上克隆一个技能库为例，我常用的做法是：

# 选择一个目录存放技能库 mkdir -p ~/skills-repos && cd ~/skills-repos # 克隆你选中的技能库 git clone https://github.com/xxx/awesome-skills.git

然后进到克隆下来的目录里，看它的技能文件结构，一般是每个技能一个子目录，里面有个 SKILL.md。接下来根据你用的工具，把对应的技能目录复制到指定位置。

Claude Code 的项目级目录是：

# 在项目根目录下 mkdir -p .claude/skills cp -r ~/skills-repos/awesome-skills/code-review .claude/skills/

Codex 的写法稍微不同，它支持通过配置文件指定 skills 路径。OpenCode 则是把 skill 放在全局配置目录或者项目目录下，具体路径以它官方文档为准。复制过去之后重启会话，让助手重新扫描目录。

提示：复制时保持目录名和 SKILL.md 里的 name 字段一致，大小写都别马虎。目录名不一致在某些工具里会导致 skill 加载不出来。

2.3 怎么确认 skill 真的装好了

装完不是就完事了，一定要验证加载状态。我常用的验证方式有两种。

第一种是直接问助手：“你现在有哪些可用技能？”，大多数工具会把它扫描到的 skill 列表列出来。如果你刚装的那个出现在列表里，说明加载成功了。

第二种是触发式验证，更靠谱。根据 skill 的 description 字段里写的触发场景，故意给它一个对应任务。比如装了一个代码审查 skill，就丢一小段带 bug 的代码让它审查，然后观察它是不是按 skill 里的流程走。如果它回答得跟普通聊天一样，没按照你写的规则执行，那就是加载没生效。

我自己还习惯在刚装完 skill 之后先跑一次空会话，看日志里有没有读取 SKILL.md 的记录。有些工具在 verbose 模式下会打印加载了哪些 skill，这个信息对排查问题非常有用。

3. 自己动手写一个 skill：从框架到能用的完整示范

3.1 SKILL.md 的文件结构

写 skill 本质上就是写一个 Markdown 文件，但里面有几个约定俗成的规矩。最外层是 YAML 格式的 frontmatter，通常包含name、description两个字段，有些还会加上allowed-tools、version之类的扩展字段。

frontmatter 下面是正文，正文就是你希望模型严格执行的规则。写正文有几个基本原则：能用列表就别用长段落，模型对结构化的规则遵守度更高；每条规则说清楚“做什么+什么情况下做+别做什么”；尽量给出输入和输出的格式示例。

最核心的一条是 description 要写得“让人一眼就能触发”。你想想加载机制：模型得根据用户当前的问题，判断要不要启用某个 skill。如果 description 写得太宽泛，模型不知道该什么时候用；写得太窄，该触发的时候又触发了不了。我的经验是里面至少包含主关键词加具体场景，比如“审查”“重构”“代码质量”“PR 之前”。

3.2 实战：写一个“Python 小项目脚手架”skill

拿我自己写过的脚手架 skill 当例子，这个 skill 的作用是：当用户想要新建一个 Python 项目时，自动按指定目录结构、依赖分组、配置文件模板来初始化，避免每次手敲目录。

SKILL.md 的前半部分长这样：

--- name: python-scaffold description: 当用户要求新建一个 Python 项目、初始化项目结构、创建标准配置时使用。适用于从零开始的项目，包含 src 布局、pyproject.toml、lint 配置和测试目录。 --- ## 执行步骤 1. 询问项目名称与 Python 版本要求，若用户未做说明则默认 3.11。 2. 按以下结构创建文件： - src/<项目名>/__init__.py - tests/test_<项目名>.py - pyproject.toml - .gitignore - README.md 3. pyproject.toml 中把依赖分为 runtime、dev、test 三组，分别落在 [project] 和 [project.optional-dependencies]。 4. 全部文件生成完毕后，输出一段简短的启动命令说明，不少于 5 行。

这个 skill 写得很短，但实际效果很好。它的关键点在于使用了“默认值”和“明确步骤”：用户没说版本就默认 3.11，不会反复问；创建完输出后续命令，让整个流程闭环。

写完之后我把它放进.claude/skills/python-scaffold/目录，测试效果：输入“帮我新建一个 Python 项目，叫 demo”，它就开始批量创建文件，一次成型。

3.3 进阶：多文件技能包和参数设计

单个 SKILL.md 能承载的东西终究有限，复杂技能可以做成一个目录，里面除了 SKILL.md 再放几个辅助文件。比如代码审查 skill 可以放一个rule_snippets.md存各种反模式片段，放一个prompts.md存多种审查场景的提示模板。

路径引用在 SKILL.md 里用相对路径写就行，因为模型读到 SKILL.md 的时候，工具会给它标记当前文件所在的上下文目录。你在正文里写“参考./examples/bad_code.py”，模型能顺着路径读到对应文件。

参数化是进阶设计的另一个要点。你可以在正文里定义变量，比如“语言偏好：default 为 Python，支持 TS/Go”，执行的时候让模型先跟用户确认再继续。实操下来我觉得参数不要设计太多，三个以内最好，太多了模型容易顾此失彼。一个 skill 聚焦一件事，比一个 skill 干一堆事要可靠得多。

4. 按场景挑 skills：前端、数学建模、AI 漫剧各有各的刚需

4.1 前端开发：代码审查、组件生成、CSS 重构三板斧

前端场景里最热的是代码审查类 skills。我之前自己写的代码审查 skill 后来就改成了一组规则文件，重点盯三个层面：组件职责是否单一、状态是否过度提升、事件处理有没有内存泄漏。

组件生成类 skills 要写得更细一点，因为它不只是“生成一个按钮”，而是要把你团队的技术栈写进去。比如技术栈是 React + Tailwind + TypeScript，就在 SKILL.md 里写明：组件 props 用 interface 定义、样式类按 Tailwind 规范、事件处理函数用handle前缀。这样生成的代码直接能进团队 Code Review，而不是交上来再大改。

CSS 重构类 skills 近几年需求也比较大，核心逻辑是：先分析现有样式表结构，找到重复类名和冗余选择器，再按“变量抽取-拆分-合并”三步走。这种 skill 有个好处——规则非常固定，模型只要照着执行，结果就非常稳定。

实操提醒：前端类 skills 最好在项目根目录单独建一份.claude/skills/，不要全局安装。因为前端技术栈更新太快，全局装一个老组件规范，很容易跟项目新规范打架。

4.2 数学建模：华为杯这类比赛到底需要什么 skills

数学建模这块的热度是比赛带起来的，特别是华为杯前后，一堆人在问“有没有好用的 codex skills”。建模比赛真正耗时间的不是建模本身，而是数据处理、可视化和论文排版这三件事。

数据处理类 skills 的核心规则包括：优先检查缺失值和异常值；列名统一转换；处理后的数据要输出 describe 统计结果。写进 skill 里之后，每次拿到新数据它都会自动先走这套流程，不会再用一遍再问你一遍。

可视化类 skills 也值得专门配一个，重点不是生成图片，而是控制风格。比赛论文里的图表风格必须一致，所以 SKILL.md 里我会写明统一的配色方案、字体大小、图注格式。

论文摘要生成类的 skills 属于进阶玩法。它读完整篇论文后，按“问题背景-模型方法-结果指标-创新点”四段式输出摘要。这对卡字数特别有用，也能保证逻辑不散。

4.3 AI 漫剧：角色一致性、分镜、台词这仨 skill 最常用

AI 漫剧圈找我推荐 skills 的特别多，这个领域需求跟编程完全两码事，但底层逻辑一样：让模型按固定规则批量生产内容。

漫剧最痛的一点是角色一致性。同一个角色前一个镜头长这样，下一个镜头就变样了。针对这个写的 skill，核心规则是“先生成角色设定卡，再让设定卡约束每一次出图提示词”。也就是说每次生成图片前，把角色五官、服饰、色调这些固定描述拼到提示词里，而不是每次让模型自由发挥。

分镜类 skills 的规则是：输入一段剧情，输出分镜表，每行包括景别、运镜、画面内容、时长。说清楚 1 到 2 秒一刀，转场用什么方式。模型按这个结构跑，输出整齐划一，后期剪辑省很多事。

台词类 skills 则偏向对话节奏控制，比如每句不超过 15 个字、口语化、保留口头禅。这个对固定人设特别管用。

5. 管理 skill：清理、更新、防冲突，别让技能库变成垃圾堆

5.1 为什么你必须要定期清理 skills

很多人的习惯是看到好用的 skill 就往里装，装了二三十个也不管。积累到一定程度问题就出来了：一是每次会话模型都要扫描全部 skill，加载变慢；二是 skill 之间触发词重叠，你只是想让它格式化代码，结果它把另一个审查类技能也激活了，行为直接跑偏；三是 token 占用会上升，因为很多工具会把 skill 的描述信息预加载进上下文，白占额度。

我自己的原则是：全局只保留不超过五个核心 skill，其余的按项目放在项目目录里，用到查得到，不用不干扰。

5.2 社区流传的清理方法实操版（tibo 那套思路）

社区里 tibo 分享过一套清理 skills 的方法，核心思路总结起来就是三个字：“列、筛、删”。具体操作：

# 查看当前所有 skills 目录及大小 find . -type d -name "SKILL.md" | xargs du -h # 按修改时间排序，找出很久没用的 find . -type d -name "SKILL.md" -printf "%T@ %p\n" | sort -n | tail -20 # 删除指定技能目录 rm -rf .claude/skills/old-skill

这套思路的精华在于不看广告看数据：哪个 skill 最近没触发过、哪个目录占了多大空间，一目了然。不是凭感觉删，而是拿实际使用频率做依据。

我照着这个思路又加了一步：做一个“禁用优先”的过渡流程。先在不删文件的情况下，把不太确定的 skill 目录加个.disabled后缀挪出扫描范围，用几天看核心功能有没有受影响，确认不受影响再彻底删除。比直接删更稳。

5.3 更新和防冲突：版本管理的小习惯

skill 更新其实没有特别复杂的机制，GitHub 上克隆的库直接git pull就行，自己写的检查一下 SKILL.md 有没有改动需求。问题是很多人在项目里手动改过 skill 文件，一 pull 又跟远程冲突了。

避免冲突最简单的习惯是：不直接改克隆来的源文件，改成复制一份到你自己的非受管目录里再改，或者遇到需要自定义的场景就直接 fork 原仓库。这样远程更新能平滑合入，自己的定制也不丢。

还有一个很容易撞车的问题：同名 skill。Claude Code 会优先加载项目级目录，再往上找用户级目录。如果你项目里放了一个定制版frontend-review，全局又有一个同名技能，项目级会盖掉全局的。记得这一点，排查“为什么改了规则没生效”会少走很多弯路。

6. 常见问题与排查技巧实录

6.1 装了 skill 但助手无动于衷，怎么办

这个问题遇到的频率最高，我按顺序排查这三件事：路径、名称、描述。

先看路径对不对。Claude Code 是.claude/skills/<name>/SKILL.md，少一层或多一层都会扫描不到。再看目录名和 name 字段是否一致，不一致有概率加载失败。最后看 description 是否过于含蓄，模型感知不到触发条件。

提示：修改 SKILL.md 后一定要重启会话。加载动作基本发生在会话初始化阶段，中途改文件不重启，新规则不会生效。

6.2 多个 skill 互相掐架，触发错乱怎么定位

当你发现助手在干 A 任务时突然按 B 任务的规则来，基本就是两个 skill 的 description 重复了。比如一个写“代码审查”，另一个写“代码质量评估”，模型分不清什么时候用哪个。

定位办法是逐个看 description 的触发关键词，找出重叠部分，改了其中一个的描述，把触发场景写得再细一点：“仅当用户要求逐行审查时使用”；另一个写“仅当用户要求整体架构评估时使用”。这样从源头隔离触发条件，比对话里反复纠正省事得多。

6.3 token 占用过高，是不是 skills 的锅

编程助手 token 消耗变大不一定是 skill 造成的，但 skill 确实是嫌疑之一。检查方法很简单：把某个项目里的 skills 目录临时改名，跑一个相同任务对比 token 消耗，如果明显下降，说明技能库太庞杂了。

对策两个方向：一是精简正文，把 SKILL.md 里那些泛泛而谈的背景介绍删掉，只留规则和示例；二是拆分触发，把一个大而全的 skill 拆成多个小技能，避免每次对话都整本加载。我拆完一个大 skill 之后，日常会话的 token 消耗大概降了两三成。

我自己的经验是：skills 这套东西，上手门槛不高，但真正用得顺手需要一点时间和耐心。别一上来就装几十个，先挑两个最痛的高频场景，比如代码审查和项目初始化，各装一个或者自己写一个，用两周观察差异，再去扩展其他场景。写 skill 时永远记住一句话：给模型的不是记忆，而是可执行的流程。流程越清晰，输出越稳定。