前言

我们从最基础的大模型、Prompt，一路学到了Agent、Function Calling、MCP。前面这些技术在咱们之前的「智能OnCall项目」中都有用到。

不过，从26年初开始，AI圈子又出了个叫Skills（技能）的新东西。当时我们在做智能OnCall项目时，还没有Skills这个概念，自然项目也就没有用到。

不过今天，我还是得专门带大家来学习一下Skills这个新玩意，因为它现在真的太火了，现在的AI岗位面试几乎逢考必问！

很多同学在看各种AI框架源码时，经常被这几个词绕晕：「它们到底是个啥？谁先出谁后出？有啥区别？」

别慌，今天咱们就泡杯茶，用最接地气的话，按照技术演进的真实时间线，把这三个概念从头到尾盘一盘。

---

一、第一阶段：AI的「破壁人」—— Function Calling（函数调用）

咱们先回想一下早期的ChatGPT。那时的它就像是一个被关在小黑屋里的超级学霸：

• 虽然上知天文下知地理

• 但它没网（没法查实时数据）

• 也没手（没法帮你真正去执行操作，比如发邮件、查数据库）

为了让大模型能连接外部世界，Function Calling诞生了。

用白话说，这就是大模型和外部世界打交道的一种「底层暗号」。

工作流程

你想让AI查今天深圳的天气，它自己查不到。但你可以给它提供一个get_weather的函数说明书。

1. AI看到你的需求和说明书后，不会直接回答天气

2. 而是输出一段JSON代码：「我决定调用get_weather，参数是深圳」

3. 你的代码拿着这个参数去真正调用API，查到结果后再喂给AI

4. AI最后总结成人类语言回复你

划重点：Function Calling是最基础的机制，它赋予了AI使用工具的「潜能」。

---

二、第二阶段：大一统的「Type-C接口」—— MCP（模型上下文协议）

有了Function Calling，大家都很兴奋，开始给AI疯狂写各种工具（查天气、查MySQL、读GitHub等等）。

但很快，新的灾难来了：接口完全不兼容。

• 张三用Python写了个查数据库的工具

• 李四用Java搞了个读本地文件的工具

由于没有统一的标准，你的AI应用想要接入这些现成的工具，就得挨个去适配它们千奇百怪的数据格式和通信逻辑。

这就像你买了个新手机，却发现大家用的充电线有圆头、扁头、方头，简直让人崩溃。

这时候，MCP（Model Context Protocol，模型上下文协议）闪亮登场。

用大白话说，MCP就是AI世界里的「Type-C接口标准」。

它是一套通用的开源协议。只要外部工具（数据源、数据库、代码仓库）按照MCP的标准开发成MCP Server，那么无论前端是哪个大模型（MCP Client），都可以无缝、零代码修改地直接插上去用。

MCP把Function Calling的能力彻底标准化了。

---

三、第三阶段：终极进化—— Skills（技能）为什么会出现？

好，现在AI有了底层机制（Function Calling），也有了标准化的工具箱（MCP）。是不是就天下太平了？

并没有！

随着咱们让AI干的活越来越复杂，26年初，一个极其痛点的问题暴露了出来：每次让AI干活，沟通成本太高了！

举个例子

假设你要让AI帮你写一份项目日报。你手里虽然已经有了MCP提供的「读取数据库」和「读取Jira」的标准化工具，但你每次跟AI聊天，还是得像个唐僧一样反复叮嘱。

没有Skills之前的现状：每次对话都要重新描述相同的工作流程

text

用户：「帮我按XX格式生成报告」
用户：「生成报告前，先去调用数据库工具获取今天的数据」
用户：「记得要包含数据分析和总结部分」
用户：「别忘了图表的排版细节……」
（每次生成报告，都要重复这段痛苦的「念经过程」）

发现问题了吗？ 工具虽然标准化了，但「使用工具的流程」和「大脑的思考方式（Prompt）」并没有被沉淀下来。

为了解决这个痛点，Skills（技能）应运而生！

---

四、什么是Skill？

Skill就像是给AI定制的一份「标准作业程序（SOP）」。

它把解决特定问题所需的背景设定（Prompt）、执行步骤和所需的工具（MCP），打包成了一个干净利落的代码文件。

用了Skills之后的方案：把经验沉淀为可复用的配置

markdown

---
name: report-generator
description: 按照公司标准格式自动收集数据并生成报告
tools:
  - mcp-jira-reader      # 挂载所需的MCP工具
  - mcp-database-query
---

# 报告生成流程
1. 包含封面页（模板见templates/cover.md）
2. 执行数据分析（自动调用 mcp-database-query 获取今日核心指标）
3. 提取任务进度（自动调用 mcp-jira-reader 获取任务状态）
4. 生成图表和摘要

只要有了这个Skill文件，你下次只需要对AI说一句：「帮我生成今天的日报」。

AI就会自动加载report-generator这个技能，自动按顺序调用MCP工具，按规定格式输出。一步到位，神清气爽！

---

五、拆解：一个Skill的内部结构长什么样？

从上面的对比图咱们能看出来，一个优秀的Skill，结构是非常清晰的，通常分为两部分：

1. 头部配置（Frontmatter）

• 通常用YAML语法写在最前面（被---包裹）

• 这里用来定义技能的名字、描述

• 最重要的是：在这里声明它需要挂载哪些MCP工具（Tools）

这就好比一个电工师傅出门前，先在工具箱里挑好今天要用的螺丝刀和万用表。

