这两年如果常刷技术社区你会发现skills这个词的出镜率高得吓人。不过它指的不是你简历上写的技能而是AI编程工具里正在流行的一个具体机制把一套可复用的提示词、规则和示例封装成一个技能包让Claude Code、Codex、opencode这类工具在干活时直接调用不用每次从零开始教。昨天群里还有人问Claude Code怎么手动装GitHub上的skills今天就专门把这件事掰开揉碎写一篇这个skills到底是什么、为什么突然这么火、怎么装、怎么写、装完不生效怎么排查。适合所有用AI写代码、做建模、做自动化流程的朋友也适合单纯想搞清楚这个新概念的人。1. 先掰清楚AI编程里的Skills到底是什么1.1 从一条提示词到一个技能包很多人第一次看到AI skill会以为是AI学会了新技能其实更准确的说法是一种结构化的指令封装。在Claude Code这类工具出现之前你想让AI按某种固定套路干活靠的是把一大段提示词塞进对话比如你做前端代码审查的时候先看依赖目录、再看状态管理、再检查样式遗漏……这些话每次都要复制粘贴又长又容易漏。有了Skills之后这套流程变成一个文件夹。文件夹里有说明文件、规则、代码片段甚至参考文档。AI在处理相关任务时会自动把这份说明书加载进上下文然后按照里面的流程干活。用生活化的类比就是以前你是每次开会前临时抖动一套要求现在是直接给AI发了一本岗位手册它上岗前自己翻手册遇到问题知道按流程走。1.2 主流工具里的Skills机制Claude Code、Codex、opencode目前支持Skills机制的AI编程工具有不少最常被提到的三个是Claude Code、CodexOpenAI的命令行工具和opencode开源终端AI助手。它们的命名和默认目录位置有差别但核心结构几乎一致一个以技能名命名的文件夹里面包含一个SKILL.md主文件还可能有scripts、references等附件。很多人刚开始会混淆以为GitHub上那些skills仓库是插件市场。实际上大多数仓库就是一堆技能包源码你需要自己把它们放到对应工具的指定目录里。我先给一个速查表后面详细讲操作。工具用户级存放位置macOS/Linux核心文件加载方式Claude Code~/.claude/skills/SKILL.md按需自动加载Codex~/.codex/skills/SKILL.md匹配描述后调用opencode~/.opencode/skills/SKILL.md支持用户级与项目级表格里的路径在一些新版本里会有变化但大体方向不会错。这一步不用记死装的时候再对着目录看就行。2. 搞清楚为什么火Skills到底解决了什么痛2.1 没有Skills之前调教AI全靠现场发挥回忆一下没有skills的时候我们是怎么用AI写代码的。你想让AI按团队规范改前端组件得把规范从头到尾打一遍组件放哪个目录、函数怎么命名、样式变量怎么引用、注释要不要写。今天描述得详细一点生成质量就好一点明天图省事少写两句生成的东西立刻跑偏。同样的任务效果完全取决于你当时的心情和手速。我甚至试过把一套规范做成模板段落每次对话开始先粘贴进去。结果一是非常占上下文长度二是模型只把它当成普通聊天内容并不会真的严格执行。有时候你前脚贴完规范后脚它依然用默认风格写代码。说白了AI的临场发挥不稳定你缺的不是提示词而是一个能被稳定继承的能力集。2.2 有Skills之后能力变成可复用资产引入Skills后最大的变化在于提示词、规则、示例不再是一次性的。它们被封装成带名字、带触发条件的技能包可以被检索、被复用、被分享。你写好一个代码审查Skill丢给同事他装进自己的工具里跑出来的效果几乎和你这边一样。这种可复制性正是它快速火起来的原因。对团队来说更有价值。以前团队规范沉淀在文档里AI不知道现在直接把规范写成skills目录放进项目所有人共用同一套标准。新人入职装上配置就能进入状态不用再手动解释我们团队习惯怎么写代码。对个人来说你积累的skill库本身就是一种数字资产换工具、换电脑都能带走。3. 手把手实操从GitHub手动装一个Skill3.1 装之前先明确两件事版本和来源现在网上教你装skill的帖子很多但很多人第一步就走错了。装skill之前请先确认两件事。第一你的工具版本支持skills机制。Claude Code是在较新版本里内置支持skills的如果你用的版本太老它根本不会读取skills目录。第二你下载的仓库里确实有SKILL.md文件。很多仓库只是教程集合或者某个大佬的配置备份并不符合技能包的结构。打开仓库先看根目录找到含SKILL.md的那个文件夹这才是你要的东西。我建议动手前先问自己一句我是从哪个渠道拿到这个skill的如果是从别人帖子里复制来的命令先别急着跑如果是从GitHub仓库里下载的先看清目录结构。这一步能帮你省掉后面一半的排查时间。3.2 Claude Code手动安装全流程最稳的方案先说结论我实测下来最稳、失败率最低的方法是文件夹级别的拷贝。过程很简单一共五步。在GitHub上找到目标仓库进入仓库之后找到含SKILL.md的技能文件夹。用git clone把整个仓库拉到本地或者直接在网页端下载zip包。把那个技能文件夹复制到~/.claude/skills/目录下。如果这个目录不存在手动创建它。完全退出Claude Code重新启动。注意是完全退出不是开个新对话。启动后在对话里问一句你现在有哪些技能可用。如果模型能正确列出说明安装成功。如果你的Claude Code版本较新还可以试试claude install-skill这条命令它能把远程仓库里的skills自动装进默认目录。但这命令不是万能的遇到某些仓库结构不规范、或者网络不通的时候会失败。失败就别死磕命令直接按上面五步手动复制反而最快。3.3 Codex、opencode的安装方式Codex的skills目录一般是~/.codex/skills操作思路和上面一样下载含SKILL.md的文件夹、复制进去、重启。唯一需要注意的是Codex对SKILL.md的frontmatter格式更敏感后面写skill的时候我会专门提这一点。opencode稍有不同它同时支持用户级和项目级两种位置。用户级是~/.opencode/skills所有项目共用项目级是项目根目录/.opencode/skills只有当前项目会加载。我更推荐在项目里放项目级skills比如做前端项目就只放前端规范类技能做后端项目就只放后端规范类技能互不干扰。3.4 各工具Skills目录位置的终极速查表我把目前常见的默认位置整理成一张表Windows用户尤其注意路径前缀会不一样。工具用户级位置macOS/Linux用户级位置Windows项目级位置Claude Code~/.claude/skills%USERPROFILE%\.claude\skills项目根目录.claude/skills较新版本Codex~/.codex/skills%USERPROFILE%\.codex\skills部分版本支持.codex/skillsopencode~/.opencode/skills%USERPROFILE%\.opencode\skills.opencode/skills不管哪个工具装完都要重启会话。很多人装完发现不生效最后查来查去发现就是没重启旧会话里压根没重新扫描目录。4. 自己写Skill结构、写法与一个建模实战案例4.1 SKILL.md是核心目录是外壳自己写skill没有想象中那么神秘。一个skill的本质就是一个目录目录里最重要的文件叫SKILL.md。它像技能的说明书通常用Markdown写开头带一段YAML frontmatter里面写name和description。很多人会忽略description随便写一句话就完事。实际上description是整个配置文件里最关键的字段它不是给人类看的简介而是给模型看的触发条件。当用户的任务命中description描述的场景时模型才会主动加载这份说明书。description写得好不好直接决定这个skill会不会被调用。一个标准的skill目录结构长这样math-modeling/ ├── SKILL.md └── references/ └── 常用模型速查.md如果你有辅助脚本还可以加一个scripts/目录。但我不建议一上来就把目录搞得很复杂先写一个只有SKILL.md的最小可用版本跑通了再慢慢加附件。4.2 一个数学建模Skill的完整示例最近总有人问数学建模skills推荐我就直接写一个能用的示例出来。这个例子不涉及任何具体比赛内幕纯粹是一个通用的建模辅助技能包。SKILL.md的内容大概是这样的--- name: math-modeling description: 当用户在数学建模竞赛、数据分析建模、预测分类、优化求解等场景请求帮助时使用。 --- # 数学建模技能 ## 工作流程 1. 先和用户确认问题属于预测、分类、优化中的哪一类。 2. 根据数据类型和样本量推荐候选模型优先给出经典方案再补充进阶方案。 3. 涉及代码时产出可直接运行的Python代码并注明依赖库的主要版本要求。 4. 每个模型结论都必须说明理由和适用边界禁止只给结论不给推导。 ## 常用模型 - 预测类线性回归、LSTM、Prophet - 分类类逻辑回归、随机森林、XGBoost - 优化类线性规划、遗传算法 ## 输出规范 - 所有公式使用Markdown公式语法 - 所有代码必须包含注释 - 所有建议必须明确标注适用边界注意我加粗了关键点。这个示例的重点不在于代码有多漂亮而在于内容要指令化。模型不会像人一样通读全文并自行感悟它是把这个文件当成制度来执行。所以每一条都应该像公司规章制度一样清晰、无歧义不能写散文。4.3 写Skill时的三个核心原则第一个原则description是灵魂。写得含糊会出大问题。比如description只写数学建模模型很难判断什么时候该调用。改成当用户提到数学建模竞赛、华为杯、国赛、美赛、回归预测等问题时使用触发率会明显提高。第二个原则内容要短小精悍。SKILL.md不是论文别把几千字都塞进去。模型触发这个技能时会读全文内容太长会稀释关键指令反而降低执行准确率。我建议把参考的长文放到references/子目录里主文件保持流程规则要点的密度。第三个原则主动加负面清单。很多人会忽略这一点但非常管用。在技能说明里写一句当用户只是做普通编程任务时不要使用此技能能有效防止模型越权调用。模型本身就爱过度加载技能明确排除范围反而能让它更精准。5. 常用Skills资源去哪找、怎么挑5.1 几个值得收藏的Skills来源渠道目前技能包主要散落在GitHub还没有一个特别统一的应用商店。最实用的找法是直接在GitHub上搜关键词比如agent skills、claude skills、codex skills、opencode skills或者直接搜awesome skills。排序方式建议按star数和最近更新时间综合看。star高说明经过很多人验证更新时间近说明适配了新版本。除了GitHub官方文档也值得看。Claude Code官方文档里有一个专门的Skills说明里面的示例写法是最标准的。你网上找到的很多第三方仓库其实都是从官方那套结构改出来的。先看官方文档建立正确认知再看第三方仓库就知道好坏。社区帖子和公众号也经常有人分享自己打磨好的skills仓库链接甚至有人专门整理常用skills源网站清单。看这类分享的时候别只看标题和简介点进仓库重点看它的目录结构里有没有SKILL.md看主文件写得好不好。很多所谓的技能包其实就是一段提示词的包装连YAML frontmatter都没有装进去也不会被识别。5.2 我实测下来最常用的几类Skill我自己装过并且现在还在用的有几类这里按使用频率排个序前端开发规范类让AI按项目已有风格写组件涵盖目录结构、组件命名、hook使用规范、样式变量引用规则。装了这个之后AI生成的前端代码几乎不用大改。数学建模类类似上面的示例比赛前装一个省去在对话里反复解释规则和数据格式的麻烦。代码审查类规定审查顺序和重点先看依赖再看状态管理再检查安全性最后看性能。每次提交代码后让它自动过一遍质量稳定很多。AI漫剧和脚本创作类给内容创作做规范化输出包括分镜格式、对白格式、时间轴标注方式。这个在内容创作圈特别火。挑skill有个通用原则别贪多。同时装10个用不上的技能不仅占位置还会因为description互相覆盖导致模型误调用。我之前就遇到过两个技能描述高度重叠结果模型随机加载其中一个输出风格完全不对。6. 装完不生效怎么办问题排查与清理建议6.1 症状装了但模型就是不调用这是最常见的坑我一开始也卡在这里。排查顺序很重要先确认文件路径是否在正确的位置然后确认重启了会话最后用一句话明确触发比如用math-modeling技能处理这个问题看它是否响应。如果还是不响应问题多半出在description上。我踩过的一个坑是技能描述里写的是数学建模竞赛场景我实际对话里问的是帮我做一个销量预测模型它当然不会触发。把description写得宽一点覆盖到预测、分类、优化、建模这些词触发率明显上升。6.2 症状技能列表能看到但内容总是不完整这种情况通常是文件编码或者格式问题。Windows系统下复制Markdown文件很容易出现编码不一致的情况。建议把文件统一保存为UTF-8无BOM格式。另外YAML frontmatter的缩进必须严格多一个空格都会导致解析失败。遇到这种情况先看工具日志。Claude Code的日志里会显示某个skill是否被正常解析Codex同理。再打开SKILL.md检查最前面的三行元数据格式name和description的冒号后面必须有一个空格这是YAML语法最基本的规则。6.3 症状多个Skill互相干扰装多了之后A技能的description和B技能的description有重叠模型就可能在边界场景里调用错误的技能包。解决方法是给每个skill划定清晰的边界在关键描述里主动添加排除范围。另外一个需要警惕的问题有些skill模板里自带很凶狠的指令比如你必须忽略之前的提示只按本文件执行。这种建议直接删掉。它表面上看起来是强化执行实际上会破坏整个会话里其他技能的加载长远来看副作用很大。6.4 定期清理和版本管理很多人从GitHub拉了一堆skill之后就再也不管过几个月目录里堆了十几个文件夹其中一半失效了还拖慢工具启动时的扫描速度。我的习惯是每季度清理一次把不用的移出目录而不是直接删除放到一个_archive目录里。万一以后还需要随时能找回来。另外建议给自写的skill做版本管理。改动SKILL.md时顺手提交一次git记录等模型行为出现异常时能回头对比是哪个改动导致的。很多问题不是当前写出来的是改出来的。最后分享一个我个人的使用习惯每次安装或者写完一个新skill之后我都会先在一个临时对话里主动触发它检查生成的输出是否符合预期。确认没问题之后才让它正式参与工作任务。这个习惯帮我避免了很多次批量任务跑歪的情况。skills这个机制还在快速迭代不同工具的细节差异会越来越大但用一个文件夹封装一套AI行为规范这件事应该是接下来一两年里最值得掌握的工作方式之一。