最近“skills”这个词在AI编程圈里热度一路飙高从Claude Code到Codex再到OpenCode几乎每个主流AI编码工具都在往自家产品里塞进“skills”能力。作为一个长期折腾各种AI工作流的人我前前后后把skills相关的工具、仓库、写法摸了个遍也踩了不少坑。这篇就把手动装GitHub上的skills、自己写skills、以及清理技能库的经验完整捋一遍希望能帮到正在纠结“skills怎么装、怎么选、怎么用”的朋友。1. Skills到底是什么从“叠提示词”到“自带技能包”1.1 一个让AI从“聪明”到“专业”的机制很多刚开始接触skills的人第一反应是“这不就是提示词吗把我常用的prompt格式化成文档有什么新鲜的”这个理解方向对了一半。skills确实可以理解为一套经过结构化编排的提示词集合但它和直接在对话里粘贴prompt有本质区别。你可以把AI工具当成一个刚入职的实习生没有skills的时候你每一次都要重新交代流程、格式、边界、示例它才能像一个熟手一样干活。而skills相当于给这个实习生发了一套标准作业手册他每次遇到这类任务自己就知道去翻手册、按流程走、输出指定的格式。对它本质上就是给AI提前准备好的“作业指导书检查清单样例库”而且是可复用的。我实际用下来的感受是没有skills的时候让AI写一个数据分析报告我得在提示词里反复强调“先看数据分布、再检验相关性、最后给结论结论要带置信度”。有了skills之后我只说一句“用数学建模工作流看一下这份数据”AI就会自动按标准流程干活输出的结构、风格、详略程度都是高度统一的。这个“一次安装、长期复用”的体验才是skills真正的价值所在。1.2 Skills vs MCP vs 插件别再傻傻分不清我知道很多人会把skills和MCPModel Context Protocol弄混。这两个东西的关系经常被网上各种文章绕晕我的理解是MCP解决的是“AI能不能连上外部数据源和工具”的问题比如读数据库、调用API、操作浏览器、查文件系统它给AI提供的是手脚而skills解决的是“AI在干活时懂不懂这个领域的门道”的问题它给AI提供的是脑子里的经验。举个实际例子。你给AI接了一个MCP服务器它就能直接连上你的数据库但你希望它查数据时遵循“先看表结构、再写查询条件、最后对结果做质量校验”这套流程这就得靠skills来约束。一个管手、一个管脑两者互补不是同一层的东西。那插件呢插件是一个更大的概念可以理解为包含了MCP连接、skills、自定义命令等所有扩展能力的“大盒子”。所以你在GitHub上看到一个项目叫“XX插件”它里面可能同时有skill目录、MCP配置、以及各种工具脚本。理解了这个层次关系你就能大致判断自己缺的是哪一块不会装了一堆无关的东西。1.3 谁适合用Skills用之前先想清楚坦白说不是所有人都需要马上尝试skills。如果你平时只是用AI聊天、写点零散文案那花时间整理skills是纯浪费。skills的典型受益人群是这两类一类是有固定重复工作流的人比如每周都要出数据分析报告、经常要写同结构的代码模块、或者反复做同一类型的审核检查这类人把流程沉淀成skill边际收益极高。另一类是追求输出一致性的团队比如一个小组十几个人都用AI辅助写代码如果每个人都各写各的prompt产出的代码风格五花八门review成本极高。这时候把团队的编码规范、架构约束做成一个共用skill所有成员让AI干活时都会自动遵守同一套规则相当于把团队最佳实践固化到了AI层。关于“如何学习skills”这件事我的建议是先花一周时间记录自己跟AI的高频交互看看有没有重复出现的任务。如果每次都让AI做同类事情却要重新组织语言那这个任务就值得做成skill如果每次任务都不同没有可沉淀的固定模式skills对你来说就是个“看起来很强但用不上”的花架子。学习技能包的最好方式不是看大量教程而是直接装一个、用一个、改一个从别人的落地例子里感知什么叫“可执行的流程说明”。我顺便想说一下为什么这个词会在热搜里这么火。其实不是skills本身有多少创新而是AI编码工具厂商把“技能包”做成了标准化交付物GitHub上出现了大量可直接安装的skills库比如superpower skills这类打包合集。对普通用户来说创建一个新skill的成本从“自己写一套完整提示词系统”降到了“克隆一个仓库并放到指定目录”门槛降了一个数量级自然就火起来了。这也解释了为什么那么多人搜索“怎么手动装github上的skills”——因为大家最常见的需求根本不是自己开发而是把别人做好的技能包拿过来用。2. 手动安装GitHub上的Skills全流程2.1 安装前先搞清楚你的工具支持哪套规范这是我觉得最关键的步骤也是很多人安装半天不生效的根本原因。目前市面上支持skills的主流工具各自对“skill应该放在哪里、用什么格式定义”是有差异的不能说你在Claude Code里装好的路径拿到Codex里就一定能用。我建议动手之前先做三件小事第一确认你正在用的AI编程工具版本是最新的skills功能往往依赖新版本第二打开工具官方文档搜一下skills或者agents相关的说明看它支持的目录路径第三如果你用的是某个二次封装或集成工具别直接套用社区教程的路径最好先看一下这个工具自己的配置目录结构。不同工具对skill的定义文件名也可能有差异有的用SKILL.md作为入口有的可能用AGENTS.md或者依赖manifest文件。这不是智商税而是各家实现方式不同。你只需要认准自己工具官方说的那个文件名和目录结构就行其他的先不要乱试。2.2 Claude Code手动安装git clone 目录放置我们以目前社区讨论度最高的Claude Code为例手动安装一个GitHub上的skills标准流程其实就三步。第一步找到你要安装的skill仓库。在GitHub上搜索时关键词建议带上“claude skills”或“agent skills”比如你想找前端开发相关的就搜“claude skills frontend”这样命中的仓库更精准。第二步把仓库克隆到本地的skills目录。常见的位置有两种一是用户级别的全局目录通常是~/.claude/skills/放到这里面之后你在任何项目里都能用到二是项目级别的目录通常放在项目根目录下的.claude/skills/这样只有在这个项目里才会生效。部分工具也允许你把skills放到工作区配置目录里以官方文档为准。命令也很简单git clone https://github.com/作者名/skill仓库名.git ~/.claude/skills/skill名称如果仓库本身就符合skill目录规范克隆下来直接就是一个可用的skill如果仓库里嵌套了一层子目录你再手动把对应的skill文件夹复制到目标目录即可。第三步验证安装。装完之后重启你的AI编程终端在会话里输入查看skills的命令不同工具的命令不太一样一般是/skills或/agents或者直接在对话里问AI“你现在有哪些可用的技能”让它描述一遍。如果能列出来说明安装成功了。我再补充一个很多教程不会跟你说的细节如果某个skill仓库里除了SKILL.md之外还有一堆辅助脚本和资源文件一定要整个目录一起克隆下来别只复制一个md文件进去否则AI按照skill里的流程执行时找不到配套的工具和参考数据效果会大打折扣。我自己最开始就只复制了md结果skill一直说“需要读取references目录下的文件”排查了半天才反应过来是少复制了资源文件。2.3 Codex、OpenCode等工具的安装差异除了Claude Code现在Codex、OpenCode等工具也都在接入skills生态。Codex的安装方式跟Claude Code略有不同它更强调通过配置文件来声明很多情况下你需要把skill的内容合并进已有的agent配置里而不是简单地往某个目录丢一个文件夹。OpenCode则是一个对社区skills兼容性做得比较好的工具你经常能在GitHub仓库的README里看到“这个skill同时支持Claude Code和OpenCode”的说明。这种情况下安装方法基本还是那三板斧克隆仓库、找到对应平台的目录、放置后重启验证。像codex nature skills这类仓库就是作者围绕Codex的agent行为做的一整套配置与skill打包通常自带Codex配置文件安装前要特别留意它适配的Codex版本。我必须提醒一件事社区里的skills仓库经常是多平台通用的但不同平台的版本更新节奏不一致有可能skill作者只在某个平台测试过另外的平台只是顺手加了个说明。所以安装后如果发现表现不如预期先别急着怀疑自己的操作看看这个仓库的issue区域有没有相同平台的踩坑反馈大概率不是你一个人的问题。另外还有一个需要留意的点不是所有叫“skill”的仓库都真的是skill。有些仓库打着skill的旗号实际内容是普通的prompt合集充其量算“写法参考”并不能直接安装到你的工具里。判断方法很简单看仓库里有没有标准的SKILL.md或对应的skill定义文件没有的话就是纯提示词分享你可以手动把内容拿去做参考但别指望粘贴路径就能生效。2.4 装完怎么确认真的生效了很多新手安装完明明提示成功了但用起来总觉得AI没什么变化这时候就需要一个可靠的验证方法。我的建议是做一个“最小化实测”构造一个这个skill本该最擅长的任务用一个非常简短的提示词去触发它比如你装了一个“数学建模工作流”的skill就直接说“帮我对这份数据做一次完整的建模前探索”然后观察AI的行为。如果你用的是带网页端的AI编程工具通常在网页设置或左侧面板里也能看到当前已加载的skills列表列不出来就说明根本没装进对应环境。如果AI没有按skill描述里的流程走大概率是几种情况一是skill根本没被加载二是被加载了但描述里的触发词跟你说的对不上三是同一类任务同时有多个skill覆盖AI不知道选哪个。这些我会在后面的问题排查章节里细说这里先给个结论验证的关键不是看“安装成功”的提示而是看行为是否真的发生了变化。3. 常用Skills源网站与场景化推荐3.1 去哪找靠谱的Skills写到这里肯定有人要问“那我到底该去哪找skills”我平时主要会逛三类地方。第一类就是GitHub的聚合仓库搜索“awesome skills”或者“awesome claude skills”这类仓库通常会把社区里口碑好的skill按场景分类整理作者信息、描述、star数都写得很清楚适合从零开始逛。第二类是开发者自己维护的单一skill仓库作者往往会在README里写清楚适用场景、效果截图、安装命令甚至给出测试用例。这类仓库可能star数不高但胜在针对性极强比如某个专门做数学建模论文排版的skill就是这类。第三类是社区论坛和社交平台上分享的技能包不过这类内容质量参差不齐我看的时候会格外留意三点一是看有没有提供原始GitHub链接纯截图或者纯文档描述的我不太敢直接用二是看评论区有没有其他人反馈实测效果三是看作者有没有维护说明或者更新记录。这三关过了我才会把它加到安装清单里。另外仓库命名里带有typesafe、ai、skills字样的合集通常更注重工程化质量比如类型定义和版本管理做得更完善用到生产环境更放心而像cola skills这类名字相当风格化的仓库就更要拿上面的三关原则去严格要求——先看README是否写清边界再看issue区有没有人踩坑最后看最近是否还有更新记录。这三关过了我才敢放心装进环境。3.2 数学建模与竞赛场景华为杯、美赛都适用热搜词里好几个都指向数学建模那就重点说说这个场景。数学建模竞赛比如华为杯、美赛的典型流程是题目理解、数据收集与清洗、模型选择与实现、结果可视化、论文写作与排版。每个环节其实都可以对应一个独立的skill或者做成一个组合skill。我实际用过觉得值得推荐的组合是一个数据探索skill负责自动做EDA分析、生成分布图、相关性矩阵并对缺失值和异常值提出处理建议一个统计分析skill负责输出描述性统计、显著性检验、回归分析的完整流程一个论文排版skill负责按照竞赛模板要求组织论文结构生成LaTeX或Word格式的章节框架。这三个叠加起来能把建模流程里最耗时的杂活压缩一大块。如果你是Codex用户在GitHub搜索时直接加上codex skills关键词就能找到适配Codex的数学建模类仓库。有一点要注意竞赛场景下AI产出的东西必须经过你自己验证特别是模型结果和数值不能无脑采用。skill再强也只是助手你的名字会出现在最终报告上数据错了是要扣分的。所以用这类skill时我自己的习惯是让AI把每一步的推导过程和计算依据都写清楚我会快速复核一遍再进入下一步。3.3 前端开发与AI漫剧两类高频需求前端开发是另一个skills高频需求场景。这里我推荐优先找这几类skill设计稿转代码、组件生成与代码风格格式化、可访问性检查、性能预算检查。设计稿转代码这个技能包一般会内置常见CSS布局模式、设计规范映射规则能让AI生成的界面更接近设计意图可访问性检查技能包则能让AI在生成代码之后自动跑一遍无障碍规则省得你再手动review。AI漫剧这个场景最近讨论度也很高核心痛点其实不是“生成一张图”而是“保持角色一致性”和“分镜叙事连贯”。所以这个领域的skills通常会包含分镜脚本生成、角色外观库维护、镜头语言描述、文生图提示词模板。比如你给AI装一个“分镜skill”它就能根据你的脚本自动拆出景别、运镜、时长、对白然后输出给绘画模型使用。我的观察是这类创作类skill的发挥水平很大程度上取决于你喂给它的素材质量。如果角色设定写得语焉不详再强的分镜skill也救不回来。所以装完之后第一件事应该是把你自己常用的角色库、画风描述、场景设定整理成配套文档跟skill放在一起效果会好非常多。4. 从零写一个属于自己的AI Skill4.1 一个Skill的本质就是一套说明书会用了别人的skill之后你迟早会冒出“我也想要一个专属skill”的念头。别怕自己写skill其实没有想象中那么神秘它的本质就是给AI写一套结构化的说明书让它遇到相关任务时按照说明书工作。一个标准的skill目录通常包含一个SKILL.md作为入口文件里面用YAML格式写元信息比如name、description正文部分写清楚这个skill适合处理什么任务、任务的标准流程是什么、输出格式应该长什么样、有哪些必须遵守的边界和禁忌、以及可以参考哪些同目录下的辅助材料。如果你在skill里需要AI读取特定数据或模板可以在同目录下放references、templates、scripts之类子目录然后在SKILL.md里引用。写作时有一个关键原则你是在跟AI“约定行为”不是在教一个新手程序员。所以不要写“请逐步分析问题”而要写“当收到一个含数值型列的数据集时第一步应检查该列是否存在缺失值若缺失率超过20%应在结果报告中标注”。给AI的说明书越具体、越可执行、越带条件判断它的行为就越稳定。4.2 编写SKILL.md的四个关键节奏结合我自己的踩坑经验写一个靠谱的SKILL.md至少要把握四个节奏。第一个节奏是描述要精准。SKILL.md开头的description是AI决定“该不该调用这个skill”的依据如果描述写得太宽泛比如“负责所有数据分析任务”AI会频繁误调导致一个skill把其他任务的活也抢了。最好写成“负责探索性数据分析生成描述性统计、分布图、相关性分析并输出中文结论”明确边界。第二个节奏是流程要带分支。不要只给一条直线流程要把任务中可能出现的常见分支写进去比如“若数据中存在重复行应先去除并记录处理数量若目标列是时间序列应优先绘制时序图”。AI在分支选择上天然擅长只要你的说明书给了它判断依据它会执行得比写死规则更灵活。第三个节奏是示例要具体。每一条关键输出要求后面最好配一个简短的期望输出样例甚至是一段配了注释的代码片段。AI看到“你要输出的是这样的东西”比看十遍“请按规范输出”都管用。这跟人带新人是一个道理给个成品参照比反复讲道理快得多。第四个节奏是边界要明确。明确写出不许做什么有时比写要做什么更重要。比如“不得在未提供数据来源的情况下编造统计显著性结论”“不得在生成图表时隐藏缺失值”。给AI设边界是防止它在真实任务里自由发挥导致翻车的关键。4.3 发布与维护让其他人也能用你的Skill自己写的skill除了本地自用很多人也乐意发布到GitHub上分享。发布前我建议做一轮完整自测就是拿不同类型的输入去触发这个skill看它在正常场景、边界场景、异常输入下会不会乱来。自测通过后把skill目录整理成标准结构在仓库根目录写一个README说清楚适用场景、安装方法、效果示例再加一个简单的目录树。发布到GitHub之后要留意的反而是后面的事情。你的skill可能会被其他人拿去用由于不同AI工具的实现差异人家装完可能表现得跟你本地不一样。我建议在README里写明“本skill在XX工具XX版本下测试通过”并留下反馈渠道。随着AI工具版本迭代你认为写得很好的skill规则可能会被新版本废弃或弱化就需要定期回来更新。写skill这件事最容易被低估的是维护成本。别把自己的skill库当成只写不修的存盘点最好每过一两个版本周期就回头看看还有没有人在用描述是否还匹配现有词边界设置是否过时把这些随时调整好你的skill才会越用越顺手而不是越积越废。5. Skills管理与清理安装一时爽长期垃圾场5.1 为什么Skills会越装越乱Skills的安装成本太低了低到很多人会同时往自己的环境里塞几十上百个skill。装的时候很快等真正跑起来就会发现AI在决定调用哪个skill时经常无所适从有些skill描述相似导致互相抢活有些skill占用大量上下文导致响应变慢还有些老仓库里的skill规则跟新版本AI已经水土不服。我见过最典型的乱象是一个人装了“通用数据分析”“数学建模工作流”“统计检验助手”三套skill然后喂一份简单数据让AI跑均值结果三个skill分别给出一套流程输出风格互不统一最后还得自己手动整合。这种混乱不是skill本身的问题而是安装阶段没有做规划和去重。5.2 清理Skills的实操套路社区里关于清理skills的讨论不少我记得有个开发者分享过一套比较系统的清理方法核心思路就一句话先审计后取舍。具体展开就是三步。第一步盘点清单。把你环境里所有已安装的skill列出来逐个记录它的名称、功能定位、最近一次生效是什么时候。如果你连某个skill是干什么的都回忆不起来它就是清理候选。第二步留强去弱。对每个skill做一次“有用性评分”我的评分标准就三条这个skill在过去两周内是否被动用过它是否在某个任务上表现明显优于无skill状态的AI移除它是否会让现有工作流直接瘫痪三条全中的是核心保留项一条不中的果断删掉处于中间的先移动到备份目录观察两周再做决定。第三步删前备份。删除skill之前别直接把目录销毁先移动到一个统一的备份目录至少要保留一个发布地址或版本记录。万一你删完发现某些旧任务还是离不开它备份目录就是你的后悔药。另外我强烈建议给已经确认要长期保留的skill建立版本锁定。很多工具允许你锁定某个skill的版本避免哪天更新后行为大变。社区里流传的“tibo的清理方法”这类经验贴本质上都是在这三步基础上加上了各自的优先级判断你完全可以照着自己的习惯调。5.3 保持Skill库健康的几个原则经过几次大清理之后我现在给自己定了几条原则分享出来给大家参考。限量原则同时安装使用的skill不超过8到10个每个重要领域最多一个不搞同类备份。场景原则全局只放那种真正“跨项目通用”的skill比如通用的代码审查规范项目相关的skill尽量放项目级目录里项目结束就清理避免全局库越长越臃肿。更新原则不追新版本只在当前版本的skill出现明显问题或者官方有大版本升级提示时才去更新避免频繁变动导致行为不稳定。最后一条原则最朴素把skills当成你的工具柜而不是收藏夹。工具柜里的每一样东西都是要用到的收藏夹里的东西只会越堆越多、越来越积灰。每隔一个月花十分钟做一次快速盘点保持工具柜干净你的AI工作效率会直接上一个台阶。6. 常见问题与排查技巧6.1 装完不生效先查路径再查格式这个坑绝对排在第一。装完不生效八成是路径放错了或者格式不对。先核对你的工具版本是否支持skills再检查目录路径是否与官方文档一致特别要注意全局目录和项目目录的区别还有目录名称的大小写和拼接方式很多工具是区分大小写的。格式问题也不少见比如SKILL.md文件编码用了带BOM的UTF-8某些工具解析元信息会失败或者YAML frontmatter里冒号后面没加空格导致字段解析异常。这些错误平时人眼很难发现建议打开文件用编辑器看一遍或者直接用YAML校验器验证一下头部内容。6.2 行为不稳定、多个Skill互相“抢活”还有一种很常见的情况skill确实加载了但AI的行为忽好忽坏。这个时候最优先怀疑“多skill冲突”。两个描述相近的skill同时放在同一作用域AI在选择时会摇摆有时候用这个有时候用那个输出自然就不稳定。处理方式很简单把相近的skill分到不同目录作用域或者直接删掉其中较弱的那个。另一个原因可能是AI当前对话上下文太长skill里的关键指令被淹没在大量无关对话里。解决办法是开一个新会话再试一次不要让旧对话里的杂讯影响新任务的执行。我自己的经验是凡是感觉skill表现飘忽不定先开新会话往往一次就正常了。6.3 上下文被Skill文件撑爆注意资源文件体量skill不是越大越好。如果一个skill的目录里塞了几十份大型参考文档AI在触发这个skill时会把它们一起读进上下文这会让你的可用上下文迅速见底大任务根本跑不动。因此装完skill后我建议检查一下它的参考文件总体量如果单文本超过几万token就只保留与当前业务最相关的部分或者把资料按类型拆分到多个子skill里按需加载。如果遇到“上下文窗口不足”的报错而且确定不是当前任务本身数据量太大造成的那大概率就是skill的资源文件在拖后腿。这也是我对“superpower skills”这类合集类skill又爱又恨的原因它能力确实全但一次性全装会让很多任务都背上不必要的上下文负担最适合的做法是只摘取其中单独的子skill按需安装而不是整个合集一把梭。6.4 快速排查清单我把上面这些经验浓缩成了一张排查速查表遇到问题可以直接对照着看。症状可能原因快速处理skill完全无反应路径错误、工具不支持、格式解析失败核对官方文档路径与SKILL.md头部格式功能出来了但时好时坏多skill描述重叠、上下文被污染开新会话精简或移除重复skill上下文不足、响应变慢资源文件过大、skill数量过多精简参考文件控制同时保留的skill数量输出风格与预期不符描述触发词不精确、示例太少调整SKILL.md描述补充具体输出样例同一个任务被多个skill竞争描述范围互相覆盖收紧描述边界给高频场景保留唯一skill我个人的体会是在AI工具快速迭代的这几年里skills算是我见过少有的“给一点结构就能显著提升效果”的能力。它不需要你懂很深的算法只要愿意花点时间把经验整理成可执行的说明书AI就能稳定复制你的工作方式。这也是为什么我觉得与其去追那些各家厂商都在宣传的所谓智能体不如先把skill这套基本功打扎实。如果你看完还是觉得无从下手我的建议是从一个最小的实用skill开始练手比如把你每周都会重复的一类任务做成skill装上、跑通、优化你就会彻底明白这套机制到底是怎么回事。技能这东西跟技能包一样装上之后还得会用会用了才算真正属于你。