Agent 工具正在从被动应答转向主动协作，但多数用户仍停留在初级问答阶段。Skill 的出现彻底改变了这一局面——它像标准化菜谱一样，将团队经验、工作流程和行业知识封装成可复用的数字资产。本文深度解析 Skill 的底层逻辑与实操方法，揭示 AI 时代真正的竞争壁垒。

相信现在一谈到agent，我知道大家都在想什么。不就是装个 Claude Code 或者 OpenClaw 吗？然后呢？然后就是反复地问问题，每次都要把自己的需求从头解释一遍。这感觉，就像你每次去一家新餐厅，都要重新跟服务员解释一遍你爱吃辣、不要香菜、饮料要少冰——累不累啊？

说实话，我自己在今年去做AI企业内训的时候，我发现一个很尴尬的现象：团队里的产品经理们人人都在用 AI，但每次给他们演示怎么用，演示完了下次还是不会。问题出在哪？就在于他们只是在”问”AI，而不是在”教”AI。

而今天我介绍的Skill 就是来解决这个问题的。

01 什么是 Skill？——给 AI 的”员工手册”

在说 Skill 是什么之前，我们先来理解一个痛点。

你有没有这样的经历：每次和 AI 对话，都要从头解释一遍”我是做什么的”、”我们团队用什么工具”、”报告要按什么格式写”？就像教一个新员工一样，从零开始教一遍，干完活就忘，下次再来一遍。

这个问题的本质是：大模型有海量的知识储备，但它不知道你的具体工作流程。它知道怎么写代码，但不知道你们团队的代码规范；它知道怎么处理数据，但不知道你的分析方法论。

怎么理解 Skill？我用三个比喻来说。

第一层：Prompt 是点单。你跟服务员说”老板，给我来个牛肉汉堡，不要洋葱”——指令很明确，但怎么做，全看厨师心情。Prompt 就是这么回事，你给 AI 一个指令，它自己想怎么执行就怎么执行。

第二层：MCP 是厨房里的工具和食材。铲子、平底锅、牛肉饼、面包，这些是执行任务需要用到的家伙事儿。MCP 解决的是 AI 能调用什么工具的问题。

第三层：Skill 是秘制菜谱加员工守则。”第一步，肉饼必须煎三分半；第二步，酱汁只能挤两圈半；第三步，做完必须清理灶台。” Skill 规定了动作的先后顺序、质量底线和执行标准。有了它，AI 不再瞎猜你的心思，而是按部就班地干活。

简单来说：Prompt 告诉 AI”做什么”，MCP 告诉 AI”用什么工具”，而 Skill 告诉 AI”怎么做”。

所以我才说，没有 Skill 的 Agent，就像刚入职的新同事——你得培训，反复教他。而有了 Skill 的 Agent，则更像是一位老同事，开箱即用，配合默契，非常靠谱。

💡 知识卡片Skill 是 AI 时代的”员工手册”：
· Prompt = 点单（告诉做什么）
· MCP = 厨房工具（告诉用什么）
· Skill = 秘制菜谱 + 员工守则（告诉怎么做）

02 Skill 的核心架构——四件套文件夹

说完了 Skill 是什么，我们来看看 Skill 长什么样。

其实 Skill 就是一个标准化的文件夹。你没听错，就是一个文件夹。里面放着一些 Markdown 文件、脚本、参考资料，仅此而已。

标准的 Skill 结构是这样的：

your-skill-name/
├── SKILL.md# 必须——核心指令文件
├── scripts/# 可选——可执行代码
├── references/# 可选——参考文档
└── assets/# 可选——素材资源

SKILL.md 是最核心的文件，必须有。它包含两部分内容：YAML 前置信息（供 AI 判断”什么时候该用这个 Skill”）和 Markdown 正文（具体执行指令）。

scripts/ 是可选的，用来放可执行代码，比如 Python 脚本、Bash 脚本等。当 Skill 需要执行一些自动化任务时，脚本就放在这里。

references/ 也是可选的，用来放长参考文档。比如技术规范、API 文档、代码片段、设计指南等。这些内容不会默认加载，只有 AI 需要的时候才会去读取。

assets/ 同样是可选的，用来放模板、字体、图片等素材资源。

关于命名，有几条规范必须遵守：

• 文件夹名必须使用 kebab-case（短横线连接小写字母），比如 `article-scorer`、`pdf-parser`。不能用空格、下划线或者大写字母。
• 文件夹名不能以 `-skill` 结尾。比如你不能创建 `article-scorer-skill` 这样的文件夹。
• 打包后的文件名格式是 `.skill`，比如 `article-scorer.skill`。
• 所有文档都要放在 SKILL.md 或 references/ 里，不要放 README.md。

