---

目录

• 一、前言：继MCP之后，Anthropic又推出了Skill
• 二、快速认识Skill：什么是Skill？
• 三、Skill VS MCP：两者有何区别？
• 四、快速开发Skill的最佳实践：让AI来写Skill
• 五、Skill编写的最佳实践：从设计到执行
• 六、总结

---

一、前言：继MCP之后，Anthropic又推出了Skill

最近在学习Claude相关的技术时，我发现了一个很有意思的现象：继MCP（Model Context Protocol）之后，Anthropic又推出了一项叫做Skill（技能） 的功能。

说实话，第一反应是：不是已经有MCP了吗？为什么还要搞一个Skill？ 这两个东西到底有什么区别？带着这个疑问，我深入阅读了相关文档和文章，读完之后才发现，Skill代表了一种全新的思路——一种更轻量、更灵活的能力扩展方式。

更让我受启发的是，在阅读过程中我意识到：Skill的开发本身就应该让AI来完成，这不仅仅是一个工具，更是一种"元能力"的体现。今天把这些思考整理出来，希望能给同样在探索AI辅助开发的同学一些参考。

---

二、快速认识Skill：什么是Skill？

读完文章后，我对Skill的理解是：Skill就是对AI agent的行为模式和最佳实践的封装。

Skill的基本结构

一个Skill通常放在skills文件夹内，每个技能一个文件夹，核心文件是SKILL.md：

SKILL.md的组成

每个SKILL.md文件包含两部分：

1. YAML头部（元信息）：始终在上下文中，用于Agent判断何时使用该技能
2. Markdown主体：按需加载，描述具体的技能内容

关键设计原则（这是我在阅读后特别认同的一点）：

• 元信息常驻：Agent始终能看到Skill的name、description、tags，用于动态决策
• 主体按需加载：只有触发时才会加载，减少token消耗
• 渐进式披露：像剥洋葱一样一层层提供信息，而不是一次性全部塞给AI

给我印象最深的是文章提到的500行黄金法则：主文件体保持在500行以内，超过则必须拆分。这让我意识到，写Skill不是写得越多越好，而是要思考每个token是否真的必要。

---

三、Skill VS MCP：两者有何区别？

这是我在阅读过程中思考最多的一个问题。现在MCP已经存在了，为什么还需要Skill？

读完文章后，我自己的理解是：Skill和MCP解决的是两个不同层面的问题。

本质区别

简单来说：

• Skill是"方法论"：封装的是经验、流程、最佳实践
• MCP是"工具箱"：提供的是具体的功能和外部连接

对比分析

维度	Skill	MCP
加载方式	渐进式按需加载	启动时全量加载
资源消耗	低token消耗	较高token消耗
复杂度	轻量，Markdown+脚本	需要服务端-客户端架构
适用场景	流程封装、经验沉淀	外部API调用、数据集成

我的理解是：两者是互补关系，而非替代关系。Agent通过Skills获取"怎么做"的知识，通过MCP拓展"能做什么"的能力。

---

四、快速开发Skill的最佳实践：让AI来写Skill

这是我在阅读过程中最大的收获和启发。

传统思路的问题

一开始，我的想法和很多人一样：既然要开发Skill，那就去看看官方示例，照葫芦画瓢自己写一个呗。

但文章指出了一个关键问题：手写Skill既耗时又难以保证质量。我们需要思考文件结构、提示词布局，还要花大量时间打磨，但结果未必理想。

思维转变：默认让AI来做

读完这一部分，我意识到一个思维范式的转变：

核心思想：既然AI是目标用户，那为什么要让人来写Skill？让最顶尖的模型来写，质量可能比我们自己写还要好。

具体实践流程

文章展示了一个很完整的案例（开发"提示词优化专家"Skill），我总结出了一套可复用的流程：

第一步：准备上下文资料

1. 拉取官方Skills仓库（anthropics/skills）
2. 用工具（如Qoder）生成仓库Wiki，快速了解结构
3. 收集领域相关的高质量资料

