2026 效率分水岭：从"会提问"到"会写技能"，Rules、Skills、MCP 三剑客重塑 AI 协作核心概念什么

核心概念

什么是 Agent Skills？

Agent Skills 是由 Anthropic 开发并作为开放标准发布的智能体能力扩展工具，其本质是将专业知识和工作流封装为可复用的能力单元。

与传统提示词工程不同，Agent Skills 采用"文件夹+SKILL.md"的结构化设计，使模型能够按需加载不同层级的技能信息。

Agent Skills 的三大核心价值

知识外置化：将领域知识从模型权重中解耦，变成可编辑、可版本控制的文件
上下文高效化：通过渐进式披露，在有限窗口中最大化有效信息密度
能力生态化：通过开放标准，实现跨平台的知识共享与复用

渐进式披露机制

Agent Skills 最核心的创新是**渐进式披露（Progressive Disclosure）**机制。该机制将技能信息分为三个层次，智能体按需逐步加载：

（1）元数据层（Metadata）

在 Skills 的设计中，每个技能都存放在一个独立的文件夹中，核心是一个名为 SKILL.md 的 Markdown 文件。这个文件必须以 YAML 格式的 Frontmatter 开头，定义技能的基本信息：

---
name: pdf-processing
description: Extract text and tables from PDF files... Use when working with PDF files...
---

当智能体启动时，它会扫描所有已安装的技能文件夹，仅读取每个 SKILL.md 的 Frontmatter 部分，将这些元数据加载到系统提示词中。根据实测数据，每个技能的元数据仅消耗约 100 个 token。

（2）指令层（Instructions）

当智能体通过分析用户请求，判断某个技能与当前任务高度相关时，它会进入第二层加载。此时，智能体会读取该技能的完整 SKILL.md 文件内容，将详细的指令、注意事项、示例等加载到上下文中。这部分内容的 token 消耗取决于指令的复杂度，通常在 1,000 到 5,000 个 token 之间。

（3）资源层（Scripts & References）

对于更复杂的技能，SKILL.md 可以引用同一文件夹下的其他文件：脚本、配置文件、参考文档等。智能体仅在需要时才加载这些资源。

层级	内容	加载策略	Token消耗	技术价值
元数据层	YAML Frontmatter的name和description字段	Always-On常驻加载	极低(<1%)	模型路由决策与意图识别
指令层	SKILL.md正文的规则和步骤	On-Demand按需加载	中等(5-10%)	定义业务处理逻辑与SOP
资源层	外部文档、手册、脚本等	Context-Triggered条件触发	高但可变	按需加载专业知识，用完即弃

Rules、Skills、MCP 三者的关系

1. Rules（规则）的定位

Rules 是项目级别的静态规范，定义了代码风格、架构模式、开发流程等通用规则。

特点：

Always-On（常驻）：始终加载在系统提示词中
项目特定：针对特定项目的编码规范和最佳实践
静态知识：不随任务变化，是项目的基础约束

典型用途：

代码风格规范（ESLint、TypeScript 规范）
项目架构模式（组件结构、文件组织）
技术栈使用规范（UnoCSS 优先、组件库使用）
命名规范和注释规范

示例（Cursor Rules）：

# 项目开发规范

## 编码规范
- 使用 TypeScript，严格类型检查
- 优先使用 UnoCSS 原子类
- 组件逻辑抽离到 useXxx.ts hooks 文件

2. Skills（技能）的定位

Skills 是任务级别的动态能力，提供特定领域的专业知识和工作流程。

特点：

On-Demand（按需）：仅在相关任务时加载
领域特定：针对特定任务或领域的专业知识
可复用：跨项目、跨平台复用

典型用途：

设计稿转代码（Figma → uni-app）
API 集成指南
数据分析工作流
文档处理流程

示例（Design Conversion Skill）：

---
name: design-conversion
description: Figma 设计稿转换为 uni-app 代码的技能，包含图片资源下载、UnoCSS 原子类使用、rpx 单位转换等完整规范
---

3. MCP（Model Context Protocol）的定位

MCP 是工具级别的连接协议，提供标准化的外部工具和数据访问接口。

特点：

