我前阵子花了整整两个晚上把 GitHub 上那些叫 skills 的东西挨个翻了一遍。不看不知道这里面水确实深有写得像样的有纯粹凑数的还有不少是作者自己都没用过就丢上去的。这篇文章不打算讲什么高深理论就把我目前对 AI skills技能的理解、怎么挑、怎么写以及最容易踩的坑一五一十分享出来。1. 到底什么是 AI skills它解决了什么问题先说个最直观的感受。以前我用 AI 助手干活总觉得自己像个传话筒先描述需求再把 AI 的输出复制到别处改完再贴回来来回折腾。后来接触了 skills才发现这个东西本质上是把“你平时怎么干活”的那套流程、规则、话术打包成一坨结构化的提示词让 AI 能一次性按你的套路执行。我习惯这么理解如果说大模型是一张什么都会一点的白纸那 skills 就是你在纸上面提前画好的格子。模型按格子走就不会跑偏。skills 能解决的问题其实是把“经验”沉淀下来。举个例子我在写前端代码的时候经常要处理表单校验、请求封装、状态管理这类重复性很高的需求。如果每次都在对话里重新描述一遍“你帮我按项目的规范写”既累又不稳定。做成一个 skill 之后丢给它一个需求描述它就知道该输出什么风格的代码、该遵守什么约束甚至会自动参考项目里已有的文件结构。GitHub 上比较火的几个 skills 库比如 awesome-claude-skills 这类其实就是一群人在共享自己总结出来的“最佳实践”。你下载到本地给 AI 工具配置一下路径就能在对话里直接调用。这事儿听起来有点像装插件但实际用起来比插件更轻——它不改变模型本身只改变模型被调用时的上下文和指令。说到底skills 的核心价值在于让 AI 从“会聊天”变成“会干活”。光这一点就值得花点时间弄清楚它是怎么运作的。2. 怎么把 GitHub 上的 skills 装到 Claude Code 里我最早接触的就是 Claude Code身边问“怎么手动装 GitHub 上的 skills”的人也最多所以先把这条路径盘清楚。严格说起来手动安装一个 skill 也就是三步把代码库拉到本地找到或者创建合适目录然后在配置里告诉工具“技能在哪”。我用一个真实例子演示。假设你在 GitHub 上找到某个作者发布的 skills 仓库仓库里通常会有个 skills 或者 .claude/skills 目录。你要做的第一件事是把整个仓库 clone 下来或者像下文件一样下成 zip 再解压。这个动作没有太多技术含量但要注意一点尽量把 skills 放在一个固定的、不带空格、不带中文的路径下不然一些工具解析路径的时候容易出幺蛾子。第二步就是搞清楚这个仓库里哪些目录是有效的 skill。一个标准的 skill目录下应该至少有一个 SKILL.md 文件这个文件就是技能的核心定义。有的仓库打包了一堆技能有的一个技能单独占一个仓库差别只在于管理习惯。你在本地建一个总目录比如叫 ~/my-skills然后把各个仓库里的技能目录拷进去保持每个技能是一个独立文件夹。第三步是打开 Claude Code 的配置文件。这块不同版本可能略有差异但大方向是一致的在配置里增加一个路径指向让工具启动时能扫描到这些技能。我的做法是在项目根目录或者用户目录下的 .claude 设置里加上 skills 路径然后把工具重启一遍。重启之后你在对话里只要提到跟某个技能相关的关键词它会自动去匹配或者你直接问它有没有某个技能它也能列出来。装好之后怎么验证我的土办法是随便起一个新对话在对话里直接说“加载 XX 技能然后按这个技能的要求帮我做一件事”看它是不是走你预设的那套流程。如果它还像没装之前一样自由发挥八成就是路径没配对或者 SKILL.md 的头部格式不标准工具没识别出来。这份排查思路等后面章节我再细化。3. 哪些 skills 值得装以及如何挑选如果说安装是体力活那挑选就是智商活了。GitHub 上搜“skills”结果数量大得离谱而且星球大战式地分化一部分是真的好用一部分是花架子还有一部分是拿别人代码改个名就上传的。我的选择标准就三条看作者、看示例、看维护情况。先说看作者。如果这个仓库是某个知名的 AI 工具配套出的比如 Anthropic 官方推荐的或者作者是某个语言项目的核心维护者那质量基本有保障。反过来说一个刚注册没几天、就上传了一个万能大锦集式 skills 的账号大概率是拿集成的提示词充数下载的意义不大。然后是看示例。只有一个 SKILL.md 的仓库信息量通常不够。好的 skills 仓库一般会带上几个示例输入输出甚至有一小段测试用的样例数据。这个细节特别重要因为技能的效果很难通过阅读描述判断只有看它实际产出的东西你才能知道输出风格适不适合自己。我见过不少仓库描述写得很唬人点开示例一看完全是用英文回答的或者全部是空泛的套话这种就直接别折腾了。最后是看维护。一个技能能不能长期用取决于作者是否持续更新。Model 的能力在变工具的调用规则也在变今年能用的提示词半年后可能就变味了。我的经验是看一眼最近一次 commit 的时间超过六个月没动的除非功能极其封闭稳定否则不如自己写一个。具体到我个人常用的大概这么几类。一是代码评审类的 skills它会给 AI 设定一整套审查规则比如按可维护性、性能、安全性分层打分输出时带严重级别标注。二是数据清洗类的 skills适合做表结构检查、缺失值统计配置好之后处理 CSV 效率特别高。三是文档生成类的 skills它会要求 AI 按固定模板生成项目说明、接口文档篇幅和措辞都能控制得住。热词里提到的“数学建模 skills”“AI 漫剧常用 skills”我也研究过。数学建模那类技能本质是把建模比赛常用的分析流程比如问题重述、假设检验、模型构建、敏感性分析固化成一套输出模板比赛时确实能省不少时间。AI 漫剧那类则更偏向创意生产它会规定分镜描述格式、角色一致性规则、对白风格本质上也是把创作者的创作规范压缩成提示词。可见不同领域的 skills 长得不一样但内核逻辑都是“把经验模板化”。4. 从零写一个 skill格式、思路和避坑如果你已经用了一些现成的 skills下一步自然会手痒想写一个自己的。我鼓励你尝试因为自己写出来的技能才最贴合你的习惯。一个完整的技能核心就一个文件SKILL.md。这个文件通常分两段头部是 YAML 格式的元信息正文是 Markdown 格式的指令内容。头部看起来大概是这样的--- name: code-reviewer description: 用于对前端代码进行系统性审查覆盖性能、安全性与可维护性 ---这个 name 和 description 是工具识别技能用的description 尤其关键因为 AI 在判断要不要调用这个技能时主要就是靠读 description 来做语义匹配。你描述得越具体越容易在对话中被正确触发。别写“一个用于代码审查的技能”这种大废话要写成“审查 React 项目中的组件性能与状态管理代码输出分级问题列表与修改建议”。正文部分就是你要给 AI 的完整指令。这里我建议按顺序写四块内容。第一块写这个技能的适用场景和不适用场景。以代码审查为例你可以说这个技能面向前端项目的 PR 审查不适用于后端架构评审。这样 AI 遇到不合场景的问题时不会硬套模板。第二块写执行流程。给 AI 一个固定的动作顺序比如先通读代码并定位关键函数再按安全、性能、可读性分层检查最后生成带严重级别的报告。AI 一旦有了明确的步骤就不会乱来。第三块写输出格式。这是我特别看重的一步格式不固定是很多人写技能失败的通病。你应该告诉它报告必须分几个章节每个问题怎么描述是否给出修复代码片段整体用中文输出还是英文输出甚至要求它把结果控制在多少字内。格式不设死AI 就放飞自我这个技能跟没写一样。第四块写负面约束。比如“不要修改原始代码”“不要在报告中评价代码作者”“不要输出鼓励性套话”。负面约束的作用是用显式的规则挡住 AI 的自由发挥实测下来非常管用。写完初版之后一定要多做几轮测试。除非是很简单的技能否则一次写对几乎不可能。你拿着示例数据跑一遍看输出的东西哪里不像话再回 SKILL.md 里补规则。这个迭代过程才是真正把技能调顺的必经之路。另外有个细节一个 skill 目录里除了 SKILL.md你也可以放一些辅助文件比如脚本、模板、参考文档。AI 在处理任务时可以查阅这些文件。用得好技能的能力边界会大很多比如审查技能里放一份团队代码规范文档AI 就会拿它当标准去比对。5. 数学建模比赛里的 skills真的能提分吗近两年“数学建模 skills”成了热门搜索词很多参赛者想走捷径。我的看法是skills 在建模比赛里的价值主要体现在压缩重复劳动上而不是替代模型思维。先把比赛流程拆开看从读题、找数据、建模、求解、写论文到答辩 PPT哪一步最耗时多数队伍会死在写论文和做结果分析上。前者要按组委会模板输出大量规范性文字后者要做不同参数条件下的敏感性对比。这两块恰恰是 skills 最擅长的事情。我见过一套做得不错的数学建模 skills它的做法是建立多个子技能分别负责“题目理解与问题重述”“数据探索与可视化”“模型结果表格生成”。每个子技能都规定了输出格式和行文风格。比如“题目理解”这个子技能会要求 AI 用三句话提炼问题核心、列出约束条件、识别可用数据源。这样的输出可以直接粘贴进论文开头省下大量调格式的时间。但有一点必须提醒技能写得好不好并不等于模型算得对不对。比赛里最核心的算法设计、公式推导、结果合理性判断仍然需要人来做。我见过有队伍把技能生成的分析报告直接当结论用结果把某个明显偏离实际的参数也写进论文里最后被评委追问得很难看。技能是帮你节省整理和表达的时间不是负责产生真正的洞察。如果你要自己组一套建模用的 skills我建议优先覆盖这几个方向数据清洗与统计摘要、图表输出规范、论文各章节写作模板。这几项占了比赛流程中可模板化的大部分工作。至于建模思路生成这类偏向创造性输出的技能效果不稳定不如老老实实自己读题想模型。6. 常见的配置问题与排查方法使用 skills 的过程中遇到的绝大多数问题都集中在“工具没识别到技能”和“技能加载了但不生效”这两类。我把这些问题整理成一张排查表能帮你快速定位。现象可能原因处理办法对话里完全感知不到技能存在配置路径没写对或工具没重启检查配置文件中路径是否存在重启工具后再试技能能列出但执行没有按规则走SKILL.md 头部 YAML 格式损坏检查 name 和 description 是否规范确保没有格式错位同一个技能有时生效有时失效description 写得过于宽泛匹配不稳定改进 description 的关键词和适用场景描述技能输出带乱码或路径错误辅助文件路径包含中文字符或空格把技能整体挪到纯英文路径下再试更新技能后还是老行为工具缓存了旧的技能内容清除工具缓存或删除旧目录重新加载这里想特别提一下“清理 skills”这个话题。热词里提到的 tibo 关于清理 skills 的方法我总结下来核心思路就一句话定期删除不再用或者重复的技能。很多用户喜欢疯狂下载各种技能装了一堆之后工具匹配时反而会被不相关的描述干扰该触发的技能反而不触发了。我现在每个月会清理一次技能目录把使用频率低的移到备份文件夹只保留真正依赖的那几个。这样的好处是匹配更准启动加载更快排查问题也更容易。还有一个小经验如果你同时用多个 AI 工具比如既用 Claude Code 也用别的终端工具不同工具对技能目录的约定不一样。有的是按文件名识别有的要求写成特殊的前缀。我踩过坑后学乖了分别在各自的配置里指向独立目录不要让两个工具共享同一个技能目录不然其中一个工具更新了文件另一个用的还是旧配置互相干扰。7. 怎么上手最稳零基础也能跑通全流程如果你是第一次接触 skills我建议不要急着看花里胡哨的热门技能库先走一条最稳的路找一个官方示例技能装好跑通一个最简单的例子再自己改一个句子试试手。这样能在最小代价下建立起对“技能到底是怎么起效”的感觉。第一步选定一个工具。你手头日常用的 AI 编程工具或终端助手是哪个就用哪个。以 Claude Code 为例先确认它能正常运行然后去官方文档里找到内置 skills 或者示例技能的位置。第二步下载一个极简技能。最好是个只包含一个 SKILL.md 的仓库别碰那些动辄几十个技能、还有一堆依赖的库。第三步按前面第二章节的步骤安装配好。第四步用一个具体的小任务测试比如“帮我用规范格式写一个 TODO 文件”。如果输出明显符合技能里预设的标准说明整套链路是通的。第五步改动技能里的一个输出格式要求再跑一次感受一下改动带来的变化。做完这五步你对 skills 的掌控力就超过绝大多数只看过介绍的人了。之后再进入自己写技能的阶段一定从需求最痛的场景开始别一上来就想搞个全能技能。比如你每周都要生成项目周报那就写一个周报技能规定好结构、措辞、篇幅。这个技能帮到你之后你自然知道下一个该写什么。就我个人的经验skills 这个东西门槛不高但天花板很高。你花一晚上把流程跑通再用几周慢慢迭代自己的技能库之后每次用 AI 干活的效率都会有肉眼可见的提升。控制好自己的技能数量保持整理习惯它就会变成一个越用越顺手的个人工具箱而不是摆设。最后分享一个小技巧写 SKILL.md 的时候多用“必须”“禁止”“如果……则……”这类明确指令少用“可以”“建议”这类模糊词。AI 对肯定指令的遵循度明显更高。这句话算是我踩了无数坑之后最想告诉你的。