Skill系列2：重新定义提示词——Skill的核心机制与设计思路

那么，Skill到底是什么？

从本质上来说，它依然是“提示词”。
或者更准确一点，是提供给大模型的上下文（Context）——因为在当前阶段，这仍然是大模型唯一的输入。

但Skill并不是传统意义上的Prompt拼接，它在结构和机制上，已经发生了明显的进化。

一、Skill vs MCP：核心差异在哪里？

在上一篇我们提到，MCP有一个非常明显的硬伤：

每一轮对话，都需要把完整的工具列表和参数定义全部塞进上下文。

这会带来两个问题：

• 上下文窗口被迅速占满
• 模型处理负担过重，效率下降

而Skill，解决这个问题的关键在于一个核心机制——渐进式披露（Progressive Disclosure）

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

Skill采用了一种分层加载的方式来管理上下文信息。

在初始阶段，只会加载非常轻量的元数据，例如：

• Skill名称
• 描述
• 版本号

即使同时加载几十个Skill，占用的上下文也非常有限。

只有当某个任务真正“命中”某个Skill时，才会进一步加载：

• 更详细的规则
• 操作步骤
• 相关上下文信息

如果你有编程背景，这种设计其实非常熟悉：

索引 + 懒加载（Lazy Loading）

本质上，Skill并没有发明全新的思想，而是把成熟的软件工程理念，引入到了大模型的上下文管理中。

三、不只是Prompt：Skill的扩展能力

Skill的能力，并不止于“结构化提示词”。

它还可以进一步扩展，包括：

• 📄 Markdown文档（References）
  用于承载规则、知识库或领域背景
• ⚙️ 脚本（Scripts）
  支持 Bash / Python 等，用于执行确定性任务

例如：

• 文件读取与筛选
• API调用
• 数据处理

四、为什么要引入Scripts？

在大模型的实践中，一个共识正在逐渐形成：

确定的事情，应该交给确定性的程序来做。

模型擅长的是：

• 理解自然语言
• 提取语义
• 做推理和生成

而程序擅长的是：

• 精确执行
• 数据处理
• 可控输出

Skill的设计，正是把这两者进行了清晰分工：

让系统整体既智能，又可靠。

五、总结：Skill到底解决了什么问题？

从机制上来看，Skill带来了三点关键提升：

1. 上下文更高效：通过渐进式披露，避免信息冗余
2. 结构更清晰：分层设计，让能力模块化
3. 能力更完整：结合脚本，实现“理解 + 执行”的闭环