最近 Anthropic 推出了 Claude Skills 功能，官方宣传说它能让 AI 具备"专业技能"，让 Claude 从通用助手变成领域专家。听起来很美好，但这个功能到底解决了什么真实问题？它和我们直接写个 prompt 文件有什么本质区别？

一、Skills 到底是什么？

说白了，Skills 就是一个标准化的文件夹结构，里面包含：

skill-name/
├── SKILL.md          # 核心说明文件（必需）
├── scripts/          # 可执行脚本（可选）
├── templates/        # 模板文件（可选）
└── reference.md      # 参考资料（可选）

SKILL.md 文件开头必须有这样的元数据：

---
name: PDF Processing
description: 处理 PDF 文件，包括提取文本、填写表单等
---

然后下面是具体的指令、使用说明、示例等内容。

听到这里你可能会想：这不就是把 prompt 写到文件里吗？

对，但也不完全对。

二、Skills 的核心机制：渐进式披露

Skills 最关键的设计是渐进式披露（Progressive Disclosure）。这个概念听起来很学术，但其实很好理解。

想象你去图书馆找一本书。你不会一开始就把整个图书馆的所有书都搬到你面前，而是：

1. 先看目录索引，找到相关的分类
2. 走到那个书架，浏览书名
3. 拿起感兴趣的书，翻到具体章节
4. 如果需要更多信息，再去查参考文献

Skills 就是这样工作的，分三个层级：

启动时（Level 1）：Claude 只看到所有 Skills 的名字和简短描述，就像图书馆的目录索引。比如"PDF Processing - 处理 PDF 文件"，大概 100 tokens。

任务匹配时（Level 2）：当用户说"帮我提取这个 PDF 的文本"，Claude 判断需要 PDF 技能，就去读 SKILL.md 的正文，了解具体能做什么、怎么做。这部分通常 1000-5000 tokens。

需要细节时（Level 3）：如果 SKILL.md 里提到"详细的表单填写步骤见 forms.md"，Claude 会继续读那个文件。如果需要运行脚本，就直接调用 scripts/ 里的代码，脚本内容不占用上下文窗口。

这个设计的巧妙之处在于：把文件系统当作上下文窗口的延伸。Claude 不是一次性把所有知识塞进脑子里，而是知道"哪里有什么知识"，需要的时候再去拿。

三、和直接写 Prompt 文件有什么区别？

这是最关键的问题。我们来对比一下：

传统 Prompt 文件的问题

假设你有一个 pdf_processing_prompt.md，里面写了 3500 字，包括文本提取、表单填写、文件合并等各种操作的详细说明。

每次对话，你都要把这 3500 字全部塞进上下文。即使用户只是问"怎么提取文本"，表单填写、文件合并的内容也要跟着加载。更麻烦的是，多个 prompt 文件之间无法互相引用，更新维护也很头疼。

Skills 的工作方式

同样的内容，用 Skills 组织：

pdf-skill/
├── SKILL.md              # 核心说明（500 字）
├── extraction.md         # 文本提取专项（800 字）
├── forms.md              # 表单处理专项（1200 字）
├── merging.md            # 合并拆分专项（600 字）
└── scripts/
    └── extract_fields.py # 字段提取脚本

用户问"帮我提取这个 PDF 的文本"时，Claude 的处理流程是：

1. 看到 PDF Processing 这个 Skill 的描述，判断相关
2. 读取 SKILL.md（500 字），了解大致能做什么
3. 发现需要详细步骤，读取 extraction.md（800 字）
4. 如果需要运行脚本，直接调用 extract_fields.py（不占上下文）

整个过程只加载了 1300 字左右，而不是 3500 字。关键是，这个加载是 Claude 自己决定的，不需要你手动指定。

四、Skills 真正解决的三个问题

我认为 Skills 主要解决了三个问题。

1. 上下文窗口的经济性

