最近跟几个做AI应用的朋友聊天，绕不开一个词：skills。无论是Claude Code、Codex还是OpenCode，大家讨论的核心已经从“怎么让模型读懂代码”转向了“怎么让工具在特定场景下自动干活”。skills就是把这类经验固化成文件，让AI助手在碰到对应任务时，自动加载一套标准动作、提示词和脚本。这篇文章我用自己的实操经验来讲讲skills到底怎么用、怎么写，以及怎么把GitHub上的现成skills装进来。适合正在折腾AI编程工具、想让工具更懂自己工作流的人，也适合刚接触AI辅助开发、听到“skills”一头雾水的新手。
先说个直观感受：没配skills之前，我的Claude Code每次做前端重构都要反复叮嘱“保持原有组件风格”、“注意TypeScript类型安全”、“别破坏现有接口”，结果它还是偶尔自由发挥。配好skills之后，同样任务一句话就能触发，AI自动按我定好的规范干活，输出质量稳定太多。这就是skills的价值——把零散的提示词沉淀成可复用、可分享、可版本化的“操作手册”。
1. skills到底是什么，为什么突然这么火
1.1 先给一个生活类比
我习惯把skills理解成“麦当劳的岗位操作卡”。一个新人店员不需要重新发明汉堡怎么包，只需要打开那张卡，上面写着：面包怎么烤、酱挤多少克、菜放几片、包装朝向。skills就是给AI的岗位操作卡，只不过里面的内容不是“烤面包”，而是“怎么帮你写代码、做数据分析、生成漫画分镜、完成数学建模”。
在Claude Code、Codex、OpenCode这类AI编码工具里，skills是一组带特定结构的文件目录。目录里通常有一个SKILL.md作为主说明书，可以附带脚本、模板、参考文档。当AI判断当前用户请求命中这个skill的描述时，就会自动加载它、按照说明书里的步骤干活。
这个设计解决的核心痛点，是“AI每次都要重新发明轮子”。你让它做数学建模，它不知道比赛文档有哪些套路；让它做前端页面，它不知道你项目的组件边界和风格规范；让它做漫剧分镜，它不知道角色一致性怎么保持。这些问题每个场景都不同，而通用大模型很难覆盖所有细分的“私房规矩”。skills把规矩写下来，让AI第一次就做对。
1.2 和MCP、AGENTS.md的区别
很多人会把skills和MCP服务器、AGENTS.md搞混，我一开始也踩过这个坑。MCP是给AI提供“实时工具调用能力”的，比如让AI能查数据库、调API、读文件系统，它解决的是“AI的手能不能伸出去”的问题，偏运行时和连接层。AGENTS.md更像项目级备忘录，写的是整个项目的工作约定，比如代码风格、测试要求、目录结构，AI在整个会话里都会参考它。
skills则是“任务级操作手册”，只针对某一类具体任务生效，命中场景才加载。用一句话概括：MCP给AI接上手脚，AGENTS.md给AI定项目宪法，skills给AI发具体岗位的作业指导书。三者有重叠但定位不同，实际项目里经常配合使用。比如一个数据清洗skill，内部可以通过MCP工具读取数据文件，再按照SKILL.md里的步骤做清洗，最后调用输出脚本生成报告。
1.3 社区为什么开始把skills当“资产”
GitHub上现在能搜到大量skills仓库，比如superpower这类把几十个常用技能打包成库的项目，也有typesafe ai skills这种偏工程规范的skill集合。越来越多的团队把内部沉淀的流程做成skills提交到公开仓库，像开源代码一样共享。原因很简单：skills是纯文本文件，跨平台、跨工具兼容，不进数据库、不依赖特定服务，很容易被复用和传播。对个人开发者来说，一套趁手的skills就是自己的“第二大脑外置接口”，换电脑、换项目、换工具都不丢。
2. 怎么手动安装GitHub上的现成skills
2.1 先说手动安装三件套
GitHub上很多skills项目都带install脚本或者配套安装命令，但我强烈建议你先会手动装，因为手动装一遍你能真正理解它的目录规范，后面自己写skills才不会懵。以Claude Code官方支持的结构为例，手动安装只需要三步：
第一步，找到仓库里的skills目标。大部分仓库会按skills/<技能名>/SKILL.md组织，也有放在src/skills或plugins/skills下的。打开仓库后直接在网页搜索框输入SKILL.md，能快速定位所有技能文件。
第二步，把整个技能目录下载下来。不需要下载整个仓库，除非你想把全部技能都装上。GitHub网页端可以在目录页面里逐个文件保存，也可以用仓库的下载包解压后只拿出需要的目录，或者直接用git clone拉下来再拷贝。我的习惯是clone整个仓库到本地临时目录，挑完再删掉，省得零散文件搞得乱七八糟。
第三步，放进工具能识别的目录。Claude Code支持两种位置：项目级目录.claude/skills/<技能名>/SKILL.md，只对这个项目生效；全局目录~/.claude/skills/<技能名>/SKILL.md，对所有项目生效。Codex也是类似思路，常见位置是.codex/skills，OpenCode同样有自己的skills目录约定。选哪种要看你的目的：个人通用习惯放全局，团队协作或者特定项目流程放项目级。
装完之后，重启工具或者新开一个会话，再测试一下。最简单的验证方法就是直接说一句跟技能描述相关的请求，比如装了一个“代码审查”skill，就让它“按技能里的规范审查一下当前代码改动”，然后看它的行为是不是明显“换了个人”。
2.2 命名、目录与版本管理
装skills的时候要留意命名冲突问题。不同仓库可能都有叫code-review的技能，如果同时装了两个，工具通常会报错或者随机加载一个，行为不可控。我的做法是装之前先看一眼目标目录下有没有同名文件，有的话比较一下哪份更新、哪份更适合自己，再决定覆盖还是改名。
另外建议把全局skills目录纳入版本管理。哪怕你只用一台电脑，也值得在全局skills目录下初始化一个Git仓库，定期提交。因为skills是文本，改动很频繁，今天加个步骤明天改个提示词，没有版本管理你很难回溯“上次明明还能用，这周怎么就不对劲了”。我甚至见过有人把全局skills目录托管到私有Git仓库，换电脑时直接clone下来，一秒恢复战斗状态。
还有一个小技巧：不要直接修改GitHub上clone下来的原文件，最好留一份“原版”和自己改过的“本地版”。因为社区仓库经常更新，你改了原文件之后，pull新版本很容易冲突。我自己的习惯是skills/<技能名>-local放改动版，原版保持干净，等原作者更新后手动把新特性合进local版。麻烦是麻烦一点，但比混乱强得多。
2.3 装完以后必做的验证
装上skill不代表能用，我见过太多人装完就说“没用啊”，结果一看是SKILL.md格式写错了。拿到一个skills之后，我建议按这个顺序验证：先确认目录层级是技能名/SKILL.md，不能多一层少一层，有些工具会递归扫描子目录，但规范起见还是保持两层结构；再确认SKILL.md带YAML头部，且name和description字段齐全，description写清楚了“什么时候该用这个技能”；接着在对话里明确触发它，观察AI回复是否引用了技能内容，有经验的工具会显示它加载了哪一个skill；最后跑一遍技能里要求的关键步骤，确保脚本可执行、无路径硬编码。
注意：有些skills项目里的脚本是给Unix系统写的，Windows上直接跑会报错。装之前看一眼脚本内容，涉及
bash专有语法或者绝对路径的，需要自己调整。我在Windows环境实测过不少GitHub上的skills，真正能开箱即用的大概只有七成，剩下的要么改路径要么改脚本解释器。
3. 手写自己的skills，从零到能用的完整过程
3.1 写作的核心原则：从场景出发，不要从技术出发
很多人第一次写skills容易犯的错误，是一上来就想“我要把所有知识都塞进去”，结果写出一份百科全书，AI加载后反而无所适从。正确姿势是从你反复遇到的场景出发。什么叫场景？就是你发现自己每两周就要给AI下同一串指令，或者每次都要把同一段提示词从记事本里翻出来。那个重复劳动，就是你的第一个skill。
我举个例子。以前我要让AI做数学建模的数据预处理，每次都要说一大段：“导入CSV、检测缺失值、异常值用IQR处理、统一列名格式、输出清洗报告”。说了一段之后AI还会遗漏细节。后来我把这段整理成一个matlab-data-cleaning的skill，把步骤、处理规则、输出模板全部写进SKILL.md。现在只要说“按建模规范清洗这份数据”，AI自动把整套流程走完，还能顺手生成报告。省下来的时间不是一点点。
3.2 SKILL.md的标准结构：YAML头部和正文
SKILL.md目前虽然没有一个全球统一的强制标准，但社区已经形成了事实规范。YAML头部至少要有name和description，这是AI决定什么时候触发这个skill的核心依据。description写得越准确、越具体，触发命中率越高。我看到很多新手在这里偷懒，写“用于数据处理”，结果AI把它当成普通数据处理工具在任何时候调用，反而污染上下文。好的描述应该是“在用户给出包含缺失值或异常值的表格文件、需要做清洗和预处理时使用，按统一规范输出干净数据和报告”。
正文部分则分成几个层次：先写这个skill的目标和适用范围，告诉AI这个技能解决什么问题、不解决什么问题；再写详细的执行步骤，用编号列表把它们按顺序列清楚，AI执行时最怕的是步骤之间没有强依赖关系，它容易跳步骤；接着写关键规则和禁忌，比如“不要修改原始文件”“遇到日期格式统一转换为ISO 8601”；最后可以附上一个示例，展示输入和输出长什么样。对于复杂工作流，还可以在SKILL.md里引用同级目录下的脚本或模板文件，让AI去调用，而不是把所有逻辑塞进一个文档。
3.3 一个数学建模场景的skill示例
我拿自己实际在用的一个数学建模预处理skill做拆解，你可以照着改。它的目录结构是这样的：
matlab-data-cleaning/ ├── SKILL.md └── scripts/ └── generate_report.pySKILL.md的YAML头部长这样：
--- name: matlab-data-cleaning description: 数学建模场景下对表格数据做清洗预处理，包括缺失值、异常值、格式统一和报告生成。当用户提到建模数据、CSV预处理、数据清洗、比赛数据处理时使用。 ---正文核心步骤我简化成四段：读取数据、质量检查、规则清洗、输出报告。质量检查不是随便看一眼，而是要求AI先输出数据的行列数、每列缺失率、数据类型和异常值数量，让用户对数据有一个全局认识。清洗规则我明确写成：缺失率超过30%的列直接丢弃；数值型异常值用四分位距法处理并用中位数填充；重复行去重；列名全部转换为小写下划线风格。最后要求AI运行scripts/generate_report.py生成一份Markdown报告，包含清洗前后的对比。
这套skill用起来的体验很爽：AI不再“自由发挥”，而是严格按照我规定的规则走。以前数据清洗结果每次不一样，现在只要数据源没变，跑十次都是一模一样的输出，这在数学建模这种需要复现的比赛场景里特别重要。
3.4 前端开发场景的skill示例
前端开发是我日常工作里用skills收益最大的一块。我给Claude Code写过一个前端组件生成skill，描述是“在用户需要新增React组件、且希望符合项目现有组件风格时使用”。它的正文核心是：先扫描项目里现有的组件目录，分析最近3个组件的代码风格；再创建新组件，Props类型定义必须完整，样式方案跟随项目已有方案，禁用内联样式；最后自动生成Storybook故事文件和基础单元测试。
这个skill最有价值的不是让AI“写代码”，而是让AI“按项目规矩写代码”。以前重构一个页面，AI能写出十种风格的组件，有了skill之后，它先看存量代码再动手，新组件跟老组件放在一起像同一个团队写的。我还在skill里塞了一条硬性规矩：新组件不得引入未在package.json中声明的依赖。这一条直接杜绝了AI乱装库的问题，实测节省我会后排查依赖的不少时间。
3.5 关于LLMskills规范和编写工具的选择
如果你正式想入坑skills开发，我建议去读一下开源社区里的skills规范文档，重点看几个方面：目录结构是否支持多文件、YAML里有没有allowed-tools之类的权限字段、正文有没有支持!command之类让AI执行本地命令的语法。以typesafe ai skills为代表的工程化项目在规范上做得比较严谨，很多思路值得借鉴。
写SKILL.md用什么编辑器不重要，VS Code、Obsidian甚至纯文本编辑器都行，它本质就是Markdown加YAML。我反倒建议你用专门的Markdown编辑器，因为它能实时看YAML语法有没有错。YAML头部一旦缩进错，整个skill可能不被加载，而且报错信息还很隐蔽，排查半小时算轻的。
4. 不同场景下值得装的skills推荐
4.1 数学建模和环境配置向
参加过数学建模比赛的朋友应该深有体会，比赛时间紧、任务重，光靠通用对话累死人。有人整理了一套“数学建模全家桶”，覆盖数据探索、特征工程、模型对比、论文图表绘制和摘要生成。我实测下来，最有用的两个一是数据清洗预处理skill，能把脏数据快速变成可直接分析的表格；二是论文配图规范skill，能根据比赛要求统一生成图表样式，字体、坐标轴、配色一次性到位，省掉了赛后大量调整排版的痛苦。
安装这类skills的时候，我建议特别注意脚本的依赖完整性。有些skill会调用pandas、numpy、matplotlib等Python库，如果你环境里没装，AI执行到一半会报ModuleNotFoundError。装完skill后先手动跑一次依赖检查比临场去查报错高效得多。
4.2 前端开发和代码工程向
前端方向现在有相当多高质量skills。我推荐几个方向：组件生成类skill，负责按项目规范产出新组件；迁移重构类skill，比如把class组件迁移到函数组件、把旧架构代码迁移到新框架；代码审查类skill，按照你团队的规范检查PR，输出结构化评审意见。这些比那些“万能写代码”提示词靠谱太多，因为它们不靠“让AI聪明一点”，而是靠“给AI明确一点”。
如果你是Codex用户，OpenCode用户，也能用类似目录结构装这些技能。不同工具之间可能有小差异，我在Claude Code上写的skill拿到Codex上基本都能用，只是触发机制略有区别。有个小技巧：下载社区skills时留意仓库的README，通常作者会写明兼容哪些工具，避免装完发现不认。
4.3 AI漫剧和内容创作向
AI漫剧是这两年的新玩法，很多人用AI批量生成分镜脚本、角色设定和漫画排版。这类skills的核心是解决“一致性”问题——AI画同一角色经常换脸换服装，漫画连续性和场景连贯性全靠一股“玄学”。我见过有人整理的漫剧分镜skill，在SKILL.md里要求AI每次先生成角色参数卡，固定角色特征，再根据剧本生成分镜，同时统一画面比例和风格关键词。这套思路跟纯提示词完全不一样，它是把“工作流”固化了。
装这类内容创作skills时，要留意它对模型能力的依赖。有些技能写得太“贪心”，要求AI一次完成角色设定、分镜、文案和排版，模型容易顾此失彼。好的漫剧skill通常把流程拆成多个阶段，每个阶段一个明确约束。选的时候看它的正文步骤数量，步骤太少的往往不够实用，步骤太多又容易超出上下文限制，一般5到8步是比较合理的区间。
5. 常见问题、排查心得与清理方法
5.1 装了skills但AI就是不用，怎么办
这是被问得最多的问题，通常有三个原因。一是description写得不好，AI判断这个任务跟技能描述不匹配，所以不触发。解决办法是让描述贴近真实用户用语，多列几个触发场景，不要写太抽象。二是skill放在项目级目录，但你当前的工作目录不对。比如你把skill放.claude/skills，却在另一个目录下提问，AI自然找不到。三是工具版本太老，旧版本对skills支持不完整，升级工具版本试试。我自己踩过最隐蔽的坑是插件管理器的缓存问题——skill文件更新了，但工具还按旧内容加载，重启工具或者清理缓存目录就能解决。
5.2 上下文膨胀和性能变差
skill数量装多了以后，AI在每次会话都要扫描所有skill的描述，虽然只有命中才加载正文，但扫描本身也会占用上下文空间。我在某个项目里一次性装了20多个skills，结果明显感觉对话响应变慢、理解质量下降。后来一查，发现那个工具把所有YAML描述都塞进了系统提示词。解决方案很朴素：精简数量。项目级目录只保留和项目强相关的技能，全局目录控制在10个以内，常年不用的先移出去归档，别躺在目录里占资源。
5.3 skill之间冲突怎么办
如果两个skill的描述都覆盖了同一个触发场景，AI可能左右为难，或者随机选一个。我以前装过一个“通用代码生成”skill和一个“前端React组件生成”skill，结果让AI写React组件时，它经常走错门。排查口诀是：先查YAML的description，调整其中一个的适用范围，让它们不要重叠；再查目录里是不是有重名的技能；如果两个技能必须共存，可以在描述里写清楚“当用户提到React时优先用A，提到Vue时用B”。冲突是stack出来的，不是玄学，文本层面一定能解决。
5.4 定期清理和“瘦身”方法
AI编程工具用顺手以后，skills会越攒越多，像手机App一样装的时候觉得“以后能用上”，实际上80%是吃灰的。我后来形成了一套清理节奏，大概是两个月做一次“技能审计”：先打开目录按修改时间排序，超过3个月没动过的技能标记为候选删除；然后逐个看description，如果自己都说不清楚这个技能是干嘛用的，直接删。删之前不要彻底删，而是先移到_archive目录观察两周，确实没有调用需求再清掉。这样既不心疼，又不会误删正在用的好东西。
如果技能数量实在多，建议把skills目录拆分成“核心库”和“扩展库”，核心库放高频刚需技能并同步到Git仓库，扩展库保留低频技能只存在本地。用软链接把核心库映射到工具目录，扩展库按需手动启用。这招我用了半年，再也没出现过“装了但找不到”的混乱情况。
提示：任何清理操作前，先看一眼有没有正在跑的会话在用相关skill。我干过一次蠢事，正跑着一个数据清洗任务，顺手把数据清洗skill目录挪了，结果AI跑一半找不着脚本直接报错。先确认无运行会话再动手，或者挪完立刻新建会话验证一下，别等出问题才反应过来。
写在最后的经验
我对skills最大的感悟是：它不是“提示词锦集”，而是一种把个人工作方法物化成文件的习惯。真正好用的skill一定是从你的重复劳动里长出来的，GitHub上那些热门的现成skill能给你灵感，但很难完全贴合你的场景。我建议你的第一个skill不要贪大，就写一个“每次最烦重复交代的那件事”，配上执行步骤、几条铁律和一个输出模板，用起来之后再慢慢迭代。也别追求一次写完美，SKILL.md是活文档，今天三步骤明天加一个脚本都是正常的。AI工具底层的模型能力每隔几个月就升级一次，但只要你手里握着这套“操作卡”，换什么工具、来什么新模型，你都能很快让AI按你的规矩给你干活，而不是你追着AI的性子跑。