所以核心架构如下：

03 手把手实战：创建一个”文章评分”Skill

光说不练假把式。现在我来手把手带你创建一个真正的 Skill。

这个 Skill 的功能是：帮用户评估文章的质量，给出打分和改进建议。

Step 1：创建文件夹结构

首先，我们创建一个文件夹叫 `article-scorer`：

article-scorer/
├── SKILL.md# 必须
├── scripts/# 可选，本次不创建
├── references/# 可选，本次不创建
└── assets/# 可选，本次不创建

Step 2：编写 YAML frontmatter

打开 SKILL.md，首先写 YAML 前置信息。这部分决定了这个 Skill 什么时候会被触发：

—
name:article-scorer
description:评估文章质量并给出改进建议。当用户说”帮我评分这篇文章”、”评估一下这篇文章写得怎么样”、”给这篇文章打个分”时使用。
—

name 字段必须用 kebab-case，不能用大写字母或下划线。

description 字段是最关键的，因为它告诉 AI 什么时候该用这个 Skill。一个好的 description 要包含两部分：一是能做什么，二是触发场景。

Step 3：编写 SKILL.md 正文

YAML 写完之后，开始写正文。正文结构一般包含以下几个章节：

任务目标：

## 任务目标
– 评估文章的整体质量，包括结构、逻辑、表达三个维度
– 给出一个 1-10 分的综合评分
– 指出文章的主要问题并给出具体改进建议

评分标准：

## 评分标准
– 结构（30%）：开头是否有吸引力、层次是否清晰、结尾是否有总结
– 逻辑（40%）：论点是否明确、论据是否充分、推理是否严谨
– 表达（30%）：语句是否通顺、用词是否准确、是否有错别字

操作步骤：

## 操作步骤
1. 读取用户提供的文章内容
2. 按照评分标准逐项分析
3. 计算综合评分
4. 输出评分结果和改进建议

输出格式：

## 输出格式
最终输出应该包含：
– 综合评分（1-10分）
– 各维度评分（结构/逻辑/表达）
– 主要优点（1-3条）
– 主要问题（1-3条）
– 改进建议（具体可执行）

这样一个简单的 Skill 就完成了。

你看，其实没那么复杂，就是一个标准化的文件夹加上 Markdown 文件。

04 YAML frontmatter 详解——决定 Skill 是否被触发的关键

刚才我们写的 YAML 看起来很简单，但这里面的门道不少。

description 是整个 frontmatter 里最重要的字段，因为它决定了 AI 在什么时候会激活这个 Skill。

可能有人要说了，description 不就是写几句话吗？有什么难的？但说实话，我见过太多人的 description 写得跟谜语一样，AI 看了根本不知道什么时候该激活这个 Skill。

好好好，我直接给你们看两个对比。

反面例子：

description:一个有用的工具

正面例子：

description:评估文章质量并给出改进建议。当用户说”帮我评分这篇文章”、”评估一下这篇文章写得怎么样”、”给这篇文章打个分”时使用。

区别在哪里？好的 description 有具体的触发短语，AI 可以精准匹配用户意图。

一个好的 description 要包含三个要素：

第一，能做什么。清楚地说出 Skill 的核心功能。比如”评估文章质量并给出改进建议”。

第二，何时使用。告诉用户怎么触发这个 Skill。比如”当用户说’帮我评分这篇文章’时使用”。

第三，触发短语。列出一些典型的用户表达方式，让 AI 能够准确识别。

话说回来，还有两个常见的错误要提醒大家：

description 写得太太长。frontmatter 是每次对话都会加载的，如果太长，会浪费宝贵的上下文空间。一般来说，description 控制在 100-150 个字符就够了。

把多个功能塞进一个 Skill。有人觉得一个 Skill 做一件事太麻烦了，想做一个”万能 Skill”。这是不对的设计。Skill 的核心原则是：每个 Skill 只做一件事。

💡 知识卡片description 三大要素：
· 能做什么 — 核心功能
· 何时使用 — 触发时机
· 触发短语 — 典型表达方式
原则：控制在 100-150 字符，每个 Skill 只做一件事

05 SKILL.md 正文怎么写——渐进式披露的艺术

说完了 frontmatter，我们来看看正文的写法。

Skill 最重要的设计理念是”渐进式披露”。什么意思呢？

AI 处理长上下文是很吃力的，如果每次激活 Skill 都把所有内容加载进去，效率会很低。渐进式披露就是来解决这个问题的。

