最近使用 Claude Code、Codex 或其他 AI 编程工具时，你可能会频繁看到一个新概念：

Skill。

有些项目会提供专门的 Skills 目录，有些插件支持安装第三方 Skill，还有一些开发者开始编写 SKILL.md，把代码审查、生成测试、发布检查和文档整理等流程封装成可复用技能。

它看起来有点像提示词，又和 AI Agent、MCP、工具调用存在联系。

于是，很多刚接触 Skill 的用户会产生疑问：

• AI Skill 到底是什么？
• 它和普通提示词有什么区别？
• SKILL.md 文件是做什么的？
• Skill 与 MCP、Function Calling 有什么关系？
• 安装第三方 Skill 是否存在安全风险？
• 普通用户和开发者如何编写自己的第一个 Skill？

本文将从基础概念出发，介绍 AI Agent Skill 的工作方式、文件结构和实际用途，并通过一个简单示例，帮助新手理解如何把重复执行的 AI 工作流程封装成可复用技能。

说明：不同 AI 产品对 Skill 的定义、目录结构和加载方式可能不同。本文介绍的是当前 Agent 工具中较常见的设计思路，实际配置应以对应产品的最新文档为准。

---

一、AI Agent Skill 是什么？

Skill 可以翻译为“技能”。

在 AI Agent 场景中，它通常指一组围绕特定任务组织起来的说明、规则和资源，用于告诉 Agent：

• 这个技能解决什么问题
• 什么时候应该使用它
• 任务应该按照什么步骤执行
• 可以调用哪些脚本或工具
• 输出应该满足什么格式
• 哪些操作需要用户确认
• 出现失败时应该如何处理

例如，一个“代码审查 Skill”可以要求 Agent：

1. 先读取项目开发规范
2. 再检查本次代码变更
3. 重点关注安全、性能和兼容性
4. 按严重程度排列问题
5. 每个问题标注文件和位置
6. 没有发现问题时明确说明

以后再进行代码审查时，用户就不需要重复输入整套要求。

可以把 Skill 简单理解为：

为某类任务准备的一套可复用操作手册。

它不一定包含复杂代码，也不等于一个全新的模型。很多 Skill 的核心只是结构化说明，必要时再配合模板、参考资料和脚本。

---

二、为什么 Skill 最近受到关注？

早期使用 AI 时，任务通常比较简单：

解释这段代码

帮我总结这篇文章

把这封邮件改得更正式

一段临时提示词通常就能完成。

但随着 AI 进入代码开发、内容生产和自动化工作流，任务开始变得更复杂。例如发布一个项目版本，可能需要：

检查工作区状态
  ↓
运行测试
  ↓
检查构建结果
  ↓
整理版本变更
  ↓
更新发布说明
  ↓
等待用户确认
  ↓
执行发布操作

如果每次都由用户重新说明流程，不仅麻烦，也很容易遗漏步骤。

Skill 的价值就是把稳定的工作方法保存下来，使 Agent 能够重复使用。

这反映了 AI 使用方式的一种变化：

临时提问
  ↓
固定提示模板
  ↓
可复用工作流
  ↓
由 Agent 调用的 Skill

当 AI 从“回答问题”逐步转向“参与工作”，如何保存和复用操作流程，自然会成为重要问题。

---

三、Skill 通常由哪些内容组成？

不同产品采用的 Skill 格式可能存在差异，但常见组成包括以下几部分。

1. 技能说明

说明 Skill 的名称、用途和适用场景。

例如：

名称：article-review
用途：检查技术文章中的事实、结构和表达问题
适用场景：文章发布前的质量检查

清晰的说明有助于 Agent 判断什么时候应该加载这个 Skill。

2. 执行步骤

定义任务的处理顺序。

例如：

1. 阅读文章全文
2. 提取事实性陈述
3. 检查是否缺少来源
4. 检查标题与正文是否一致
5. 检查是否存在重复内容
6. 输出修改建议

3. 约束规则

明确 Agent 不能做什么。

不要虚构资料来源
不要直接修改原文
不要把个人判断写成官方结论
不确定的信息必须标记为待核实

4. 输出格式

约束最终结果的结构。

严重问题
一般问题
表达建议
待核实信息
修改后的摘要

