AI编程Skills全指南：从手动安装到自主编写与清理

最近“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和MCP（Model 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 Skill

4.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 快速排查清单

我把上面这些经验浓缩成了一张排查速查表，遇到问题可以直接对照着看。

我个人的体会是，在AI工具快速迭代的这几年里，skills算是我见过少有的“给一点结构就能显著提升效果”的能力。它不需要你懂很深的算法，只要愿意花点时间把经验整理成可执行的说明书，AI就能稳定复制你的工作方式。这也是为什么我觉得，与其去追那些各家厂商都在宣传的所谓智能体，不如先把skill这套基本功打扎实。

如果你看完还是觉得无从下手，我的建议是从一个最小的实用skill开始练手，比如把你每周都会重复的一类任务做成skill，装上、跑通、优化，你就会彻底明白这套机制到底是怎么回事。技能这东西，跟技能包一样，装上之后还得会用，会用了才算真正属于你。