大模型Skills技能包实战：从安装到开发与清理的完整指南

最近在折腾AI编程工具链，我把Claude Code、Codex、OpenCode底下的skills挨个翻了一遍，前后装了三十多个技能包，真正留下来常驻的不超过五个。这让我对“skills”有了一个不太一样，但更实际的理解：它不只是一个新名词，更像是一套让大模型按固定流程稳定执行任务的“能力模板”。尤其当你做数学建模、前端开发、AI漫剧这类重复性极高的活儿时，一个好的skills能直接省掉你大半条prompt。这篇就沿着我自己的踩坑路径，把skills的安装、开发、推荐和清理一次讲透。不管你是刚开始接触，还是已经装了一堆但总觉得“不听话”，应该都能找到解决办法。

1. Skills到底是什么，为什么突然火起来

1.1 从一条prompt到一套技能包

在官方宣传里，skills通常被描述为“模型的一项技能”，但真正落到目录结构上，它更像一个“带说明书的工具包”。一条prompt只能告诉模型“做什么”，而skills会告诉它“按什么顺序做、每步做到什么程度、结果用什么格式输出”。我常用的对比是：prompt是菜谱，写着食材和步骤，但火候和摆盘全凭厨师心情；skills则是卤料包加操作流程加质检卡，味道很固定，出品很稳定。

为什么会突然火？我觉得核心原因是：大模型的上下文窗口虽然越来越大，但真正稳定的能力来自“把容易出错的部分固化成流程”。skills把领域知识、操作步骤、判断规则、示例代码打包在一起，让模型在处理任务时“有法可依”。比起每次写一长串prompt，或者把规则塞进system prompt里，skills的可复用性要高得多。比如你有一个“数据检查”的技能，不管喂给模型的是电商订单还是比赛数据，它都会先按统一标准做缺失值、异常值扫描，而不是换一个数据集就换一套行为方式。

我这里再补充一个容易忽略的点：skills并不仅仅适用于编程。像AI漫剧的分镜脚本、内容创作的提示词管理、甚至数学建模的论文排版，都能被封装成skills。它的底层逻辑是一致的：把“这次任务希望模型怎么思考”以结构化的方式固定下来，避免每次都在同一个问题上返工。

1.2 为什么Claude Code、Codex、OpenCode都在推

这三家工具几乎是同一个时间点开始把skills作为一等公民。原因很简单：工具链本身的差异化越来越小，真正决定生产效率的是“模型在具体场景中的表现”。skills机制允许不同团队、不同个人分享和沉淀自己最好的工作方法。像“superpower skills”这个词能火，就是因为有人总结了一套“提示词增强+工作流管理”的组合技，能让模型输出质量上一个台阶。

从工程角度看，skills的流行也和MCP生态有关。MCP解决的是“模型怎么调用外部工具”，skills解决的是“模型怎么按流程完成任务”。两者是互补的，不是替代关系。后来我看到“typesafe ai skills”这种偏工程化的项目，本质上就是把skills当成“可维护的代码资产”，有版本、有依赖、有测试，这套思路明显比单纯靠文本prompt更可靠。

2. 动手前先搞清三个核心概念

2.1 Skills、Plugins和MCP，别傻傻分不清

很多新手最常问的一句话是：skills和插件有什么区别？我给的答案很简单：插件通常绑定平台，有独立的界面和生命周期，比如浏览器的扩展，或者IDE的插件；skills则是一套纯文本加脚本的“指导文件”，模型在运行时读取它，不存在编译和安装包。MCP则是另一回事，它更像是一个标准的工具通讯协议，让模型能接入计算器、搜索API、数据库等外部能力。

我用一张表把三者的区别说明白，后面选型时就不会搞混：

所以你在搜索skills时，看到“xxx mcp server”别当成skills装错地方。两者可以搭配：用MCP让模型读数据，用skills让模型知道怎么分析数据。我自己经常在一个项目里同时放一个MCP数据库连接器和一个数据清洗skill，各管一摊，配合得很好。

2.2 一个标准Skills目录到底长什么样

先贴一个典型目录结构，大家有个直观印象：

math-modeling/ ├── SKILL.md ├── assets/ │ └── templates/ │ └── report_template.md ├── scripts/ │ ├── eda.py │ └── evaluation.py ├── reference/ │ └── model_glossary.md └── tests/ └── test_parser.py

SKILL.md是这个目录的心脏。它通常用Markdown写，第一部分是frontmatter，里面有name、description、when_to_use之类字段；第二部分是正文，包括工作流和输出格式。模型在接到任务时，会先读取描述和适用条件，决定当前任务是否匹配这个技能，然后按步骤执行。