5. 参考资料

Skill 可以附带模板、规范、示例或业务文档。

比如代码审查 Skill 可以附带团队编码规范，写作 Skill 可以附带内容风格说明。

6. 脚本和工具

复杂 Skill 还可能包含脚本，用于执行确定性任务，例如：

• 运行测试
• 检查格式
• 分析日志
• 获取 Git 变更
• 转换文件
• 调用内部接口

需要注意：能执行脚本的 Skill 比纯文本 Skill 风险更高，使用前必须检查脚本内容和权限范围。

---

四、SKILL.md 是什么？

SKILL.md 是一种常见的 Skill 说明文件形式。

它通常使用 Markdown 编写，既方便人阅读，也方便 Agent 加载。一个简化的目录可能是：

article-review/
├── SKILL.md
├── references/
│   └── style-guide.md
└── templates/
    └── review-result.md

其中：

• SKILL.md：描述技能用途、流程和规则
• references/：保存参考规范
• templates/：保存输出模板
• scripts/：如果需要，可以存放辅助脚本

SKILL.md 并不是所有 AI 产品都统一强制使用的格式。不同工具可能使用不同的目录、元数据字段或加载规则。

因此，从网上获取 Skill 后，首先应该检查：

• 它为哪个客户端或 Agent 设计
• 应该放在哪个目录
• 是否需要额外依赖
• 是否会调用脚本或外部命令
• 是否支持当前版本的工具

不要看到文件名相同，就默认所有平台都能直接兼容。

---

五、一个简单的 SKILL.md 长什么样？

下面以“技术文章发布前检查”为例，展示一个适合新手理解的简化版本：

---
name: article-review
description: 发布技术文章前，检查事实、结构、表达和引用。
---

# 技术文章检查

## 使用场景

当用户准备发布技术博客、公众号文章或产品教程时使用。

## 执行步骤

1. 阅读标题、摘要和正文。
2. 检查标题是否准确反映正文。
3. 找出涉及版本、价格、发布日期和性能的数据。
4. 检查事实性内容是否有可靠依据。
5. 检查章节是否重复或存在逻辑跳跃。
6. 检查示例代码是否完整、是否存在明显错误。
7. 按指定格式输出检查结果。

## 约束

- 不得虚构官方公告、测试结果或资料来源。
- 不确定的信息标记为“待核实”。
- 不把作者体验写成普遍事实。
- 未经用户允许，不直接重写整篇文章。

## 输出格式

### 必须修改
- 问题
- 原因
- 修改建议

### 建议优化
- 问题
- 修改建议

### 待核实
- 原始表述
- 需要核实的内容

这个 Skill 没有复杂程序，它本质上是一套稳定、清楚且可以反复执行的文章检查流程。

实际使用时，需要根据目标 Agent 的规范调整头部字段、文件路径和加载方式。

---

六、Skill 和普通 Prompt 有什么区别？

Skill 与 Prompt 都会向模型提供指令，但两者的使用方式不同。

Prompt 通常面向当前任务

例如：

请检查这篇文章是否存在事实错误。

这是一条临时指令。任务结束后，下次可能还要重新输入。

Skill 面向一类可以重复执行的任务

Skill 不只包含一句要求，还可能包含：

触发条件
执行步骤
检查标准
参考资料
输出格式
脚本工具
安全边界

可以简单比较：

对比项	Prompt	Skill
主要用途	完成当前一次任务	复用一类任务流程
内容长度	通常较短	可以包含完整规范
是否保存	不一定	通常以文件形式保存
是否带资源	较少	可以附带模板、资料和脚本
是否适合团队共享	一般	更适合版本管理和共享
维护方式	临时修改	可以持续迭代

一个实用判断是：

偶尔执行一次的要求，使用 Prompt；反复执行并且有固定规则的任务，可以整理成 Skill。

---

七、Skill 和工具调用有什么区别？

工具调用解决的是“Agent 能做什么”。

例如，一个 Agent 可能拥有以下工具：

读取文件
搜索代码
运行测试
执行终端命令
访问数据库
获取网页内容

Skill 解决的是“为了完成某类任务，应该如何使用这些能力”。

例如，工具层只告诉 Agent：

你可以运行测试。

代码审查 Skill 则会告诉它：

