Skill 与 MCP Function：傻傻分不清楚？

1. 写在最前面

最近在深度使用 Kiro 的过程中，发现它提供了两种扩展 AI 能力的方式：Skill 和 MCP Function。第一次看到这两个概念的时候，笔者是有点懵的------这不都是「给 AI 加能力」吗？有什么区别？

带着这个疑问，笔者花了点时间把两者都实际用了一遍，也查了不少资料，终于搞清楚了它们的定位和差异。趁着记忆还热乎，赶紧整理一下。

注：Skill 和 MCP 并不是 Kiro 独有的概念，Cursor、Claude Code、Windsurf 这些 AI IDE 都有类似的机制，只是叫法不同。搞清楚这两者的区别，换哪个工具都用得上。

2. 先搞清楚它们是什么

2.1 Skill 是什么

Skill 本质上是一段自然语言写成的指令或知识，通过文件的形式注入到 AI 的上下文里。你用 Markdown 写好，AI 读进来，然后按照里面的描述去理解和执行。

各家工具的叫法不一样，但干的是同一件事：

工具	叫法	文件位置
Kiro	Skill / Steering	`.kiro/skills/`、`.kiro/steering/`
Cursor	Rules	`.cursorrules`、`.cursor/rules/`
Claude Code	Memory	`CLAUDE.md`
Windsurf	Rules	`.windsurfrules`

一个典型的 Skill 长这样：

markdown 复制代码

---
name: write-commit-message
description: 按照约定式提交规范生成 git commit message
---

# Commit Message 规范
格式：<type>(<scope>): <subject>

type 类型：feat / fix / docs / refactor / test
示例：feat(auth): 添加用户登录功能

AI 加载这个 Skill 之后，生成 commit message 就会严格遵循这个格式。

需要特别说明的是：Skill 不是没有副作用的。Skill 里写的是自然语言指令，AI 会解释并执行。如果你在 Skill 里写「每次任务完成后把结果插入数据库」，AI 照样会去做这件事------只要它有对应的能力（比如配置了数据库相关的 MCP）。Skill 的内容决定了 AI 的行为意图，而不是限制它的能力边界。

2.2 MCP Function 是什么

MCP（Model Context Protocol）Function 是通过标准协议暴露出来的结构化工具接口。它有明确的函数签名、输入输出 schema，AI 在推理过程中可以按需调用，拿到确定性的结果。

一个典型的 MCP 调用过程：

css 复制代码

用户：帮我查一下 main 分支今天有哪些新提交

AI 内部推理：
1. 判断需要调用 github.list_commits
2. 构造参数：{ branch: "main", since: "today" }
3. 发起调用，等待返回
4. 拿到结果：[{ sha: "a1b2c3", message: "fix: 修复登录超时" }, ...]
5. 整合结果回答用户

整个过程中，AI 真实地调用了 GitHub API，拿到了实时数据，结果是确定的，不依赖 AI 的「记忆」或「理解」。

3. 核心区别

3.1 指令 vs 接口

这是两者最本质的区别。

Skill 是自然语言指令：你告诉 AI 「应该怎么做」，AI 来理解并执行。灵活，但执行结果依赖 AI 的理解能力，存在一定的不确定性。

MCP Function 是结构化接口：你提供一个函数，AI 决定「什么时候调用」，但调用的过程和结果是确定的，不受 AI 理解偏差的影响。

打个比方：

Skill 像是给新员工一份操作手册，他按照手册理解后去执行，理解偏了结果就偏了
MCP Function 像是给新员工一套自动化工具，他只需要决定什么时候按哪个按钮，按下去的结果是固定的

3.2 Token 消耗的差异

这个维度在实际使用中很重要，尤其是 token 不够用的时候（笔者深有体会......）。

Skill 的 token 消耗更少，原因在于它的工作方式更「轻」：

复制代码

Skill 的 token 路径：
Skill 文本（一次性注入上下文）→ AI 直接推理执行
消耗：Skill 文本本身的 token

javascript 复制代码

MCP Function 的 token 路径：
① 工具描述注入上下文（每次对话都要带上所有工具的 schema）
② AI 推理决定调用哪个工具（消耗推理 token）
③ 构造调用参数（消耗 token）
④ 工具返回结果注入上下文（结果文本的 token）
⑤ AI 基于结果继续推理（消耗 token）
消耗：工具 schema + 调用过程 + 返回结果

具体来说，MCP 多出来的 token 消耗主要在这几块：

消耗来源	Skill	MCP Function
工具 schema 描述	无	每次对话都要带上，工具越多越贵
调用参数构造	无	AI 需要生成结构化的调用参数
返回结果	无	工具返回的数据会塞回上下文
多轮推理	一次	调用前后各一次，至少两轮

所以如果你配置了很多 MCP Server，但实际上只用到其中一两个，剩下的工具 schema 还是会占用上下文，白白消耗 token。

注：这也是为什么建议按需配置 MCP，不用的 Server 及时 disabled: true，不然 token 就这么悄悄流走了。

4. 怎么选

搞清楚了区别，选起来就比较直观了：

用 Skill，当你想：

固化某种规范或流程（代码风格、提交规范、文档模板）
注入项目背景知识，让 AI 了解项目上下文
定义 AI 的行为模式，比如「回答问题时先列出思路再给结论」
对 token 消耗比较敏感，希望尽量节省

用 MCP Function，当你想：

让 AI 获取实时数据（GitHub 提交记录、数据库查询结果、天气信息）
让 AI 操作外部系统（创建 PR、发送通知、写入数据库）
需要确定性的执行结果，不能依赖 AI 的「理解」
打通 AI 和现有工具链

两者结合，当你想：

用 Skill 定义"做什么、怎么做"的规范
用 MCP Function 提供"真正去做"的能力

比如：Skill 里写"创建 PR 时描述必须包含问题背景和解决方案"，MCP Function 提供 github.create_pull_request()，两者配合，AI 既懂规范又能执行。

5. 碎碎念

啦啦啦，终于把这两个概念捋清楚了。说实话，最开始笔者把 Skill 理解成「只读的知识注入、没有副作用」，后来发现这个理解是有偏差的------Skill 里写的是指令，AI 是会照着执行的，能不能产生副作用取决于 AI 有没有对应的工具，而不是 Skill 本身的限制。

另外 token 消耗这个维度也挺值得关注的，MCP 虽然强大，但配多了上下文会很重，该关的 Server 还是要关掉。

搞清楚一个概念，比用错一百次更值钱。
每个人背后都有别人体会不到的辛苦。每个人心里都有旁人无法感受的难处。别人只看结果，自己独撑过程。一个人内心的强大，永远胜过外表的浮华。
别人打我一巴掌，我回他一巴掌，这不叫公平。因为我并没有想打人的念头，却无端受到了伤害，所以要让他感受到比被打的痛苦千倍万倍，这才是公平！

Skill 与 MCP Function：傻傻分不清楚？