Skill：让能力成为可组合的单元

o0恋静0o
1 阅读12分钟

本系列文章将从提示词工程出发，逐步讨论人类如何提升对大模型行为的控制能力：从优化提问方式，到设计输入环境，再到连接外部能力，最终形成可复用的能力单元。

换句话说，我们关注的不只是“如何让模型回答更好”，而是“如何让模型稳定地完成工作”。

当模型可以通过接口调用能力后，下一个问题是：这些能力如何被组织与复用？

如果每个任务都重新设计一套调用逻辑，系统将难以维护。于是，我们需要将能力封装为可组合的单元。

本篇是系列最后一篇，将讨论 Skill 的概念：如何把能力变成可以持续积累与复用的模块，使模型从一次次完成任务，走向具备长期工作的能力。

Skill 在解决什么问题

前一篇文章我们介绍了 MCP，不过现在又出现了一个新的概念：Skill

你如果看一些自媒体或者公众号文章，它们会说这是给大模型装上了手脚，让大模型能够实际做事情。但同时你一定也会有这样的一个疑问：给模型装上手脚，让模型实际做事情这件事儿，MCP 不是已经搞定了么？那么为什么又搞出一个 Skill 呢？

实际上，Skill 和 MCP 两者之间不是竞争关系，而是相辅相成的关系，Skill 本质上就是在 MCP 的基础上做了一层流程的封装。

举个例子，以前只有 MCP 的时候，模型面对的是：

  • get_weather
  • query_db
  • send_email
  • create_order
  • ...

几十甚至上百个工具，此时存在的问题就是：

  • 粒度太细
  • 顺序不确定
  • 组合随机

你让大模型做同样的一件事情，第一次可能调用了 A 工具，第二次可能调用的是 B 工具，并且每一个步骤都像是在开盲盒，是不确定的。

有了 Skill 之后，相当于是对做一件事情的具体流程做了一层封装。比如：

  • weather_assistant
  • order_assistant
  • report_generator
  • customer_service_flow

这里的每一个 Skill，都包含了做一件事情的完整流程，比如 weather_assistant，只要模型选择了要使用这个 Skill，那么：

  1. 第一步做什么，要调用哪个工具
  2. 第二步做什么，要如何处理结果
  3. 第三步做什么，要如何生成最终输出

这些流程，其实已经提前被设计好了。模型不再需要每一次都去“临时思考”：

  • 要不要调用工具？
  • 调用哪个工具？
  • 调用顺序是什么？

而是只需要做一件事情：选择当前最合适的 Skill

你可以这样理解：

  • 在只有 MCP 的时候，模型面对的是“零散的工具集合”，需要自己去拼装流程；
  • 而有了 Skill 之后，我们帮模型把这些工具提前组织成了“可复用的能力单元”。

当然，看到这里，你一定会有这样一个疑问：即便有了 Skill，不也面临需要选择使用哪一个 Skill 么？

没错，你有这个疑问是很正常的。

因为“选择”这件事情本身是无法被消除的，只要系统中存在多个能力，大模型就一定需要做决策。哪怕再向上封装一层，甚至十层，这个问题依然会存在。

但关键在于：Skill 并不是在消除“选择”，而是在降低“选择的复杂度”。

在只有 MCP 的时候，模型需要同时解决三件事情：

  • 是否需要调用工具？
  • 调用哪一个工具？
  • 多个工具如何组合、如何排序？

这些都是“低层决策”，而且充满不确定性。

而有了 Skill 之后，我们把其中最复杂的一部分，也就是工具的组合方式与执行流程提前设计并固化下来。模型需要做的事情，被大幅简化为：在有限的 Skill 中，选择一个最合适的能力单元。

从工程角度来看，这其实是一种典型的抽象手段：

  • 把“低层能力组合问题”，上升为“高层能力选择问题”
  • 把“随机推理行为”，转化为“结构化执行能力”

最后我再做一个形象的比喻，假设你要去餐厅为聚会点一桌餐：

  • 以前的 MCP 模式：你（模型）需要自己决定每一道菜 —— 点什么前菜、凉菜、热菜、汤菜，甚至还要考虑搭配和顺序
  • 现在的 Skill：你（模型）只需要选择一个套餐，而套餐里面已经包含了一整套搭配好的菜品

Skill 的不同形式

理解了 Skill 的核心思想后，接下来大家可能就想落地到具体呈现形式，比如我现在要使用 Skill，具体该如何来用呢？

可能大家或多或少见过 Skill 好像是以 markdown 的形式来呈现的。不过我们先不着急，在理解了 Skill 核心思想的基础上，接下来我们来探讨一下 Skill 不同的呈现形式，或者说一下和 Skill 类似的一些东西。

