你可能在各种地方看到过关于Claude Skills的介绍，但说实话，大部分文章看完之后你还是不知道它到底是怎么运作的。
今天我想用最真实的方式，带你完整走一遍Skills 的整个流程，看看这个看似神秘的机制到底是怎么回事。
一个命令背后发生了什么
当我们使用 Claude Code 处理一个 PDF 文件时，只需要输入一行简单的命令：“帮我从 report.pdf 提取文字”。
但在这行文字背后，系统实际上经历了一系列精心设计的关键步骤。
当你启动 Claude Code 的那一刻，整个系统就已经开始默默工作了。
后台会扫描三个关键目录：用户个人的 skills 目录、项目下的 skills 目录，以及插件提供的 skills 目录。
以 PDF 处理为例，系统会在~/.claude/skills/pdf/目录下找到对应的技能包，里面包含主文件 SKILL.md、脚本目录和参考文档目录。
但这里有个很关键的细节：系统此时只会读取 SKILL.md 的头部信息，也就是 name、description 和 allowed-tools 这几行。
一份完整的 800 行 SKILL.md 文件，在启动阶段只会被读取前面这几行内容。
这个设计乍看起来有点反直觉，但实际上非常巧妙。
它意味着即使你安装了 100 个不同的 Skills，系统启动时也只需要处理几千个 token 的元数据，而不是把所有技能的完整内容都加载进来。
当你输入处理 PDF 的请求后，这个请求会被封装成一个 HTTP 请求发送到 Anthropic 的 API。
请求体中包含了一个特殊的Skill 工具，里面列出了所有可用 Skills 的简短描述。
这时候 PDF Skill 的 800 行完整内容并没有被发送出去，取而代之的只是那 20 个 token 的简短描述。
Claude 收到请求后，会根据用户的自然语言去匹配最合适的 Skill。当它识别到用户想处理 PDF 文件时，就会决定调用 PDF Skill。
这个决策过程我们看不到，但从抓包数据可以确认，Claude 确实是在这一步做出了调用特定 Skill 的判断。
真正的关键点在 Skill 被激活的那一刻。
系统此时才会去读取完整的 SKILL.md 文件，把那份 800 行的工作流程、指令和工具说明注入到对话上下文中。
这条注入的消息对用户是不可见的，但它会被发送给 Claude，成为指导 Claude 后续行为的核心指令。同时，系统还会预先批准 SKILL.md 中声明的工具权限，比如允许 Claude 调用 Bash(python:*)、Read、Write 等工具，而且这些工具调用不需要用户再次确认。
为什么这样设计
了解完整流程后，你会发现Claude Skills 的本质其实就是一套基于 prompt 注入的元工具架构。
它不是什么可执行的代码片段，而是一种动态的上下文增强机制。
这种架构带来了几个非常实际的好处。
首先是按需加载。
你安装再多的 Skills，系统启动时也只会读取元数据，只有真正用到的 Skill 才会加载完整内容。
其次是格式统一。
所有的 Skills 都遵循相同的结构，降低了使用和分享的门槛。
第三是权限精细化。
每个 Skill 在执行时都明确声明了可以使用哪些工具，而且这些权限只在 Skill 活跃期间有效。
如果没有这套机制，每次处理 PDF 你都需要手动描述整个流程：用什么命令提取文字、怎么处理错误、怎么读取结果、怎么格式化输出。
这不仅增加了 token 消耗，更重要的是每次都要重复描述这些细节。有了 Skills 之后，你只需要用自然语言表达意图，剩下的工作流程由 Skills 自动完成。
结语
所以，下次当你看到各种 Skills 列表和应用场景时，不妨想想它背后的这整套机制。
一个看似简单的帮我处理 PDF命令，实际上经历了启动扫描、请求发送、意图匹配、技能激活、指令注入、工具执行这一系列步骤。理解这些底层逻辑，你才能真正明白 Skills 的价值在哪里，以及如何更好地利用它们来提升工作效率。
技术的东西，说复杂可以讲得很复杂，但说简单也可以讲得很简单。关键是别被表面的概念吓住，也别被简单的介绍糊弄过去。
真正动手看看它是怎么跑的，很多疑惑自然就解开了，对吧？