工具接口：定义如何访问外部工具和数据
标准化：统一的协议规范
运行时：动态调用外部服务

典型用途：

文件系统操作
数据库查询
API 调用
外部服务集成（Figma、GitHub 等）

三者关系详解

关系类比

用一个完整的软件开发流程来理解：

Rules = 公司编码规范手册
- 定义"怎么写代码"的通用规则
- 所有项目都要遵循
- 例如：使用 TypeScript、优先使用 UnoCSS
Skills = 特定任务的操作手册
- 定义"如何完成特定任务"的专业知识
- 按需加载，针对特定场景
- 例如：如何将 Figma 设计稿转换为代码
MCP = 工具和服务的驱动程序
- 定义"如何连接和使用工具"
- 提供标准化的接口
- 例如：如何访问 Figma API、如何操作文件系统

协作流程示例

假设用户请求："帮我把这个 Figma 设计稿转换成代码"

1. Rules 提供基础约束
   └─> "使用 UnoCSS 原子类，不要自定义 CSS"
   └─> "使用 TypeScript，严格类型检查"
   └─> "组件逻辑抽离到 hooks 文件"

2. Skills 提供专业知识
   └─> 触发 design-conversion skill
   └─> 加载 "如何从 Figma 下载图片"
   └─> 加载 "rpx 单位转换规则"
   └─> 加载 "UnoCSS 使用规范"

3. MCP 提供工具接口
   └─> 使用 Figma MCP 下载图片资源
   └─> 使用文件系统 MCP 保存文件
   └─> 使用代码编辑器 MCP 创建文件

职责分离原则

设计理念：连接性（Connectivity）与能力（Capability）应该分离。

MCP 专注于连接性：提供标准化的访问接口，让智能体能够"够得着"外部世界的数据和工具
Skills 专注于能力：提供领域专业知识，告诉智能体在特定场景下"如何组合使用这些工具"
Rules 专注于约束：提供项目级别的规范和最佳实践，确保输出符合项目标准

如果说 MCP 为智能体提供了"手"来操作工具，那么 Skills 就提供了"操作手册"或"SOP（标准作业程序）"，Rules 则提供了"公司规范手册"。

对比总结

维度	Rules	Skills	MCP
定位	项目规范	领域知识	工具接口
加载时机	Always-On	On-Demand	Runtime
作用范围	项目级别	任务级别	工具级别
内容性质	静态规范	动态能力	连接协议
Token消耗	中等（常驻）	可变（按需）	低（接口定义）
复用性	项目内	跨项目	跨平台
更新频率	低	中	中

如何写好一个 Skill

核心原则

1. 简洁是关键

上下文窗口是公共资源。 技能与 Claude 需要的所有其他内容共享上下文窗口：系统提示、对话历史、其他技能的元数据以及实际的用户请求。

默认假设：Claude 已经非常智能。 只添加 Claude 尚未具备的上下文。质疑每条信息：

"Claude 真的需要这个解释吗？"
"这段文字值得它的 token 成本吗？"

优先使用简洁的示例而不是冗长的解释。

2. 设置适当的自由度

根据任务的脆弱性和可变性匹配具体程度：

高自由度（基于文本的指令）：当多种方法都有效、决策取决于上下文或启发式方法指导方法时使用
中等自由度（伪代码或带参数的脚本）：当存在首选模式、可接受一些变化或配置影响行为时使用
低自由度（特定脚本，少量参数）：当操作脆弱且容易出错、一致性至关重要或必须遵循特定顺序时使用

将 Claude 想象成在探索一条路径：有悬崖的狭窄桥梁需要特定的护栏（低自由度），而开阔的田野允许多条路线（高自由度）。

3. 渐进式披露设计

保持 SKILL.md 正文精简，不超过 500 行，以最小化上下文膨胀。当接近此限制时，将内容拆分到单独的文件中。

关键原则： 当技能支持多种变体、框架或选项时，仅在 SKILL.md 中保留核心工作流程和选择指导。将特定于变体的详细信息（模式、示例、配置）移至单独的参考文件。

Skill 创建流程

步骤 1：通过具体示例理解技能

