前言

近期Skills概念出现，同样由Anthropic（Claude）提出。首先要搞清楚的是：MCP和Skills的区别和联系是什么？

MCP和Skills的关系

一、两者的区别

MCP（Model Context Protocol）本质是一种模型与外部系统交互的协议标准。Skills是被封装成可直接调用能力单元的工具能力。

二、两者的联系

MCP是底层连接机制，Skill是上层能力产品化。未来趋势非常明确：MCP逐渐隐藏，Skills成为主角。这不是一种完全取代的关系。

简单说：Skills让大模型做得更好，MCP让Claude做得更多。两者可以结合使用。比如用MCP拿到Google Drive的文件，再用docx Skill的最佳实践来处理它。

模型
   ↓
MCP（协议层）
   ↓
Tool / API
   ↓
Skill（能力封装）
   ↓
用户调用

架构层级说明：

• LLM/Model Host：运行模型、决定调用Skill的主体（本地模型或云模型）

• MCP Adapter/Proxy：协议适配、消息规范、输入输出验证、限流与审计

• Orchestration Layer（Agent Manager）：调度Skill、执行工作流、管理状态机与回滚

• Skill Registry（能力市场）：Skill的元数据、权限、版本、用量计费与发现

• Backend Services：真实执行单元（数据库、第三方API、脚本、容器化服务等）

不同厂商会在MCP与Orchestration的边界上有不同的实现侧重点。

Skills构建方式

从构建方式主要分两类：

1. 源码方式（开发者模式）

2. 界面方式（低代码或可视化方式）

Claude虽然最先提出Skill的概念，但大部分人使用Claude有门槛。现在其他大模型平台逐渐支持Skill能力：

Claude Skills最佳实践总结

基于《The Complete Guide to Building Skills for Claude》整理。

一、核心架构设计

三层渐进式披露（Progressive Disclosure）。这是整个Skills系统最关键的设计哲学：

设计目的：最小化token消耗，同时保持专业能力。

二、文件结构规范

your-skill-name/          ← kebab-case命名，不能有空格/大写/下划线
├── SKILL.md              ← 必须，大小写精确匹配
├── scripts/              ← 可选，Python/Bash等脚本
├── references/           ← 可选，详细文档
└── assets/               ← 可选，模板/字体/图标

错误写法：skill.md或SKILL.MD
正确写法：SKILL.md

错误写法：Notion Project Setup
正确写法：notion-project-setup

注意：skill名称中不能包含"claude"或"anthropic"，这些是保留字。

三、YAML Frontmatter黄金写法

Description公式：[做什么] + [何时使用] + [关键触发短语]

---
name: your-skill-name
description: >
  做什么的简洁说明。Use when user mentions "具体词A"、
  "具体词B"，or asks to "执行某操作"。
license: MIT
metadata:
  author: YourName
  version: 1.0.0
  mcp-server: your-server
---

描述对比：

核心原则：必须同时包含WHAT（做什么）和WHEN（触发条件或用户实际会说的词语），上限1024字符。

四、五种核心工作流模式

Pattern 1：顺序工作流编排

适用场景：有严格步骤顺序的多步任务

Step 1 → 验证 → Step 2 → 验证 → Step 3 → 回滚机制

关键技巧：每步之间声明依赖关系，每步验证通过后再继续，提供失败回滚指令。

Pattern 2：多MCP协调

适用场景：工作流跨越多个服务（如Figma → Drive → Linear → Slack）

Phase 1: Figma MCP → 导出设计资产
Phase 2: Drive MCP → 存储并生成链接
Phase 3: Linear MCP → 创建开发任务
Phase 4: Slack MCP → 发送交接通知

关键技巧：明确的阶段分隔，跨MCP的数据传递方式说明，集中错误处理逻辑。

Pattern 3：迭代精炼

适用场景：输出质量需要多轮迭代提升（如报告生成）

初稿生成 → 验证脚本检查 → 发现问题列表 → 修正 → 再验证 → 达到质量阈值后终止

关键技巧：明确的质量判断标准，使用脚本做验证（确定性更高），设置迭代终止条件避免无限循环。

Pattern 4：上下文感知工具选择

适用场景：同一目标，根据上下文选择不同工具

判断文件类型/大小
    ├── >10MB          → 云存储MCP
    ├── 协作文档       → Notion/Docs MCP
    ├── 代码文件       → GitHub MCP
    └── 临时文件       → 本地存储
→ 向用户解释选择原因

关键技巧：清晰的决策树，提供备用方案，对用户透明地说明选择逻辑。

Pattern 5：领域专业智能

适用场景：嵌入特定领域知识（合规、法律、金融等）

获取数据 → [合规前置检查] → 通过则执行 / 不通过则标记审核 → 生成审计日志

关键技巧：执行前先做合规或风险检查，完整记录审计日志，清晰的治理和审批流程。

五、测试的三个维度

1. 触发测试（最重要）

• 应触发：直接表述、同义改写、不同措辞，各测一遍

• 不应触发：无关领域话题（天气、其他完全不同的任务）

调试技巧：直接问Claude「你什么时候会用[skill名称]？」，它会将description复述出来，你就能看出哪里写得不够精准。

2. 功能测试

• 输出格式和内容是否正确

• API或MCP调用是否成功

• 边缘情况和异常是否有处理

3. 性能对比（有Skill和无Skill）

六、常见问题速查

七、最佳实践精华

设计阶段

• 先定义2-3个具体用例，再动笔写SKILL.md

• 区分「问题优先」和「工具优先」视角，选择合适的Pattern

• 用结果而非功能描述skill价值

编写阶段

• Description = 用户说的话，而不是技术描述

• 关键指令置顶，次要细节放references/

• 为每种常见错误写明：原因 + 解决步骤

• 确定性要求高的验证逻辑，用脚本而非语言描述（代码是确定性的，语言不是）

迭代阶段

• 先把一个复杂任务做到完美，再扩展覆盖更多场景

• 善用skill-creator skill生成初稿和评审

• Skill是活文档，根据触发过多或过少的信号持续迭代

分发阶段

• GitHub开源 + MCP文档交叉链接

• 对外描述用价值语言：「节省30分钟手动配置」，而不是「包含YAML frontmatter」

八、快速验证清单

开发前

• 已识别2-3个具体用例

• 已确定所需工具（内置或MCP）

• 已规划文件夹结构

开发中

• 文件夹名为kebab-case

• 文件名精确为SKILL.md

• YAML有---开闭分隔符

• name字段：kebab-case，无空格，无大写

• description包含WHAT和WHEN

• 无XML标签< >

• 指令清晰可操作，包含错误处理和示例

• 详细文档放在references/而非内联

上传前

• 测试：明显相关任务可触发

• 测试：改写措辞后仍可触发

• 测试：无关话题不触发

• MCP工具调用正常（如适用）

上传后

• 在真实对话中测试

• 监控触发过多或过少

• 收集用户反馈

• 根据反馈迭代description和instructions

一句话核心

Skill的本质是把你的领域经验和工作流程，结构化地教给Claude一次，之后每次都自动复用。写好description让它能自动触发，写好instructions让它每次都能稳定执行，这是成功的两大关键。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13680