首先需要明确一点：Skill 本身并不是某一种固定的“格式”，而是一种能力封装的思想。

Claude：以 Markdown 形式呈现

目前最常见、也是讨论最多的一种形式，就是 Claude 提供的 Markdown Skill。

它通常长这样：

## Skill: Weather Advisor

1. Step 1: 调用 get_weather
2. Step 2: 分析天气情况
3. Step 3: 给出穿衣建议

这种形式的特点是：

  • 人类可读性强
  • 模型容易理解
  • 天然融合 Prompt + 流程 + 工具调用

你可以把它理解为，这是在用自然语言描述的一段“可执行流程”。

LangChain / LangGraph：以代码形式呈现

描述一段“可执行流程”，难道只有 Markdown 这一种方式吗？答案显然是否定的。

如果你深入使用过 LangChain 或 LangGraph，你会发现它们本质上也是在做“流程封装”：LangChain 侧重于线性执行的 Chain，而 LangGraph 则通过 Graph 实现了更复杂的节点编排与状态流转。

尽管它们在作用上与 Skill 非常相似，但这种“相似”并不意味着“等价”。深入剖析两者的底层逻辑，你会发现它们在三个维度上分道扬镳：

  • 表达范式： Skill 偏向“自然语言叙事”，是在写逻辑描述；Chain/Graph 偏向“硬核编程”，是在写运行逻辑。
  • 控制权归属： Skill 的逻辑交给了模型去推理，是“模型主导”；Chain/Graph 的逻辑是写死在代码里的，模型只是个“打工人”，属于“程序控制”。
  • 认知层级： Skill 是模型“感知”到的自我能力延伸；而 Chain/Graph 则是外部框架强加的约束，模型本身对此一无所知。

Skill 核心结构

在有了前面内容的铺垫后，接下来我们再回到 Skill 具体该怎么做的问题。

这里还是以目前最为流行的 Markdown 形式的 Skill 来介绍。

当前，Skills 已从渗透至各个行业的普通职场人士，GitHub 官方 Skills 库 收获近 10 万星标，技能商店中出现超 7000+人安装的爆款应用。

image-20260319110251430

一个 Skill 本质上就是一个 Markdown 文件（文件名固定为 SKILL.md），内容几乎只由下面内容组成：

my-skill/
└── SKILL.md   （唯一必需）

这里举一个查询天气的 Skill 为例，大家可以先感受一下：

---
name: WeatherAssistant
description: 获取全球实时天气预报、空气质量及出行建议
version: 1.0.0
tools:
  - weather_api:get_current
  - weather_api:get_forecast
---

# Weather Assistant Skill

当你需要查询天气信息或根据气候提供生活建议时，激活此 Skill。

## 1. 触发场景 (Triggers)
* 用户询问特定城市当前的天气状况（如：“北京现在冷吗？”）。
* 用户计划行程并需要未来几天的预报（如：“下周去上海出差需要带雨伞吗？”）。
* 用户询问空气质量或户外活动建议。

## 2. 执行逻辑 (Instructions)
1. **参数提取**：从用户输入中提取 `location`（城市/地区）和 `time_range`（时间跨度）。如果地点不明，优先询问用户。
2. **数据调用**：
   - 使用 `get_current` 获取实时温度、湿度、风力。
   - 如果涉及未来计划，调用 `get_forecast` 获取未来 3-7 天趋势。
3. **逻辑加工**：
   - **体感转化**：不要只报数字，要转化为体感描述（如：“28°C 配合高湿度，体感会比较闷热”）。
   - **穿衣建议**：根据昼夜温差给出具体的穿衣参考。
   - **预警提醒**：如果存在大风、暴雨等极端天气，必须在回复的最开头加粗提醒。

## 3. 输出格式 (Output Format)
请按以下结构组织回复：
- **[当前实况]**：简述天气、气温、空气质量。
- **[趋势预测]**：如果是多日查询，使用表格或简洁列表。
- **[小贴士]**：穿衣、雨具或户外运动建议。

## 4. 约束限制 (Constraints)
- 严禁编造天气数据，若 API 返回失败，请告知用户系统暂时无法联网获取实时信息。
- 默认使用摄氏度 (°C)，除非用户明确要求华氏度。

一般来讲，一个 Skill 的 Markdown 文档会包含这么几个部分：

  1. 元数据（YAML 结构）
  2. 详细指令或者说步骤
  3. 关联资源（可选）

第一层：语义元数据