要创建有效的技能，需要清楚理解技能将如何使用的具体示例。这种理解可以来自直接的用户示例或经过用户反馈验证的生成示例。

关键问题：

"此技能应该支持哪些功能？"
"您能给一些如何使用此技能的示例吗？"
"用户说什么应该触发此技能？"

步骤 2：规划可重用的技能内容

要将具体示例转化为有效的技能，通过以下方式分析每个示例：

考虑如何从头开始执行示例
确定在重复执行这些工作流程时哪些脚本、参考资料和资产会有帮助

分析维度：

脚本（scripts/）：需要确定性可靠性或重复编写的代码
参考资料（references/）：需要参考的文档、API 规范、数据库模式等
资产（assets/）：模板、图标、字体等输出资源

步骤 3：编写 YAML 前置元数据

这是技能最重要的部分，因为这是 Claude 用来确定何时使用该技能的唯一字段。

---
name: skill-name
description: 清晰全面地描述技能是什么以及何时应该使用它。包括技能做什么以及使用它的特定触发器/上下文。
---

关键要点：

name：技能名称，使用 kebab-case
description：必须包含所有"何时使用"信息——而不是在正文中。正文仅在触发后加载，因此正文中的"何时使用此技能"部分对 Claude 没有帮助
不要在 YAML 前置元数据中包含任何其他字段（除非有特殊需求，如 license）

好的描述示例：

description: 全面的文档创建、编辑和分析，支持修订追踪、批注、格式保留和文本提取。当 Claude 需要处理专业文档（.docx 文件）时使用，用于：(1) 创建新文档，(2) 修改或编辑内容，(3) 处理修订追踪，(4) 添加批注，或任何其他文档任务

步骤 4：编写 SKILL.md 正文

写作指南： 始终使用祈使句/不定式形式。

结构建议：

快速入门：核心工作流程的简洁示例
详细规则：分步骤的详细说明
注意事项：常见错误和陷阱
参考资源：链接到 references/ 中的详细文档

避免：

冗长的解释（优先使用示例）
重复 Rules 中已有的内容
过于详细的实现细节（移到 references/ 中）

步骤 5：组织资源文件

根据步骤 2 的分析，创建必要的资源文件：

scripts/：可执行代码（Python/Bash 等）
references/：参考文档（API 文档、数据库模式、详细指南等）
assets/：输出资源（模板、图标、字体等）

重要原则：

避免重复：信息应仅存在于 SKILL.md 或参考文件中，而不是两者都有
保持 SKILL.md 精简：仅在 SKILL.md 中保留基本的程序性指令和工作流程指导
将详细的参考材料、模式和示例移至参考文件

步骤 6：测试和迭代

在实际任务中使用技能，注意困难或低效之处，确定应如何更新 SKILL.md 或捆绑资源，实施更改并再次测试。

Skill 的通用目录结构

标准目录结构

skill-name/
├── SKILL.md                    # 必需：技能主文件
│   ├── YAML 前置元数据（必需）
│   │   ├── name:（必需）
│   │   └── description:（必需）
│   └── Markdown 说明（必需）
│
└── 捆绑资源（可选）
    ├── scripts/                # 可执行代码
    │   ├── process_data.py
    │   └── generate_report.sh
    │
    ├── references/             # 参考文档
    │   ├── api-docs.md
    │   ├── database-schema.md
    │   └── workflows.md
    │
    └── assets/                 # 输出资源
        ├── templates/
        │   └── report-template.html
        ├── icons/
        │   └── logo.png
        └── fonts/
            └── custom-font.ttf

目录说明

SKILL.md（必需）

每个技能的核心文件，包含：

YAML 前置元数据（必需）

---
name: skill-name
description: 技能描述，包含何时使用此技能的信息
---

Markdown 正文（必需）
- 使用技能的说明和指导
- 仅在技能触发后加载
- 保持精简，不超过 500 行

scripts/（可选）

用于需要确定性可靠性或重复编写的任务的可执行代码。

何时包含：

当相同的代码被重复编写时
当需要确定性可靠性时
当操作复杂且容易出错时

示例：

scripts/rotate_pdf.py - PDF 旋转任务
scripts/process_data.py - 数据处理脚本
scripts/generate_report.sh - 报告生成脚本

