最近AI编程圈里skills这个关键词几乎天天出现在我的信息流里。Claude Code、Codex、OpenCode甚至一些内部工具链都在用skills来做能力扩展。简单说一个skill就是给AI预装的一套专业外挂——把某一类任务的最佳实践、检查清单、代码样本全固化下来AI遇到对应场景时直接调用不用每次从零开始编提示词。前端做代码审查、数学建模比赛里跑数据、AI漫剧分镜生成这些都是skills的高频应用场景。我最早接触skills也是一头雾水这不就是提示词模板吗为什么还要搞目录、搞配置文件直到自己手动装了几个GitHub上的skills、又拆了几个开源skill包之后才真正明白它的价值。这篇文章就把我从skills是个啥到怎么装、怎么选、怎么写、怎么清理的完整链路讲清楚。不管你是刚开始折腾Claude Code还是已经在用Codex跑竞赛项目这里面都有能直接拿去用的东西。1. 先搞清楚AI Skills到底是什么东西1.1 从提示词模板到技能包的进化很多人第一次听到skills第一反应跟我一样这不就是把一段prompt存成文件下次复制粘贴吗只对了一半。提示词模板是文字skills是一套可执行的操作流程。你可以把skill理解成一本带目录的操作手册它告诉AI你什么时候该用我启动后按什么顺序做每一步有什么约束最后要输出什么格式。而且这个手册是结构化的AI能根据文件名和描述自动判断该不该调用。打个比方。普通提示词是你在路边招手拦车告诉司机去哪skill是提前在APP里绑定好常用路线你一上车司机已经知道你要走哪条路、走哪条辅路避开拥堵、在哪停。前者靠临场表述后者靠提前配置。所以skills实际改变的是AI在特定任务上的稳定性——它不再是看心情发挥而是绑定了一套经过验证的作业标准。这种进化背后的原因是大模型的上下文窗口再大也不可能把每个领域的全部细节都塞进对话里。skills把高频任务的知识点外置了需要用的时候才加载。对于前端开发、数学建模、代码审查这类有明确规范和重复步骤的活儿非常合适。1.2 Skills与传统插件、MCP、Agent的区别我刚开始也被这几个概念绕晕。后来自己总结了一个区分方法看它管的是哪一层的事。传统插件管的是工具层面。比如VS Code插件管的是编辑器UI、快捷键、语言服务它跟AI模型本身没直接关系。MCPModel Context Protocol管的是数据接入。它让AI能通过标准协议读外部数据源、调用外部工具比如查数据库、调天气API。MCP解决的是AI的手能伸多远的问题。Agent管的是任务拆解和循环执行。它让AI能自主规划步骤、调用工具、根据中间结果调整方案。Agent解决的是AI能自己跑多远的问题。Skills管的是专业能力。它不直接给AI提供新工具而是给AI提供在某个领域里的干活方法论。比如一个LaTeX论文格式化skill并不会自己去调LaTeX编译器但它会把排版规范、常见坑、检查清单全部喂给AI让AI在生成文本时直接按这些规范来。所以skills更像是给Agent和MCP之间加了一层行为准则。这三者不是替代关系而是协作关系。你可以让一个Agent同时挂着文件操作的MCP server再加载一个前端代码审查的skill。skill负责怎么审查MCP负责怎么读文件Agent负责什么时候调用它们。1.3 一个Skill的典型文件结构动手装之前先知道skill长什么样。到目前为止我见过的绝大多数开源skill都遵守一个基本约定一个文件夹就是一个skill文件夹里必须有一个SKILL.md作为核心描述文件其他资源文件放在同目录下。举个例子一个用于代码清理的skill目录如下code-cleanup/ ├── SKILL.md ├── scripts/ │ └── remove-dead-code.py ├── examples/ │ └── before-after.md └── references/ └── best-practices.mdSKILL.md是这个skill的说明书入口。它里面一般包含name技能名、description描述说明什么场景触发这个技能、instructions具体执行步骤、examples给AI参考的输入输出样例。AI在读取skill时最先看的就是description判断当前用户的请求跟哪个skill匹配。如果描述写得模糊AI很容易忽略掉这个skill。这就是我后来自写skill时反复踩坑的地方文件结构不难难的是让AI在正确的时候想起这个skill。后面第4章专门聊这个。2. 手工安装GitHub上的Skills最稳的接入方式2.1 别急着自动同步先搞懂目录结构现在很多AI编程工具都支持从远程仓库自动同步skills比如在配置里填一个GitHub仓库地址工具就帮你拉下来。看起来方便但我不建议新手上来就自动同步。原因很简单你根本不知道这个skill的目录会被放在哪、能不能被正确识别、跟已有配置有没有冲突。一旦出问题排查起来比手动装麻烦得多。手动装的优势在于每一步都清楚。你知道skill是从哪个仓库来的放在了本机什么位置配置文件里加了哪行生效。出了问题大不了删掉重来。自动同步适合你已经积累了一套稳定的skills配置、需要多台机器同步的情况。新手阶段手动装一次能帮你把整个机制摸透。多数AI编程工具的skills目录约定在特定路径下。比如Claude Code默认去项目目录的.claude/skills/或用户目录的~/.claude/skills/下查找OpenCode用的是.opencode/skills/或配置目录下的skills文件夹。安装的本质就是把GitHub仓库里的skill文件夹放到工具搜索路径下面。2.2 Claude Code手动安装从clone到配置以Claude Code为例完整流程分四步。第一步找到你想装的GitHub仓库。假设是someauthor/awesome-skill仓库里有一个code-review文件夹这就是一个skill。第二步克隆仓库到临时目录git clone https://github.com/someauthor/awesome-skill.git /tmp/awesome-skill第三步把skill文件夹复制到Claude Code的skills目录mkdir -p ~/.claude/skills cp -r /tmp/awesome-skill/code-review ~/.claude/skills/第四步验证。打开Claude Code直接给一个代码审查类的请求比如帮我审查一下src/main.ts里的潜在问题。如果AI自动提到了它正在使用code-review技能说明安装成功。这里有个细节有些仓库把多个skill打包在一起你在clone后会发现里面有skills/code-review、skills/test-generator等多个子目录。这种打包结构很常见复制的时候一定要带上一整层code-review目录而不是把里面所有文件直接平铺到skills/根目录。否则AI会把散落的SKILL.md当成一堆孤儿文件根本不会触发。2.3 Codex、OpenCode和其他工具怎么装Codex和OpenCode的安装逻辑跟Claude Code大同小异只是目录名不同。我自己在用的Codex它的skill目录通常在~/.codex/skills/或项目根目录.codex/skills/。操作方式一样把GitHub上的skill文件夹复制进去就行。如果你用的是OpenCode目录是.opencode/skills/。有些版本还支持通过网页版控制台导入搜索skills标签页点上传文件夹即可。不管哪个工具安装前建议先看一下官方文档里skills location的说明。因为这个概念还在快速迭代目录位置可能变化。我之前就遇到过某次工具升级后旧的skills配置路径失效AI一直找不到技能。最后查了更新日志才发现新版本把扫描目录从.config/skills/换成了项目级.agent/skills/。如果你用的工具不是主流这几款可以做个简单实验新建一个空目录放一个只有SKILL.md的测试skill名字起得特殊一点比如zz-test-skill。然后在对话里明确问AI“你有哪些skills可用”。要是AI能报出zz-test-skill这个名字说明路径对了。要是报不出来换个目录再试。2.4 安装后验证让Skill真正被AI发现光把文件放进目录还不算完你得确认AI真的看见了它。我最常用的验证方法有三种。第一种是直接询问。在对话框里输入列出你当前可以使用的所有skills按名称和用途说明。如果工具支持它会返回一个列表。看到刚装的skill在里面就说明文件结构没问题。第二种是行为验证。给一个能触发该skill的任务观察AI是否按skill里的步骤走。比如装了一个数学建模数据处理skill你就让它处理一份带缺失值的CSV看它会不会按skill里的流程先做缺失值统计、再决定填充策略。如果AI只是自己随便写了一段pandas代码没提skill说明触发条件没写好。第三种是日志验证。Claude Code和OpenCode在debug模式下会打印skill加载记录。以Claude Code为例启动时加上--debug --verbose参数能看到它扫描了哪些目录、加载了哪些skill。这个最直观能帮你定位路径问题。提示如果你把skill放进了项目目录比如项目下的.claude/skills它只对当前项目生效。放进用户目录~/.claude/skills则对全局生效。做实验时优先放全局方便多个项目复用。3. 值得收藏的Skills资源与实战推荐3.1 前端开发Skills代码审查与UI生成前端是skills玩得最成熟的方向之一。社区里最常见的几个场景是代码审查、组件生成、样式规范检查。比如一个React组件审查skill里面通常包含组件拆分合理性、props命名规范、hooks依赖检查、无障碍属性等检查项。装上它之后让AI审查代码得到的不再是泛泛而谈的代码清晰注意性能而是一份按规范逐项打分的报告。我实际用下来的体会是前端skills的价值在于把团队规范变成AI的默认行为。你不需要每次在提示词里重申我们要求函数组件优先props用TypeScript interface定义样式用CSS Modules这些全写进skill。AI一旦识别到与React组件相关的请求自动按规范处理。如果是新接手一个老项目这种方法尤其好用——把老项目的代码规范抽象成一个skill等于给AI也做了一次入职培训。UI生成类skill也很有意思。有些skill会内置一套设计组件库的使用说明告诉AI哪些组件可用、哪些属性必填。这样AI生成页面时产出的代码直接符合公司的组件库规范而不是自己造一堆不存在的组件。对于需要大量前端交付的团队这类skill能把返工率压下去不少。3.2 数学建模竞赛Skills华为杯场景实测热词里出现了华为杯建模比赛这块我非常熟。数学建模赛题通常集中在数据处理、模型构建、论文排版三个环节。以前用AI辅助每个环节都要反复解释任务背景、数据格式、格式要求。装了几个竞赛向skills后整个流程顺了很多。数据处理类skill我见过做得好的会包含缺失值占比统计、异常值检测方法建议、数据标准化代码模板、特征相关性热力图生成脚本。你只要告诉AI这份CSV有3万行目标是预测XXX帮我做数据清洗它就会按skill内的流程一步步来而不是一上来就给你一个pd.dropna()敷衍了事。模型构建类skill价值在于模型选型决策树。数学建模不像工程开发很多时候需要对比多个模型的效果。一个好的竞赛skill会把常见模型的使用场景、优缺点、复杂度写在里面AI会根据数据量、特征类型、目标变量类型帮你做对比实验并给出选择建议。论文排版类skill直接绑定LaTeX模板。华为杯这种比赛对论文格式有严格要求目录、公式编号、三线表、参考文献格式缺一不可。每次手动叮嘱很痛苦。装上排版skill之后AI生成内容时自动按模板走公式用\begin{equation}编号表格用booktabs宏包的三线表格式。我在一次模拟赛中实测光是调格式节省的时间就有两三个小时以上。3.3 社区高赞Skill集Superpower、Typesafe AI等GitHub上有几个明星级skill集热词里提到的Superpower Skills、Typesafe AI Skills我都实际拉下来用过。Superpower Skills是社区里讨论度很高的一个合集号称给AI一百种超能力。里面包含大量细分技能从文档编写、代码调试到项目复盘都有。它最大的优点是覆盖面广、说明文档详细。缺点也很明显体积大、SKILL.md数量多如果全量装上AI在加载时会有不小开销甚至导致无关skill之间的描述互相干扰。我的建议是不要整库复制按需挑几个实际用得到的子技能。Typesafe AI Skills来自一个开源组织特点是对TypeScript和类型安全有很强的执念。它里面的skill基本都以类型优先为核心比如数据库schema设计、API客户端生成、迁移脚本编写。我做前端项目的时候会挑其中的一两个配合使用。如果你本身就用TypeScript写全栈这个集子值得翻一翻。另外还有一些小而美的独立skill比如专门做Git提交信息规范化、专门做README生成的。这类单点skill装起来轻不容易造成冲突反而比大而全的技能集更常用。3.4 常用Skills源网站与下载渠道很多朋友问我去哪找skill这里整理一下我自己常逛的渠道。一是GitHub直接搜索。搜索关键词建议用awesome AI skills、claude skills、codex skills或者直接搜SKILL.md能看到大量个人项目。打开仓库看目录结构有SKILL.md的就能装。二是社区Skill库网站像是skills页面类的工具站。有些第三方站点做了可视化的skill导航按分类列出来了前端开发数据科学写作助手等下载方式通常也是跳转到对应的GitHub仓库。这类网站的好处是有人帮筛选过质量相对可控。三是官方仓库或技术博客提到的示例。Claude和OpenCode的官方文档里都有skill示例可以作为入门参考。另外一些做AI工具教程的博客也会维护自己的skill列表跟着下载一般不会踩坑。我的建议是优先装有过维护记录、README清晰、有实际示例文件的仓库。如果仓库最近几个月都没更新、SKILL.md写得很随意、没有examples目录这种大概率装了也没多大用。4. 自己动手写一个Skill从0到1的完整套路4.1 SKILL.md用元数据描述触发条件装了一堆skill之后你大概率会想写一个符合自己工作流的skill。别怕这个不复杂。核心文件就是SKILL.md写好了就成功了一半。看一个最小的SKILL.md开头--- name: code-cleanup description: 用于清理代码中的死代码、无用导入、重复定义等。当用户要求清理代码删除未使用变量移除无用依赖时使用。 ---中间的name是技能名description是触发条件。这部分非常关键。AI用什么方式选中这个skill就是读description看当前用户请求跟描述是否匹配。所以description里一定要写清楚什么时候用最好附上触发关键词和行为特征比如当用户要求。我刚写第一个skill时description写得很抽象用于代码质量管理。结果AI完全不知道什么时候刷这个技能经常是用户已经明确说清理代码了它还在用默认流程回答。后来我把description改成当用户请求与代码清理、死代码删除、未使用导入移除相关时使用包括要求代码整洁、移除无用代码、重构冗余逻辑等场景。触发准确率一下子就上来了。4.2 分步指令与参考示例的设计SKILL.md描述之下就是instructions部分。这部分要写得像一份清晰的操作手册而不是一段囫囵的说法。以代码清理skill为例我会按步骤拆## Instructions 1. 先扫描目标文件的import语句标记所有未使用的导入。 2. 搜索变量声明和赋值点识别只赋值未读取的死变量。 3. 对重复定义的函数或常量合并相同的实现。 4. 检查被注释掉的代码块询问用户是否删除不要默认删除。 5. 输出清理后的完整文件并附上变更摘要。步骤之间要有明确的顺序和判断规则。AI执行时会把每一步当成一个子任务逐项完成。如果你只写清理所有无用代码保持整洁AI大概率只能做一次粗略扫描不会按清单逐项确认。除此之外SKILL.md里最好加## Examples给一个before/after示例。AI能从示例中直接学到什么叫清理后的效果。比如## Examples **Before** python import os import json def unused(): return 1 def main(): data json.load(a.json) print(data)Afterimport json def main(): data json.load(a.json) print(data)这段示例看起来简单但它能让AI的输出风格保持一致。没有示例的skill就像是只给员工列了规则没给样例做出来的东西各次都不一样。 ### 4.3 实操写一个代码清理Skill并调试 下面我把自己写过的一个code-cleanup skill完整走一遍你可以直接照着抄。 先在~/.claude/skills/下建目录 bash mkdir -p ~/.claude/skills/code-cleanup然后创建SKILL.md内容参考我在4.1、4.2里给的结构加上一条规则除非用户明确说明否则不删除代码只标记并给出修改建议。这条规则是我踩过坑后加的因为AI一旦放开手脚很可能会把一些有用的代码当成死代码删掉尤其是一些通过反射或动态导入引用的模块静态扫描根本识别不出来。接着创建一个参考文件examples/before-after.md放一组从简单到复杂的代码清理示例。再创建一个references/checklist.md把Python和TypeScript各自需要检查的点分开列。调试时我建议在一个小型测试项目里做。给AI的指令是用code-cleanup技能分析一下src/util.py。然后观察它的输出。如果AI没有自动提到使用了这个技能先检查description命名。如果AI提到了技能但执行漂移就检查instructions写的是否足够具体。调试不要怕烦。我第一个skill改了三个版本才稳定第一版没有examples输出风格不稳定第二版步骤顺序不明确AI会把删除被注释的代码和清理导入混在一起第三版把每个步骤都加了输出约束比如每一步完成后等用户确认再继续下一步才真正可控。5. Skills管理更新、清理与避坑5.1 版本更新与依赖冲突处理skills看起来只是markdown文件但它们也存在版本问题。开源skill会更新你自己也可能在SKILL.md里添加新规则。更新时最容易出问题旧文件被覆盖但老版本的引用文件还散落在目录里导致AI读到的instructions是新的examples却是旧的。我的习惯是给skill版本号写在SKILL.md的metadata里像这样--- name: code-cleanup version: 1.2.0 description: ... ---更新时先diff一下本地和远程的差异再决定要不要全量覆盖。用git管理skills目录也是一招。把~/.claude/skills/做成一个git仓库每次更新后commit出问题还能回到上一个版本。这套操作我强烈推荐成本低而且保命。依赖冲突主要发生在两个场景。一是两个skill处理同一个任务比如一个代码审查skill和一个安全扫描skill都可能对一段代码提出建议AI在触发时不知道选哪个最后可能把两边的规则混在一起。解决办法是在description里把边界写清楚安全扫描只关注安全问题不评论代码风格。二是skill与工具内置行为的冲突。比如你装了一个生成commit message的skill它规定格式是feat: xxx但工具本身有一个commit message模板两边就会打架。这种冲突没法完全避免只能靠观察。遇到AI输出的格式跟你的预期不对先检查是不是有别的skill在起作用。5.2 清理无用SkillsTibo思路给我的启发前阵子看到社区里Tibo分享的清理skills思路给我启发很大。他的核心观点是skills不是攒得越多越好每次跟AI对话它都要去比对所有SKILL.md的描述确定哪个该触发。装了几百个skill之后描述之间的语义重叠会让AI选择困难触发质量直线下降。他推荐的清理方法是按需建索引。不是把每个skill都放在同一层目录下而是先建几个分类目录比如web-dev/、>