大概是从去年年底开始，我发现自己写代码进入了一个奇怪的状态：工具链越来越成熟，用Claude Code、Codex这些AI编程助手干活也越来越顺手，但每次换个项目、换个任务，总要把同样的规范、同样的流程、同样的检查清单反复粘贴到对话框里。项目一多，这些重复劳动比我实际写代码的耗时还长。直到有次我在GitHub上翻到一些开源项目，看到别人把这类"对话工作流"做成了一个个独立的模块，还给它们起了个名字——skills。从那一刻起，我的AI编程方式彻底变了。

今天这篇不聊虚的，就围绕skills这套东西好好展开。它是什么、为什么现在每个人都在谈、怎么把GitHub上现成的skills装进Claude Code或Codex、有哪些值得收藏的skills库、数学建模和AI漫剧这些场景怎么写自己的skills、以及如果装太多之后该怎么清理。我踩过的坑、试错后的经验都会写出来，你直接照着抄就行。

1. skills到底是什么？为什么AI编程突然都在聊它

1.1 从"会聊天的AI"到"会干活的AI"

先明确一个概念：skills在AI编程工具里，指的是一组可复用的指令、规范、脚本和资源的集合。它不是独立的软件，更像是一份"岗位说明书"——告诉AI助手：当你接到某类任务时，应该按什么流程做、用什么工具、检查什么指标、输出什么格式。

说得更直白一点。以前你用AI写代码，像是请了个聪明的实习生，你每件事都要叮嘱一句："先跑一下测试"、"记得处理边界情况"、"按ESLint规范来"。有了skills，你相当于给这个实习生配了一整本操作手册，他接到任务就知道该翻到哪一页、按哪条标准执行、最后交付什么。

我见过一个很典型的案例。有哥们做前端开发，他把团队的代码规范、组件写法、PR检查标准全写进了一个skill，然后让Claude Code处理页面重构。原来要来回磨好几轮、改完还要人肉review一遍的活，现在AI一次性生成的结果基本就能达到提测要求。我后来也照做，效果确实夸张。这不是AI变聪明了，而是它"知道该怎么干活"了。

1.2 skills和提示词、MCP、Agent到底什么关系

很多刚接触的朋友容易把几个概念搞混：提示词（Prompt）、Agent、MCP（Model Context Protocol）和skills。

• 提示词是一次性的、临时写给AI的指令，用完就没了。
• skills是工程化的、可复用的提示词+工作流，是有组织、有结构的"手册"，可以被AI按需加载。
• Agent是AI的"自主行动能力"，skills可以理解为给Agent配的"经验库"，让它行动时有所依据。
• MCP是一种协议，负责让AI连接外部数据源和工具（比如读数据库、调用API）。skills可以引用MCP工具，但skills本身更偏重"流程和规范"。

用一句话概括：MCP解决"AI能碰什么"，skills解决"AI怎么干"。

明白了这层关系，你就知道为什么skills突然火起来。现在各家AI编程工具的能力底子已经足够强，差距恰恰体现在"你怎么引导它干活"上。谁沉淀的skills多、质量高，谁用AI干活的上限就高。这就像同一个厨师、同一口锅，菜谱的质量决定了成菜的水平。

2. 快速上手：怎么把别人的skills装进自己的工具

2.1 Claude Code手动安装GitHub上的skills

Claude Code的skills机制是目前生态里最成熟的。安装分三种方式：官方插件市场装、命令行装、手动装。这里重点说手动装，因为很多优质skills并不在市场里，只托管在GitHub仓库上。

直接复制到目录

第一步：确认你的Claude Code版本支持skills，建议用最新版。在终端执行claude --version查看，如果版本太老，先升级。

第二步：找到Claude Code的配置目录。macOS和Linux在~/.claude/，Windows在%USERPROFILE%\.claude\。skills对应的是该目录下的skills/文件夹，如果没有就手动创建。

第三步：去GitHub上找到你要装的skills仓库，把整个skill文件夹（比如一个叫frontend-review的目录，里面含SKILL.md和其他资源文件）下载下来，放进~/.claude/skills/目录下。

装好之后，目录结构是这样的：

~/.claude/skills/ ├── frontend-review/ │ ├── SKILL.md │ └── reference/ ├──>/plugin install repo-owner/repo-name

