哈喽大家好，我是欧呦，这篇文章将为大家分享如何从 0 到 1 了解什么是 AI Agent 的 Skill——包括它到底是什么、为什么能省下大量上下文、总共分为哪两类，以及新手怎么挑选和安装别人写好的 Skill。

平时用 AI Agent 写代码或处理日常工作，我们最容易碰到两个痛点：一是每次做同类事情都要重复描述一大串内容，不得不把长长的提示词反复复制粘贴到输入框里；二是「AI Agent 使用姿势的分发」——当别人想要学习我是怎么样使用 AI Agent 的，或者想要学习我的提示词和工作方式时，光靠发几段零散的文字，别人很难直接拿过去跑出一样的效果。

Skill 解决的就是这两个痛点。它既能把你反复执行的工作方式保存下来，也是一种非常适合打包分发「AI Agent 使用姿势」的承载形式。

Skill 是什么？

很多人第一次听说 Skill，会以为它是什么复杂的专属插件系统。

其实从官方背景来说，Skill（Agent Skills）最早是由 Anthropic（也就是 Claude 背后的公司）推出并开源的一套开放规范，最初在 Claude 与 Claude Code 中落地。但这套规范推出后，很快就不再局限于 Claude 一家，像 OpenAI 的 Codex、Cursor、DeepSeek Harness 等主流 AI Agent 工具都纷纷支持了同一套结构。

为什么一家公司推出的规范，能这么快变成所有 AI Agent 通用的标准？因为 Skill 的本质其实就是几个文件，它只是一个有约束规范的文件夹。

现在的 AI Agent 本身就已经具备了读取文件、写入文件的能力，还可以自己执行终端命令、调用脚本。既然 Agent 可以自己去读取本地文件，那就不需要我们每次一次性地复制一大串提示词粘贴在输入框里了；而且正因为它是一个文件夹，里面除了写给 AI 看的说明文档（SKILL.md），还可以放脚本、参考文件这一类的东西。

不依赖特定平台的私有接口，只要按照这套约定的目录规范把文件放在一个文件夹里，任何能读文件的 AI Agent 都能直接读懂并照着执行——写好一份 Skill，你在不同 Agent 里都能直接复用。

为什么不直接把内容全塞进上下文？

知道了 Agent 能自己读文件，很多人紧接着会问：那我直接把所有要求和规范都写进项目的全局规则文件（比如 AGENTS.md 或 CLAUDE.md）里，让 Agent 每次对话都默认带上，不就好了吗？为什么要单独做成 Skill？

这是因为 Skill 有渐进式加载的机制。

如果我们直接在 AI Agent 里面注入大量的上下文，其中很大一部分内容很有可能是跟当前执行的那些任务无关的。比如你今天只是想改一段后端接口，如果上下文里硬塞着几万字的 UI 设计规范、文案润色标准和视频剪辑流程，导致上下文膨胀之后，AI Agent 不仅它的 Token（模型处理文本的容量与计费单位）开销高，而且它的执行效果也会变差——因为模型有注意力机制，无关信息塞得太多，注意力就会被分散。

而使用 Skill 的话，我们可以像查字典一样：先看目录，根据目录里面的索引，再对应到具体的内容。这样我们就可以向模型输入尽可能少的上下文。

一次性塞入大量无关上下文与 Skill 像查字典一样渐进式加载的对比

拆开一个标准的 Skill 文件夹

顺着「先看目录、再翻正文、最后按需用工具」的思路，一个标准的 Skill 文件夹通常长这样：

my-skill/
├── SKILL.md        # 必选入口：顶部写目录索引，下方写执行主流程
├── scripts/        # 按需添加：放固化的可执行脚本
├── references/     # 按需添加：放详细的参考规范或长文档
└── assets/         # 按需添加：放页面模板、图片等静态资产