你是一家公司的技术负责人，需要让 Claude 遵循公司的代码规范（3000 字）、API 设计标准（2000 字）、安全审查清单（1500 字）、测试流程说明（1000 字）。

传统方式，每次对话都要加载 7500 字，大约 2500 tokens。如果你一天要用 100 次，那就是 25 万 tokens 的输入成本。

用 Skills，启动时只加载 4 个技能的元数据（400 tokens），实际使用时按需加载相关部分，可能只需 1000-1500 tokens。这能节省 40%-60% 的成本。对于高频使用的场景，这个节省是很可观的。

2. 知识的可复用性

数据分析团队和产品团队都需要处理 Excel 数据。传统方式下，两个团队各自写了一份 prompt，内容大同小异，但要各自维护。如果 Excel 处理的最佳实践更新了，两边都要改。

用 Skills，创建一个 excel-processing Skill，两个团队共享使用。更新一次，全员受益。这不仅节省了重复劳动，还确保了知识的一致性。

3. 复杂任务的可靠性

需要处理一个 200 页的 PDF 表单，提取 50 个字段。传统方式是让 Claude 生成代码，但每次生成的代码可能不一样，可能有各种边界情况的 bug。

用 Skills，你可以在 Skill 中放一个预先测试好的 extract_fields.py 脚本。Claude 直接调用这个脚本，而不是每次都重新生成代码。这是确定性操作 + AI 灵活性的结合，既保证了可靠性，又保留了 AI 的智能判断能力。

五、Skills 的局限性

说完优点，我们也要看到局限。

虽然官方说"只需要 Markdown"，但实际上你需要理解渐进式披露的概念，需要合理组织文件结构，需要写好元数据和引用关系。对普通用户来说，还是有一定门槛的。

而且 Skills 更适合结构化、可重复的任务，比如文档处理、代码审查、合规检查。对于一次性的创意任务、高度灵活的探索性工作、简单的日常对话，Skills 反而是过度设计。

目前官方提供的 Skills 数量也很有限，主要是文档处理类。第三方 Skills 市场刚刚起步，质量参差不齐。更麻烦的是，Claude.ai、API、Claude Code 之间的 Skills 不互通，你得在各个平台分别管理。

六、和 MCP 的关系

很多人会把 Skills 和 MCP（Model Context Protocol）搞混。简单说，MCP 解决的是"数据访问"问题，比如连接数据库、调用 API，就像给 AI 装"传感器"。Skills 解决的是"知识处理"问题，比如定义工作流程、封装专业知识，就像给 AI 写"操作手册"。

它们是互补关系。一个完整的企业 AI 应用可能同时需要两者：用 MCP 获取 Salesforce 的数据，用 Skills 按公司标准生成销售报告。

七、如果你已经在用文件系统维护 Prompt，Skills 还有意义吗？

这是一个非常尖锐的问题。如果你已经建立了自己的 prompt 文件管理体系，Skills 的革新性确实要打个问号。

假设你已经这样组织 prompt：

my-prompts/
├── coding/
│   ├── python-style-guide.md
│   ├── code-review-checklist.md
│   └── api-design-patterns.md
├── writing/
│   ├── blog-writing-guide.md
│   └── technical-documentation.md
└── tools/
    └── pdf-processing-guide.md

每次使用时，你手动把相关文件内容复制到对话框，或者通过 API 读取文件内容拼接到 prompt 中。

这和 Skills 有什么本质区别？

第一个区别是谁来决定加载什么。你的方案需要人工判断当前任务需要哪些文件，手动复制粘贴或编写代码读取，可能加载过多或遗漏关键信息。Skills 让 Claude 根据任务描述自动匹配相关 Skills，自动决定需要加载哪些文件，动态调整加载深度。Skills 把"加载决策"交给了 AI，减少了人工干预。