这条命令会把整个仓库作为插件装进Claude Code，里面的skills会一并注册。这种方式适合安装包含多个skills的聚合包，比手动一个个丢目录省事很多。如果你用的是Codex或者OpenCode，它们各有自己的skills目录，通常也在用户目录下，比如~/.codex/skills/，安装逻辑是类似的：找到目录、放进去、重启生效。

提示：装完skills之后，建议花两分钟检查一下SKILL.md里声明的name和description，这两个字段会在AI决策是否加载该skill时起关键作用。描述写得含糊，AI可能该用的时候不用、不该用的时候乱用。

2.2 superpower skills这类聚合包怎么装

说到装skills，绕不开一个名字：superpowers。这是社区里知名度极高的skills聚合库，作者是Jesse Vincent（也就是obra），GitHub地址是obra/superpowers。它不是单个skill，而是一整套方法论——包含项目规划、任务拆解、代码审查、测试驱动开发、调试等一揽子工作流。

安装超级简单，官方推荐直接通过Claude Code的插件机制装：

/plugin install obra/superpowers

装完之后，你会看到一堆skills出现在目录里。注意，聚合包的意义不是让你全用上，而是让AI根据任务自己选。比如你丢给Claude Code一个复杂的重构任务，它会自动调用superpowers里的规划skill，先拆任务再动手。

我的建议是：新手不要一上来就装超级聚合包，先把单点skills用熟，知道每个skill的触发方式和输出逻辑，再装superpowers这类重量级选手。否则你根本分不清是哪个skill在生效，出了问题也不知道该排查谁。

2.3 Codex、OpenCode等工具的skills安装差异

不少朋友是在Codex上用的，尤其华为杯、美赛这类数学建模竞赛，Codex的skills生态最近也很活跃。Codex安装skills的原理和Claude Code相同，但有几个细节要注意：

第一，Codex的skills目录不一定在~/.codex/skills/，具体看版本。你可以先跑一条命令确认：

codex --version

然后查看用户目录下有没有.codex文件夹，确认skills子目录的位置。

第二，Codex对skills的加载策略更"挑食"。它要求SKILL.md里的描述和目标任务匹配度足够高才触发，模糊描述很容易被跳过。所以装完别人的skills，如果发现不生效，先检查是目录没放对还是描述写太泛。

第三，OpenCode这类开源工具对skills的支持还在快速迭代中，不同版本的文件组织方式可能都不一样。最稳妥的办法是去看它的官方文档里"skills"或"agents"那节，按对应版本操作。

对我来说，跨工具使用skills最大的心得是：skills文件本身是通用的，瓶颈在于你用的工具认不认这个目录结构。所以无论在哪装，先确认路径，再确认重启，最后用一句话测试触发，三步走完基本不会有大问题。

3. 值得收藏的skills源与场景推荐

3.1 常用skills源网站和GitHub仓库

社区里已经有不少人专门维护skills的"应用商店"，只是没有统一的官方商店而已。我常用的几个渠道：

• GitHub搜索：直接搜claude skills、codex skills、awesome skills这类关键词。GitHub的awesome系列列表质量很高，比如awesome-claude-skills，里面按前端、后端、写作、数据分析等场景做了分类。
• anthropics/skills：官方实验仓库，里面有不少官方维护的示例skills，内容质量有保障，直接看代码能学到不少写作技巧。
• obra/superpowers：刚才提到的聚合包，方法论向，值得研究它怎么组织一个skill的目录结构和上下文引用。
• typesafe的AI skills仓库：TypeSafe团队开源了一套面向类型安全和工程规范的skills，对做严肃工程项目的朋友帮助很大，里面关于代码生成、类型推导校验、重构安全的思路值得参考。
• cola skills：社区里近期讨论度较高的一个集合，主打创意类和内容生成类任务，很多做AI漫剧、短视频脚本的朋友在推，里面关于分镜和角色一致性的skill写法很有启发。

找skills源有个技巧：不要只盯star数，要看最近更新时间和SKILL.md里描述的具体程度。很多仓库star很高但skill写得很水，描述全是空话；有的冷门仓库反而是作者从真实业务里提炼出来的，读一遍就懂为什么那么写。

3.2 前端开发场景到底需要哪些skills

前端是skills应用最成熟的领域之一，因为前端开发流程标准化程度高、可检查的指标明确。我自己整理并实测下来，最常用的几个：

代码规范审查skill。这个skill让AI按你团队的ESLint规则、组件命名规范、TypeScript类型约定来检查生成的代码。装之前，AI写的组件props命名全看心情；装之后，它会老老实实按你定好的风格走。一条skill解决的问题，比你给AI单次强调十遍"请遵守规范"都有效。