文件夹里一定会有一个 SKILL.md 作为入口，配合三个按需添加的子目录，分成三层来工作：

  1. 第一层是「字典目录」（SKILL.md 顶部的元数据）。SKILL.md 最开头有一小段用 --- 包起来的元数据（YAML frontmatter），包含这个 Skill 的名字（name）和触发描述（description）。Agent 平时处理请求时，上下文窗口里始终只加载所有 Skill 的 name 和 description，用它来跟你的需求做匹配。这是 Agent 判断「这次要不要用这个 Skill」的唯一依据。
  2. 第二层是「正文说明」（SKILL.md 的主体内容）。只有当你的需求匹配上了目录里的描述，Agent 才会真正打开并读取 SKILL.md 的正文，了解这项任务的目标、判断标准和执行步骤。
  3. 第三层是「按需附件」（scripts/、references/ 和 assets/）。正文之外的资源默认都不会放进上下文里，只有执行到具体某一步需要时才会调用：
    • scripts/ 用来放可执行脚本，把重复、稳定的操作固化成程序；
    • references/ 用来放长篇参考文件（比如流程里某一步才用得到的详细规范），Agent 需要时再去读对应文件；
    • assets/ 用来放模板或静态资产（比如填上数据就能在浏览器打开的 HTML 预览模板）。

为了让你有个直观概念，一个真实的 SKILL.md 其实非常直观，核心结构就这么几行：

---
name: my-ui-helper
description: 设计与优化网页 UI 界面。当用户要求探索页面视觉方向、生成同屏对比稿或对照真实截图修改样式时使用。不要用于纯后端接口开发。
---

## 执行步骤

1. 先和用户确认页面目标，给出 3 个构图不同的设计方向。
2. 需要生成同屏对比页时，直接运行 `scripts/build-compare.mjs`，不要每次临时手写合并代码。
3. 需要核对排版细节时，再读取 `references/layout-checklist.md` 中的检查项。

可以看到，这套分层结构的共同目的，就是把复杂的准备工作留在创建 Skill 的时候，让 Agent 在日常使用时始终保持最精简、最清醒的上下文。

Skill 的两种分类：知识型与流程型

在我看来，所有的 Skill 总共就分为两种：知识型的 Skill 和 流程型的 Skill。

知识型 Skill 补充判断标准与流程型 Skill 固化多步工作流的左右对比

1. 知识型 Skill：补充 Agent 原本没有的判断标准

模型不是万能的，很多事情如果直接让它做，它只会用自己默认的那套习惯去应付。比如让 AI 写中文文案，它默认经常堆砌修饰词、生造比喻或者写出一股生硬的翻译腔；再比如让它拆解一条爆款视频，它往往抓不到核心。

这时候就可以把我们自己的经验、审美和判断标准写成知识型 Skill，让 Agent 每次动手前先读取这套方法论。以我开源的文风规范 Skill oil-tone 为例，它就是一个典型的知识型 Skill：里面没有复杂的外部程序，核心就是告诉 Agent 怎样把中英文文案写得自然、易读、通顺、清楚——比如按读者此时已经知道的信息安排段落顺序、保留让语气自然的「的」「了」等虚词、删掉没有信息量的空话。有了这套明确的判断标准，模型就不再只是凭默认习惯乱加修辞。

2. 流程型 Skill：固化多步工作流与配套脚本

另一类是每天或经常要执行的重复工作流：先做什么、再做什么、中间用什么工具处理、最后怎么检查和交付。如果每次都用一大段话重新描述一遍，成本非常高，这类任务就适合固化成流程型 Skill。

以我开源的 UI 设计 Skill Oil UI 为例，它代表的就是流程型 Skill：里面不仅规定了从「先拉开构图差异探索方向 → 准备素材 → 编码实现 → 独立看图评审 → 最后做视觉减法」的完整步骤，还在文件夹里直接提供了配套脚本，让 Agent 可以按步骤稳定地跑完整条设计链路。

什么样的内容没必要做成 Skill？

弄清楚知识型和流程型这两个作用后，就能排除掉很多没有实际价值的 Skill。

现在大家创建 Skill 大多会借助 AI 生成，但如果没有人为地提供 knowhow（真知灼见与具体实战经验），生成出来的 Skill 其实帮助不大——让 AI 自己写给 AI 自己看的内容，它只会把原本就已经知道的常识再复述一遍。比如把九九乘法表做成 Skill，并不能提升模型的数学能力；还有一些写得很通用的 UI/UX 指导，里面只写一句「你是一个顶级设计师」，却没有任何具体的规范和判断标准，模型能力差的看了还是差，能力强的本来就不需要。Skill 越通用、越宽泛，对具体某一件事的作用就越小。