第二个区别是加载的颗粒度。你的方案是文件级加载，要么加载整个文件，要么不加载，即使只需要其中一小部分，也要全部加载。Skills 是渐进式加载：先看元数据（100 tokens），再加载主文件（1000 tokens），最后按需加载引用文件（2000 tokens）。这种更细粒度的按需加载，在处理复杂知识时效率更高。

第三个区别是代码执行的位置。在你的 prompt 文件里，如果有 200 行 Python 代码，这 200 行会占用你的上下文窗口。Skills 把代码放在 scripts/ 文件夹里，Claude 直接执行，不占用上下文。Skills 把代码从"知识"变成了"工具"。

Skills 的真正创新是什么？

经过深入思考，我认为 Skills 的创新点不在于"文件系统管理 prompt"（这个想法很多人都有），而在于三个方面。

第一，把文件系统变成了 AI 的"工作记忆"。

在上下文工程（Context Engineering）中，上下文不仅仅是 prompt，而是模型生成回答之前所看到的一切信息，包括系统提示词、用户输入、对话历史、工具返回的信息，以及从外部存储中检索的知识。

Skills 的设计让文件系统成为了"外部存储"的标准化方案。Claude 可以主动检索文件系统中的知识，决定什么时候读取哪些文件，控制读取的深度。这比"你手动复制粘贴文件内容"要智能得多。

第二，实现了"上下文预算"的自动管理。

上下文窗口是有限的（即使是 200K tokens 的模型）。如何在有限的预算内放入最相关的信息，是上下文工程的核心挑战。

如果你手动管理文件，你需要估算每个文件的 token 数，计算总共能放多少内容，手动裁剪或压缩内容。Skills 通过渐进式披露自动解决了这个问题：先用 100 tokens 的元数据"试探"是否相关，确认相关后再加载主文件，如果还需要更多，再加载引用文件。这是一个动态的上下文预算管理系统。

第三，把"工具调用"和"知识检索"统一了。

在传统的 AI Agent 架构中，工具（Tool）是可以执行的函数，比如查询数据库、发送邮件；知识（Knowledge）是通过 RAG 检索的文档、通过 prompt 提供的指令。这是两套不同的机制。

Skills 模糊了这两者的边界。Skill 既包含知识（SKILL.md 中的指令），也包含工具（scripts/ 中的可执行脚本），Claude 通过同一个机制（bash 命令）访问它们。这种统一简化了 Agent 的架构设计。

那么，如果你已经有自己的文件系统呢？

短期来看，如果你已经建立了良好的 prompt 管理体系，Skills 的价值确实有限。你可以继续用自己的方式组织文件，通过代码实现按需加载，效果可能和 Skills 差不多。

长期来看，Skills 的价值在于标准化。如果 Skills 成为行业标准，你可以复用社区的 Skills，实现跨平台兼容（理论上，如果其他 AI 也支持 Skills 格式），团队协作也更容易（统一的文件结构和元数据格式）。

这就像 Docker 出现之前，每个公司都有自己的部署脚本，格式五花八门，难以共享和复用。Docker 之后，有了统一的 Dockerfile 格式，可以直接使用别人的镜像，形成了庞大的生态系统。

Skills 试图做同样的事情：标准化 AI 能力的封装和分发。但能否成功，取决于 Anthropic 是否愿意开放这个标准，社区是否愿意贡献高质量的 Skills，以及是否会出现更好的替代方案。

八、Skills 对上下文工程的贡献

现在我们来回答第二个核心问题：Skills 对上下文工程有什么帮助？

先理解一个概念：提示词工程（Prompt Engineering）是设计和优化单次输入给 AI 的文本，比如"你是一个 Python 专家，请帮我写一个函数"。上下文工程（Context Engineering）是为 AI 设计和构建动态上下文的系统工程，包括系统提示词、用户输入、对话历史、从代码库检索的相关代码、可用工具、用户偏好等所有信息。

上下文工程关注的是：什么信息应该进入上下文，什么时候进入上下文，以什么格式进入上下文，如何压缩上下文以节省 tokens。