通常会在文件开头使用类似 YAML 的结构，描述 Skill 的名称、用途等基础信息。Claude 会基于这些简要信息，判断当前任务是否需要使用该 Skill。在这一阶段，模型只接触到“轻量级描述”，而不会加载完整内容。这使得即使安装了上百个技能，初始 Token 消耗也极低（通常每个技能仅占 ~50-100 tokens）。

第二层：详细指令

当模型判断某个 Skill 相关时，会通过工具机制读取 SKILL.md 的完整内容，并将其纳入上下文。

此时，模型才真正获得：

  • 执行步骤
  • 工具使用方式
  • 输出要求

这种“按需加载”的机制，可以有效减少不必要的上下文消耗。

第三层：关联资源

在复杂场景中，Skill 还可以关联额外的文件，例如：

  • 详细说明文档（forms.md）
  • 流程规范（process.pdf）
  • 示例代码（examples.py）

这些内容不会在一开始进入上下文，而是在特定步骤中按需读取。

下面我们再来举一个和翻译相关的 Skill 的例子，目录结构如下：

tech-translator/
├── SKILL.md          # 核心：元数据与执行逻辑
├── glossary.json     # 资源：技术术语映射表 
└── post-process.py   # 脚本：格式化处理工具

SKILL.md

---
name: TechTranslator
description: 将英文技术文档翻译为专业中文，支持术语对齐与 Markdown 格式优化。
version: 1.1.0
---

# Technical Translation Skill

当你需要翻译技术博客、GitHub Readme 或 API 文档时，激活此 Skill。

## 1. 激活逻辑 (L1 触发)
* 用户输入包含：`translate`, `翻译`, `技术文档`。
* 识别到代码片段或计算机科学相关的英文术语。

## 2. 执行指令 (L2 逻辑)
1. **术语对齐**：在开始翻译前，必须读取同目录下的 `glossary.json`。
   - 例如：将 "State Machine" 统一翻译为 "状态机" 而非 "陈述机器"。
2. **风格约束**：
   - 保持 Markdown 结构完整。
   - 在中英文之间强制添加空格（遵循盘古框架规范）。
   - 保持代码块、公式（LaTeX）原封不动。
3. **后处理调用**：
   - 翻译完成后，调用 `python3 post-process.py` 对生成的文本进行最终的校验和格式纠偏。

## 3. 关联资源 (L3 参考)
- **术语库**：`./glossary.json` (包含 500+ 前端与 AI 领域专有名词)
- **工具链**：`./post-process.py` (执行正则替换，修复错误的标点符号)

glossary.json：确保翻译的专业性，不占上下文

{
  "LLM": "大语言模型",
  "Zero-shot": "零样本",
  "Inference": "推理",
  "Frontend": "前端"
}

当技能超过 500–800 行，或需要模板/脚本/参考资料时，推荐以下组织方式：

~/.claude/skills/fx-component/
  ├── SKILL.md                  # 核心指令 + 元数据（建议控制在 400 行内）
  │
  ├── templates/                # 常用模板（Claude 按需读取）
  │   ├── functional.tsx.md
  │   └── class-component.md
  │
  ├── examples/                 # 优秀/反例（给 Claude 看标准）
  │   ├── good.md
  │   └── anti-pattern.md
  │
  ├── references/               # 规范、规则、禁用词表
  │   ├── hooks-rules.md
  │   └── naming-convention.md
  │
  └── scripts/                  # 可执行脚本
      ├── validate-props.py
      └── check-cycle-deps.sh

写在最后

从最初研究如何写好一段 Prompt，到如今讨论如何构建一套复杂的 Skill 体系，我们对大模型的认知正在经历一场深刻的变革：模型不再仅仅是一个“聊天对象”，而是一个可以被工程化驱动的“执行核心”。

Skill 的出现，本质上是在为 AI 建立一套“肌肉记忆”。它让我们意识到，要让模型稳定地处理复杂任务，关键不在于祈祷模型足够聪明，而在于人类能否提供足够清晰、可组合且具备结构化的逻辑框架。

  • MCP 提供了连接万物的可能，让模型拥有了感知与操作物理世界的能力；
  • Skill 提供了组织逻辑的范式，通过分层加载与资源关联，在无限的知识边界与有限的上下文成本之间找到了精妙的平衡。

作为开发者，我们正在从“提问者”转变为“架构师”。未来的 AI 应用，或许就是由无数个像 SKILL.md 这样轻量、专注且强大的能力单元组合而成的有机体。

本系列文章到此告一段落，但人类探索大模型控制边界的旅程才刚刚开始。希望这套从提示词工程到能力单元的思考路径，能为你构建下一代 AI 应用提供一些有价值的参考。

-EOF-

avatar
文章
阅读
粉丝