最近社区里聊 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.mdOpenCode 是.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 时永远记住一句话给模型的不是记忆而是可执行的流程。流程越清晰输出越稳定。