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

superjiaming

鹅厂技术派·编辑的话

都说要养好虾🦞，离不开好的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 全景调用关系——从用户指令到工具执行的完整链路

图中关键路径解读：

• 用户→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 分别负责“知识注册”和“工具注册”，共同构成系统的完整能力目录。
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：编写参考文档和模板
在

 

re

ference

s/

 

中放 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 调用实例

以一个典型的文档生成场景为例——

t

ech-wik

i

 

Skill 在生成技术文档时，调用 

dia

gram-generator

 

Skill 自动绘制架构图：

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

2、协作设计模式

3、管理最佳实践

• 命名空间：
  领域-功能
   格式（
  code-review
  、
  commit-message
  、
  api-doc
  ）
  
• 单一职责：宁可多建几个小 Skill 也不要一个大而全
  
• 松耦合：Skill 之间通过文件系统交互，不依赖内部 API
  
• 版本控制：Skill 文件跟项目代码一起 Git 管理
  
• 文档先行：先写 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 都是手写的。但可以预见的趋势是：

• 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 如何调用外部工具
Skill 实践

• CodeBuddy Skills Documentation
  

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

• Cursor 
  .cursorrules
   Community Collection, GitHub
  

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

hcyw2008

支持分享