不问大家还记不记得一年前，我们折腾 AI 编程助手时还在纠结“写提示词”“调上下文长度”。到现在，圈子里的关键词已经变成了 skills——各种技能包、技能市场、superpower 满天飞。老实说，第一次听到“给 Claude 装 skills”这种说法，我心里想的是：这不就是插件吗？换了个马甲？但真上手玩了一段时间之后，我得说，这玩意儿比插件走得更远，它直接改变的是 AI 的工作方式，而不只是给它加个按钮。
这几个月我把 GitHub 上能翻到的 skills 仓库翻了个底朝天，也在实际项目里从零写了好几个自己的技能包，包括数学建模赛题里用的数据处理技能、AI 漫剧批量分镜脚本，甚至帮朋友调试过他自己写的半吊子技能文件。今天这篇文章，我不打算写那种教科书式的“什么是 skills”，我想直接从一个实践者的角度，把“怎么装”“怎么写”“怎么排坑”“怎么用出效果”这四件事讲透。如果你正准备接触 skills，或者已经在用但总觉得没发挥出威力，这篇文章应该能帮你省下几周的摸索时间。
1. 先搞清楚 skills 到底是什么、能解决什么问题
1.1 不要把 skills 理解成插件
我先说个很多新手会踩的认知误区。我们习惯性地把新东西类比成旧东西，看到 skills 就想到 IDE 插件、浏览器扩展，以为装一个就能给 AI 加一个功能按钮。不是这样的。
插件是“你主动调用的工具”，而 skills 是“ AI 在干活时自动遵循的工作手册”。
我用一个我们最熟悉的场景来解释。你现在让一个 AI 助手帮你写一段 Python 爬虫，普通情况下它会凭记忆写，写出来的东西可能是几年前的用法，可能跟你项目的文件结构完全不搭，甚至会用错框架。但如果你给它装了一个“Python 爬虫开发 skills”，它在动手之前就会按照技能文件里的说明，先确认目标站点的 robots 协议、检查你本地有没有安装对应依赖库、按照技能里规定的代码风格来写、写完还会自动补充异常处理和日志记录。
这就像是——你请了一个新手程序员，他只能凭自己的经验干活；又或者你给这个程序员配了一本你们团队自己写的《开发规范手册》，他干活之前先翻手册，每步都按规矩来。差别就是这么大。
1.2 skills 在实际工作中到底能改变什么
我自己的体感是，用了 skills 之后， AI 的输出稳定性有了质的提升。没用 skills 之前，同一个问题你问三次，它能给你三个不同风格的答案，有时候还会互相矛盾。但有了 skills，等于给 AI 的行为划了一条明确的跑道，它不会再天马行空。
具体来说，skills 在下面这几个方向上表现最突出：
第一是流程固化。比如数学建模竞赛那种流程极度标准的任务——数据清洗、特征工程、模型对比、论文生成，每个环节都有固定套路。把套路写成 skill，AI 就能按部就班地执行，不会漏步骤。
第二是风格统一。比如 AI 漫剧创作，今天你要的是古风旁白风格，明天是现代都市风，如果每次都靠提示词临时调，效果非常不稳定。但把这些风格规范写进 skill 文件之后，AI 每次生成的台词、分镜描述都会被强制拉回到你定义的风格框架内。
第三是知识固化。团队里有经验的成员把一些工程实践、避坑经验写成技能文件，就等于把个人经验变成了团队资产。新人用 AI 时，不用再重复问这些问题，skill 文件里全有。
1.3 和几种相似事物的边界划分
为了让大家后面读起来不至于混乱，我这里把几个容易混淆的概念一次性说清楚。
skills 和 MCP（Model Context Protocol）不一样。MCP 解决的是“AI 怎么调用外部工具和数据源”的连接问题，比如连数据库、连浏览器、连本地文件系统。skills 解决的是“AI 按照什么规范来完成一个任务”的方法问题。一个是通路，一个是方法，两者其实可以共存，互不冲突。
skills 和 prompt 模板也不一样。prompt 是一次性的，你在对话里贴上这段提示词，这次有效，下个新对话可能又打回原形。skills 是持久化的，装好一次，以后每次对话它在后台自动生效。
skills 和插件的区别前面已经说过了，一个是工作手册，一个是功能扩展，完全两回事。
2. 动手之前先选对路线：skills 的安装与资源获取
2.1 不同 AI 助手的 skills 支持现状
目前市面上支持 skills 机制的 AI 工具，最主流的是 Claude Code、Codex 这些面向开发者的命令行工具，OpenCode 这类开源项目也支持，还有不少基于大模型的 Agent 框架也在跟进。但说实话，这玩意儿的生态还处于战国时代，各家支持方式略有差异，没有完全统一的标准。
我自己的主力环境是 Claude Code。用它的时间最长，踩坑最多，也最顺手。Codex 我也试过，它的 skills 机制跟 Claude Code 有点不一样，部分命令和配置文件格式不通用。如果你同时在用两套工具，建议把技能文件单独维护，再针对不同工具做适配，别指望一份文件通吃。
2.2 手动安装 GitHub 上的 skills 全流程
先说说大家问得最多的一个问题：GitHub 上看到别人分享的 skills 仓库，怎么装到本地？
不同工具安装方式略有不同，但核心逻辑是一致的：把技能文件下载到指定目录，然后在工具配置里注册这个目录。以 Claude Code 为例，我给你们完整走一遍流程。
第一步，在 GitHub 上找到你想装的 skills 仓库。目前常见的技能文件格式是.md文件，里面用特定结构描述了技能的触发条件、使用流程、注意事项等。
第二步，把仓库克隆到本地。我习惯把它们统一放在一个目录下，比如~/.claude/skills/，每个技能一个子目录。
git clone https://github.com/某个用户/某个skills仓库.git ~/.claude/skills/那个技能名如果你只想要其中某一个技能，也可以只复制对应的.md文件到 skills 目录下。
第三步，确认 Claude Code 能识别到这个技能目录。实际上 Claude Code 会自动扫描~/.claude/skills/目录下的所有子目录，把每个子目录里的技能文件加载进来。装好后你可以在对话里问 AI 一句“你现在有哪些 skills 可用”，它会列出当前加载的技能列表。
第四步，验证技能是否生效。最直接的办法是给 AI 一个该技能覆盖的任务，看它是否按照技能文件里的流程执行。如果它没反应，检查文件格式是否合规、目录层级是否正确。
2.3 常用 skills 源网站和仓库推荐
很多朋友会问有没有那种“skills 应用市场”一样的网站，集中下载各种技能。目前确实有一些社区在收集整理技能库，做得比较好的是 GitHub 上的几个大仓库，里面收录了上百个常用技能，覆盖编程开发、数据分析、内容创作等方向。
我给几个我实测过质量不错的源：
第一个是 Anthropic 官方维护的 skills 仓库，里面的技能质量最高，但数量不多，都是官方团队自己写的，算是“官方认证”。第二个是社区整理的 awesome-skills 类型的聚合仓库，这类仓库的价值在于分类清晰，你会知道去哪找数学建模的技能、去哪找 AI 漫剧的技能。第三个是各个独立开发者自己维护的技能包，质量参差不齐，但往往更贴合特定场景，遇到好的要赶紧存下来。
我的建议是：先用官方仓库建立基准认知，再用聚合仓库扩展覆盖面，最后根据自己的实际场景自研技能。只靠下载别人的技能，永远解决不了你自己的独特问题。
2.4 superpower skills 到底是什么
热词里出现的 superpower skills 值得单独拿出来说一下。这名字听起来很唬人，其实它是一套由社区开发者维护的高质量 skills 合集，覆盖了非常多常见任务场景，从写作到编程到分析都有。它的质量确实比一般散落的技能文件高出不少，因为它是体系化维护的，技能与技能之间有统一的规范。
如果你刚接触 skills，直接去 GitHub 搜 superpower skills，然后按照它的 README 文档安装即可。但我要提醒一句：别一次全装。它的技能包数量很多，全装进去会让 AI 的上下文负担变重，反而影响响应速度和判断准确性。我建议先挑三四个跟你的工作最相关的装，用熟了再慢慢加。
3. 核心环节：从零编写一个真正好用的 skills 文件
3.1 skills 文件的结构与格式规范
光会装别人的 skills 不算本事，真正的高手都是自己写技能。接下来我重点讲讲怎么写，这是整个 skills 玩法的核心。
目前主流工具对 skills 文件的格式要求大同小异。本质要求是：用 Markdown 格式写一个结构化的文档，文档里说清楚这个技能是干什么的、什么情况下会被触发、具体要怎么干活、有哪些注意事项。
以 Claude Code 的默认格式为例，一个标准的技能文件长这样：
--- name: 技能名称 description: 一段精准的描述，说明该技能的用途和适用场景 --- # 具体的操作指引 ## 前置检查 ## 执行步骤 ## 注意事项最关键的是description字段。这句话写得越精准，AI 在任务匹配时就越容易激活正确的技能。如果描述得太笼统，AI 会不知道该不该用这个技能；描述得太窄，又可能错过匹配。
3.2 设计决策树：让 AI 拿到技能后知道先做什么后做什么
我在写技能文件时发现，只有清单还不够。AI 读一个技能文件，就像一个人拿到一份 SOP，如果 SOP 只是列了一二三四五，没有逻辑关系，执行者很容易犯选择困难症。
所以我在技能文件里会加入决策树逻辑，用条件判断来控制流程走向。举个具体例子，我写过一个“数据清洗技能”，文件里会这么写：
## 前置判断步骤 1. 检查原始数据格式（CSV/Excel/JSON） - 如果是 CSV：确认分隔符类型、有无表头 - 如果是 Excel：确认读取方式、sheet 名称 - 如果是 JSON：确认嵌套层级、是否需要扁平化 2. 检查缺失值占比 - 缺失率小于 5%：直接删除缺失行 - 缺失率大于 5% 小于 30%：根据字段类型选择填充策略 - 缺失率大于 30%：警告用户该字段可能无法使用这样的写法，AI 在执行时就有了明确的“if-else”逻辑，而不是机械地按顺序执行完所有步骤。这是技能文件质量高低的分水岭。很多新手写的技能文件，本质上是提示词换了马甲，就是因为缺少这种决策结构。
3.3 变量与参数设计：让技能可复用可扩展
好的技能应该是“半成品”，不是“成品”。什么意思？就是技能文件里应该预留变量和参数位，让 AI 在面对具体任务时往里面填具体的值，而不是把所有细节都写死。
我常用的做法是在技能文件开头设置一个“输入参数区”：
## 输入参数 - 数据源路径：[用户提供] - 目标格式：[用户提供，默认 CSV] - 编码方式：[用户提供，默认 utf-8]这样 AI 在匹配技能并执行任务时，会主动去识别并抽取这些参数。用户的体验是：AI 像个熟练工一样，知道先问什么，再做什么。而且同一个技能文件，换个参数就能反复使用，不用每个任务重写一遍技能。
参数设计的原则是：该让用户定的事绝不替用户定，该 AI 自己判断的事绝不写成硬编码。比如“输出文件命名规则”这种，可以直接写死；但“分析目标”这种，必须留参数让用户输入。
3.4 各类场景下的编写模板参考
为了让大家更直观地理解，我分别从几个热词场景来说一下技能文件的大致写法。
数学建模场景：这类技能的关键在于流程严格化和算法选型的判断逻辑。我写过一个“数模赛题分析技能”，核心内容包括：数据预处理优先级设定、模型选型决策树（数据量小用传统机器学习，数据量大用深度学习，时间序列用 ARIMA 或 LSTM，需要可解释性用回归树）、论文框架固定结构。华为杯这类比赛的逻辑是——评审看重的是完整性和规范性，所以技能里会特别强调每一部分输出的格式和内容边界。
AI 漫剧场景：这类技能的核心是风格控制和情感节奏。比如我朋友写的一个“古风漫剧分镜技能”，里面定义了：开场旁白的句式模板、角色台词的语感要求、转场描述的意象库、分镜描述的字数限制。AI 按这套规则生成的分镜，风格统一性远超临时提示词的效果。
编程开发场景：这类技能的重点是技术栈规范和代码风格约束。比如你团队用的是 TypeScript + React，就可以把项目结构约定、组件命名规范、状态管理方案、请求封装方式都写进技能文件。新成员用 AI 写代码时，AI 会天然遵循团队的既定规范，产出的代码不需要大量重构。
3.5 编写技能文件时的常见低级错误
我检查过不少别人写的技能文件，发现同一个套路性的问题特别多：
第一是没有触发条件说明。AI 根本不知道什么时候该用这个技能，结果就是技能装了和没装一样。
第二是步骤太宽泛。写“分析数据”三个字就完事了，AI 拿去执行，完全不知道该从哪里下手。好的技能文件，步骤要细化到“用什么工具、读哪个文件、先处理哪个字段、输出什么样的表格”。
第三是没有禁止事项。这是一个很多人忽略的地方。好的技能文件不仅要写“该做什么”，还要写“不该做什么”。比如我在数据清洗技能里会写明“禁止在未确认数据含义之前删除任何字段”，这能防止 AI 自作聪明地把关键数据删掉。
4. 实操演练：从安装到自研一个完整技能的全过程
4.1 环境准备与项目规划
空谈理论没意思，我带大家完整体验一遍。假设我们现在要为“数学建模竞赛”场景开发一个技能，目标是让 AI 帮我们从赛题发布到论文产出全程减少无效劳动。
首先盘点一下环境。我现在用的是 Claude Code 最新版本，操作系统是 macOS，已安装 Node.js 和 Python 3.10，本地有 Git。这些基础工具是跑 AI 编程助手所必需的，缺哪个先补哪个。
规划阶段我会想清楚这个技能要覆盖哪些环节。数学建模国赛或者华为杯这类竞赛，完整流程无非就是这么几步：赛题理解、文献查阅、数据预处理、模型建立与验证、结果分析、论文撰写。我不能把这些全塞进一个技能文件里，否则文件会太长，AI 上下文处理不过来，而且某个环节出错时不好排查。
我的规划方案是拆成四个技能文件：数据预处理技能、模型选型与调参技能、结果可视化技能、论文结构控制技能。平时各自独立使用，比赛时按顺序分别激活。
4.2 完整编写过程：以数据预处理技能为例
我就拿其中最有代表性的“数据预处理技能”来说，完整展示从零到一的编写过程。
先创建技能目录：
mkdir -p ~/.claude/skills/data-preprocess然后创建技能主文件SKILL.md：
--- name:>mkdir -p ~/.claude/skills-archive mv ~/.claude/skills/某个不常用技能 ~/.claude/skills-archive/移走之后立即测试 AI 的响应质量，你会明显感受到它恢复到了原有的聪明程度。这里也可以参考一些社区老手分享的清理思路：按周为周期，把本周实际用过的技能做标记，超过一个月没有命中的技能全部归档。别舍不得，真正能用的技能就那么几个，装一堆不用的等于给 AI 拖后腿。
7. 写在最后的个人经验
前面把 skills 的安装、编写、调试、清理讲完了，最后补充点我自己的感悟。
说真的，我见过太多人折腾 skills，一开始热情高涨，结果下载了上百个技能文件，却没真正用起来几个。原因无他，就是没弄明白“技能不是收藏品，而是工具”。真正有价值的技能，一定是你自己在干活的过程中沉淀出来的。那些市面上能下载的技能，看了别人的实现思路，借鉴里面的决策逻辑，这是有意义的学习路径。但属于自己的那套工作流，还是要基于自己的场景写出来，才能解决自己的实际问题。
我在实际编写技能文件时养成的一个习惯是：准备一个“技能草稿本”，每次在 AI 对话中发现它某个行为模式特别好，就顺手记下来，攒到一定程度就整理成技能文件。这个过程是渐进式的，不是憋大招。最开始的技能文件写得粗糙也没关系，先装上用，看到 AI 有哪些地方执行得不对，回头改文件，再测试，再改。这样迭代几轮之后，技能质量就会变得很扎实。
如果你还没动手写过自己的第一个技能，我的建议是：别先从复杂的开始，挑一个你日常工作里最高频、最重复、AI 做得最不稳定的任务，把它写成技能。体量不需要大，20 行以内就够。装上，测试，调几轮。等你跑通这一遍流程，你再回头看那些号称“superpower”的技能包，就会发现它们其实没有多神秘，每一条都只是把特定任务干漂亮的方法论。
接下来就交给你们了，装一个、写一个、用起来，这个过程里踩的坑，回过头来看会发现都是财富。