assets放模板、参考图片或文件；scripts放可执行脚本，目的是把机械劳动交给代码；reference可以放缩写表、指标说明等人肉词典；tests是可选的自测脚本，用来验证技能输入输出是否符合预期。如果你看到合集的SKILL.md不在根目录，那它很可能不是单个技能，而是一个技能仓库，需要你进一步拆开使用。

2.3 判断一个Skills好不好用，就看这五点

我下载任何skills之前都会先读SKILL.md，读完基本能判断出它质量如何。判断标准可以总结成五点：

• 任务边界是否单一。好的skill只做好一件事，不要又想分析数据又想生成漫画分镜。
• 输入输出是否明确定义。比如“输入：csv路径，输出：建模报告”比“帮助用户分析数据”靠谱得多。
• 步骤是否可独立检查。每步都应该有可验证的结果，比如“输出前三行预览”“打印缺失率”，而不是模棱两可的“认真分析”。
• 有没有处理异常的分支。数据为空、文件缺失、格式不对怎么办，好skill会提前写清。
• 示例是否够具体。有few-shot示例，模型理解成本直接降一半。

我一般在下载后先看SKILL.md，如果前几行写得含糊，直接放弃。看一个好库，其实是在看作者的流程设计能力，而不是看代码量。代码再漂亮，如果任务边界说不清，装上去只会让模型更加犹豫。

3. 从GitHub手动安装Skills到本地

3.1 安装前准备：确认工具版本和目录

手动装skills的原因多种多样：可能是自动安装器太笨，可能是你用的是内网环境，也可能是你想把某个私有仓库放进来。不管哪种情况，第一步都是找到对应工具的skills目录。

常用目录如下，但这几年工具更新遍地都是，如果发现目录不对，请先跑一下工具名 --help确认：

• Claude Code：~/.claude/skills/
• Codex：新版支持~/.codex/skills/，老版本可能要用plugins或commands目录
• OpenCode：~/.config/opencode/skills/

以我自己的经验，比较稳妥的方法是：先手动建好skills目录，随便放一个最简单的skill进去，然后重启工具，用“skills list”这类命令看看它扫描到的路径。如果能看到你放进去的skill，说明路径没问题；如果找不到，再去翻配置文件和版本说明。

3.2 Claude Code手动安装实操

假设你盯上了一个叫superpowers-claude-skills的仓库，手动安装步骤是这样的：

mkdir -p ~/.claude/skills cd ~/.claude/skills git clone https://github.com/你的用户名/superpowers-claude-skills.git superpowers

注意这里有个关键点：clone完一定要检查仓库里是不是直接放着SKILL.md。如果仓库根目录就是SKILL.md，那superpowers本身就是一个skill；如果里面还有多个子目录，那它是个合集，你需要把每个子目录单独装到skills根目录下。

检查命令：

find ~/.claude/skills -maxdepth 2 -name SKILL.md

看到SKILL.md在正确层级后，重启Claude Code，在输入框里敲一个和该skill相关的任务。以superpowers为例，它包含的步骤通常是“先拆解任务、再检查假设、最后输出结构化结果”，你自己就能感知到加载成功与否。

提示：千万不要把整个合集仓库直接丢进~/.claude/skills/的一级目录，如果里面有多个SKILL.md位于二级目录，系统会识别不了。我踩过这个坑，花了半小时才发现问题。

3.3 Codex和OpenCode的加载方式

Codex的skills加载分两层：全局技能和项目技能。全局技能放在~/.codex/skills，项目技能放在项目根目录的.codex/skills。使用的时候，有些版本要求用@技能名直接引用，有些版本会自动根据上下文匹配，差异很大。最可靠的方式是查看codex skills --help。