Skills 如何改进上下文工程？

首先，解决了"上下文污染"问题。

如果你把所有可能用到的知识都塞进上下文，会导致上下文过长（成本高昂），无关信息干扰 AI 的判断，AI 可能被"淹没"在信息海洋中找不到重点。Skills 通过元数据筛选相关 Skills，只加载当前任务需要的知识，保持上下文的"信噪比"。

其次，实现了"上下文分层"。

在复杂的 Agent 系统中，上下文可以分为多个层次：系统提示词永久存在，Skills 元数据在启动时加载，Skills 主文件在任务匹配时加载，Skills 引用文件在需要详细信息时加载，工具执行结果动态生成。

Skills 提供了一个清晰的分层结构，让 AI 可以从粗到细地获取信息，在任何层次停止（如果信息已经足够），避免一次性加载所有内容。

第三，把"静态知识"变成"动态检索"。

传统方案是把所有规则都写在系统提示词里，每次对话都要加载。比如代码审查专家，系统提示词里写了 100 条代码规范、50 条安全检查清单，每次都要加载这 150 条规则。

Skills 方案是在系统提示词里只写"可用 Skills: code-style-guide、security-checklist"，只有在需要时才加载具体规则。这种动态检索大大降低了每次对话的 token 消耗。

第四，天然支持"上下文缓存"优化。

现代 LLM API（如 Claude）支持 Prompt Caching。如果 prompt 的前缀部分相同，可以复用缓存，节省 75% 的成本，减少 80% 的延迟。

Skills 的设计天然支持缓存：Skills 元数据在系统提示词中，前缀固定；Skills 主文件通常不变，可以缓存；只有用户输入和工具结果是动态的。这比"每次手动拼接不同的文件内容"更容易命中缓存。

Skills 在上下文工程中的定位

我们可以把 AI Agent 的上下文来源分为几类：静态知识（固定不变的系统规则、角色定义，对应 System Prompt），结构化知识（按需加载的工作流程、专业知识，对应 Skills），外部数据（实时检索的文档、数据库，对应 RAG / MCP），对话历史（动态累积的多轮对话，对应 Memory System），工具结果（临时生成的执行反馈，对应 Tool Outputs）。

Skills 填补了"静态知识"和"外部数据"之间的空白。它比静态 prompt 更灵活（按需加载），比 RAG 更结构化（明确的工作流程），比 MCP 更关注知识而非数据。

一个完整的例子

假设你要构建一个"代码审查 Agent"。

没有 Skills 的方案，每次都要加载所有内容：代码审查专家的角色定义、完整的代码风格指南（3000 tokens）、完整的安全规则（2000 tokens）、完整的最佳实践（2500 tokens）、用户输入"审查这个 Python 函数"、要审查的代码。总计 7500+ tokens。

使用 Skills 的方案，启动时只加载：代码审查专家的角色定义、三个 Skills 的元数据（各 100 tokens，共 300 tokens）、用户输入"审查这个 Python 函数"、要审查的代码。

然后 Claude 判断这个任务需要 style-guide 和 security 两个 Skills，自动加载 style-guide/SKILL.md（1000 tokens）和 security/SKILL.md（800 tokens）。总计 2100 tokens，节省了 70% 的 tokens。

九、Skills 是不是"过度设计"？

回到最开始的问题：如果你已经用文件系统维护 prompt，Skills 还有多大意义？

我的答案是：取决于你的场景。

如果你只是偶尔用 AI，或者需求简单，Skills 可能是过度设计，直接写 prompt 或手动管理几个文件就够了。

如果你的团队有 3-10 人，需要共享一些 AI 使用规范，Skills 有一定价值，但不是必需。可以先用简单的文件系统 + Git 管理，如果发现维护成本高，再考虑迁移到 Skills。

如果你在构建生产级的 AI Agent 系统，Skills 的价值就体现出来了。标准化的格式便于团队协作，渐进式加载可以显著降低成本，与 MCP 等协议的整合提供了更完整的解决方案。