1. 先读取变更文件
2. 检查项目测试命令
3. 运行与变更相关的测试
4. 测试失败时分析日志
5. 不要为了让测试通过而删除测试
6. 最终报告中记录实际运行的命令

两者的关系可以概括为：

工具：提供能力
Skill：组织能力
Agent：根据目标执行

Skill 本身不一定提供新的底层能力。没有文件读取工具时，仅靠一个 Skill 也无法真正读取本地文件。

---

八、Skill 和 MCP 有什么区别？

MCP 的全称是 Model Context Protocol，主要用于连接外部工具和数据。

通过 MCP，AI 应用可以连接：

• 本地文件
• 数据库
• Git 仓库
• 搜索服务
• 浏览器
• 项目管理系统
• 企业内部 API

Skill 则用于描述某类任务应该如何完成。

例如，一个“生成开发周报”的 Agent 工作流可以是：

Skill：
规定周报需要哪些内容、按什么顺序处理、输出什么格式

MCP：
连接 Git 仓库、Issue 系统和项目文档

模型：
理解变更内容并生成周报

Agent：
组织整个执行过程

可以把它们的职责总结为：

MCP：连接工具与数据
Skill：保存任务方法和流程
模型：负责理解、推理和生成
Agent：决定如何执行任务

两者并不是竞争关系。

一个 Skill 完全可以要求 Agent 调用 MCP 提供的工具。反过来，MCP Server 只提供能力，并不自动知道团队希望按照什么业务流程使用这些能力。

---

九、Skill 与模型有什么关系？

Skill 本身不是模型，也不会直接生成结果。

它需要由大模型读取和执行。

同一个 Skill 交给不同模型，效果可能存在明显差异，原因包括：

• 指令遵循能力不同
• 代码理解能力不同
• 工具调用能力不同
• 上下文长度不同
• 复杂任务规划能力不同
• 对结构化输出的支持不同

例如，一个 Skill 要求 Agent：

先读取规范，再检查代码，最后运行测试；
任何一步失败都要停止，并说明原因。

有些模型能够稳定遵守顺序，有些模型可能跳过规范读取，或者在测试失败后继续执行。

因此，Skill 解决的是任务流程复用问题，模型能力仍然决定执行质量的上限。

---

十、如何在多个模型中测试同一个 Skill？

为了判断一个 Skill 是否可靠，可以使用相同任务对不同模型进行测试。

对于支持自定义 OpenAI 兼容接口的客户端，通常需要配置：

API Key
Base URL
模型名称

如果同时使用多个 Agent、代码编辑器或自动化工具，可以采用统一模型接入方式集中管理这些配置。例如，https://transitai.chat/ 这类模型中转服务，可以作为多模型接入和测试的一种参考。

完整链路可以理解为：

用户任务
  ↓
Agent 加载 Skill
  ↓
Agent 调用工具或 MCP
  ↓
通过统一模型入口调用模型
  ↓
模型生成决策和结果

测试时，可以给不同模型提供相同的：

• Skill 文件
• 项目资料
• 用户任务
• 工具权限
• 输出要求
• 最大执行步骤

然后记录：

指标	检查内容
触发准确性	是否在正确场景加载 Skill
流程遵循	是否按规定顺序执行
工具调用	是否选择了正确工具
格式稳定性	是否符合输出模板
异常处理	失败时是否按要求停止
响应时间	完成任务需要多久
Token 消耗	Skill 和任务共消耗多少 Token
实际成本	完成一次任务的调用费用

使用 transitai.chat 或其他第三方接入服务前，应查看其实际模型列表、接口格式、工具调用支持、计费说明和数据处理规则。

统一入口解决的是模型配置和切换问题，并不能保证 Skill 一定能在所有模型上稳定执行。

---

十一、新手适合从哪些 Skill 开始？

刚开始学习时，不建议直接制作可以部署生产系统或修改数据库的 Skill。

可以先从低风险、结果容易验证的任务开始。

1. 文章检查 Skill

用于检查：

• 标题是否准确
• 结构是否清楚
• 是否存在重复内容
• 数据是否需要来源
• 摘要是否与正文一致

2. 代码解释 Skill

规定固定输出结构：

代码用途
输入与输出
核心流程
外部依赖
潜在风险
修改建议