第二步：明确需求逻辑

比如"提示词优化专家"的逻辑：

1. 用户给出原始提示词
2. 判断是否有歧义/错误
3. 匹配最合适的提示词框架
4. 生成专业提示词

第三步：让AI生成Skill

只需要把需求描述清楚，把准备好的资料给到AI，它就能生成非常专业的Skill。

更巧妙的发现：文章提到官方居然也提供了skill-creator这个技能——用Skill来创建Skill，这简直就是"递归"的最佳实践。

我对这种方式的思考

这种模式给我的启发是：当模型足够强大时，我们的角色正在发生变化。

• 从"执行者"变为"设计者"：我们不需要关心具体怎么写，而是要关心"要做什么"
• 从"手写代码"变为"提供上下文"：把AI干活所需的信息准备充足，比自己去写更重要

---

五、Skill编写的最佳实践：从设计到执行

在阅读文章的后半部分时，我积累了很多关于Skill编写的具体实践心得。

1. 核心设计哲学：Token是公共品

这一点让我印象特别深刻：你的Skill会与系统提示词、对话历史和其他Skill共享上下文窗口。

这意味着：

• 每个token都要接受质问：“这句话真的必要吗？”
• 默认Claude很聪明，不要解释显而易见的概念
• 保持精简，500行是黄金法则

2. 自由度控制（Degrees of Freedom）

这是我从文章中学到的非常有价值的一个概念：根据任务容错率，设定不同的指令严格程度。

这个概念让我意识到，写Skill时要根据任务性质调整指令的严格程度，而不是一刀切。

3. 渐进式披露（Progressive Disclosure）

避免一次性把所有东西塞进上下文，而是像"洋葱"一样一层层剥开。

三种组织模式：

• 概览+引用：SKILL.md只是目录，详情在REFERENCE.md
• 领域隔离：销售看sales/，财务看finance/
• 按需加载：只有用户提到特定功能时才加载对应文档

关键约束：

• 引用层级不要超过1层（否则Claude可能偷懒只读部分）
• 路径永远用正斜杠/，不要用Windows的反斜杠\

4. 命名与元数据规范

Name（名称）：

• 推荐动名词形式：processing-pdfs、analyzing-spreadsheets
• 避免helper、utils这种毫无意义的名字

Description（描述）：

• 至关重要：这是Claude在100+个Skill中决定是否调用你的唯一依据
• 第三人称写法：不要用"I can…“，直接写"Processes Excel files…”
• 包含触发词：明确写Skill做什么以及何时使用

5. 迭代开发：用Claude训练Claude

文章提到的这个开发循环非常有趣：

多模型测试：必须在Haiku（测试引导是否足够）、Sonnet（测试效率）、Opus（测试是否啰嗦）上都跑通。

6. 可执行Skills：代码 > 纯文本

对于复杂任务，脚本比纯文本指令更可靠。文章提到的Plan-Validate-Execute模式很实用：

1. 分析需求
2. 生成计划文件（changes.json）
3. 运行脚本验证计划
4. 执行并确认

---

六、总结

读完这篇文章，我对Claude Agent Skills有了更深入的理解：

1. Skill vs MCP：Skill封装"怎么做"的经验，MCP提供"有什么"的工具，两者互补
2. 开发思维转变：让AI来写Skill，而不是自己手写——这是"元能力"的体现
3. Token优化意识：每个token都是公共品，要精简、要渐进式披露
4. 自由度控制：根据任务风险设定不同严格程度
5. 迭代开发：用Claude训练Claude，形成开发闭环

这套方案给我的最大启发是：当模型足够强大时，我们的工作方式会发生根本性变化。我们不再需要关心"怎么写"，而是要关注"要做什么"以及"如何给AI提供充足的上下文"。

如果你的项目也正在探索AI Agent的能力扩展，希望这篇文章能给你一些参考。记住：Skill的价值不在于写得多复杂，而在于设计得多精准。

---

参考来源： https://mp.weixin.qq.com/s/5hFHlItI3XQUWekejC_kiw