2. 技能主体（Body）

• 这里写的是具体的指令、工作流（Workflow）、规则限制和模板

• 这里的大白话指令，就是在教大模型「拿到工具后，第一步干啥，第二步干啥」

---

六、灵魂拷问：Skills不就是高级一点的Prompt吗？

可能看到这里，有同学心里犯嘀咕了：

「我看你这SKILL.md里面，主体部分不还是写了一堆自然语言的步骤吗？这不就是个长一点的Prompt吗？跟我在对话框里敲字有什么区别？」

这个问题问得太好了！ 其实很多人刚接触时都会有这个错觉。咱们来掰扯掰扯它俩到底是什么关系、有什么区别：

对比维度	Prompt	Skill
关系	Prompt是Skill的「灵魂核心」	完整Skill = Prompt + 工具列表 + 触发条件 + 上下文状态
能力	只能控制大模型的「嘴」	给AI赋予了「手」——通过绑定的tools，真的能去后台调用代码、拉取数据
工程化	「临时工」——上下文一长就忘，下次还得重敲	「标准资产」——写在项目目录里的配置文件，可提交到Git仓库
复用性	个人临时使用	整个团队都可以直接复用的SOP

打个粗俗点的比方

概念	类比
Prompt	你站在厨房门口喊：「去给我炒个鱼香肉丝，先放葱姜蒜，再放肉丝！」
Skill	你把《鱼香肉丝菜谱》写好，连带厨房里自动炒菜机的「启动钥匙」，一起装进了一个信封里。以后谁饿了，拿着这个信封扫一下，菜就自动炒出来了

---

七、实战加餐：以Claude Code为例，看看Skills到底有多强？

光说不练假把式。今年（2026年）Anthropic发布的终端编程神器Claude Code，直接把Skills机制带火了。咱们就以它为例，看看真实项目里是怎么玩Skills的。

场景假设

假设你在开发一个前端网站，经常需要把设计稿里的大图片压缩、转换成WebP格式，然后再挪到public文件夹里。

如果每次都让大模型现写一段Python脚本来跑，既费时间又容易出错。

有了Skills之后

你可以直接在项目目录下建一个专门干这活的「图片优化技能」。

目录结构

text

your-web-project/
├── src/
└── .claude/                    # Claude Code的专属配置目录
    └── skills/                  # 这里就是技能大本营
        └── image-optimizer/     # 我们自定义的「图片优化技能」
            ├── SKILL.md         # 技能的说明书和工作流
            └── optimize.py      # 真正干活的Python压缩脚本

SKILL.md里面写了啥？

markdown

---
name: image-optimizer
description: 专门用于将大尺寸图片压缩并转换为webp格式，输出到 public/assets
tools:
  - mcp-python-runner    # 声明需要用到运行Python代码的工具能力
---

# 任务流程
当你收到优化图片的指令时，请严格按照以下步骤执行：

1. 读取用户指定的原图片文件
2. 调用同目录下的 optimize.py 脚本，将原图转换为高质量的webp格式
3. 将转换后的图片移动到项目的 public/assets/ 目录下
4. 在终端打印出压缩前后的文件大小对比

怎么使用？

配置好之后，你在Claude Code的终端里，只需要像聊天一样发一句话：

text

用户：「把这张刚生成的测试图，用你的image-optimizer技能处理一下。」

Claude会自动：

1. 扫描skills/目录

2. 读取SKILL.md，理解整个工作流

3. 默默在后台调用脚本、压缩图片、移动文件

4. 最后在终端里回复你：「搞定了！图片大小从631KB压缩到了56KB，已经放在public目录啦！」

发现了吗？ 这种目录结构最大的好处是「热插拔」。

有了Skill，你实际上是在给AI「教流程」、写「SOP」。

以后再遇到类似的脏活累活，AI就能像个熟练的老员工一样，直接照着这个目录里的SOP帮你把活干得漂漂亮亮！

---

八、总结：理清它们的三角关系

最后，我再用一句话帮大家总结一下今天聊的这三个核心概念：

概念	本质	一句话总结
Function Calling	底层技术	让大模型拥有了「伸手」调取外部工具的能力
MCP	接口标准	统一了全网工具的接入规格，让AI拥有了「Type-C」通用插口
Skills	上层业务封装	将Prompt指令和MCP工具组合成「标准工作流」，让AI可以随拿随用、告别重复劳动

技术演进的时间线

text

能干活（Function Calling）
    ↓
统一标准（MCP）
    ↓
工程化沉淀和管理（Skills）

技术的发展永远是这样：从「能干活」，到「统一标准」，再到「工程化沉淀和管理」。

---

思维导图（文字版）

text

AI工具调用技术演进
│
├── 第一阶段：Function Calling（底层机制）
│   ├── 解决：大模型无法连接外部世界
│   ├── 方式：输出JSON格式的调用指令
│   └── 本质：赋予AI使用工具的「潜能」
│
├── 第二阶段：MCP（接口标准）
│   ├── 解决：工具接口不兼容，无法复用
│   ├── 方式：统一的Type-C接口标准
│   └── 本质：把Function Calling能力「标准化」
│
└── 第三阶段：Skills（业务封装）
    ├── 解决：每次对话都要重复描述工作流程
    ├── 方式：Prompt + MCP工具 + 工作流 = 配置文件
    └── 本质：给AI「教流程」、写「SOP」