OpenCode我最近用得比较多，它的配置比较透明。在~/.config/opencode/skills下放好目录之后，可以在配置文件的skills字段指定路径，也可以依赖默认扫描。它支持通配符，比如~/.config/opencode/skills/*加载所有子目录，这对懒人很友好。

3.4 手动安装的几个额外心得

第一，优先选择带scripts的skill，因为纯文本的skill只是prompt，带脚本的skill才是真正的自动化。第二，装完之后不要急着上生产任务，先用最小样例验证。比如装了一个数据分析skill，就找一个只有几十行的CSV跑一遍，看它能不能走完完整流程。第三，更新用git pull而不是删除重装，否则你本地改过的模板会被覆盖。

另外，有朋友问“GitHub上看到好多skills合集，要不要全装”。我建议不要。合集一般是为“演示”和“挖掘灵感”存在的，真正干活时只需要几个垂直技能。全装会让模型在匹配skill时产生歧义，等于没装。我自己的做法是：每个合集只挑两三个最贴近自己业务的技能，其他的一律不碰。

4. 推荐一些我实测过的高质量Skills库

4.1 数学建模与华为杯场景

数学建模是我最推荐的入门场景，因为流程相对固定：数据清洗、特征分析、模型选择、结果评估、报告生成。这个流程如果靠临时prompt，每次都会偏离方向；用skills直接砍掉大量重复沟通。

搜索关键词可以是“math-modeling skill”“eda skill”“竞赛报告 skill”。实测下来，一个合格的建模skill至少要做到三点：自动识别数据缺失和异常、给出可复用的特征工程代码、最后按论文格式输出结果。华为杯那种比赛，数据量通常不大但脏数据很多，所以我会在skill里专门加一条“先检查行列范围和缺失率再动手”，能省很多事。

4.2 前端开发场景

前端开发是另一个值得装skills的点。我用过最顺手的几个方向包括：React/Tailwind组件审查、可访问性检查、响应式布局调试。这些任务很琐碎，但规则明确，非常适合固化成skills。

举个实际例子：以前我让AI帮我改一个组件，它经常改完样式忘了补alt属性。后来装了一个专门做accessibility审查的skill，流程变成：先检查语义标签、再补充键盘交互、最后跑一次对比。从那以后，这类问题的返工率直线下降。前端skills的另一个好处是能统一团队代码风格：你把命名规则、props顺序、测试覆盖要求写进SKILL.md，让AI提交PR前自己先检查一遍，省掉不少代码 review 的口舌。

4.3 AI漫剧与内容创作场景

AI漫剧最近挺火，很多人用它生成分镜脚本、角色设定、台词和对白。这属于创作类场景，skills一样能起作用，但不是为了“替代创意”，而是为了“保证格式一致”。

常用的技能包括：分镜脚本生成、角色一致性管理、台词风格约束。比如让skill规定每一次生成的角色外貌描述都从统一字段读取，避免主角一会儿红发一会儿蓝发。这类skills通常会把提示词模板和校验规则放在assets里，模型每次生成前先读模板。内容创作本来就是主观的，但只要有统一的结构，模型产出的东西就更容易检查和修改。

4.4 常用Skills源网站和仓库清单

下面这些关键词在GitHub上都能直接搜到，建议你按需检索，不要闭眼全装：

我自己的筛选习惯是：先看README的更新时间，再看SKILL.md的字段完整度，最后看作者是否给测试用例。满足这三点的库，坑很少。把“源网站”理解为“带说明书的工具仓库”，比理解为“安装包市场”更准确。

5. 手把手写一个自己的Skills

5.1 从一次建模任务反推边界

写skills的第一步不是写代码，而是确定“输入-输出-流程”。以数学建模为例，假设你经常接到这样的活：给一份CSV，要求做一个预测模型并输出报告。那么skill的输入就是CSV路径和任务描述，输出就是“分析报告+图表+代码”。

流程可以定成六步：

1. 检查数据形态：行列数、缺失率、异常值。
2. 做描述性统计：均值、方差、分布情况。
3. 数据清洗：处理缺失、删重复、归一化。
4. 特征工程：根据业务选择或派生特征。
5. 建模与评估：在3个候选模型间比较。
6. 输出规范报告：包含结论表格和可视化。

这一步的目的，是把“以前模型随意发挥的空间”压缩到最小。边界越清晰，后面越好写。如果你自己都没有把流程想清楚，写出来的skill大概率也是空话。

5.2 SKILL.md的完整模板

下面是我用过的一种结构，你可以直接抄：

--- name: math-modeling-eda description: 当用户提供一个结构化数据文件并要求建模分析时，使用本技能 when_to_use: 任务包含数据探索、模型选择或结果报告中的任意一项 --- # 工作流程 ## 1 数据检查 - 读取文件，打印前5行。 - 输出行列数、缺失值统计。 - 如果缺失率超过30%，先提醒用户，不要自动填充。 ## 2 描述性统计 - 对数值列输出均值、方差、最小值、最大值。 - 对分类列输出唯一值数量。 ## 3 数据清洗 - 执行缺失值处理策略，记录处理方式。 - 删除全空列。 ## 4 特征工程 - 从现有列派生至少两个业务相关特征。 - 记录特征名称和含义。 ## 5 模型选择 - 对分类问题依次尝试逻辑回归、随机森林、XGBoost。 - 输出每个模型交叉验证分数。 ## 6 报告输出 - 使用assets/report_template.md生成最终报告。 - 报告必须包含表格和可视化，不允许只有文字结论。 # 输出格式 - 第一部分：数据概况 - 第二部分：模型对比表 - 第三部分：最终结论与建议

注意里面的几个细节：when_to_use写得越窄，技能被误触发的概率就越低。步骤里写“不要自动填充”这类约束，是为了防止模型自作聪明。比如缺失率超过30%时，很多模型会直接填零或删列，但实际比赛里这往往会导致信息损失，明确禁止就能逼着它先问用户。

5.3 加入质检和防呆设计

好的skills不只是指导模型“怎么做”，还要防止模型“永远按流程走”。我在数学建模skill里加了两个“防呆”设计。

第一个是前置检查。模型必须先输出数据检查结果，才能进入下一步。如果模型跳过检查直接建模，就明确提示它“请先执行步骤1”。这听起来简单，但能挡住80%的跑偏。

第二个是输出校验。在最后一步要求“必须包含图表和表格”，如果只给了文字，就让它重写。用模型自己校验自己，是把技能固化下来的关键手段。不要指望模型每次都自觉，技能里写得越硬，它越不敢偷懒。

5.4 本地测试和迭代

写完之后，立刻用三份不同类型的数据做测试：一份正常数据、一份全缺失列数据、一份空文件。看看skill在边界情况下的表现。我习惯用下面这个命令快速验证：

cp -r my-skill ~/.claude/skills/math-modeling-eda

然后在Claude Code里让它“分析xxx.csv并给出建模报告”，看它是否按步骤走。如果它总跳过步骤，就去SKILL.md里加一句“必须按照章节顺序执行，不得省略”。迭代3到5轮之后，这个skill才算是能用的状态。之后可以把仓库推到自己GitHub，团队其他人用git clone也能直接共享。

6. 常见问题与排查技巧实录

6.1 skill没被加载，原因通常只有五个

很多人装完skill后，直接在工具里发“用那个数据分析技能”，结果发现完全没反应。排查顺序如下：

1. 看目录名是否是SKILL.md，不能叫skill.md或SKILL.MD，大小写很关键。
2. 看路径是否正确。Claude Code装到~/.claude/skills，别装到~/.codex/skills。
3. 看是否有多个SKILL.md嵌套。如果合集仓库直接clone，系统可能无法识别二级目录下的skill。
4. 看工具的运行时目录是否被覆盖。比如项目里有.claude/settings.json把skills目录指向别处。
5. 最后再重启一次工具，很多加载是启动时扫描的。

按这个顺序，基本五分钟内能定位问题。不要一开始就怀疑工具坏了，大部分情况是路径或者命名问题。

6.2 多个skills冲突怎么办

同名skill或者相近description会导致匹配混乱。我的处理方案是给skill目录加上带人名的前缀，比如user-math-modeling，并把description写得更具体，让它们覆盖不同场景。如果两个skill的职责确实重叠，就保留最近更新、依赖更少的那个。

还有一种情况：你装了“通用数据分析”和“数学建模EDA”两个技能，它们都会在收到CSV时触发。为了避免冲突，我会把通用数据分析的when_to_use改得更严格，比如加一句“除非用户明确要求通用分析，否则不要使用本技能”。冲突的本质是职责边界不清楚，重新定义触发条件比硬删更有效。

6.3 参考清理思路，让技能库保持干净

热词里提到的清理方法，我顺手整理了一下。核心观点：技能库要像冰箱一样定期清。

我的做法分四步：

1. 列出所有skills，标记使用频率（高/中/低/从未）。
2. 对“从未”和“低”的skills，先移到~/.claude/skills_disabled，而不是直接删除。
3. 检查依赖：如果某个skill的scripts引用了另一个skill的脚本，记得保留依赖。
4. 每季度做一次总清，只保留三个月内用过的。

用软链接管理而不是复制，能避免重复维护。比如把常用的5个skill软链到专门的active_skills目录，其他全部放在仓库里，需要时再链过去。这套方法的好处是：清理不是永久删除，而是把不常用的东西移到隔离区，等你某天突然需要，再花两秒钟链回来就行。

6.4 模型就是不按skills走，怎么办

如果模型已经识别到skill，但执行时总跳过某些步骤，说明skill内容的约束力不够。可以叠加三层措施：第一，在任务prompt开头显式写“必须使用math-modeling-eda技能，必须按步骤执行”；第二，在SKILL.md里用“如果缺少某步输出则整体无效”这种强约束；第三，把核心步骤改成调用脚本，让脚本直接产出中间结果，模型绕不开。

我个人认为，第三层最有效。纯文本prompt可以被模型忽略，但脚本执行的过程是确定的。把技能中可以被代码固化的部分全部交给scripts，剩下的判断部分才留给模型。这是从“提示词技巧”到“系统工程思维”的一个关键转变。

最后再聊一点个人体会。我用skills最大的收获，不是“AI变听话了”，而是我开始强迫自己把工作流程想清楚。以前写prompt，只需要描述结果；现在写skills，我必须定义边界、顺序、输出格式。这套思考方式放到任何项目里都成立。如果你也刚开始接触，我的建议是从“一个小场景”起步，比如只做一个数学建模的数据检查技能，或者只做一个前端可访问性检查技能，先跑通，再慢慢扩展。技能库不是为了越装越厚，是为了让你常用的东西越来越稳。你踩过坑之后，回头再看那些“超级技能包”，会发现最顶级的技能其实就是“清晰”二字。