如果你最近在用 Claude Code、Codex 这类 AI 编程助手肯定没少在社区刷到 skills 这个词。我最早也以为这只是个包装过的提示词玩法无非就是给 AI 多喂几段话。直到去年带队打一场数学建模比赛发现隔壁组用一组建模 skills把论文初稿、敏感性分析、可视化全都半自动跑完了我才意识到自己之前完全低估了这个东西。认真研究加实操了几个月之后我的结论是skills 不是锦上添花的玩具它是把 AI 从能聊天变成能交付的关键一环。这篇文章我会按自己的实际使用路径来写先讲明白 skills 到底是什么、解决什么问题再给出一套从 GitHub 手动安装的方法然后拆解怎么自己写 skill最后按数学建模、前端开发、AI 漫剧这几个高频场景聊聊选型和组合收尾是日常维护和个人踩过的坑。内容不绕弯子全部是我实操验证过的。1. 先搞清楚 skills 到底是什么1.1 它不是提示词是给 AI 的岗位说明书很多人第一次接触 skills 时的反应跟我一样这不就是把长提示词换了个文件夹放吗实际用下来会发现区别非常大。提示词是一段一次性发出去的指令你说了这遍AI 就照着这遍办下一轮对话如果没有上下文了它就可能忘得干干净净。而 skills 是一套可复用的、结构化的专业工作流它被存放在固定的目录里每次对话触发时由工具自动加载。它不只是告诉 AI 该做什么而是规定了 AI 应该用什么标准、按什么顺序、产出什么格式的结果。我打个比方。一个名校毕业的聪明新人进公司智商和基础能力都够但如果没看过岗位说明书和部门 SOP他第一周大概率会做出各种风格迥异的输出。写代码的人可能一个用 4 空格缩进、一个用 Tab做数据分析的人可能一个交 CSV、一个交 Excel。skills 起的就是这个作用它把你认可的干活标准固化成文件AI 每次被召唤时都能稳定复现。这也是它能省心的核心原因一致性。你不再需要每次对话里反复交代背景和规范触发 skill 就等于给 AI 上了一套岗位培训。1.2 和 MCP、插件到底有什么区别用完 skills 之后很多人下一个问题就是那它跟 MCP、插件有什么区别MCPModel Context Protocol解决的是AI 怎么接到外部工具和外部数据比如让它能查数据库、调接口、操作文件系统本质是打通管道。skills 解决的则是AI 拿到工具和上下文之后怎么把事情做对、做规范本质是沉淀方法论。一个是硬件层的通路一个是软件层的流程两者是互补关系不是替代关系。打个比方MCP 像是给了厨师一个设备齐全的后厨里面有锅有灶有冰箱skills 更像是后厨墙上贴的那套标准菜谱规定了每道菜放多少盐、炒多长时间、装盘怎么摆。没有后厨菜谱执行不了没有菜谱厨师做出的菜时好时坏。在实际项目里我通常是 MCP 管数据接入和工具调用skills 管分析和交付的流程规范两个配合效率最高。2. 从 GitHub 手动安装 skills完整操作流程2.1 值得收藏的 skills 技能库源网站社区里已经积累了不少高质量的 skills 仓库我这里按实用度排序推荐几个。Superpower Skills 是目前社区里最热门的合集之一覆盖面很广从代码审查到文档写作都有Typesafe AI Skills 偏 TypeScript、类型工程方向做前端和全栈的同事可以重点关注Anthropic 官方的 skills 仓库虽然数量不算多但胜在规范、示例清晰适合拿来当标准答案学习还有一些诸如 awesome-claude-skills 之类的合集仓库里面会按分类罗列很多零散技能适合没事淘一淘。找 skill 的时候别贪多我建议先看两个指标仓库的 star 数和最近更新时间。一个三个月不更新的 skill 仓库很可能跟当前主流工具的版本已经不兼容了装上反而出问题。另外看仓库里是否有配套的 README 和示例一个连说明书都懒得写的 skill实际用起来大概率也得自己踩坑填坑。优先选那些有明确维护节奏、有 issue 互动的项目这类仓库出问题的概率会低很多。2.2 Claude Code 手动装 GitHub 上的 skills 的详细步骤以 Claude Code 为例手动安装 GitHub 上的 skills 其实就五步。第一步把目标仓库 clone 到本地或者直接 Download ZIP 解压这一步相当于把技能包拿到电脑上。第二步进入仓库目录找到存放 skills 的文件夹绝大多数仓库会放在统一的 skills/ 子目录下部分仓库则是每个 skill 独立一个 repo这种情况就直接看仓库根目录把对应 skill 文件夹找出来。第三步是最关键的一步把 skill 文件夹放到 Claude Code 的全局 skills 目录里。Claude Code 的 skills 默认读取~/.claude/skills/也就是在你的用户主目录下、.claude文件夹里面的skills子目录。每个 skill 必须是一个独立子文件夹文件夹内部至少要有一个SKILL.md文件。直接把文件夹复制进去即可不用做额外配置。第四步重启 Claude Code让它重新扫描 skills 目录。如果是在会话中复制进去的最简单是退出当前会话重新进入。第五步输入/skills命令查看当前已加载的技能列表确认新安装的 skill 在列表里。我安装完习惯再用一句触发词做一次冒烟测试比如装了一个数据探索skill就发一句帮我做一次快速的数据探索看看它是否真的激活了。这一步能筛掉很多装了但没用上的假成功。2.3 安装时最容易踩的坑装 skill 本身不难但我见过太多人在这一步栽跟头。第一个坑是把SKILL.md直接扔在~/.claude/skills/目录下而不是放在以 skill 命名的子文件夹里。Claude Code 扫描的时候是按目录下有 SKILL.md这个规则来找的你平铺放进去它根本识别不了。第二个坑是装完不重启会话就急着用出来一堆莫名其妙的报错其实只是工具还没重新加载。第三个坑是同时装了好几个功能重叠的 skill比如两个都会处理数据分析的结果触发时互相打架输出风格完全不一致。我的习惯是同类 skill 只保留一个先看 description 是否覆盖当前需求再决定要不要装第二个。注意如果你使用 Codex、OpenCode 等其他支持 skills 的工具目录结构会略有差异比如 Codex 的平台级技能和项目级技能是分开存放的。安装前一定先看工具官方文档确认路径不要盲目套用 Claude Code 的路径。3. 怎么写自己的 skills核心语法与实操模板3.1 SKILL.md 文件结构与写法拆解一个 skill 的核心就是SKILL.md文件它由两大部分组成YAML 格式的 frontmatter 和 Markdown 格式的正文。frontmatter 部分是给工具看的元信息最重要、也最容易写砸的字段是description。因为它不仅用来显示说明还直接决定什么时候触发这个 skill。工具是通过你的自然语言指令和所有已安装 skill 的description做匹配的。description 写得太笼统比如处理数据分析任何涉及数据的对话都会触发它导致误激活写得太窄比如专门处理波士顿房价数据集换一个数据集它就不出来了。正文部分是给 AI 看的工作手册我的写法一般分四块。第一块是任务目标用一段话明确这个 skill 在什么场景下使用、要交付什么。第二块是强制规范用必须和禁止来约束 AI 的行为比如必须输出中文报告禁止删除原始数据。第三块是工作流程按顺序列出 AI 需要执行的步骤这一步是核心越具体越好AI 的规划能力再强也怕没有明确指引。第四块是输出格式与自检清单告诉 AI 最后应该产出什么类型的东西以及交付前逐项检查什么。3.2 一个可以直接用的数学建模 skills 示例单纯讲语法有点枯燥我直接贴一个我常用的赛题拆解与建模规划 skill 的核心内容这种 skill 在数学建模比赛开头非常有用。frontmatter 里我会这样写--- name: modeling-scoping description: 当用户给出一道数学建模赛题或一份待建模的问题描述需要完成问题拆解、模型选型和任务规划时使用。 ---正文里我会让它按五个步骤走第一步把赛题里的每个小问拆成独立的子任务判断每个子任务属于预测、优化、评价还是分类并给出理由第二步根据每个子任务的数据条件推荐 2 到 3 个候选模型优先考虑经典模型先用 lasso、随机森林这类模型做 benchmark第三步给出一份可执行的时间规划包括数据清洗、模型训练、敏感性分析、论文写作的时间占比第四步输出一份任务清单给用户确认第五步等待确认后再进入实际建模阶段。这个 skill 的核心价值是逼着 AI 在动手写代码之前先做结构化思考。没有它的时候AI 经常会一上来就写代码写到一半发现选题理解错了白白浪费大量 token。有了这个 skillAI 会先做任务拆解和选型论证你再决定怎么执行。写 skill 不是写文学作品而是写一份可执行、可检查、可复现的操作流程越像操作手册越好。3.3 调试和迭代 skills 的几点经验写完 skill 第一次跑效果几乎一定不完美这很正常。我调试的时候基本参考三个信号。第一个信号是触发率如果聊了半天 skill 也没激活先改description把它写得更贴近用户的真实表达。比如与其写用于数据探索性分析不如写当用户提供一份数据集需要查看字段分布、缺失值、统计描述和相关性时使用触发率会明显提高。第二个信号是输出规范如果 AI 用的是自己的口头禅和自由格式说明正文里的强制规范写得不够强我会把必须换成严格必须并明确给出一份带编号的输出模板。第三个信号是 token 消耗。skill 正文越长每次触发加载的上下文就越多对话越贵、越慢。如果正文超过 300 行我会把可选的细节操作拆到同目录下的辅助文件里或者做成被调用的脚本工具只在SKILL.md里保留核心流程和关键的检查清单。写 skill 的本质是用尽可能精简的内容约束 AI 干尽可能标准的事所以边界控制比内容堆砌更重要。4. 不同场景下怎么挑 skills建模、前端、AI 漫剧4.1 数学建模场景竞赛和实战用什么 skills数学建模算是 skills 用得比较多的场景之一尤其是华为杯这类比赛赛程短、任务重、多线程并行AI 提效的价值非常大。我把常用技能分成四类。第一类是数据处理与探索类负责做数据清洗、缺失值分析、可视化它在比赛第一天最关键能帮你快速摸清数据底细。第二类是模型选型与基准类负责根据问题特征推荐算法跑几个经典模型做对照避免你在模型选择上反复纠结浪费时间。第三类是论文写作类负责把建模思路、实验结果、敏感性分析整理成符合学术规范的 LaTeX 文本。最后一类是敏感性分析与稳健性检验类它更像质检员保证投出去论文经得起评委追问。在挑选这类 skill 的时候我的建议是不需要全装按比赛阶段装。第一天重点用数据处理类模型确定之后再用论文写作类。如果你把所有类型的 skills 都装上反而会因为每一次对话触发多个类似技能导致上下文负载过重。这个道理跟工具箱一样你不可能把家里所有扳手都带在身上根据当天的活选那两三件就够了。4.2 前端开发场景提效明显的几类 skills前端开发的场景里我常用的 skills 有三类。第一类是组件脚手架生成你告诉它需求它按团队既有的目录规范、命名规范、样式方案生成完整的组件文件而不是给你一段自由发挥的代码。第二类是代码审查类它会按你设定的规范检查代码比如 prop 命名、逻辑分支复杂度、样式嵌套层级并给出可执行的重构建议。第三类是接口文档同步类它可以从后端接口定义生成 TypeScript 类型定义和对应的调用封装这算是我个人使用频率最高的一类。前端 skills 和建模 skills 最大的区别是前端更依赖团队已有规范。比如团队用 CSS Modules 还是 Tailwind这个偏好必须明确写进SKILL.md的强制规范里。我曾经遇到过一个 skill能力很强但输出的是 styled-components 风格代码而我们团队用的是 Tailwind每次都要花额外时间去改后来我直接在 description 里加了仅当用户明确要求 styled-components 风格时使用才解决这个问题。这说明 skill 再强也要跟你的技术栈对齐才真正有用。4.3 AI 漫剧等创作场景的 skills 搭配思路AI 漫剧、短剧这类内容创作场景skills 的核心价值在于保持一致性。一个做得好的漫剧 skill通常包含分镜脚本生成、角色外貌与性格设定、画面提示词生成、连续场景衔接这几个模块。它的难点不在单次生成而在多轮生成后的角色一致性。前一轮主角是戴银框眼镜、左眼角有泪痣下一轮如果 AI 忘了画面就会崩。把角色设定固化成一个 skill每次生成前强制加载就可以避免这个问题。配这类 skills 的时候我的经验是把设定文件当数据库维护不要把设定写死在 skill 正文里。正文只放生成规则和提示词模板具体角色信息放到一个单独的 markdown 或 json 文件里让 skill 引用它。这样既能保证每次生成前拉取最新设定也方便多个 skill 复用的同一份角色档案。很多玩 AI 漫剧的人容易把大量文字塞进单一 skill结果 skill 越来越臃肿生成却越来越慢改成规则 数据分离的结构之后就顺畅多了。5. 日常管理与问题排查实录5.1 skills 常见的坑和排查思路用 skills 半年多我踩过不少坑挑几个最典型的说说。第一个是装了但没触发。这种问题九成出在description上或者是同类 skill 重复匹配时被别的 skill 抢走了。我的排查方法是先用/skills看所有已加载的技能再逐条描述你要执行的任务看哪个 skill 从描述上最匹配。如果两个 skill 都写到处理数据生成报告那就留一个删掉另一个不要指望 AI 每次都能猜中你的意图。第二个是触发后行为很怪。比如写报告 skill结果输出了一堆代码。原因一般是SKILL.md正文里的工作流程表述不够强AI 把 skill 当成上下文而不是指令。解决办法是在强制规范里直接写现在你正在执行 report-generator 技能所有输出必须遵循以下步骤不得自行调整语气要硬一点AI 对这种明确指令的服从度会高很多。第三个是版本升级后失效。Claude Code、Codex 这类工具更新节奏快skills 的格式、目录、触发规则偶尔会调整。旧 skill 在新版本下可能出现加载失败或者描述不生效。我通常的做法是工具大版本更新后先跑一遍自己最常用的两三个 skill确认没问题再大规模回归。平时也要留意官方更新日志里关于 skills 或 Agent Skills 的说明。5.2 定期清理和组织 skills 的方法关于清理社区里 tibo 有一句话我特别认同skills 跟浏览器插件一样装得越多每次对话的思考负担越重反而谁都干不好。我现在的管理方案很朴素每个季度做一次大扫除。第一步列出当前所有 skills 和近一个月实际触发次数工具日志里一般都有相关信息。第二步把触发次数为零、或近一个月没用过的 skill 移出全局目录放到一个备份文件夹里而不是直接删除。第三步把功能重叠的同类 skill 合并成一个合并的时候保留更具体、更新鲜的那个避免冲突。除了清理我还会给长期不用的 skill 做降级归档。把它们从全局目录挪到项目级目录哪天真用到了再按需移回来。这样做的收益很明显全局目录干净了每次对话时自动加载的上下文变短了AI 的响应速度和准确性都有提升。另外我强烈建议给每个 skill 文件夹建一个自己的 CHANGELOG 文件哪怕只是简单记录改过哪些关键字段。很多 skill 用着用着行为变了你根本想不起来上一个版本是哪天改的有个 changelog 能省非常多事。最后再分享一个小经验skills 这东西初期安装快感很强但真正有价值的 skill 往往是自己迭代过好几轮的。建议别急着堆数量而是把你日常工作里重复次数最多的那类任务用 skill 固化下来然后滚上一个月的对话看哪里不满意就改哪里。你会发现一个这样打磨出来的 skill比二十个从网上随手装来的直用型 skill 更贴近你手头的活也更能沉淀出属于你自己的方法论。先从一个能真正解决你痛点的 skill 开始剩下的等用熟了自然就知道该怎么写了。