聊到AI编程助手最近绕不开的一个词就是skills。前有 Claude Code 把 Skills 当作核心能力推后有 Codex、Cursor 这些工具跟进GitHub 上一夜之间冒出来各种awesome-skills合集、superpower skills仓库数学建模群里甚至开始流传“华为杯好用的 skills 清单”。不管你是写前端、做数据分析还是搞 AI 漫剧内容生产这套东西都已经开始影响你的工作流。这篇文章想从我的实际使用经验出发把 skills 到底是什么、怎么装、怎么写、怎么避坑讲透。先说结论skills 本质上是把“一段提示词 一套工作流 一堆脚本工具”打包成一个可以被 AI 助手随时调用的能力模块。它解决的最大问题是让 AI 助手从“每次都要现场教”变成“装好技能就会干”。这篇内容适合所有在用或准备用 AI 编程助手的人尤其是想自己开发 skills、或者被各种 skills 推荐刷屏却不知道从哪下手的同学。1. Skills 到底是什么一次把概念讲透1.1 从 Prompt 到 SkillsAI 助手的能力封装革命早先我们用 AI 编程助手靠的是什么靠的是写 Prompt。比如我让 Claude 帮我写一个 React 组件就得把需求、技术栈、代码风格、文件路径全说清楚。一次两次还行但同一个任务做十遍每次都要重复这些上下文效率很低而且每次生成的风格还不稳定。Skills 改变的就是这件事。它把“做某类任务”的完整方法提前固化成一个文件夹里面包括指导 AI 怎么思考的指令文本、可选的参考脚本、必要的规则说明、甚至示例代码。AI 助手在被问到相关任务时会自动加载这个技能然后按照里面的流程去执行。我打过一个比方传统的 Prompt 像是一份菜谱你每次做菜都要把菜谱翻出来念一遍而 Skills 像是一个会做这道菜的厨师你只要说“今天做水煮鱼”他自己就知道该腌鱼、炒料、淋油整套流程肌肉记忆般跑完。那这个“厨师”是怎么练出来的其实就是在 SKILL.md 这个核心文件里预先写好了任务拆解步骤、决策规则、输出格式、质量校验点。AI 模型读取这份指令后会按里面的约束来完成任务。所以 Skills 的效果下限基本取决于你写的 SKILL.md 质量。1.2 Skills 与插件、MCP、Agent 的区别刚接触 skills 的人经常会混淆几个概念插件Plugin、MCP、Agent、Skills。它们确实都在增强 AI 助手的能力但角度不同。插件偏向于“接入外部工具”。装了某个插件AI 就能操作浏览器、读写文件、调用 API。它解决的是“AI 手不够长”的问题。MCP 则是一个统一的工具接入协议像是给 AI 装了一个标准化的 USB 接口任何支持 MCP 的工具都可以插上就用。Agent 是一个具备自主规划、执行、反思能力的智能体它更像一个“项目经理”拿着目标拆任务调用工具去完成。而 Skills 解决的是“AI 会不会干活”的问题。它不关心工具从哪来关心的是面对某类任务时AI 有没有一套标准的、经过验证的处理流程。你可以把 Skills 理解成 Agent 的“职业技能证书”插件和 MCP 是它的“工具箱”Agent 是“项目负责人”。实际使用中这几个东西经常组合出现。比如一个数学建模的 Skill可能会通过 MCP 去连接本地的数据处理工具也可能会调用 Python 脚本执行计算最后用文档插件生成报告。Skills 本身不排斥其他机制它是任务层的封装其他是能力层的提供。1.3 什么样的任务值得做成 Skill这是很多人第一个踩坑的地方什么任务都往 skills 里塞结果库越来越臃肿真正用的时候 AI 反而不知道调哪个。从我的经验看值得做成 skill 的任务有三个特征。第一重复性强你一个月内会用到三次以上。像“给 React 项目搭组件目录结构”“对 CSV 数据做标准化清洗”这种高频任务就值得固化。第二流程固定且有明确步骤每一步都知道该怎么做不需要太多自由发挥。第三有专业领域判断逻辑比如数学建模里“如何根据数据特征选回归模型”这种经验性知识很难靠一次 Prompt 说清楚写成 skill 之后 AI 每次都能按经验规则来。反之一次性的、探索性的、结果特别依赖临场创新的任务不适合做成 skills。比如“帮我看看这段代码哪里有问题”这种适合直接对话固化成 skill 反而绑手绑脚。2. 从零上手怎么把 GitHub 上的 Skills 装进你的助手2.1 不同助手的 Skills 目录与配置方式装 skills 的第一步是搞懂你用的工具把技能放在哪个目录。目前主流几款编程助手的做法略有差异但大方向一致都是在你本机的用户配置目录下建一个 skills 文件夹。以 Claude Code 为例它会读取~/.claude/skills/目录下的所有技能文件夹。每个技能一个子目录里面必须有SKILL.md文件。Codex 则是放在~/.codex/skills/结构和 Claude 的类似。Cursor 目前也支持类似的 skills 机制具体路径要看版本可以在设置界面里找到 Skills 管理入口。安装方式通常有两种。一种是直接git clone到对应目录一种是下载压缩包解压进去。我个人推荐用 git clone因为后续能通过git pull更新技能版本不用反复手动下载。cd ~/.claude/skills git clone https://github.com/example/some-skill.git如果你用的是 Codex把路径换成cd ~/.codex/skills git clone https://github.com/example/some-skill.git这里有一个容易忽略的坑很多 GitHub 仓库是仓库根目录直接就是技能但也有的仓库里包含多个技能每个技能在各自的子目录中。后者一定要把对应的子目录 clone 到 skills 目录里而不是把整个仓库塞进去否则 AI 读不到 SKILL.md。2.2 常用的 Skills 来源网站和仓库推荐GitHub 是最大的 skills 来源地但找起来确实费劲。我平时主要刷这几个地方。首先是各家的官方示例库。Anthropic 官方维护了一个 skills 示例仓库里面包含了一些常见任务的参考实现质量比较高。还有一些组织做了聚合仓库比如 awesome-claude-skills 这类列表型项目会把分散在各处的 skills 按领域整理好适合找灵感。其次是社区热门项目。superpower-skills 算是一个出圈的项目收集了大量可以直接用的 skills从写代码到写文档都有。它的安装方式比较友好很多技能下载下来就能直接用。typesafe-ai 的 skills 仓库也值得关注这个组织做的 skills 偏 TypeScript / 全栈方向对前端开发者特别友好。再就是各个作者自己维护的独立仓库。搜索时可以按skills、claude-skills、codex-skills这些关键词来找注意看仓库的 star 数、更新时间、README 里的使用说明。干净、有文档、有示例的技能才能放心用。2.3 安装后如何验证和管理装完不等于能用了。我每次装新 skill 都会做三件事。先检查目录结构。确认 SKILL.md 在正确位置而且 frontmatter 格式没坏。很多技能装完不生效就是因为在复制过程中把 YAML 格式弄乱了或者文件名大小写不对。SKILL.md 是强制要求skill.md或Skill.md都不被识别。再测试触发是否正常。重新启动一次 AI 助手会话然后用贴近该技能描述的自然语言提一个需求观察 AI 是否主动使用该技能。如果它只是泛泛地回答而没有加载技能可能是 SKILL.md 里的 description 写的太窄AI 识别不到或者你需要把需求问得更明确。最后做一次质量抽检。用技能产出一个实际结果看看输出质量是否真的比不用技能时更好。如果差不多甚至更差这个技能大概率不值得留。3. 真正理解 Skills一次完整开发实战3.1 Skills 的标准目录结构想用好 skills光会装不够最好自己会写。先看标准结构。一个规范的 skills 目录大致长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── run.py ├── assets/ │ └── template.html ├── rules/ │ └── style.md └── references/ └── faq.mdSKILL.md 是整个技能的核心入口所有行为指令都靠它来传达。scripts 目录放可执行的脚本assets 放模板、样例、静态资源rules 放附加的规则说明references 放参考文档。这些辅助目录不是必选项但一个好技能通常会用它们来减少主文件的冗余。写 SKILL.md 的时候frontmatter 是最关键的部分。一个标准的 frontmatter 长这样--- name: react-component-generator description: 用于生成 React 组件代码。当用户需要创建新的 React 组件、页面或重构现有组件时使用。 allowed-tools: - read_file - write_file - bash ---其中name是这个技能的唯一标识description决定了 AI 在什么情况下会触发这个技能。这是最重要的字段写不好整个技能就形同虚设。allowed-tools是可选字段用来声明这个技能可以调用哪些工具起到权限控制作用。3.2 写好 SKILL.md 的关键细节很多第一次写 skill 的人把 SKILL.md 当成一篇长篇大论的文章来写结果 AI 读完抓不住重点。我的经验是SKILL.md 最好具备四个部分任务定义、执行步骤、质量要求、边界与兜底。任务定义部分要写清楚这个技能解决什么问题适合什么场景不适合什么场景。执行步骤是核心尽量用有序列表把每个阶段拆开每个步骤里说明输入是什么、要做什么处理、输出是什么。质量要求部分则要给出可检查的验收标准比如“生成的代码必须通过 TypeScript 编译”“图表必须包含数据来源标注”。边界与兜底是很多人忽略的但特别重要。要让 AI 知道什么时候该停下来问用户而不是继续瞎做。比如“如果数据缺失超过 30%不要填补直接返回清洗报告”。还有几个细节要注意。描述要具体到场景不要写“用于前端开发”这种宽泛话要写“当用户需要生成一个新的 React 函数组件且项目使用 TypeScript 时”。步骤里的动词要明确避免“分析数据”这种模糊指令改成“按时间粒度聚合数据分别计算每组的均值、中位数、缺失值占比”。示例要给够一个复杂技能配上输入输出的示例AI 的理解准确度会提升一大截。3.3 前端开发 Skills 案例拆解拿前端开发来举例。我常用的一个自定义技能是“React 组件脚手架生成器”。以前我建一个页面组件要手动写组件文件、样式文件、storybook 故事、单元测试一套下来十几分钟。现在一个 skill 搞定。这个 skill 的 SKILL.md 里我把流程拆成了五步。第一步识别技术栈确认项目用的 TypeScript 还是 JavaScript、样式方案是 CSS Modules 还是 Tailwind。第二步生成组件主文件按项目的目录规范放到指定路径。第三步生成配套的样式文件和类型定义。第四步生成基础测试用例覆盖渲染、交互和异常输入。第五步跑一次 lint 和类型检查如果有问题自动修复。为了让 AI 不跑偏我在质量要求里写明了“所有生成的代码必须遵循 ESLint 规则”“测试文件必须包含至少两个用例”。在边界部分写清楚了“如果用户想要的是 class 组件而不是函数组件停下来询问确认”。实测下来这个技能把前端里最机械的活接管了我只需要检查 AI 生成的代码是否符合项目风格微调几处就行。省下来的时间不是几分钟是一天里好几次“切换上下文再切回来”的损耗。3.4 数学建模 Skills 案例拆解另一个很有代表性的场景是数学建模竞赛。群里流传的那些“数学建模 skills 推荐”指向的其实就是这类技能。比赛时间紧、任务重、流程固定几乎每个队都要做数据处理、模型选择、论文排版这几件事特别适合做成 skills。一个实用的“数模论文助手” skill流程大概是六步。第一步读取题目和数据文件明确目标和约束。第二步数据探索输出缺失值、异常值、分布特征报告。第三步根据数据特征推荐模型比如数据量小且线性关系明显时推荐回归样本量大有分类标签时推荐随机森林或 XGBoost。第四步生成 LaTeX 论文框架把摘要、问题分析、模型假设、模型建立、求解结果、模型检验这些章节铺好。第五步根据模型输出自动生成图表并统一图表风格。第六步做结果校验检查单位、有效数字、图表编号。这个技能的价值在于它把指导老师平时反复强调的那些赛题经验直接固化了。AI 每次建模的时候都会按照“先探索、再选模型、再验证”的顺序走不会漏掉关键步骤。比赛场上比的本来就是谁少犯错有了技能兜底至少能少犯低级错误。数学建模还有一种常用技能是“数据清洗与特征工程”处理那种动辄几十万行、一堆缺失值和乱编码的数据集。技能里规定了对缺失值采用“看缺失比例决定删除还是插补”的逻辑对异常值用 IQR 方法识别对分类特征做编码转换每一步还要求输出处理前后的对比。这种流程化操作正是 skills 最擅长的事。4. 常用 Skills 源与选型心得4.1 值得收藏的 Skills 合集我平时收藏的 skills 来源大致可以分为三类。第一类是官方与半官方示例库。Anthropic 官方 skills 仓库是首选里面的示例代码和文档风格非常规范适合作为学习范本。TypeSafe AI 的仓库也属于这一梯队它的每个技能都配有详细使用说明代码质量普遍在线。第二类是社区大而全的集合库。superpower-skills 是最有代表性的一个收录了几百个技能覆盖面从编程到写作到音视频脚本。这类库适合刚开始探索时批量试水但我不建议全部安装只挑自己真正用得到的部分。第三类是垂直领域小仓库。比如专门做数据科学的 skills、专门做前端工程的 skills。这类技能往往出自一线从业者之手场景颗粒度更细用起来也更顺手。4.2 怎么挑选靠谱的 Skills装多了之后你会发现skills 质量参差不齐有的装完体验惊艳有的装了等于没装。我总结了一套筛选标准。先看作者。优先选择有技术社区背书、平时活跃在开源项目里的作者。再看更新频率超过一年没更新的技能大概率不兼容新版模型。三看 README 质量真正用心的作者会写上详细的安装说明、使用示例、注意事项那些几行字匆匆带过的往往内容也敷衍。四看 skills 的设计如果 SKILL.md 里 description 写得宽泛随意执行步骤模糊不清基本可以放弃。还有一个容易被忽略的指标技能是不是过度依赖特定脚本。有的技能喜欢调用一大堆外部工具装起来很麻烦跑起来还可能因为依赖版本冲突挂掉。我倾向于选那些以指令为主的技能脚本越少维护成本越低。4.3 Skills 的清理与维护skills 装多了之后最常遇到的不是某个技能坏了而是技能之间互相抢占触发。AI 看到你的需求可能同时匹配两三个技能表现就会变得很奇怪甚至把两个技能的流程混合在一起执行。我在实际使用中养成了一个清理习惯。每两周整理一次技能目录把不常用的技能移到一个archive目录下归档而不是直接删除。这样既能保留备用的又不会干扰主技能库。不同类别的技能我还会分区管理。比如frontend、>