一、概述
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 执行的完整调度链路。
图中关键路径解读：
用户→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 不是竞争关系，而是互补关系：
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、管理最佳实践
命名空间：领域-功能 格式（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 的灵感来源
推荐阅读
Simon Willison, "Prompt Engineering and LLM Customization", 2024
📌 亮点：从 Prompt Engineering 到结构化知识管理的演进思考
Harrison Chase, "Building LLM Applications with LangChain", 2024
📌 亮点：Agent + Tool Use 的工程实践，与 Skill 理念相通