响应式与可访问性检查skill。它会要求AI在生成页面后，主动检查断点布局、对比度、focus态、ARIA标签这些细节。我以前做完页面总要自己跑一遍Lighthouse，现在让AI先自查一轮，明显省事。

性能优化skill。触发它会自动分析Bundle体积、图片尺寸、懒加载时机，并给出优化方案。对做中后台系统的团队特别有用。

组件库二次封装skill。如果你用Ant Design或Element Plus这类组件库，这个skill能把"组件统一风格"的要求固化下来，AI生成页面时自动引用封装过的组件，而不是直接用原始组件导致样式漂移。

我见过不少前端团队把这类skills直接放进~/.claude/skills/目录后，要求组员统一使用，代码review的批注量肉眼可见减少。说到底，skills解决的不仅是效率问题，更是团队协作的一致性难题。

3.3 数学建模场景的skills推荐

数学模型比赛是skills使用场景里挺特别的一个存在。因为它需要的技能栈非常杂：数据清洗、模型选型、代码实现、可视化、论文排版，每一个环节AI都能帮上忙，但每个环节的"正确工作方式"完全不一样。华为杯、美赛、国赛这几年越来越多人用AI辅助，直接把skills队伍带起来了。

数据清洗和探索性分析skill。建模的第一步永远是处理数据。一个好的data-cleaning skill会严格规定缺失值处理策略、异常值检测流程、归一化方式，并自动生成探索性图表。这个skill能避免AI拿到数据就瞎跑模型。

模型选型skill。做评价类问题，该用层次分析法、熵权法还是TOPSIS；做预测类问题，该用回归、时间序列还是神经网络。模型选型skill会把decision tree写进指令里，要求AI先分析问题类型，再论证模型选择，然后才动手写代码。

LaTeX论文排版skill。建模比赛时间紧，论文排版经常是最后一道坎。写一个论文skill，把三线表、公式规范、算法伪代码模板、参考文献格式全固化进去，AI直接按你的目标期刊/比赛要求生成论文段落，效率翻倍。

可视化skill也值得装。它会让AI生成图表时统一配色、字体、标注格式，保证论文里的图和代码里跑出来的图风格一致。

数学建模场景我个人的体会是：不要把skills理解成"做题神器"，它更像你的规范化助教。它不能替你想出创新模型，但它能确保你在有限时间内，把每个环节都做到位，不留扣分死角。

4. 自己动手写一个skills：从需求到落地

4.1 SKILL.md的标准结构和写作规范

聊完"用"，必须聊"写"。只有自己能写skills，才能真正把AI变成"你的"AI。

一个标准skill在磁盘上的结构是这样的：

my-skill/ ├── SKILL.md ├── scripts/ # 可选的脚本 ├── reference/ # 可选的参考资料 └── assets/ # 可选的模板文件

其中SKILL.md是核心，它决定了这一个skill能不能被正确触发、能不能按预期工作。我第一次写skills时犯的错就是把SKILL.md写成了长篇大论。后来看了不少优秀开源项目才悟到，SKILL.md的正确写法是有固定框架的。

第一部分是YAML frontmatter：

--- name:>--- name: anime-storyboard description: 根据剧情文本生成AI漫剧分镜表，包含景别、运镜、时长、台词、画面描述及对应文生视频prompt。适用于需要批量生成分镜脚本的场景。 ---

正文里的工作流部分：

## 工作流 1. 解析输入剧本，提取场景、角色、动作、对白。 2. 按"场景-镜头编号"生成分镜表，列为：编号、景别、运镜、时长、画面描述、台词、备注。 3. 角色一致性：如出现已登记角色，必须在画面描述中使用该角色的固定外观描述，不得自行改写。 4. 为每个分镜生成文生视频Prompt，包含主体、环境、镜头运动、画风、质量修饰词。

第四步，测试优化。装好后用一段实际剧本文本触发它，第一次跑出来分镜表结构没问题，但Prompt里的画风修饰词太统一、缺少变化。我又在skill里加了一条指令：画风修饰词需根据场景情绪动态选择（如紧张用暗调、温馨用暖色），重跑之后效果明显好多了。

从这个案例里能总结出一个通用心法：写skill本质上是"把你的隐形经验显性化"。规则越具体、边界越清晰，skill效果越好。别指望AI能理解你脑子里的默认值，你一定要把所有影响输出的条件都写清楚。