Skills 的真正竞争对手

Skills 的竞争对手不是"手动管理文件"，而是其他 AI 平台的类似方案（OpenAI 的 GPTs、Anthropic 自己的 Projects 功能、各种 AI Agent 框架），以及更激进的技术方案（Fine-tuning、RAG、专用的 Agent 框架）。

Skills 的优势在于"够用且简单"，但这也是它的劣势——它不够激进，不够"性感"。就像前端开发中的 CSS Modules，简单、直观、易于理解，不需要学习新的范式，但也不是最强大或最灵活的。

十、总结

在上下文工程层面，Skills 实现了上下文的分层加载，把文件系统变成了 AI 的"工作记忆"，提供了动态的上下文预算管理机制，天然支持 Prompt Caching 优化。

在知识管理层面，Skills 标准化了 AI 能力的封装格式，统一了"知识"和"工具"的访问方式，让专业知识可以打包、共享、复用，降低了团队协作的沟通成本。

在工程实践层面，Skills 比 Fine-tuning 更轻量、更灵活，比纯 Prompt Engineering 更系统化，比 RAG 更适合结构化知识，在成本、性能、可维护性之间找到了平衡。

如果你已经用文件系统维护 prompt，Skills 的核心区别在于：加载决策从人工判断变成 AI 自动判断，加载颗粒度从文件级变成渐进式分层，代码从占用 token 的"知识"变成不占 token 的"工具"，缓存优化从难以实现变成天然支持，标准化从个人/团队标准变成行业标准（理论上），生态系统从无法复用他人成果变成可以使用社区 Skills。

简单说，自维护文件系统是你自己管理的知识库，Claude Skills 是 AI 主动管理的知识库。

Skills 有明显价值的场景包括：需要让 AI 遵循复杂的工作流程（超过 2000 字的指令），AI 应用会高频调用（成本优化很重要），需要团队协作（标准化很重要），知识会频繁更新（版本管理很重要），希望复用社区的 Skills（生态价值）。

Skills 价值不大的场景包括：一次性任务或低频使用，指令简单（几百字就能说清楚），只有你一个人用，任务高度灵活每次都不一样。

Skills 让我们重新思考上下文工程。传统思路是"如何写好一个 prompt"，新思路是"如何为 AI 构建一个动态的知识获取系统"。这包括什么知识应该"常驻内存"（system prompt），什么知识应该"按需加载"（Skills），什么知识应该"实时检索"（RAG），如何在有限的上下文窗口中做出最优选择。Skills 提供了一个"按需加载"的参考实现，但这只是上下文工程的一部分。

Skills 是不是革命性的？不是。Skills 是不是有价值的？是的，但要看场景。Skills 会不会成为标准？取决于 Anthropic 是否愿意开放这个格式，其他 AI 平台是否愿意支持，社区是否愿意贡献高质量 Skills，是否会出现更好的替代方案。

我的预测：短期（1-2 年）Skills 会在 Claude 生态内流行，但不会成为通用标准；中期（3-5 年）可能会出现类似的跨平台标准（就像 Docker 统一了容器格式）；长期（5+ 年）可能会被更先进的技术取代（如更智能的 RAG、更便宜的 Fine-tuning）。

但无论如何，Skills 提出的问题比它的答案更重要：如何让 AI 更好地管理和利用外部知识？如何在成本、性能、灵活性之间找到平衡？如何标准化 AI 能力的封装和分发？这些问题会持续推动行业的发展，而 Skills 只是其中一个尝试。

---

这篇文章花了我相当多的时间去调研和思考。我试图超越表面的功能介绍，去理解 Skills 在整个 AI 发展脉络中的位置。如果你已经在维护自己的 prompt 文件系统，不要觉得 Skills 让你的工作"过时"了。相反，你自己的实践可能比 Skills 更适合你的场景。