另外，如果只是一两句经常发送的短指令——比如让 Agent 排查问题时，经常要提醒它「一定要先定位到核心问题，不需要直接动手，定位后先跟我用最直观的方式说清楚」——这种只有一两句话的日常叮嘱也没必要做成带目录的 Skill，直接保存成工具里的快捷提示词（Prompt，相当于常用语快捷短语）就够了。

怎么找到、安装并使用现成的 Skill？

对于刚入门的读者，如果想先体验一下别人写好的 Skill，最好的方式就是去 GitHub，或者去一些现成的 Skill 仓库与聚合站，比如说 SkillHub、skills.sh、SkillsMP、ClawHub 这种。代码是文件，Skill 也是文件，都可以用同一种形式托管和下载。

三种安装方式（最省事的是直接让 Agent 装）

既然 Skill 只是一个文件夹，安装它的本质，就是把这个文件夹放到电脑上 Agent 会读取的固定目录里。如果你希望所有项目都能用，就放进个人的全局目录（比如 Codex 是 ~/.codex/skills，Claude Code 是 ~/.claude/skills）；如果只想在当前项目里用或者跟团队共享，也可以放进项目仓库下的 .agents/skills（或 .claude/skills）目录里。

平时安装主要有三种方式：

  1. 手动下载解压：从 GitHub 下载仓库压缩包，解压后直接放进对应的 skills 文件夹里；
  2. 使用命令行安装：打开终端执行 npx skills add 命令（后面跟上 GitHub 的用户名和仓库名），再按提示勾选要安装到的 Agent： 
    npx skills add oil-oil/oil-tone
  3. 直接让 AI Agent 帮你装（最推荐）：大多数时候我们根本不需要自己去找目录或敲命令。因为 Agent 本身就能执行命令、下载文件和创建文件夹，它最清楚自己的 Skill 目录在哪里。你只需要把仓库地址发给它，直接说一句：

    帮我从这个地址下载 Skill，安装到对应目录，再检查是否能读取。

装好之后怎么触发使用？有自动和手动两种方式：平时你只需要在对话框里正常说需求（比如「帮我把这篇文稿改得自然通顺一点」），Agent 扫描目录里的 description 匹配上之后就会自动加载 oil-tone；如果你想明确指定它用某个 Skill，也可以直接在句子里点名（比如「请用 oil-tone 帮我润色这段话」），或者在输入框里敲 /（或 $）从列表里选中它。

核心原则：没遇到问题前先别用，Skill 不是越多越好

在安装和使用第三方 Skill 时，有一个非常重要的点：如果自己在没有遇到具体问题之前，尽量先不要使用 Skill；而且 Skill 绝不是安装得越多越好的。

很多人刚接触 Skill 时喜欢一口气装上几十个，觉得反正它是渐进式加载的，多装几个备着也没坏处。但实际上这有两个很大的问题：

  • 第一，错误的 Skill 很有可能会影响 AI Agent 的执行效果。 社区里的 Skill 质量参差不齐，如果某个 Skill 里的指令写得混乱、生硬或者逻辑有漏洞，一旦被触发，反而会把原本能正常干活的 Agent 带偏。
  • 第二，装得太多依然会干扰模型决策。 虽然 Skill 的正文是触发后才加载的，但所有已安装 Skill 的 name 和 description 始终都在上下文窗口里。如果装了一大堆功能宽泛或者互相重叠的 Skill，模型在匹配需求时很容易混淆什么时候该用哪个；无关的目录信息多了，同样会稀释注意力。

保持精简，遇到真正痛点时再针对性地引入。而当你发现某件事自己每天都要重复做，或者手头的经验值得打包分享给别人时，就可以开始动手写一个属于自己的 Skill 了——下一篇我们就来拆解怎么从 0 到 1 写出一个好用的产品级 Skill。