4.3 AI skills开发和调试的实操经验

写完skills只是开始，打磨才是重头。我建议你写完任何skill后，按下面这套方法测试：

先做单元测试：用几个典型的输入分别触发skill，检查输出是否符合预期。注意不要只测一个输入就下结论，要测边界。比如分镜skill，你给它一行文本它该怎么处理，给它一万字剧本又该怎么处理，两种情况差别很大。

再做干扰测试：故意给一个和skill场景完全无关的任务，比如数据分析skill你让它"写首诗"，看它会不会错误加载。如果它错误触发了，说明description写得有歧义，需要改得更精确。

最后做回归测试：把几个老任务重新跑一遍，确保新skill没影响之前的输出逻辑。这一步很多人忽略，直到某天发现AI行为突然变了才回头查，很浪费时间。

我自己的经验是，skill写好后最好让它能接受对话中的中途调整。比如分镜skill，用户可能在某个分镜上手动改了一版prompt，AI应该学会从那个点继续，而不是每次重新生成整套。

5. 日常维护：清理、迭代与常见问题排查

5.1 为什么skills一定要定期清理

skills装多了，"技能冗余"问题就来了。我有一段时间，前后装了二十多个skills，以为越多越好，结果AI反而变"钝"了——有时候它会在简单任务上错误地套用复杂skill，有时候因为多个skill的description互相重叠，AI不知道该选哪个，处理速度肉眼可见地变慢。

后来我参考了社区里tibo的清理思路，做了一次彻底梳理。tibo总结的方法很直接：以使用频率和触发准确度为标准，把skills分成三个等级——高频常用、偶尔用、基本闲置。常用保留，偶尔用的合并同类项，基本闲置的直接删。

具体操作也分享给大家：

第一步，列出所有已安装的skills：

ls ~/.claude/skills/

第二步，逐个看SKILL.md的description，问自己两个问题："我上一个用这个skill是什么时候？""这个描述有歧义吗？"如果两个问题都答不上来，就删。

第三步，用目录隔离低频skill。比如把不常用但可能用到的skills挪到~/.claude/skills/archive/里，让主目录保持轻量。这样AI扫描时不会被干扰，真需要用时再移回来。

第四步，定期合并同类项。比如我之前有"前端Code Review"和"组件审查"两个skill，内容高度重叠，直接合并成一个"前端工程化检查"，触发逻辑更清晰、输出也更稳定。

我之前写过一句话，清理完skills之后再说一次：skills的核心价值是把AI的注意力聚焦到你真正需要的流程上。装了二十个skill却互相打架，效果还不如只留五个精心打磨过的。

5.2 skills不生效、误触发、输出异常怎么办

用skills的过程中，我自己踩过不少坑，把这些整理成一个问题速查表，遇到问题直接按表排查：

这份排查表是我真金白银换来的经验。特别是"description写太宽泛导致触发错乱"这个问题，可以说十个skill翻车里有八个都是栽在这里。写描述时有个技巧：先写场景，再写输入，最后写输出，三要素缺一不可。比如"当你需要把CSV数据转换成中文报告时使用"，比"数据处理"好一百倍。

5.3 如何建立自己的skills迭代节奏

最后聊聊长期维护。skills不是一次写完就完事的，它应该跟着你的工作方式一起演进。我的建议是每两周专门留一个小时来做skills维护：翻一遍现有skills、看看哪些可以优化、哪些可以删除、有没有新场景值得沉淀。

另外一个容易被忽略的地方是：好的skills往往是一线项目复盘出来的，不是凭空设计的。我在给朋友写AI漫剧分镜skill之前，她根本说不出自己有什么固定偏好；是我观察她做了十几个分镜之后，才总结出那些隐含规则。所以，当你觉得某个任务反复手工调整时，先别急着忍，把它写成一个skill，一次投资长期受益。

我还想说一点，skills的写法本身也在进化。现在的生态里，很多人开始把skills和MCP工具链打通，比如skill里直接引用外部工具节点，让AI既能"按流程办事"又能"调用数据服务"。未来一段时间的趋势，一定是工具能力越来越标准化，个人差距越来越体现在你沉淀的skills方法论上。

我个人在实际操作中的体会是：skills这套东西，上手门槛比想象中低，但真正把它用好，需要的是你对自己工作流有清晰的认知。花点时间把重复劳动固化成skill，短期看是慢了，长期看是稳赚不赔的事。希望这篇能把你在AI编程skills这条路上省下不少试错的弯路。