它分为三层：

第一层：YAML frontmatter。每次对话开始时，AI 会加载所有可用 Skill 的 name 和 description。这个层级的内容必须精简，大约只需要 30-50 个 token。AI 靠这些信息判断该激活哪些 Skill。

第二层：SKILL.md 正文。只有当 AI 决定使用某个 Skill 时，才会加载完整的正文内容。正文里可以写几千字的详细指令，但只有在需要的时候才会占用上下文。

第三层：references/ 里的链接文件。如果正文里引用了参考资料，AI 会按需去读取这些文件，而不是一开始就全部加载。

这种设计的聪明之处在于”懒加载”。就像网页图片一样，滚动到了才加载，不仅省 token，还能让 AI 在长对话中保持注意力集中。

接下来，我们看看正文的结构。Anthropic 推荐的标准结构是这样的：

• 任务目标：说明这个 Skill 用来做什么，适合什么场景。
• 前置准备：需要什么依赖、准备什么文件。
• 操作步骤：具体的执行流程，最好给出决策树，告诉 AI 在什么情况下走什么分支。
• 资源索引：告诉 AI 去哪里找脚本、参考资料、模板等资源。
• 注意事项：这个部分非常重要！根据 Anthropic 内部团队的经验，最有价值的内容是”常见陷阱”章节——记录 Agent 的失败模式，让后来者可以直接绕坑。

一个高质量的 SKILL.md 通常包含以下要素：

• 明确的职责边界。告诉 AI 能做什么和绝对不能做什么。比如一个 SQL 分析 Skill 应该明确限定只能执行 SELECT 查询，禁止执行 DROP、DELETE 等危险操作。
• 具体可执行的步骤。不要写”分析一下这篇文章”，而要写”第一步读取文章，第二步检查结构，第三步评估逻辑”。
• 失败处理机制。当某个步骤出错了，AI 应该怎么办？要有明确的回退策略。

06 避坑指南——Anthropic 官方总结的常见错误

最后，我结合 Anthropic 官方指南和我的实际经验，给大家总结几个常见的坑。

坑一：description 写得太模糊，AI 无法判断何时触发

反面例子：

description:一个有用的工具

正面例子：

description:生成单元测试。当用户说”写个测试”、”帮我测试一下这段代码”、”生成 unit test”时使用。

区别在哪里？好的 description 有具体的触发短语，AI 可以精准匹配用户意图。

坑二：文件夹命名不规范

错误写法：`ArticleScorer`、`article_scorer`、`article scorer`

正确写法：`article-scorer`

记住，kebab-case 是唯一的标准格式。

坑三：一个 Skill 做太多件事

反面例子：一个 Skill 既能写文章、又能改文章、又能排版、又能发布。

正面例子：拆成四个独立的 Skill——`article-writer`、`article-editor`、`article-formatter`、`article-publisher`。

为什么？因为多个 Skill 可以同时加载，如果一个 Skill 太大太全，就会失去灵活性。专注做一件事的 Skill，更容易被组合使用。

坑四：把所有内容都塞进 SKILL.md

反面例子：SKILL.md 写了 3000 多行，里面塞满了各种参考资料。

正面例子：SKILL.md 只写核心流程，详细的技术文档放到 references/ 里，让 AI 按需读取。

话说回来，这样做的好处是什么？AI 每次只需要加载它真正需要的内容，上下文消耗可以降低 60%-80%。

💡 知识卡片Skill 四大避坑指南：
· description 要具体，含触发短语
· 文件夹名用 kebab-case
· 一个 Skill 只做一件事
· 详细内容放 references/

写到这里，关于怎么从零开始编写 Skill，已经讲得差不多了。

不知道你有没有这种感觉。AI 时代，大家都在讨论怎么”用”AI，怎么”问”AI。但真正拉开差距的，是那些会”教”AI 的人。

怎么教？你要把自己的经验、团队的工作流程、行业里那些”只有老员工才知道”的隐性知识，封装成一个又一个的 Skill。

这不是在写代码，这是在建立数字化的知识资产。

一个写好的 Skill，可以给团队里所有人用。新同事入职，再也不用从零开始培训 AI 了。老人总结出来的最佳实践，也不会因为离职而消失。

所以我才说，Skill 才是 AI 时代最重要的资产。

怎么说呢，在这个时代，我们最应该学的不是”问AI”，而是”教AI”。把重复的事交给AI，把自己的精力专注在真正重要的事情上。说白了，专注自己的业务，才是AI时代的王道。