一、引言最近我也是开始了第一段实习了到厂里第一天就让我干需求至今为止干了三天写了也有六七个需求了其中大部分都是全栈需求。现在 AI 这么强我大部分时间都是在“接到需求” —— “拆解需求” —— “向 AI 描述需求” —— “刷抖音低脂小视频边傻乐边等 AI 反馈结果” —— 检查 AI 改动位置 —— “手动走一遍完整链路做测试” —— 有问题就重复第三步和第四步没问题就提 PR。写全栈需求的时候我都是先写前端然后让 AI 一并给出后端的对齐文档再发给负责后端的 AI整个流程看似很轻松实际上 AI 经常会犯毛病再加上像我这样的三流开发者本身代码功底薄弱等原因就会导致 AI 修改代码时往往会按照它自己理解改动一些原本不需要改动的地方亦或是压根不按照该项目的开发规范进行代码书写包括但不限于Controller 层写一堆业务逻辑等~~~。有些会报错、容易排查的地方还好说如果遇到那种既不会报错又不容易复现的 BUG 逻辑才可怕就像一枚线上的定时炸弹把 Boss 和 Mentor 的脾气都给炸飞然后问这代码是谁写的这锅不得不背了。。。为了提高开发效率减少返工次数我尝试去学习如何更好的使用 AI 协助我开发于是了解到 Skill 或许是一个很好的解决方案本篇文章就带大家梳理一下 Skill 这个必不可少的技能包二、Skill 的诞生1.从 Prompt 到 Skill到底在迭代什么大模型的知识组织方式有一条清晰的演化链路 Prompt → 工具调用 → MCP → Skill需要事先强调的是他们之间不是谁代替谁的关系即便是现在他们也共同存在。这条线不是能力增强史是上下文从「一次性喂进去的文本」变成「可寻址、可组合、按需拉取的外部系统」的过程。我们都知道对于大模型而言上下文和注意力是十分珍贵的资源这条线就是在不断优化这些资源的分配效率。1Prompt —— 模型只能「说」模型是个封闭的函数输入文本输出文本。想让它做对事唯一手段是把需要的一切塞进上下文——背景、规范、示例、边界条件全靠手写。暴露的瓶颈有两个能力边界它拿不到实时数据也改不了外部世界的任何状态。你问它昨天的构建为什么失败它只能猜。复用为零你花二十分钟调出的一段好提示词活在一个对话窗口里。换个会话、换个同事从头再来。第一个瓶颈催生了工具调用第二个瓶颈一直悬着直到 Skill 才被正面回答。这是理解整条线的关键——它其实是两条线前半段解决「能不能做」后半段解决「做得对不对、能不能复用」。2工具调用 —— 模型可以「做」给模型一组带 schema 的函数声明它输出结构化的调用请求宿主程序执行把结果回灌给模型。封闭的盒子被打开了。新瓶颈是集成成本每个工具都要为每个应用写一遍胶水代码。M 个工具 × N 个宿主 M×N 份实现而且工具描述硬编码在应用里换个客户端就得重做。生态是碎的。3MCP —— 把接线方式标准化MCP 做的事很干净定义一套客户端-服务端协议服务端暴露 tools / resources / prompts任何支持 MCP 的宿主都能直接接。M×N 变成 MN。写一次 GitHub MCP server所有 MCP 客户端都能用。这是工程层面的正确解法。但它解决的仍然是「模型能接触到什么」。新瓶颈随之显形知道有create_pull_request这个工具不等于知道你们团队的 PR 该怎么写标题、要不要挂 issue、什么情况下必须拆分。能力不等于方法论。所有工具描述都要在会话开始时加载。接十个 server上下文还没开始干活就被吃掉一大块。4Skill —— 把「怎么做」也变成资产Skill 把一段专业能力打包成一个目录SKILL.md写指令旁边可以放脚本、模板、参考文档。加载方式是渐进式的——平时模型只看到名字和一句描述判断相关了才读正文正文里再按需读附件。MCP 跟 Skill 的本质区别在于前者是一段独立的程序、后者是一段说明文档前者的语义是让大模型连接到外部数据源而后者则是教大模型如何如何处理这些数据。二者是互补的适用场景不同前者在代码执行的稳定性和安全性上高于后者后者适合跑一些轻量指令。它对上面两个瓶颈的回答分别是承载方法论Skill 里写的不是「有什么能力」而是「遇到这类任务按什么顺序、依据什么标准、注意哪些坑」。工具是名词Skill 是动词。上下文可控几十个 Skill 的常驻开销只是几十行描述命中才展开。顺带解决了阶段一遗留的复用问题Skill 是文件夹可以进 Git、可以 review、可以随仓库分发。而且写它不需要写代码,领域专家自己就能产出。从 Prompt 到 Skill 的迭代前三个环节一直是关注大模型向外界的拓展只有到 Skill 开始转向了内部整个环节本质上就是尽可能地把让 “大模型” 做对事的知识存储到一个仓库中而非某个人的对话上下文并让大模型可以对这些知识进行版本管理。2.Skill 到底是什么一句话定义 Skill 就是把一段可复用的专业能力说明 脚本 参考资料打包成模型按需加载的目录所以说 Skill 的本体其实就是一个文件夹文件夹的名称就是 Skill 的名字里面主要分为 Skill.md 文件、reference文件夹、script文件夹、assets文件夹接下来就逐一介绍它们。1Skill.md —— 元数据与指令每个 Skill 的命根子在 Skill.md 文件的最上面首先就是元数据即yml文件格式的 name 和 description前者是 Skill 的名称后者是大模型判断需要加载它时的场景他们用 --- 包裹起来。下面就是 Skill 的指令部分即做事的流程可以理解为某个领域、行业沉淀的经验和要求用来教大模型怎么更专业地做一件事情。在一次交互中Claude Code 只会把所有 Skill 的 name 和 description 发送给大模型里面的指令是只有当大模型根据 description 判断需要某个 Skill 时才会加载该 Skill 的指令。因此即便装了很多 Skill 也不会占用特别多的空间这就是 Skill 大名鼎鼎的按需加载也是它区别于纯 Prompt 的一大特征。2references 文件夹 —— 参考文献目录按需加载中的按需加载~这个文件夹里面放的主要是一些 md 文件格式的参考文献他经常是和 Skill.md 文件配合使用比如说在 Skill.md 文件中设置一些规则告诉大模型出现某些词、处于某些场景时就需要去 reference 里面找参考文献作为补充文档拼回 Prompt但是如果不出现这些情况这些参考文献就会老实呆在磁盘文件里面不会占用一个 Token。我们都知道 Skill.md 文件里面的指令部分是按需加载的那么 reference 就可以称之为按需加载中的按需加载了。3scripts 文件夹 —— 让确定性交给脚本代码不确定性交给大模型判断一个 Skill 的好坏一大标准就在于它有没有将确定性任务和不确定性任务区分开来。像字数统计、禁用词检查、格式合规检查等就是典型的确定性任务因为你有一套事先确定的标准简单来说就是可用 if-else 就进行判断的任务。而像概括一篇文章的主旨、判断一篇文章的 AI 味等跟语义理解相关的就是不确定性任务了因为这种任务往往没有一个标准答案是没办法用简单的 if-else 二分类就可以解决的。由此就引出了我们的 scripts 文件夹里面存的都是各种语言的代码脚本。他也往往和 Skill.md 文件配合使用比如在 Skill.md 文件中要求大模型执行到其中的某个步骤时就到 scripts 文件夹找到某个脚本执行检验这一步骤的结果如果返回 FAIL那么就重跑这一步骤直到 PASS 为止。需要注意的是 scripts 文件夹里面的文件一般也不会占用上下文任何一个 Token因为他一般来说只是用来执行的而不是读取的。4assets 文件夹 —— 技能所需的资源百宝箱这个文件夹就是存其它材料目录里面存放图标、模板、图片、字体等资源当 Skill 中涉及的流程需要使用一些外部资源时就会到这里面来找。3.Skill 的内部机理1Skills的调用流程流程一开始的时候用户会输入请求Claude Code会把用户请求连同所有的Skill的名称和描述一起发给大模型。注意这里只带了名称和描述也就是Skill的元数据层在接到用户请求和每个Skill名称和描述之后大模型会发现用户的请求可以使用会议总结助手这个Agent Skill来解决此时它就会把这个信息告诉Claude CodeClaude Code在接到大模型响应之后会去会议总结助手那个目录里读取完整的SKILL.md文件中的全部内容Claude Code会把用户请求和完整的Skill.md内容发给大模型大模型会根据Skill.md的要求来生成响应并把响应发给Claude CodeClaude Code会把这个响应发给用户上面的流程引出了Agent Skills的第一个核心机制按需加载。虽然Skill的名称和描述是始终对模型可见的但具体的指令内容也就是正文部分只有在这个Skill被选中之后才会被加载进来给模型看这就节省了很多的Token2渐进式披露Agent Skills的设计其实是一个精密的渐进式披露结构这个结构里一共有3层每一层的加载机制都不一样第1层元数据层。这里有所有Agent Skills的名称和描述它们是始终加载的相当于大模型里面的目录大模型每次回答前都会看一下这一层的信息然后决定用户的问题是否与某个Agent Skills相匹配第2层指令层。对于SKILL.md文件里面除了名称和描述之外其余的部分只有当大模型发现用户的问题与某个Agent Skills相匹配的时候它才会去加载这一层的内容所以我们称这一层为按需加载第3层资源层。这是最深的一层它一共是包含Reference和Script两方面的内容我们称它为按需中的按需加载Reference和Script的加载方式还不一样Reference是被读取的Claude Code会把对应文件的内容放到模型的上下文中以供回答时参考Script是被执行的Claude Code根本不会去看代码的内容它只关心代码的执行结果。当然这个也不是铁律如果你没有把代码的执行方法说清楚Claude Code还是有可能去通过看一下代码的毕竟跑不下去了嘛这样的话就会占用模型的上下文了三、安装 Skill 实操说来搞笑由于我之前使用 Claude Code 都是用的 IDEA、VSCode 和 Cursor 上面的插件以为跟那种原生的命令行Claude Code 不是一个东西就想当然地以为它们安装 Skill 的方式是不一样的结果导致我到处搜插件形式的 Claude Code 的 Skill 的安装教程却没找到想要的答案。最后才发现它们的 Skill 安装是通用的这些插件本质上只是能够让开发者通过编辑器更好的看到 Claude Code 开发时的代码变化。1.Skill 下载地址Skill 本质上就是一个文件夹它可以从很多的 Skill 仓库进行下载。例如 anthropics、openai、vercel-labs等等网上一搜一大把。2.下载方式直接把这仓库的 ZIP 压缩包下载下来我尝试了单独下载里面的一个 Skill 结果以失败告终看来只能都下了。在这个 skills 目录下找到我们需要的那个 Skill 文件夹以 pdf 举例。把目标 Skill 文件夹复制到到用户目录下的 .claude 文件夹只要你下载了Claude Code照理说就会有下的 skills 文件夹下没有这层文件夹就自己新建。这是全局 Skill 配置如果是项目 Skill 的话那就复制到项目目录下的 .claude 文件夹下的 skills 文件夹下同上没有就自己创建。输入 /plugin 查看当前安装的 Skill在 Installed 里面可以看见我们刚刚安装好的 pdf Skill。我在编辑器的 Claude Code 插件检验的时候发现没有生效现在还没有发现原因四、总结Skill 看起来只是一个文件夹加一份 Markdown朴素得几乎不像技术方案。但把它放回 Prompt → 工具调用 → MCP 这条线上位置就清楚了前三步一直在扩展模型的可达范围——能说、能做、能连上一切Skill 是第一次转向内部不再追问它还能做什么而是让它把该做的事做对。工具调用给了模型手MCP 给了它标准接口Skill 给的是手册。而手册最要紧的一点在于它不必由写代码的人来写。那些原本只活在某个人脑子里、每次对话都要现讲一遍的判断标准和流程默契第一次有了可以进 Git、被 review、随仓库分发的载体。团队真正的护城河从来不是接了多少工具而是知道该怎么用它们——Skill 让这部分知识第一次能被沉淀而不是被反复重述。不必一上手就设计什么体系。挑一件你这周已经向 AI 解释过三遍的事把它写成一个 Skill.md 提交上去。下一次它自己就知道该怎么做了——沉淀就是这么开始的。