2026年3月27日,来腾讯会议(限50人)了解掌握如何用Openclaw构建企业AI生产力
免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

一文看懂:养虾人总挂在嘴边的skill到底是什么

发布日期:2026-03-24 19:52:00 浏览次数: 1531
作者:鹅厂技术派

微信搜一搜,关注“鹅厂技术派”

推荐语

腾讯云推出Skillhub,解决OpenClaw生态痛点,让AI技能包更易用高效。

核心内容:
1. Skill的定义与核心价值:标准化知识封装格式,提升AI专业能力
2. 三大痛点解决方案:标准化+持久化+可复用特性打破AI使用瓶颈
3. 技术全景解析:大模型与Skill的协同调用关系及实现路径

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

鹅厂技术派·编辑的话


都说要养好虾🦞,离不开好的Skill。

腾讯云在近期推出了OpenClaw官方开源生态ClawHub打造的本土化高速镜像平台Skillhub(https://skillhub.tencent.com/,旨在解决国内用户使用OpenClaw技能生态的核心痛点,包括访问速度慢、中文支持不足等问题。

那么Skill 到底是什么,我们要怎么样才能设计一个自己的Skill,并用好它?下面这篇文章可能是关于Skill (zui)全的介绍。

一、概述

1、什么是 Skill?

Skill(技能包)是一种标准化的知识封装格式,它让大模型在特定领域拥有专家级的执行能力。简单来说,Skill 就是一个文件夹,里面装着“该怎么做”的指令、“可以用什么工具”的脚本、以及“参考什么标准”的文档。

这个概念诞生于 AI 辅助编程工具的实践中。当开发者发现大模型虽然“什么都知道一点,但什么都不够专业”时,Skill 应运而生——它不是让模型重新训练,而是在推理时给它一个精确的行动指南

你可以把 Skill 想象成游戏里的装备系统:大模型本身是一个满级角色,但面对不同副本(任务场景),你需要给它换上不同的装备(Skill)才能发挥最大战力。

💡 人话翻译:Skill 就是写给 AI 的标准操作手册,让它按你的要求做事,而不是自由发挥。

2、 解决了什么问题?

在 Skill 出现之前,世界是这样的:

  • 痛点 1:每次让 AI 画架构图,都要在 Prompt 里写一大段样式要求,像极了每天早上重新教实习生怎么开电脑

  • 痛点 2:不同项目、不同团队成员使用 AI 的方式五花八门,生成的文档格式千奇百怪

  • 痛点 3:大模型的“好记忆”只限于当前对话窗口,下次打开又是一张白纸,所有定制化偏好归零

然后,Skill 带着它的「标准化 + 持久化 + 可复用」三板斧出现了——它把你的专业知识、风格偏好、工作流程封装成一个文件夹,AI 每次工作时自动加载,不用你重复交代。一次封装,永久生效,还能分享给团队。

3、核心优势

二、全景架构

🏗️ 在深入 Skill 的细节之前,先从上帝视角看一下大模型、MCP、HTTP、Tool Use 和 Skill 之间的关系。


1、技术栈一览

2、大模型与 Skill 全景调用关系

下图展示了从用户指令到 Skill 执行的完整调度链路。

图 1:大模型 × MCP × Skill × Tool Use 全景调用关系——从用户指令到工具执行的完整链路

图中关键路径解读:

  1. 用户→IDE→LLM→Skill(主调用链 + 知识加载链):用户的自然语言指令通过 IDE 传递给大模型,Skill Matcher 通过 Skill Registry 匹配对应的 Skill,Context Builder 按三级渐进机制加载 Skill 内容——先读元数据,再读 SKILL.md 正文,最后按需读取 references/scripts/assets

  2. LLM→IDE→MCP→Tool(工具执行链):LLM 生成 Tool Call 请求后交给 IDE,IDE 通过 MCP 协议进行能力发现和注册,Tool Dispatcher 将请求路由到具体的工具函数

  3. Skill Registry ↔ MCP 协议(能力桥梁):Skill Registry 管理 Skill 元数据供 LLM 匹配,MCP 协议管理工具能力供 Dispatcher 调度——两者分别服务于“知识选择”和“工具执行”

🔍 架构设计的精妙之处:Skill 和 Tool 是两个正交的概念——Skill 提供“知道该做什么”(领域知识),Tool 提供“能做什么”(执行能力)。同一个 Skill 可以在不同的 Tool 环境中运行,同一个 Tool 也可以被不同的 Skill 复用。Skill Registry 和 MCP Capability Discovery 分别负责“知识注册”和“工具注册”,共同构成系统的完整能力目录。

3、MCP、HTTP 与 Skill 的调用时序

从一个具体请求的视角,看看各组件之间的交互时序:

图 2:一次 Skill 调用的完整时序——从"生成提交信息"到输出结果的全链路

🔍 关键洞察:LLM 不是一次性读完所有 Skill 文件,而是先读 SKILL.md 获取工作流,再根据当前步骤按需加载 references 和 assets。这种渐进式加载有效控制了 Token 消耗。

三、Skill 的前世今生

要理解 Skill,先得知道它是怎么一步步演化来的。

1、前 Skill 时代:Prompt Engineering(2022-2023)

一切始于 Prompt Engineering——开发者发现,给大模型的提示词越详细,输出质量越高。于是出现了所谓的「超级 Prompt」,动辄 200 行的样式要求。:这些 Prompt 只存在于对话历史中,换个窗口就没了。

2、System Prompt 时代(2023)

随着 OpenAI API 引入 system 角色,IDE 插件开始支持自定义 System Prompt 文件(如.cursorrules)。进步:指令持久化了。问题:还是一坨大文本,没有结构化,也无法按需加载。

3、Skill 的诞生(2024-2025)

MCP(Model Context Protocol)协议和 Skill 体系几乎同时出现,标志着 AI 辅助开发进入结构化知识管理时代:

4、MCP 与 Skill 的关系

MCP 和 Skill 不是竞争关系,而是互补关系

图 3:Skill(知识层)与 MCP/Tool Use(执行层)的互补关系

  • Skill → 回答「做什么」和「怎么做」——领域知识、工作流、质量标准

  • MCP/Tool Use → 回答「用什么做」——读写文件、执行命令、网络请求

  • LLM → 负责「理解」和「决策」——理解意图,选择 Skill,调用 Tool

四、Skill 的专业定义

⚙️ 现在让我们打开引擎盖,看看一个标准 Skill 的内部结构。

💡 为什么只有四个东西? 任何领域知识都可以分解为:一个「总纲领」(SKILL.md),一些「参考手册」(references/),一些「工具」(scripts/),和一些「原材料」(assets/)。这是社区反复迭代后的极简设计。

1、SKILL.md 剖析

SKILL.md 由两部分组成:

Part 1: YAML Frontmatter(元数据)

description 是 Skill 匹配的核心——LLM 根据它判断是否激活该 Skill。

Part 2: Markdown 正文(工作流指令)

2、真实案例:三种典型 Skill 的对比

以社区中广泛使用的三类 Skill 为例,展示不同领域 Skill 的结构差异:

 

三个案例的设计启示

  • skill-creator 是“重型 Skill”的代表——大量脚本+子 Agent+评估流水线,适合需要迭代验证的复杂场景。注意它额外使用了 agents/ 目录存放子 Agent 定义,这是对标准四目录结构的扩展,适用于需要多 Agent 协作的高级场景

  • commit-message 是“轻量 Skill”的典范——只需一个 SKILL.md + 一个参考规范,Skill 不一定要“大而全”

  • code-review 是“中间路线”——参考文档+模板,平衡了灵活性和标准化

🔍 核心原则:没有两个 Skill 长得一模一样。根据领域特点决定各目录的权重——简单任务别过度设计,复杂任务别偷工减料。

3、三级渐进加载机制

图 4:三级渐进加载——从元数据到完整资源的按需读取

系统可以同时挂载数十个 Skill 的元数据(Level 1),但只有被触发的 Skill 才会占用上下文窗口。就像手机上装了 100 个 App,但只有正在使用的才占内存。

五、手把手定制你的第一个 Skill

🛠️ 理论够了,撸起袖子实战。本节提供两种方式——手工创建借助 Skill Creator 自动创建

1、方式一:手工创建(适合简单 Skill)

Step 1:明确定位

在动手之前,先回答三个问题:

⚠️ 常见错误:一个 Skill 应该只做一件事并做到极致。试图同时处理架构图+PPT+文档的 Skill,该拆。

Step 2:创建目录

Step 3:编写 SKILL.md

以「Commit Message 生成器」为例:

Step 4:编写参考文档和模板

 references/ 中放 AI 工作时需要参考的规范,在 assets/ 中放输出模板。

Step 5:description 编写七条黄金法则

💡 来自 skill-creator 的经验:description 宁可“主动”一点,因为 AI 当前有“欠触发”倾向——宁可多匹配,也不要在用户需要时沉默。

2、方式二:使用 Skill Creator(推荐,适合复杂 Skill

手工创建适合轻量 Skill,但如果你的 Skill 涉及复杂工作流、需要评估迭代,那么推荐使用 skill-creator ——一个专门用来「创建 Skill 的 Skill」。

什么是 Skill Creator?

Skill Creator 是 Anthropic 官方提供的元技能(Meta-Skill),它的核心理念是:用 AI 来创建给 AI 用的技能包。它内置了完整的 Skill 创建→测试→评估→迭代优化闭环。

Skill Creator 的工作流程

实战:用 Skill Creator 创建一个 Code Review Skill

Skill Creator 的独门利器

💡 选择建议:如果你的 Skill 只是简单的知识规范(如 commit-message),手工创建 5 分钟搞定;如果涉及复杂工作流、需要反复调优(如 code-review、架构图生成),用 Skill Creator 能节省大量试错时间。

六、多 Skill 协同

🎼 单个 Skill 是独奏,多个 Skill 协同才是交响乐。

1、跨 Skill 调用实例

以一个典型的文档生成场景为例——tech-wiki Skill 在生成技术文档时,调用 diagram-generator Skill 自动绘制架构图:

图 5:tech-wiki 与 diagram-generator 的跨 Skill 协作流程

2、协作设计模式

3、管理最佳实践

  1. 命名空间领域-功能 格式(code-reviewcommit-messageapi-doc

  2. 单一职责:宁可多建几个小 Skill 也不要一个大而全

  3. 松耦合:Skill 之间通过文件系统交互,不依赖内部 API

  4. 版本控制:Skill 文件跟项目代码一起 Git 管理

  5. 文档先行:先写 description,确保触发条件清晰

七、 Skill 使用核心技巧

🎯本节是全文重点中的重点——从“能用”到“用好”的进阶秘籍。每一条都来自实战经验的提炼。

1、触发技巧:让 Skill 精准命中

技巧 1:使用精确触发词

技巧 2:@mention 直接引用 Skill 路径

图片

绕过关键词匹配,直接指定 Skill——100% 命中率,这是最可靠的触发方式。

技巧 3:描述期望的输出格式

图片

明确输出格式帮助 AI 选对 Skill。

2、上下文管理:让 Skill 读到该读的

技巧 4:引导 AI 按需加载 references

Skill 的 references/ 不会一次全部加载。显式引导:

图片

技巧 5:分步骤交互,不要一次性倾倒

按 Skill 的 Workflow 步骤逐轮推进,而非一条消息交代所有需求:

图片

技巧 6:用 @attach 提供项目上下文

图片

3、质量控制:让输出达到专业级

技巧 7:利用内置质量检查清单

完成初稿后显式要求自检:

图片

技巧 8:提供反面示例(Few-shot Negative)

“不要什么”比“要什么”更有效:

图片

技巧 9:迭代优化而非推倒重来

图片

保留好的部分,只修改不满意的部分,效率提升 10 倍。

4、定制进阶:让 Skill 更懂你

技巧 10:在 references/ 中沉淀团队知识

规则如果你发现同一句话对 AI 说了 3 次,就该写进 references/。

技巧 11:用 assets/ 模板固化最佳实践

团队的标准化输出格式放进 assets/,AI 每次基于模板生成,保证格式一致。

技巧 12:用 scripts/ 实现确定性操作

不该 AI 自由发挥的操作(如文件格式转换、截图)写成脚本:

图片

5、效率提升:少花 Token,多出活

技巧 13:善用三级加载,减少 Token 消耗

在 SKILL.md 的 Workflow 中,只在需要的 Step 里引用对应文件:

图片

技巧 14:把大参考文档拆成小文件

图片

技巧 15:复用已有 Skill

创建新 Skill 前先检查:

图片

6、调试技巧:Skill 不按预期工作时

技巧 16:检查 description 关键词覆盖

图片

技巧 17:检查 SKILL.md 中的引用路径

图片

技巧 18:用“干跑”模式验证

图片

7.7 技巧速查表

八、哲学反思

🔭 工具塑造思维,思维反过来创造新工具。

1、从 Skill 看“知识的可执行化”

Skill 本质上做了一件很深刻的事:把隐性知识变成了可执行的显性知识

传统知识管理(Confluence、内部文档)是“人读给自己看的”——依赖读者的理解和执行力。而 Skill 是“写给 AI 看的”——它必须足够精确、结构化、无歧义,因为执行者是一个“聪明但死板”的语言模型。

这种转变逼着我们重新审视自己的知识:你以为你知道怎么画架构图,但当你试图把它写成 Skill 时,你会发现有 80% 的决策是“感觉”——你从来没有明确定义过“什么时候用粗箭头,什么时候用虚线”。Skill 迫使这些“感觉”变成“规则”。

某种意义上,编写 Skill 的过程就是知识考古的过程——挖掘埋藏在直觉中的专业判断,把它变成可传承、可复用的文字。

2、未解之题

「好的技术回答旧问题,伟大的技术提出新问题。」

  • Skill 的粒度悖论:太细碎则管理成本高,太粗放则不够专业。最佳粒度在哪里?目前没有公认答案

  • Skill 间的冲突解决:当两个 Skill 的 description 都匹配当前任务时,谁优先?如何避免“多个 Skill 抢活”?

  • Skill 的过期问题:技术迭代很快,写好的 Skill 多久会过时?谁负责更新?这本质上是知识管理的老问题

3、未来展望

Skill 目前还处于“手工作坊”阶段——每个 Skill 都是手写的。但可以预见的趋势是:

  1. Skill 生成 Skill:让 AI 根据用户的使用模式,自动提炼出新的 Skill(Meta-Skill)

  2. Skill 市场:像 npm/pip 一样的 Skill 包管理器,skill install code-review@v3

  3. 自适应 Skill:Skill 根据执行反馈自动优化自己的 Workflow,从“静态手册”进化为“动态专家”

💭 结语:当我们教会 AI 使用 Skill,我们其实在做一件更根本的事——梳理和结构化人类的专业知识。也许 Skill 最大的价值不在于让 AI 更强,而在于迫使我们搞清楚自己到底「知道什么」。这个过程本身,比任何工具都更有价值。

九、参考资料

📚 站在巨人的肩膀上——不过先确认巨人没有站在流沙上。

协议与规范

  • Anthropic, "Model Context Protocol (MCP) Specification", 2024. 

    What is the Model Context Protocol (MCP)? - Model Context Protocol

📌 推荐理由:MCP 是理解 Skill 执行层的关键协议,读完就明白 Tool Use 的运作机制

  • OpenAI, "Function Calling / Tool Use Documentation", 2024. 

    https://platform.openai.com/docs/guides/function-calling

📌 推荐理由:Tool Use 的鼻祖级文档,理解 AI 如何调用外部工具

Skill 实践

  • CodeBuddy Skills Documentation

📌 适合:想要从零创建 Skill 的开发者

  • Cursor .cursorrules Community Collection, GitHub

📌 亮点:大量社区贡献的 System Prompt 规则,可作为 Skill 的灵感来源

推荐阅读

  • Simon Willison, "Prompt Engineering and LLM Customization", 2024

📌 亮点:从 Prompt Engineering 到结构化知识管理的演进思考

  • Harrison Chase, "Building LLM Applications with LangChain", 2024

 📌 亮点:Agent + Tool Use 的工程实践,与 Skill 理念相通


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询