优点：

Token 效率高（可以在不加载到上下文的情况下执行）
确定性强（避免 LLM 生成过程中的不确定性）
可复用（跨任务复用）

references/（可选）

用于根据需要加载到上下文中以指导 Claude 过程和思考的文档和参考材料。

何时包含：

用于 Claude 在工作时应参考的文档
当信息量较大（>10k 字）时
当信息是领域特定的详细知识时

示例：

references/api-docs.md - API 规范文档
references/database-schema.md - 数据库模式
references/workflows.md - 详细工作流程指南
references/company-policies.md - 公司政策文档

最佳实践：

如果文件较大（>10k 字），在 SKILL.md 中包含 grep 搜索模式
避免重复：信息应仅存在于 SKILL.md 或参考文件中，而不是两者都有
结构化较长的参考文件：在顶部包含目录，以便 Claude 在预览时可以看到完整范围

assets/（可选）

不打算加载到上下文中，而是在 Claude 产生的输出中使用的文件。

何时包含：

当技能需要将在最终输出中使用的文件时
模板、图像、图标、样板代码等

示例：

assets/logo.png - 品牌资产
assets/slides.pptx - PowerPoint 模板
assets/frontend-template/ - HTML/React 样板
assets/font.ttf - 字体文件

优点：

将输出资源与文档分开
使 Claude 能够使用文件而不将其加载到上下文中

不应包含的内容

技能应仅包含直接支持其功能的必要文件。不要创建多余的文档或辅助文件，包括：

❌ README.md
❌ INSTALLATION_GUIDE.md
❌ QUICK_REFERENCE.md
❌ CHANGELOG.md
❌ 等等

技能应仅包含 AI 代理完成手头工作所需的信息。它不应包含关于创建过程的辅助上下文、设置和测试程序、面向用户的文档等。

渐进式披露模式示例

模式 1：带参考资料的高级指南

# PDF 处理

## 快速入门

使用 pdfplumber 提取文本：
[代码示例]

## 高级功能

- **表单填写**：完整指南请参见 [FORMS.md](references/FORMS.md)
- **API 参考**：所有方法请参见 [REFERENCE.md](references/REFERENCE.md)
- **示例**：常见模式请参见 [EXAMPLES.md](references/EXAMPLES.md)

Claude 仅在需要时加载 FORMS.md、REFERENCE.md 或 EXAMPLES.md。

模式 2：领域特定组织

bigquery-skill/
├── SKILL.md（概述和导航）
└── references/
    ├── finance.md（收入、账单指标）
    ├── sales.md（机会、管道）
    ├── product.md（API 使用、功能）
    └── marketing.md（活动、归因）

当用户询问销售指标时，Claude 只读取 sales.md。

模式 3：条件详情

# DOCX 处理

## 创建文档

使用 docx-js 创建新文档。请参见 [DOCX-JS.md](references/DOCX-JS.md)。

## 编辑文档

对于简单编辑，直接修改 XML。

**对于修订追踪**：请参见 [REDLINING.md](references/REDLINING.md)
**对于 OOXML 详情**：请参见 [OOXML.md](references/OOXML.md)

Claude 仅在用户需要这些功能时读取 REDLINING.md 或 OOXML.md。

重要指南：

避免深层嵌套引用 - 保持引用从 SKILL.md 起一层深度。所有参考文件应直接从 SKILL.md 链接
结构化较长的参考文件 - 对于超过 100 行的文件，在顶部包含目录

最佳实践与设计原则

1. 内容组织原则

保持 SKILL.md 精简

不超过 500 行
优先使用示例而不是冗长的解释
将详细信息移到 references/ 中

避免重复

信息应仅存在于 SKILL.md 或参考文件中，而不是两者都有
仅在 SKILL.md 中保留基本的程序性指令和工作流程指导
将详细的参考材料、模式和示例移至参考文件

使用渐进式披露

元数据层：Always-On（约 100 token）
指令层：On-Demand（1k-5k token）
资源层：Context-Triggered（可变）

2. 写作风格

使用祈使句/不定式形式

# ✅ 好的写法
使用 pdfplumber 提取文本。
优先使用 UnoCSS 原子类。

