微信扫码
添加专属顾问
我要投稿
腾讯云推出Skillhub,解决OpenClaw生态痛点,让AI技能包更易用高效。 核心内容: 1. Skill的定义与核心价值:标准化知识封装格式,提升AI专业能力 2. 三大痛点解决方案:标准化+持久化+可复用特性打破AI使用瓶颈 3. 技术全景解析:大模型与Skill的协同调用关系及实现路径
鹅厂技术派·编辑的话
一、概述
1、什么是 Skill?
Skill(技能包)是一种标准化的知识封装格式,它让大模型在特定领域拥有专家级的执行能力。简单来说,Skill 就是一个文件夹,里面装着“该怎么做”的指令、“可以用什么工具”的脚本、以及“参考什么标准”的文档。
这个概念诞生于 AI 辅助编程工具的实践中。当开发者发现大模型虽然“什么都知道一点,但什么都不够专业”时,Skill 应运而生——它不是让模型重新训练,而是在推理时给它一个精确的行动指南。
你可以把 Skill 想象成游戏里的装备系统:大模型本身是一个满级角色,但面对不同副本(任务场景),你需要给它换上不同的装备(Skill)才能发挥最大战力。
💡 人话翻译:Skill 就是写给 AI 的标准操作手册,让它按你的要求做事,而不是自由发挥。
2、 解决了什么问题?
在 Skill 出现之前,世界是这样的:
痛点 1:每次让 AI 画架构图,都要在 Prompt 里写一大段样式要求,像极了每天早上重新教实习生怎么开电脑
痛点 2:不同项目、不同团队成员使用 AI 的方式五花八门,生成的文档格式千奇百怪
痛点 3:大模型的“好记忆”只限于当前对话窗口,下次打开又是一张白纸,所有定制化偏好归零
然后,Skill 带着它的「标准化 + 持久化 + 可复用」三板斧出现了——它把你的专业知识、风格偏好、工作流程封装成一个文件夹,AI 每次工作时自动加载,不用你重复交代。一次封装,永久生效,还能分享给团队。
🏗️ 在深入 Skill 的细节之前,先从上帝视角看一下大模型、MCP、HTTP、Tool Use 和 Skill 之间的关系。
1、技术栈一览
2、大模型与 Skill 全景调用关系
下图展示了从用户指令到 Skill 执行的完整调度链路。
图 1:大模型 × MCP × Skill × Tool Use 全景调用关系——从用户指令到工具执行的完整链路
图中关键路径解读:
用户→IDE→LLM→Skill(主调用链 + 知识加载链):用户的自然语言指令通过 IDE 传递给大模型,Skill Matcher 通过 Skill Registry 匹配对应的 Skill,Context Builder 按三级渐进机制加载 Skill 内容——先读元数据,再读 SKILL.md 正文,最后按需读取 references/scripts/assets
LLM→IDE→MCP→Tool(工具执行链):LLM 生成 Tool Call 请求后交给 IDE,IDE 通过 MCP 协议进行能力发现和注册,Tool Dispatcher 将请求路由到具体的工具函数
Skill Registry ↔ MCP 协议(能力桥梁):Skill Registry 管理 Skill 元数据供 LLM 匹配,MCP 协议管理工具能力供 Dispatcher 调度——两者分别服务于“知识选择”和“工具执行”
🔍 架构设计的精妙之处:Skill 和 Tool 是两个正交的概念——Skill 提供“知道该做什么”(领域知识),Tool 提供“能做什么”(执行能力)。同一个 Skill 可以在不同的 Tool 环境中运行,同一个 Tool 也可以被不同的 Skill 复用。Skill Registry 和 MCP Capability Discovery 分别负责“知识注册”和“工具注册”,共同构成系统的完整能力目录。
从一个具体请求的视角,看看各组件之间的交互时序:
图 2:一次 Skill 调用的完整时序——从"生成提交信息"到输出结果的全链路
🔍 关键洞察:LLM 不是一次性读完所有 Skill 文件,而是先读 SKILL.md 获取工作流,再根据当前步骤按需加载 references 和 assets。这种渐进式加载有效控制了 Token 消耗。
要理解 Skill,先得知道它是怎么一步步演化来的。
一切始于 Prompt Engineering——开发者发现,给大模型的提示词越详细,输出质量越高。于是出现了所谓的「超级 Prompt」,动辄 200 行的样式要求。问题:这些 Prompt 只存在于对话历史中,换个窗口就没了。
随着 OpenAI API 引入 system 角色,IDE 插件开始支持自定义 System Prompt 文件(如.cursorrules)。进步:指令持久化了。问题:还是一坨大文本,没有结构化,也无法按需加载。
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/)。这是社区反复迭代后的极简设计。
SKILL.md 由两部分组成:
Part 1: YAML Frontmatter(元数据)
description 是 Skill 匹配的核心——LLM 根据它判断是否激活该 Skill。
以社区中广泛使用的三类 Skill 为例,展示不同领域 Skill 的结构差异:
三个案例的设计启示
:skill-creator 是“重型 Skill”的代表——大量脚本+子 Agent+评估流水线,适合需要迭代验证的复杂场景。注意它额外使用了 agents/ 目录存放子 Agent 定义,这是对标准四目录结构的扩展,适用于需要多 Agent 协作的高级场景
commit-message 是“轻量 Skill”的典范——只需一个 SKILL.md + 一个参考规范,Skill 不一定要“大而全”
code-review 是“中间路线”——参考文档+模板,平衡了灵活性和标准化
🔍 核心原则:没有两个 Skill 长得一模一样。根据领域特点决定各目录的权重——简单任务别过度设计,复杂任务别偷工减料。
图 4:三级渐进加载——从元数据到完整资源的按需读取
系统可以同时挂载数十个 Skill 的元数据(Level 1),但只有被触发的 Skill 才会占用上下文窗口。就像手机上装了 100 个 App,但只有正在使用的才占内存。
🛠️ 理论够了,撸起袖子实战。本节提供两种方式——手工创建和借助 Skill Creator 自动创建。
在动手之前,先回答三个问题:
⚠️ 常见错误:一个 Skill 应该只做一件事并做到极致。试图同时处理架构图+PPT+文档的 Skill,该拆。
以「Commit Message 生成器」为例:
Step 4:编写参考文档和模板
在 references/ 中放 AI 工作时需要参考的规范,在 assets/ 中放输出模板。
💡 来自 skill-creator 的经验:description 宁可“主动”一点,因为 AI 当前有“欠触发”倾向——宁可多匹配,也不要在用户需要时沉默。
手工创建适合轻量 Skill,但如果你的 Skill 涉及复杂工作流、需要评估迭代,那么推荐使用 skill-creator ——一个专门用来「创建 Skill 的 Skill」。
Skill Creator 是 Anthropic 官方提供的元技能(Meta-Skill),它的核心理念是:用 AI 来创建给 AI 用的技能包。它内置了完整的 Skill 创建→测试→评估→迭代优化闭环。
Skill Creator 的独门利器
💡 选择建议:如果你的 Skill 只是简单的知识规范(如 commit-message),手工创建 5 分钟搞定;如果涉及复杂工作流、需要反复调优(如 code-review、架构图生成),用 Skill Creator 能节省大量试错时间。
🎼 单个 Skill 是独奏,多个 Skill 协同才是交响乐。
以一个典型的文档生成场景为例——tech-wiki Skill 在生成技术文档时,调用 diagram-generator Skill 自动绘制架构图:
图 5:tech-wiki 与 diagram-generator 的跨 Skill 协作流程
命名空间:领域-功能 格式(code-review、commit-message、api-doc)
单一职责:宁可多建几个小 Skill 也不要一个大而全
松耦合:Skill 之间通过文件系统交互,不依赖内部 API
版本控制:Skill 文件跟项目代码一起 Git 管理
文档先行:先写 description,确保触发条件清晰
🎯本节是全文重点中的重点——从“能用”到“用好”的进阶秘籍。每一条都来自实战经验的提炼。
绕过关键词匹配,直接指定 Skill——100% 命中率,这是最可靠的触发方式。
明确输出格式帮助 AI 选对 Skill。
Skill 的 references/ 不会一次全部加载。显式引导:
按 Skill 的 Workflow 步骤逐轮推进,而非一条消息交代所有需求:
完成初稿后显式要求自检:
“不要什么”比“要什么”更有效:
保留好的部分,只修改不满意的部分,效率提升 10 倍。
规则:如果你发现同一句话对 AI 说了 3 次,就该写进 references/。
团队的标准化输出格式放进 assets/,AI 每次基于模板生成,保证格式一致。
不该 AI 自由发挥的操作(如文件格式转换、截图)写成脚本:
在 SKILL.md 的 Workflow 中,只在需要的 Step 里引用对应文件:
创建新 Skill 前先检查:
🔭 工具塑造思维,思维反过来创造新工具。
Skill 本质上做了一件很深刻的事:把隐性知识变成了可执行的显性知识。
传统知识管理(Confluence、内部文档)是“人读给自己看的”——依赖读者的理解和执行力。而 Skill 是“写给 AI 看的”——它必须足够精确、结构化、无歧义,因为执行者是一个“聪明但死板”的语言模型。
这种转变逼着我们重新审视自己的知识:你以为你知道怎么画架构图,但当你试图把它写成 Skill 时,你会发现有 80% 的决策是“感觉”——你从来没有明确定义过“什么时候用粗箭头,什么时候用虚线”。Skill 迫使这些“感觉”变成“规则”。
某种意义上,编写 Skill 的过程就是知识考古的过程——挖掘埋藏在直觉中的专业判断,把它变成可传承、可复用的文字。
「好的技术回答旧问题,伟大的技术提出新问题。」
Skill 的粒度悖论:太细碎则管理成本高,太粗放则不够专业。最佳粒度在哪里?目前没有公认答案
Skill 间的冲突解决:当两个 Skill 的 description 都匹配当前任务时,谁优先?如何避免“多个 Skill 抢活”?
Skill 的过期问题:技术迭代很快,写好的 Skill 多久会过时?谁负责更新?这本质上是知识管理的老问题
Skill 目前还处于“手工作坊”阶段——每个 Skill 都是手写的。但可以预见的趋势是:
Skill 生成 Skill:让 AI 根据用户的使用模式,自动提炼出新的 Skill(Meta-Skill)
Skill 市场:像 npm/pip 一样的 Skill 包管理器,skill install code-review@v3
自适应 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 如何调用外部工具
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+中大型企业
2026-03-24
用了这个Skill之后,我的龙虾真的开始「长记性」了
2026-03-24
【最新】阿里云ClawHub Skill扫描:3万个AI Agent技能中的安全度量
2026-03-24
把公众号写作流程做成一个 Skill,我在 ClawHub 发布了 wechat-writer
2026-03-24
对话李曼玲:OpenClaw之后,重新理解Skill
2026-03-23
技多不压身,那龙虾的 Skill 是越多越好吗?
2026-03-23
你和最会玩“龙虾”的人,可能只差这8个硬核Skills
2026-03-23
让AI变成Super员工的秘密:高效训练Skills
2026-03-23
从诞虾说起:装 Skill 之前做一次简单的安全自检
2026-03-04
2026-03-10
2026-03-03
2026-03-03
2026-03-04
2026-03-05
2026-03-05
2026-03-02
2026-03-05
2026-03-11