3. Git 提交信息 Skill

读取代码变更后，生成符合团队规范的提交信息，但不自动提交。

4. 单元测试建议 Skill

分析指定代码并列出测试场景，先生成建议，不直接修改项目。

5. 会议纪要 Skill

从会议记录中提取：

• 讨论主题
• 已确认结论
• 待办事项
• 负责人
• 截止时间
• 尚未确认的问题

6. 学习资料整理 Skill

读取文档后生成摘要、关键词、问题清单和学习计划。

这些任务风险较低，也容易人工检查 Skill 是否按要求执行。

---

十二、如何编写自己的第一个 Skill？

可以按照以下步骤开始。

第一步：选择重复任务

先找一个自己经常让 AI 完成的任务。

例如：

每次发布文章前，我都需要检查标题、事实、结构和摘要。

如果任务只会执行一次，没有必要专门创建 Skill。

第二步：写清使用场景

说明什么情况下应该使用，以及什么情况下不应该使用。

使用场景：
用户准备发布一篇完整技术文章时。

不适用：
仅生成标题、仅翻译一段文字、文章还没有完成时。

第三步：拆分执行步骤

把自己的实际操作过程按顺序写出来。

不要只写：

检查文章质量。

应该进一步拆分成：

1. 检查标题和内容是否一致
2. 检查章节结构
3. 找出事实性陈述
4. 标记缺少来源的数据
5. 检查重复段落
6. 检查摘要

第四步：增加边界

说明 Skill 不能执行哪些操作。

不要虚构数据
不要删除作者观点
不要直接发布文章
不要访问文章之外的文件

第五步：固定输出格式

结构固定后，结果更容易检查和继续处理。

第六步：用真实任务测试

至少使用几种不同情况测试：

• 内容完整的文章
• 缺少来源的文章
• 包含错误版本号的文章
• 结构混乱的文章
• 没有问题的文章

如果 Skill 只在一个示例上表现良好，还不能说明它足够可靠。

---

十三、Skill 应该写得越详细越好吗？

不一定。

Skill 太短，模型可能无法理解流程；Skill 太长，也会带来问题：

• 重要规则被大量文字淹没
• 多条规则互相冲突
• 加载时消耗更多 Token
• 模型更容易忽略靠后的要求
• 后续维护困难
• 不同场景难以复用

一个好的 Skill 应该做到：

用途明确
触发条件清楚
步骤可以执行
规则没有冲突
输出容易检查
必要资料按需加载

如果参考资料很多，可以将它们拆分到独立文件中，由 Agent 在需要时读取，而不是全部写进一个 SKILL.md。

例如：

code-review/
├── SKILL.md
├── references/
│   ├── security-checklist.md
│   ├── style-guide.md
│   └── testing-rules.md
└── templates/
    └── review-report.md

这种方式有助于控制上下文长度，也方便单独更新某一份规范。

---

十四、安装第三方 Skill 有哪些风险？

第三方 Skill 并不只是普通文本模板。

它可能要求 Agent：

• 执行终端命令
• 下载外部程序
• 访问本地文件
• 读取环境变量
• 调用网络接口
• 修改代码或配置
• 创建提交或发布内容

因此，安装 Skill 前需要认真检查。

1. 检查完整文件内容

不要只看 Skill 的名称和简介。

需要检查 SKILL.md、脚本、配置和依赖文件。

2. 检查是否包含危险命令

重点关注：

删除文件
覆盖目录
修改系统配置
上传数据
读取密钥
执行远程脚本

3. 检查权限范围

一个文章检查 Skill 不应该要求访问整个用户目录，更不应该读取 .env、SSH 私钥或浏览器数据。

4. 检查外部网络请求

确认 Skill 是否会把文件内容发送到第三方服务。

5. 在测试目录中运行

第一次使用时，应该在不含敏感数据的测试项目中执行。

6. 高风险操作保留确认

涉及提交、发布、删除、支付和生产环境修改时，必须要求用户明确确认。

使用官方模型接口或 transitai.chat 等第三方模型入口时，也要注意 Skill 读取的上下文可能会被发送给模型服务。因此，模型接入层的数据规则和 Skill 的本地权限同样需要检查。

---