# ❌ 避免的写法
你应该使用 pdfplumber 提取文本。
我们建议优先使用 UnoCSS 原子类。

3. 资源文件管理

Scripts 最佳实践

必须通过实际运行来测试
确保没有错误并且输出符合预期
如果有许多类似的脚本，只需测试具有代表性的样本

References 最佳实践

如果文件较大（>10k 字），在 SKILL.md 中包含 grep 搜索模式
在顶部包含目录（对于超过 100 行的文件）
避免深层嵌套引用（保持从 SKILL.md 起一层深度）

Assets 最佳实践

仅包含在最终输出中使用的文件
不要将资产加载到上下文中
使用有意义的命名

4. 描述（Description）编写技巧

这是技能最重要的部分，因为这是 Claude 用来确定何时使用该技能的唯一字段。

好的描述应包含：

技能做什么：清晰描述技能的核心功能
何时使用：具体的触发场景和上下文
使用场景：列举主要的使用场景

示例对比

# ❌ 不好的描述（太简短，缺少触发信息）
description: PDF 处理技能

# ✅ 好的描述（包含何时使用信息）
description: 全面的 PDF 文档处理，支持文本提取、表格提取、页面旋转和合并。当 Claude 需要处理 PDF 文件时使用，用于：(1) 提取文本内容，(2) 提取表格数据，(3) 旋转页面，(4) 合并多个 PDF，或任何其他 PDF 操作任务

实战案例

案例 1：设计稿转换 Skill

这是一个实际项目中的 Skill，展示了完整的目录结构和内容组织。

目录结构

design-conversion/
├── SKILL.md
└── references/
    ├── rpx转换速查表.md
    └── 响应式单位使用指南.md

SKILL.md 结构

---
name: design-conversion
description: Figma 设计稿转换为 uni-app 代码的技能，包含图片资源下载、UnoCSS 原子类使用、rpx 单位转换等完整规范
tags:
  - figma
  - design-to-code
  - uniapp
  - unocss
  - rpx
---

正文结构：

UnoCSS 优先使用规则（第一优先级）
图片资源下载规则
布局尺寸精确还原
颜色值精确匹配
文字样式完整复制
...（其他规则）
转换流程检查清单
相关文档链接

设计亮点

渐进式披露：
- 元数据：技能名称和描述（Always-On）
- 指令层：核心转换规则（On-Demand）
- 资源层：详细的转换速查表和指南（Context-Triggered）
避免重复：
- SKILL.md 中包含核心规则和检查清单
- 详细的转换表和指南放在 references/ 中
清晰的触发条件：
- Description 中明确说明："Figma 设计稿转换为 uni-app 代码"
- 包含具体的使用场景

案例 2：技能创建器 Skill

这是一个元技能（meta-skill），用于创建其他技能。

目录结构

skill-creator/
├── SKILL.md
├── LICENSE.txt
├── scripts/
│   ├── init_skill.py
│   ├── package_skill.py
│   └── quick_validate.py
└── references/
    ├── output-patterns.md
    └── workflows.md

设计亮点

包含脚本：
- init_skill.py：初始化新技能
- package_skill.py：打包技能
- quick_validate.py：快速验证
参考文档：
- output-patterns.md：输出格式模式
- workflows.md：工作流程指南
渐进式披露：
- 核心创建流程在 SKILL.md 中
- 详细的工作流程和输出模式在 references/ 中

总结

关键要点

Rules、Skills、MCP 三者职责分离：
- Rules：项目级别的静态规范
- Skills：任务级别的动态能力
- MCP：工具级别的连接协议
写好 Skill 的核心原则：
- 简洁是关键（质疑每条信息的必要性）
- 设置适当的自由度（根据任务脆弱性）
- 渐进式披露（三级加载系统）
标准目录结构：
- SKILL.md（必需）：元数据 + 核心指令
- scripts/（可选）：可执行代码
- references/（可选）：参考文档
- assets/（可选）：输出资源
最佳实践：
- 保持 SKILL.md 精简（不超过 500 行）
- 避免重复（信息只存在一处）
- 使用渐进式披露（按需加载）
- 优先使用示例而不是冗长解释