AI编程工具里的skills，我研究了一段时间，做了不少测试，也踩了不少坑。这东西是最近才火起来的概念，但用好了确实是给AI编程工具箱加buff。聊聊我的理解、实操步骤，还有那些文档里不太会写明的细节。
先解决最基础的问题：skills到底是什么？简单说，它是一套结构化的指令文件包，放在项目的.claude/skills或~/.claude/skills目录下，能被AI编程工具自动识别并调用。比如你给AI配备一个"数学建模"技能，当任务涉及数学建模时，AI就知道该加载对应知识库和指令集，而不是每次现场构思思路。
它解决的问题很实际：AI确实很聪明，但缺乏特定领域的专业知识和工作流程。比如数学建模，ChatGPT之类虽然能纸上谈兵，但对竞赛套路、论文排版、模型对比这些实操层面，效果往往不尽如人意。通过skills，你能把自己的方法、经验、提示词模板全部结构化存放，AI在需要时直接调用。
这套东西的适用人群挺广的：经常用AI编程工具的老手、想提升协作效率的团队、参加建模比赛或特定项目开发需要AI辅助的人。门槛不高，理解基本概念后，半小时左右能完成第一次安装和验证。
1. 先搞懂skills的核心原理和文件格式
1.1 skills本质是一份"结构化说明书"
很多人第一次看到skills目录时就一个想法：这不就是几个Markdown文件吗？对，本质就是这样，但它是有结构、有元数据的Markdown文档集合。核心是SKILL.md文件，里面用YAML格式写元信息，后面跟正文内容。
拿我一直维护的skill举例，它的SKILL.md结构大概是这样的：
--- name: mathematics_modeling description: 用于数学建模竞赛场景，涵盖问题分析、模型选择、论文撰写等完整流程。 --- # 数学建模竞赛专用技能 ## 适用场景 ...name是技能名，必须用短横线连接的命名方式，只允许小写字母、数字和短横线。description字段特别关键，AI工具靠这个判断什么时候需要调用这个技能。描述写得含糊，AI就不知道该不该加载。
正文部分就是正常的Markdown，但写法有讲究。最核心的规则是：把步骤拆到最细。比如"建立模型"这种描述太模糊，应该写成具体的步骤序列，每一步都有明确的输入、输出和检查项，AI才能准确执行。我曾经顺手装过几个用"掌握常见建模方法"这种话术写的skills，效果真是没法看，太模糊了。
1.2 为什么是Markdown，而不是其他格式
首先要明白，这些skill本质上是在给LLM投喂"少样本示例+结构化流程约束"，让模型在输出时遵循特定格式、逻辑和内容范围。用Markdown是因为它既能承载复杂格式，又不会干扰AI对内容的解析。JSON、YAML之类虽然也常用，但可读性不如Markdown，写起来也繁琐，对非程序员不够友好。
## 操作步骤 1. 明确待求解问题，列出已知条件。 2. 确定建模目标，判断属于预测、优化还是分类。 3. ...这个规范应该做到什么程度呢？按照我的经验，每个步骤都应当包含三个要素：操作目标（这一步要完成什么），操作内容（怎么完成，需要哪些输入），操作标准（怎么判断这一步做完了、做对没有）。这样AI执行起来才能像"照单买菜"一样有明确指引。
1.3 skills、commands、agents的关系
刚开始接触容易混这三个概念，我也有过一段时间的混淆。它们的核心区别在于触发方式、功能范围、依赖复杂度。
- Commands（斜杠命令）：是触发方式，用户在对话中输入斜杠命令名唤起对应操作，本质是让已有流程可复用化。
- Skills（技能包）：是按需自动加载的知识块，AI根据任务特征自主决定是否激活。
- Agents（智能体）：是能独立完成多步骤任务的执行单元，可以理解为"增强版子代理"，一般集成多种工具和技能。
实际使用层面，如果只是想让AI在特定场景下拥有专业能力，优先做skill；如果想要一系列操作都能快速复用，加几个command脚本；如果想让AI能自主规划、多次调用工具完成任务，那就得配置一个agent了。我的项目里三者都用了，但它们各自解决的痛点完全不同。
1.4 一次加载还是按需加载，这是个问题
这是我对skills印象最深的设计细节。默认情况下，AI工具会自动读取SKILL.md的元信息并拉取技能清单，但只有描述信息匹配任务上下文时才会真正加载技能正文。这样的设计是有原因的：加载所有技能正文会占用大量上下文空间，而存储空间够大不代表token余额够用。
计划性地使用技能，效果比我开始预想的好。带五个skill启动项目，AI能自动判断什么时候该参考哪个，什么时候不用管，这设计确实省心。
2. 动手装一个skills，从下载到验证
2.1 手动安装的核心操作流程
先明确一个原则：能用GitHub装的就别手动下载。但有些场景必须手动操作，比如你无法访问仓库、只想安装特定文件、需要离线使用等。手动安装其实就三步：找到skill文件、放进正确目录、验证AI能识别。
第一步，从GitHub上找到目标skills仓库，比如常见的codex skills、superpower skills等。克隆或下载整个仓库，或者只下载个别skill目录都行。
第二步，找到AI工具对应的skills目录。以Claude Code为例，全局配置在~/.claude/skills/，项目级配置在.claude/skills/。Codex和opencode各有不同的目录位置，但原理一致。
第三步，把skill文件夹放到指定目录下。注意目录结构是有规范的：
~/.claude/skills/ └── mathematics-modeling/ ├── SKILL.md ├── references/ │ ├── 模型库.md │ └── 常见数模题型.md └── scripts/ └── 数据预处理模板.py其中references/放引用资料，scripts/放辅助脚本或模板，这两个都是可选目录。但不建议把所有内容堆在SKILL.md文件里，会导致单文件太大、加载慢、AI处理也吃力。
2.2 如何验证skill安装成功
装好以后别急着用，先验证一下。在工具对话框里直接问："你支持哪些skills？"或者直接输入技能名相关的问题，比如装了数学建模技能后提问"2025年华为杯C题应该用什么模型建模？"，如果AI回答引用了技能内的知识，就是安装成功了。
验证这一步很重要。有的skill清单能显示出来，加载却一直失败，不实测根本发现不了。我第一次装"AI漫剧常用skills"时就遇到这种情况，清单里有名字，但不管怎么触发都用不上，最后发现是skill里的YAML格式写错了一个冒号，整个解析失败，AI静默降级处理了。
2.3 卸载和禁用也不难
不想要某个skill了，直接删掉对应文件夹就是卸载。更温和的做法是临时禁用：把SKILL.md改名成SKILL.md.bak，这样AI工具读不到skills元信息，自然就不会加载。需要恢复时改回原名字即可。
顺便说一句，别在多个仓库目录下放同名skills，AI载入时会因为重名冲突产生不可预期的行为。我在.claude/skills和项目.claude/skills下都放过同版本的数学建模skill，结果有一阵子AI回答建模问题时语气、格式忽变，排查了很久才发现是两套同名skill在互相干扰。
3. 从零写一个自己的skill，AI技能开发全流程
3.1 设计思路从拆解"自己是怎么做事的"开始
在看到可复用的工作流时，我的经验是把它转成skill。比如AI漫剧的分镜头脚本设计，经常有固定套路：镜头序号、景别、画面描述、台词、背景音乐、时长标记。每做一次都要复述这些规则，还要看AI输出后逐步修正。把这些固定逻辑写入skill，AI就能按模板工作，省掉大量重复的提示词修改。
写skill之前先梳理自己的操作习惯。我的办法是用文字记录一段完整操作流程，包括每步做了什么、判断标准是什么、常见排查步骤，然后转成Markdown文档。这种从实际操作出发的方式，比凭空想象要清晰得多。
设计核心原则：只描述"如何做"，不描述"做什么内容"。Skill给的是完成任务的方法、流程、标准和禁忌，而不是具体知识本身。比如数学建模skill里写"使用层次分析法解决评价类问题，权重矩阵一致性比例CR<0.1时认为合格"，这是给出方法和标准，不是直接告诉用户某个题目的答案。
3.2 手把手写一个简单的skill
以"数学建模论文摘要优化"为例子拆解：
--- name: abstract-optimizer description: 针对数学建模竞赛论文摘要进行结构优化，适用于摘要含混不清、缺乏亮点、结构不完整需快速改进的场景。 --- # 数学建模摘要优化 ## 职责 优化数学建模竞赛论文摘要，使其结构清晰、逻辑完整、亮点突出。 ## 工作流程 ### 第一步：提取与诊断 - 让用户直接粘贴原标题、摘要内容、关键词。 - 检查摘要是否包含六个要素：问题背景、解决思路、模型方法、关键结果、结论亮点、推广价值。 - 六要素覆盖少于4个，判定为"严重缺失"，需要在优化时补充。 ### 第二步：结构重排 - 目标顺序：一句话背景 → 问题描述 → 核心模型及算法 → 关键数值结果 → 对比基准 → 推广价值。 - 每部分控制在2-3句话，整个摘要控制在250-300字。 ### 第三步：语言润色 - 使用学术化表达。 - 避免口语化、冗余修饰。 - 关键结果必须给出具体数字，不能只写"效果良好"。 ## 质量检查清单 - [ ] 六要素是否齐全？ - [ ] 是否有具体数值支撑？ - [ ] 是否在篇幅限制内？ - [ ] 是否包含推广价值？这个skill大约40行，已经能覆盖绝大多数摘要优化场景。写了description之后，还需要测试多轮，观察AI的行为是否符合预期，然后反复调整文本。
这里有个重要提示：skills生效依赖AI本身的指令跟随能力。模型越强，效果越好；模型本身指令跟随能力弱，再精妙的skill也发挥不了太大作用。所以写skill时要用清晰、无歧义的语言，多用肯定句，少用"尽量""可能""大部分"这类模糊限定词。
3.3 进阶技巧：让skill携带脚本和参考数据
有的任务光靠文字说明不够，比如数据分析类skill，应该配合scripts/目录提供可复用的Python脚本模板，AI可以调用这些模板来处理数据。
我维护的数模skill里就放了一份"数据预处理标准脚本"，包含缺失值处理、异常值检测、标准化、相关性矩阵等常用操作。写进SKILL.md时，AI会先读说明，然后调用脚本模板来执行，效率和一致性都高不少。
references/目录则是给AI准备"背景知识卡片"的地方。比如AI漫剧skill里，我会放一份"镜头语言速查表"，列出景别、机位角度、光线类型和适用情绪。这样AI生成分镜时就能直接参考，不用每次临时"回忆"专业知识。
3.4 命名和描述是最容易被忽视的两个坑
说个有点反直觉的规律：skill代码内容写得好不好，远没有名字和描述写得好不好重要。因为AI工具判断"该不该加载这个skill"，主要就是看描述信息和当前任务的匹配度。描述写得烂，skill写得再好，AI也感知不到它的存在。
我见过有人写description是这样的：
description: 数学建模相关的技能，适用数学建模场景。这段话的问题在于信息量太少，匹配成功基本靠运气。换成这种写法会更准确：
description: 深入引导数学建模问题，适用于数学建模竞赛场景，覆盖问题分析、数据预处理、模型构建、模型评估、论文撰写全流程。用自然语言充分描述使用场景和功能边界，不要用"技能""工具"这类无效词汇，AI能通过语义匹配判断哪些问题适合使用这个skill。
关于放哪些内容，我推荐的规范是：写文件时先写"适用场景"和"不适用场景"两部分。有明确的适用边界，能显著减少AI误用的情况。最初写的skill往往缺这一步，后来统计误用率，加上的场景规则触发正确率高了不少。
4. 值得关注的skills生态：从数学建模到日常开发
4.1 数学建模类skills推荐
作为做数模竞赛比较多的人，先聊聊数学建模方向的skills。围绕各类国内竞赛开发的数学建模skills，通常涵盖常见的模型库、算法库、论文模板，质量参差不齐，但我发现一套好用的数学建模技能套件通常具备这些特征：
- 按题型分类（评价类、预测类、优化类）组织模型库
- 内置每种模型的标准流程和适用条件
- 提供大量可复用的Python代码框架
- 包含论文排版和摘要优化规范
上手这类技巧，最划算的做法是：直接安装开箱即用的集合包，然后看它的SKILL.md，琢磨作者的思路，再把适合自己习惯的部分拆出来改造。我这么操作了几轮，自己写skill的水平比之前直接闷头写进步快很多。
华为杯相关技能也比较多。这类竞赛重数据挖掘和建模实操，skill一般会整合数据预处理、特征工程、多种机器学习算法，以及结果可视化等能力。用下来最明显的感受是，在数据处理环节AI能少问很多基础问题，直接进入核心建模阶段，效率提升还是很可观的。
4.2 Superpower Skills这个热门项目，值得装吗
社区里讨论度很高的superpower skills，本质是一个收集了大量实用技能的集合包。它解决的问题很明确：AI编程工具官方预置的技能太少且面向通用场景，针对细分任务覆盖率不足。Superpower用一套插件机制大幅填充了技能库。
我装了一段时间，目前的评价是：值得装，但没必要全量启用。它的技能数量多，全部启用会导致AI上下文空间被严重挤占，推理时加载清单都会变慢。更合理的做法是只管挑自己需要的技能目录放进全局或项目级目录，其他留在仓库里备用。
如果只是想要更好的模型性能和推理速度，对技能生态兴趣有限，那装不装其实无所谓——这类合集是给想在垂直场景里充分使用AI能力的人准备的，不是人人都需要。
4.3 其他值得关注的skils方向
除数学建模外，我最近在关注几个方向的skills，覆盖面比较广：
前端开发skills：标准化代码审查、组件开发流程、无障碍规范检查。和团队里用Cursor和Copilot协作时，确实能减少大量代码风格的争议。一个靠谱的前端技能库通常会包含"如何组织组件结构""如何编写可维护样式""如何做跨浏览器兼容"等内容。
Typesafe AI skills：这类技能聚焦于TypeScript类型安全和数据校验，对用全栈TypeScript的团队会比较友好。好用的类型安全技能会规划好标准的类型定义策略、错误处理模式和API数据契约。
AI漫剧常用skills：比较垂直的创作类技能，专为短视频、动态漫、AI生成的漫画场景准备，覆盖分镜、台词、画面提示词生成、镜头脚本模板等内容。做自媒体内容的人用这类技能能省很多时间。
Codex skills：OpenAI Codex相关技能的统称，偏代码生成和项目管理。有人整理了codex nature skills，对自然语言任务拆解和代码生成特别加强了指令设计。
说到"tibo关于清理skills的方法"，这是个很有意思的技能集，它的核心思路不是新增技能而是删减。通过清理无用技能，释放上下文空间，减少无效加载，提升核心技能触发命中率。我实践下来很有效——装了一堆技能后发现AI越来越"呆"，很多无关的技能描述干扰了它的判断，清理完明显好转。
4.4 高效获取skils资源的渠道建议
整理几个比较靠谱的技能源：
- GitHub：大部分高质量skill都在这里，搜"awesome claude skills""codex skills"能发现不少高性能项目。
- 社区合集：不少开发者会整理常用skill列表，比如"前端开发必备skills工单""数学建模skill集合"，这类合集往往能看到每个skill的实际效果评价。
- 官方示例：Claude官方文档里有一些skill示例，结构规范，适合作为学习模板参考。
如果通过网页版环境使用AI，装技能的原理类似，只是文件目录的逻辑略有不同。我的建议是，从官方文档或信誉好的合集入手，先学结构，再学内容，最后自己动手定制。
5. 常见问题与排查技巧实录
5.1 技能根本没加载，怎么排查
症状是：提问涉及skill描述的场景，但AI回答完全没被skill内容影响。排查步骤按顺序来：
- 先说结论：最容易被忽视的是description写得不好。AI加载技能的逻辑是先读描述、做匹配，描述不清晰自然不加载。
- 检查文件结构：确认文件名一定是
SKILL.md（大写），不是skill.md或skill.txt。这是个很低级但很容易犯的错。 - 检查YAML元信息语法：漏冒号、多空格都会导致解析失败，可以用本地YAML解析工具快速排查。
- 询问AI技能清单：在对话里直接问它"你会哪些技能？"看是否能列出当前技能。如果是项目级目录，还要确认工具是否加载的是项目工作目录。
- 用其他子路径验证：把skill放到全局目录测试能否识别，能识别说明项目目录配置有问题，不能说明skill文件本身有问题。
5.2 技能加载了但效果不稳定
有时AI能明确引用技能，但输出质量和预想差距很大。大概率是skill里的指令粒度太粗。举一个反例：写"对数据进行预处理"和写"对缺失值采用中位数填充，对异常值采用3σ原则剔除，对连续变量做Z-score标准化"是两种完全不同的效果。前者靠AI自由发挥，后者是明确指令，结果稳定性天差地别。
另一个常见问题：叙述指令用了否定句式或"避免"类表述，某些模型对否定指令的处理不够稳定，反而强化了错误行为。更优写法是正面指令，比如"请明确使用XXX格式"而不是"不要使用XXX格式"。
5.3 多个skills冲突和"技能污染"
多个skill都覆盖同一类任务时，AI可能会收到互相矛盾的指令。典型表现是回答时一会儿套用A技能的格式模板，一会儿又按B技能的思路输出。处理办法是明确domain划分，编辑skills描述时把适用场景写得互不交叉。
"技能污染"这个词是我自己总结的：装太多技能后，AI会在对话开头就大量预读技能描述，导致常规问题也会被不相关技能影响。解决办法还是精简，只保留核心和高频技能。我目前项目里只常驻5个技能，效果反而明显比以前挂十几个好多了。
5.4 AI技能使用频率低，是好是坏
经常有人来问："我装的技能，AI怎么很少用？"我的判断标准是这样的：如果高频任务确实被有效处理了，只是你没察觉技能在发挥作用，这反而是好事，说明AI把技能知识内化使用了。如果任务没处理好，AI也没引用技能，那才说明是加载失效，需要排查。
具体判断是否被内化，可以故意在描述之外问一个需要技能细节的问题，比如写摘要技能就让它评估一篇摘要的六要素覆盖情况。如果它能答出来且逻辑一致，说明技能已被有效加载和使用。
6. 一些实用心得和进阶建议
说几条经过不少项目验证的经验心得。
第一条：技能的黄金法则是"一次只解决一个问题"。一个skill覆盖太多场景，往往每个场景都做不好。把复杂的技能拆成多个单一职责的小技能，效果反而更好。维护成本低了，AI的调用准确率也升了。
第二条：写skill之前先做"反向测试"——假设AI完全不理会skill内容，你预期它会怎么回答？装完skill之后再看看实际输出差异。差异越大说明skill价值越高；差异不大说明你的skill内容还在"泛泛而谈"，需要具体化。
第三条：定期做"技能体检"。每隔一段时间查看一次工具对技能清单的加载情况，删除长期未触发的技能，更新已被新版本替代的陈旧技能。这套流程是受tibo清理skills思路启发，确实能帮AI工具保持高效状态。
还有一条私藏技巧：写SKILL.md时适当加入几个"少样本示例"，展示输入和理想输出的配对。比如在"AI漫剧skills"里放一个标准分镜示例，再让AI模仿该格式生成新内容。少样本示例能让AI快速理解格式要求，大多数情况下效果比长篇说明都好。这也解释了为什么那些"带示例"的skills往往看起来"更聪明"——不是模型变了，而是示例让指令变得可执行了。
