最近跟几个做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上的现成skills2.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/skillsOpenCode同样有自己的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的性子跑。