十五、如何让 Skill 更容易维护？

Skill 不应该写完后就不再修改。

随着项目和工具变化，旧 Skill 可能逐渐失效。

可以采用以下维护方式。

1. 使用 Git 管理

将 Skill 作为普通项目文件进行版本管理，记录每次修改。

2. 增加适用范围

说明 Skill 适用于哪些工具、版本和项目。

3. 保持规则单一

一个 Skill 最好聚焦一个明确任务。

不要把代码审查、自动修复、发布和通知全部塞进一个 Skill。

4. 记录测试案例

保存几个典型输入和预期结果，修改后重新测试。

5. 定期清理过期规则

团队规范、命令和目录结构变化后，应同步更新 Skill。

6. 为危险操作增加确认

不要因为某个流程使用频率高，就取消必要的人工确认。

---

十六、Skill、MCP、Agent 和模型如何配合？

可以用一个“代码审查助手”理解完整架构。

用户：
检查当前分支的代码变更

Agent 接到任务后：

1. 加载代码审查 Skill
2. 根据 Skill 读取项目规范
3. 通过文件工具或 MCP 获取代码变更
4. 调用模型分析代码
5. 通过工具运行相关测试
6. 根据 Skill 整理审查报告
7. 等待用户决定是否修改

其中各部分的职责是：

Skill：规定代码审查方法
MCP 或工具：获取代码和执行测试
模型：理解代码并分析问题
Agent：组织任务和执行步骤
模型入口：完成底层模型调用

如果需要根据任务切换模型，还可以加入模型路由：

简单格式检查 → 轻量模型
普通代码审查 → 均衡模型
复杂架构分析 → 推理模型

transitai.chat 这类兼容接口服务可以位于模型接入层，用于集中配置不同模型。它不负责定义 Skill，也不会替代 MCP 或 Agent 的执行逻辑。

理解这些组件的分工，可以避免把所有 AI 功能都混在一起。

---

十七、关于 Skill 的几个常见误区

误区一：Skill 是一种新的大模型

不是。Skill 通常是供模型和 Agent 使用的任务说明与资源集合。

误区二：安装 Skill 就能获得新的底层能力

不一定。如果 Agent 没有文件、网络或终端工具，Skill 不能凭空获得这些能力。

误区三：Skill 就是一段更长的 Prompt

不完全是。Skill 可以包含触发条件、流程、参考资料、模板和脚本，并且能够被保存、共享和维护。

误区四：网上热门的 Skill 可以直接运行

不建议。第三方 Skill 可能包含危险命令或过大的权限要求。

误区五：Skill 写得越长越专业

不一定。规则清楚、职责单一、结果可验证，比单纯增加篇幅更重要。

误区六：同一个 Skill 在所有模型上效果相同

不同模型的指令遵循、工具调用和推理能力不同，需要实际测试。

---

AI Agent Skill 的价值，不是创造一个新的技术名词，而是把反复执行的工作方法保存下来。

以前，我们每次都要重新告诉 AI：

先做什么
再做什么
需要检查什么
不能做什么
最后输出什么

有了 Skill，这些要求可以被整理成一套可复用、可维护、可共享的任务规范。

它和其他 AI 组件的关系可以概括为：

Prompt：描述当前任务
Skill：保存可复用的任务方法
MCP：连接外部工具和数据
模型：理解、推理与生成
Agent：组织并执行完整流程

对于普通用户来说，可以先从文章检查、会议纪要和资料整理等低风险 Skill 开始。

对于开发者来说，可以逐步把代码审查、测试建议、故障排查和版本发布检查等重复流程整理成项目级 Skill。

如果需要在不同模型中测试 Skill 的执行效果，可以通过官方接口，或使用 https://transitai.chat/ 这类兼容 OpenAI 接口的统一入口配置 API Key、Base URL 和模型名称。使用前应确认模型支持情况、工具调用兼容性、费用和数据处理规则。

Skill 让 AI 从“每次都要重新教”，逐渐走向“能够复用已经定义好的工作方法”。

但无论 Skill 写得多完整，涉及删除数据、执行命令、发布内容和生产环境变更时，都应该保留人工确认。

真正可靠的 Skill，不只是能够让 Agent完成任务，还应该明确权限、失败条件和停止边界。