最近一两年只要经常跟Claude Code这类AI编程工具打交道的人肯定绕不开一个词skills。GitHub上带“skills”后缀的仓库越来越多搜“claude code skills”能翻出几十页结果有人把skills比作AI的外挂芯片有人说是给AI写的岗位说明书还有人囤了上百个skills却压根不知道它们到底怎么被触发的。我自己最早接触skills也是在Claude Code里。那会儿项目一多每次开新会话都要重新跟AI解释项目结构、代码风格、提交规范烦得要命。后来发现其实可以把这些“套路”封装起来做成一个个独立的能力包让AI在合适的场景下自动调用。这就是skills的雏形——但它背后到底是怎么工作的、怎么手动装GitHub上那些现成的skills、怎么写一个真正能派上用场的skills、以及装多了之后怎么清理网上聊得透彻的不多。这篇文章把我实操中的理解和踩过的坑一起写出来适合所有在Claude Code、Codex、OpenCode这些AI编程工具里折腾过skills的人。1. skills是什么它解决的不是“不会写代码”而是“每次都在重新写”1.1 说白了skills就是一份给AI的操作手册我经常跟朋友解释模型本身是个“什么都会一点但什么都不专”的超级实习生。你问它一个具体问题它能给你一个泛泛的答案但如果你给这个实习生一份详细的操作手册——包括项目背景、步骤流程、注意事项、输出格式它就能稳定地产出专属于你项目的结果。Skills干的就是这件事。从技术形态上看一个skill通常就是一个目录里面放着一个SKILL.md文件作为主入口旁边可能带一些参考文档、脚本模板。Claude Code在启动时会去固定的skills目录扫描这些文件把它们注入到上下文里或者等用户在对话中触发它。具体到目录结构每个工具略有差异。Claude Code默认读取的是~/.claude/skills/Codex用的是~/.codex/skills/OpenCode的路径也大同小异。每个skill的文件夹里至少要有一个SKILL.md这个文件通过YAML格式的frontmatter声明元信息包括skill的名字、功能描述、适用时机然后用Markdown正文写具体的操作流程和规则。这跟我们平时用CLAUDE.md或AGENTS.md做全局指令有什么不同呢我的理解是全局指令像公司的《员工手册》内容又多又杂模型每次都要读到skills像一个个独立的《岗位操作手册》只有当你明确需要某项技能时模型才会去翻阅对应手册。用技能包的形式把知识拆碎、按场景打包模型反而更容易精准调用上下文也不会被一堆无关规则塞满。1.2 为什么大家突然开始疯狂囤skills我之前也觉得不就是一堆Markdown写成的提示词吗有什么好稀罕的。但用久了才发现skills跟单纯的提示词有一个本质区别它有“触发机制”有“文件载体”还有“版本迭代”的空间。单纯的提示词是你每次都要手动复制粘贴进对话里的一句话或者一段指令。想来想去还是得靠人。Skills则把这段指令固化成了一个可以被模型自动识别、按文件名和描述匹配的能力模块。当任务发生时模型判断“这时候该用前端开发技能”“这时候该用数学建模技能”然后自动把对应技能的内容加载进上下文。这一步自动化省掉的不仅仅是复制粘贴的功夫更重要的是消除了“你忘记告诉AI该用什么方法”的人为误差。再加上最近Claude Code、Codex这些工具的更新都很频繁生态越来越完善GitHub上出现了大量成熟skill仓库。有人做过统计AI编程的使用者中有相当一部分人已经开始收集各种技能库像superpower skills这种集成度高的仓库甚至已经发展成了一套完整的“能力框架”。于是囤skills变成了一种近乎收藏癖的行为——看到好的就clone下来也不管用不用得上。这个现象背后其实是大家已经意识到AI的下限由模型决定上限却由这套“操作手册”的质量决定。1.3 哪些场景下skills的价值最大我自己的实践结论是skills在以下三类场景里价值最大第一类是重复性极高的任务流。比如前端项目的初始化每次都要搭脚手架、定规范、配ESLint、按团队风格建组件如果把这些写成前端开发skillsAI一上来就能按你的规范操作不用你每次复读要求。第二类是专业领域知识门槛高的场景。比如华为杯数学建模比赛评委看重的不只是结果还有建模过程的规范性和论文的格式。你可以给Codex写一个数学建模skills把常见的模型库、论文结构、排版要求全部塞进去AI一跑起来就直接按竞赛标准走比自己每次临时抱佛脚靠谱得多。第三类是多工具协作的工作流。比如AI漫剧创作涉及人物设定、分镜脚本、台词风格、画面描述等多个环节。把这些环节拆成一组相互衔接的skillsAI就能从一个环节自动衔接到下一个环节把零散的创作过程变成流水线。2. 手动安装一个GitHub上的skills其实没那么神秘2.1 先搞清楚skills的加载原理很多人一听到“手动安装”四个字就发怵以为要配什么环境、跑什么脚本。其实把原理捋清楚了手动安装就是一次文件夹复制操作。所有AI编程工具加载skills的本质逻辑都相似工具启动时扫描指定目录读取符合规则的子文件夹然后根据对话内容决定要不要调用其中的SKILL.md。也就是说只要把一个skill仓库克隆下来再放到工具指定的skills目录里工具理论上就能识别它。有些skill仓库会在README里给出专门的安装命令还有的提供了安装脚本但很多仓库文档写得并不友好这时候手动安装反而是最可靠的办法。在动手之前还有几个细节要注意。首先不是所有的文件夹都能被识别通常要求文件夹内部有合法的SKILL.md文件并且frontmatter里的name字段最好跟文件夹名对应。其次有些工具只读取特定层级的目录比如直接放在~/.claude/skills/下一级的文件夹如果你放了嵌套目录可能不会被扫描到。这也是很多人“装上了但没生效”的最大原因之一。2.2 从下载到生效完整安装步骤我以Claude Code为例演示一套完整的手动安装流程。其他的Codex、OpenCode大同小异只需要替换对应的目录路径。第一步找到你要安装的skill仓库。GitHub上搜“awesome claude skills”“skills collection”之类的关键词就能找到一堆。挑一个star数比较高的、最近还在更新的仓库。第二步把仓库克隆到本地任意临时目录git clone https://github.com/some-user/awesome-skills.git第三步打开技能目录找到跟skill名称对应的子文件夹。比如你安装的是一个叫frontend-dev的skill它通常在仓库里的路径是skills/frontend-dev/。第四步把这个文件夹复制到Claude Code的skills目录mkdir -p ~/.claude/skills cp -r awesome-skills/skills/frontend-dev ~/.claude/skills/第五步重启Claude Code在对话中输入跟这个skill相关的任务比如“帮我按前端项目规范初始化一个React工程”然后观察模型是否按skill中定义的流程执行。就这五步没有别的幺蛾子。很多人觉得手动安装麻烦其实真正麻烦的是挑选和验证技能是否适合自己复制文件反而是最机械的一步。2.3 安装完怎么确认它真的生效了装完之后最大的困惑就是“我怎么知道它到底生效了”很多模型并不会在启动时打印“我已加载xxx skill”甚至你在对话中问它“你有哪些技能”它也可能答得模模糊糊。这并不代表skill没生效反而说明你现在还不确定触发条件是否满足。比较靠谱的验证方法是查看上下文。Claude Code会在界面上显示当前会话加载了哪些文件或技能或者用调试命令查看激活的skill列表。如果你的工具没有这种可视化界面也可以用一种最笨的办法把SKILL.md中的某个标志性短语直接当成指令的一部分发给模型看看模型会不会按照skill中的步骤来回答。比如skill里写了“响应时必须先列出三种备选方案再选优”你就在对话里复述一句相关需求然后观察模型是否真的遵循了这个规则。这里有一个我交过学费的细节有些skill设计得比较“安静”它只是提供参考信息不会主动改变模型的行为。你问问题它还是按自己的理解回答。只有当你触发了它定义的具体任务类型时它才会把更细的规则加载进去。所以判断skill是否生效不要问“你加载了什么”而要直接给一个它擅长处理的任务。2.4 要不要用管理工具我的建议手动安装虽然简单但skills一多管理就成了灾难。今天装了二十个明天想更新其中的两个后天又发现某个不常用的占了地方全靠手动维护非常痛苦。所以社区里出现了一些skills管理器比如superpower skills自带的安装工具或者某些集成式脚本。我用过一阵子这些管理工具确实方便能批量安装、一键更新、查看调用情况。但我的建议是第一二次接触skills时不要用管理器老老实实手动装一遍。手动安装能帮你理解目录结构、触发机制、文件关系这些理解在以后排查问题时会救你命。等你对这套机制有了感觉再上管理工具效率会高很多。另外装别人的skills一定要养成保留来源的习惯。把克隆下来的仓库地址、commit版本、安装的目录记录下来不然过两个月想更新都不知道自己装的是哪来的。3. 自己写一个skill从“能用”到“好用”3.1 最小可用的skill长什么样网上能下载的skills很多但真正贴合自己项目的还得自己写。自己写skill并没有想象的那么难核心就是一个SKILL.md文件而已。一个最简的skill结构是这样的my-skill/ ├── SKILL.md └── references/ └── details.mdSKILL.md的完整骨架如下--- name: my-skill description: 在遇到XXX情况时使用。用于完成XXX任务输出格式为XXX。 --- # My Skill ## 适用场景 - 任务类型A - 任务类型B ## 执行步骤 1. 第一步做什么 2. 第二步做什么 ## 输出要求 - 按XXX格式输出 - 包含XXX内容看起来简单但这个文件写得好不好直接决定了skill能不能被正确触发、会不会执行偏。我见过的很多自写skill之所以没用不是因为功能太少而是因为触发逻辑写得含糊或者执行步骤写得像废话。3.2 description是灵魂触发词要写得像给AI发信号SKILL.md的frontmatter里有两个字段是灵魂name和description。name是技能标识description则是告诉模型“什么时候该用我”的触发信号。很多新手写description时容易陷入两个极端。一个极端是写得太抽象比如“帮助用户解决前端问题”“提高开发效率”这种描述模型根本没法判断“现在该不该调用”。另一个极端是写得太具体比如“当用户说‘帮我写一个计算两个日期之间天数的函数’时使用”这种描述又会限制技能的适用场景用户换个问法就触发不了。我自己的心得是description要写成“条件目的输出”的组合句式。举个例子description: 当用户需要搭建前端项目、遵循团队编码规范、或询问组件结构方案时使用。根据需求输出项目初始化步骤与目录结构建议。这种写法给了模型三个信息什么时候触发搭建前端项目/询问规范/组件方案、要干什么初始化步骤目录结构建议、输出边界是什么。模型判断起来就很准确。还有一个小技巧在正文里也放几个“触发关键词”比如在适用场景中明确列出“React、Vue、ESLint、组件规范”这类常见词。模型在语义匹配时会综合description和正文中的关键词来判断命中率会高很多。3.3 正文内容怎么写才不容易跑偏正文部分是skill真正的干货。我建议按“目标→规则→步骤→示例→禁忌”五个维度来组织。目标部分说明这个skill想达成什么结果。规则部分是硬性约束比如“代码中禁止使用any类型”“所有变量命名采用camelCase”这些是模型必须遵守的边界。步骤部分描述可执行的流程比如“先分析需求→再给出目录结构→最后生成代码”。示例部分放一两个具体例子模型看到例子之后输出风格会稳定很多。禁忌部分可以写清楚“不要做什么”这对防止模型自由发挥非常有效。我自己写skill时最大的体会是规则要写“死”步骤要写“活”。规则不写死模型会钻空子比如你只说“代码要规范”它理解不了什么叫规范你写成“必须使用ESLint推荐规则、不允许出现console.log、React组件必须使用函数式组件”它就老实了。步骤写得过于死板也会有副作用比如遇到特殊情况就卡壳因为模型严格按照步骤走一步不通就走不下去。所以步骤里最好留一些“如果遇到XXX可以跳过此步转向XXX”的分支说明。3.4 我的开发迭代流程和几个经验我自己开发一个skill通常不是一次性写完的而是遵循“提炼→封装→测试→迭代”四步流程。第一步是从已有的CLAUDE.md或者对话历史中提炼。哪里写的是“每轮对话都要遵守的通用规则”哪里是“特定场景下才需要的专属逻辑”把后者抽出来往往就是skill的雏形。第二步是封装成带frontmatter的SKILL.md搭好目录骨架。第三步是测试。开一个新会话用几个典型的任务去触发它看模型处理得对不对。重点关注两点触发命中率该触发时触发了没有和执行正确率触发了但做法是不是你想要的样子。第四步是迭代。根据测试结果调整description的措辞、增补规则和示例甚至可以拆成多个更细的skill。关于写skill我还有几条经验。第一一个skill只解决一类问题千万别做“大而全”不然description里要写的事太多触发精准度反而下降。第二先写成“能用”再优化到“好用”第一版只要满足“模型按步骤执行、输出格式可控”就算成功。第三别急着分享先在个人项目上跑两周确认稳定了再开源出去。4. 值得试的几类skills与现成库推荐4.1 superpower skills适合当“能力包”的集成式库提起skills生态绕不开的一个名字就是superpower skills。它是一个开源项目由一系列skills组成的能力包覆盖了从代码审查到文档撰写的很多场景。安装superpower skills的方式有两种。一种是用它自带的安装脚本一条命令搞定另一种是手动克隆仓库按上文的手动安装流程复制到你工具的skills目录。我个人更喜欢手动安装因为superpower skills里的技能数量不少我不需要全装挑自己用得到的复制进去就行。它里面有一类技能我觉得特别实用就是“把AI当成团队中的某个角色来使用”比如资深代码审查员、架构设计顾问。这类技能解决的不是写代码的问题而是帮你建立了一套跟AI协作的思考框架。不过也要提醒一句superpower skills的定位偏重“通用能力”对某个具体领域来说它不一定比你自写的垂直技能更有效。我的用法是用superpower skills覆盖通用开发流程自己再写几个贴合项目场景的专属skill两者配合效果最好。4.2 cola、codex等社区库怎么挑怎么用社区里的skills库非常多我平时关注比较多的就是cola skills和codex相关的skills仓库。cola skills的特点是比较“轻”按类型分类清晰适合日常杂活比如写commit message、生成代码注释、整理Markdown文档之类的小而美的技能。如果你刚开始接触skills想快速感受一下“装了skill和没装skill有什么区别”从cola skills里挑两三个装上最有感觉。codex相关的skills库则是面向OpenAI Codex环境的里面不少技能带着比较浓的研究风格适合算法探索、数据分析、论文写作这类场景。我自己在数学建模比赛中用到的不少思路就是从这类库里得到的启发。挑库的时候有几个判断标准项目最近有没有更新、issue有没有人维护、示例是否丰富。如果一个仓库半年以上没更新里面的skill大概率还停留在老版本API的写法上装完了能不能用都成问题。另外我强烈建议挑“小而专”的库而不是一个包罗万象几千个skill的大仓库。技能太多不仅管理麻烦而且会在模型调用时产生选择困难反而降低了触发准确率。4.3 前端、建模、漫剧等具体场景怎么选针对不同的热门场景选择合适的skills策略是不同的。前端开发场景优先选那些包含“项目初始化流程”和“编码规范约束”的skill。一套合格的前端开发skills至少要覆盖环境配置、目录结构、组件设计原则、代码风格检查这几个层面。装完之后新项目的起步阶段会明显感觉AI“懂规矩”了。数学建模场景我在华为杯比赛中的做法是给Codex写一个专属的建模skill里面放了问题类型判断流程、常用模型清单线性规划、整数规划、图论模型、统计模型、论文写作规范、图表格式要求。建模比赛时间紧任务重模型选择这个环节特别耗时有了skill就能把“看到题目→判断类型→选模型”这一步压缩到很短时间内。社区里也有现成的数学建模skills但实践下来还是自己写的最顺手因为比赛要求年年变现成脚本不一定跟得上。AI漫剧场景我见过一些创作者把分镜脚本、人物设定卡、台词风格、镜头语言描述之类的规则打包成一组skills。这样做的价值在于AI从一个镜头生成下一个镜头时能保持人物性格、画风、叙事节奏的一致性。很多漫剧账号更新频率高这种流水线式的skills组合就特别好用。5. 管理、清理与团队协作技能越多不等于越好用5.1 什么时候该清skills很多人装了海量skills之后发现AI的表现并没有变好反而变钝了。原因很简单skills目录里堆满了垃圾和不相关的内容模型在匹配触发词的时候多了一堆干扰项。skills跟收藏夹里的文章一样囤着不整理用的时候就是一团乱麻。我的经验是每过一个迭代周期比如一个项目做完、一次比赛结束都应该做一次skills清理。清理的标准很简单这个skill最近一次被触发是什么时候它解决的具体问题还存在吗有没有跟另一个skill的功能重叠这三个问题问完该删的基本心里有数了。5.2 tibo式清理法怎么删不心疼社区里有个叫tibo的博主分享过一套清理skills的方法我看了之后觉得非常实用核心思路是“先禁用后删除先留档再清理”。具体操作是这样的第一步把不常用的skill移到单独的disabled-skills目录里而不是直接删除。这样实际运行环境中已经没有它们了但它们还留在本机随时可以启用。第二步运行一段时间看看。如果某个skill禁用之后你完全没有感到任何不方便那说明它对你没有价值可以放心删除。如果发现少了它工作流断了一环再移回去也不迟。第三步把确认要删的skill只保留一份压缩备份或者直接记下它的GitHub仓库地址删掉本地目录。开源项目的好处就在这里——删了随时可以再clone回来不用有“删了就没了我”的心理负担。我在这套方法的基础上加了一步用一个表格记录每个skill的用途、安装来源、最近使用时间、清理评估。这样每次清理不必重新考古对着表格就可以快速决策。5.3 团队共用一套skills的思路如果你是一个小团队的技术负责人把skills纳入团队知识库是非常值得做的事。因为skills的本质就是把个人经验沉淀成团队规范一旦做成新成员上手项目的时间会大幅缩短。团队使用skills我建议采用一个单独的Git仓库来管理。目录结构按“领域/场景/技能”组织README里写明每个skill的适用场景和依赖关系。团队成员通过git clone或者子模块的方式把技能同步到本地保持版本的统一。仓库里至少要有几个必备的skill团队代码规范、项目初始化流程、提交信息规范、代码审查要点。这些是一个团队最通用也最刚需的部分。至于那些个人化的技能不建议放进团队仓库否则会把团队技能库变成杂物间。个人技能留在个人目录团队技能走仓库统一管理两边互不干扰。我在实践中还发现一个好处把skill当成代码来评审。团队里任何人想新增或修改一个skill都走PR流程让其他人看看触发描述是否准确、执行步骤是否合理。这不仅能提高skill的质量还能让全团队对AI协作形成一致的理解。6. 常见问题排查装完不生效、乱触发、冲突怎么处理6.1 AI完全不触发某个skill这是最常见的故障十有八九出在description上。我记得刚开始写skill时description写的是“帮助用户处理前端相关问题”结果死活不触发。后来把description改成“当用户要求搭建React项目、遵循团队前端规范、或者提出组件结构问题时使用”命中率马上上来了。另一个原因是目录层级不对。有些工具要求skill文件夹必须直接放在skills根目录下面不能有中间层。注意检查你的目录结构是否跟工具文档一致。还有一种情况是大小写问题。Linux和macOS的文件系统是严格区分大小写的如果你的skill文件夹叫My-Skill而frontmatter里的name写的是my-skill部分工具就会匹配不上。6.2 多个skill打架响应混乱装了多个description相似的skill之后模型可能会同时触发两个技能导致回答风格混乱。解决办法是限定使用边界重新打磨description把每个技能的适用范围写得更窄。比如“前端项目初始化”和“前端代码规范审查”这两个技能前者聚焦脚手架和目录后者聚焦代码质量描述里明确写清各自的触发场景和职责范围冲突就会减少。如果两个skill之间确实有强关联可以考虑把它们合并成一个技能用“第一个阶段用方案A第二个阶段切到方案B”的方式串联起来。合并之后模型只需要一次触发判断响应会更稳定。6.3 换个工具之后skills失效Claude Code的skills目录是~/.claude/skills/Codex可能是~/.codex/skills/OpenCode又有自己的路径。换工具时只克隆了skill仓库却放错路径自然就不生效。如果你经常在多款AI编程工具之间切换可以考虑用一个软链接把各工具的skills目录指向同一个文件夹这样装一次就处处可用。不过要注意有些工具对目录的权限要求严格软链接不一定都能成功还是以各工具的官方文档为准。6.4 保持好你自己的“技能节奏”最后分享一个关于清理和迭代的节奏感。我个人的习惯是每两周花十分钟做一次小清理每完成一个大项目做一次沉淀。小清理就是把最近明显没用过的skill禁用掉大沉淀就是在项目收尾时把这次用到的临时指令、踩坑记录固化成一个新的skill。这套节奏坚持下来之后我的skills目录从最初几十个垃圾堆积慢慢变成了一套精简但精准的“工具箱”。每次新开项目我只用其中五六个核心技能但它们覆盖了我真正高频的场景。囤skill的快感是一时的把skill变成自己手里顺手工具的过程才是真正有价值的部分。根据我自己的实际体验入门skills最快的方式还是先手动装两三个现成的用起来再拆开看里面的写法照着改一个自己项目的专属skill。亲自动手装过、写过、删过一次你对skills这套机制的掌控感就会完全不一样。