最近几个月不管是在技术社区的讨论串里还是在各种 AI 相关的群里总能看到有人在晒自己的 Skill。有人把 Skill 传得到处都是有人靠整理别人的 Skill 攒了一波关注还有人一脸懵地问这东西不就是个 Prompt 吗换了个马甲我也算是从早期就开始折腾、踩过不少坑的人。这篇文章就是想一次性把话说清楚Skill 到底是什么它和 Prompt、Tool、Plugin 有什么区别内部结构长什么样以及最关键的——它到底好用在哪儿什么时候该用它、什么时候不该用。1. 先从为什么突然冒出来说起Skill 的诞生背景1.1 大家挂在嘴边的 Skill具体指哪个先对齐一下概念。现在大家口口相传的 Skill指的是 AI 助手 / Agent 领域里的一种能力封装形式把一组完成特定任务所需的指令、脚本、模板、参考资料打包成一个目录然后在模型需要时按需加载。说得再直白一点Skill 就是给大模型配备的一份岗位说明书 工具箱。模型本身是一个通才什么都能聊几句但聊归聊真要它按你的业务规范完成一份报告、处理一批数据、生成一套符合特定结构的文档它就不一定懂规矩了。Skill 的作用就是把这些规矩和干活的家伙什一起打包好放在模型伸手就能拿到的地方。这个概念的普及主要得益于 Anthropic 在 2025 年下半年正式推出的 Agent Skills 特性——把 Skill 作为一套公开、标准化的人机协作接口然后迅速席卷了整个 AI 开发生态。国内各大模型平台也在跟进推出了类似的能力模块。到现在Skill 已经不是某个厂商的专属名词而是整个行业对模型能力扩展这件事达成的一个共识形态。我见过很多朋友对 Skill 的第一反应是这不就是 Prompt 吗换个名字炒冷饭。 实话实说这个说法能理解但不准确。它和传统 Prompt 之间差了整整一个量级的工程化程度我们下面拆开说。1.2 它和 Prompt、Tool、Plugin差别到底在哪要搞懂 Skill最有效的方式就是对比。我把这三个容易混淆的概念放在一张表里先说结论概念本质加载方式擅长解决的问题典型代表Prompt纯文本指令每次对话都跟随上下文引导表达方式、角色设定、单轮问答规范角色扮演提示词、答题模板Tool / Function Call结构化函数接口预注册模型按需调用单次、明确的原子操作查天气、发请求、算结果天气 API、计算器、搜索Plugin运行时软件扩展安装到宿主程序常驻为宿主软件增加完整功能模块浏览器插件、编辑器插件Skill指令 资源 脚本 的组合包按需加载任务相关才激活多步骤、需要专业知识的完整工作流周报生成、代码审查、行业报告撰写这张表里最关键的差异有两点。第一Skill 是任务级的Tool 是操作级的。Tool 解决的是帮我调这个接口帮我把这个字符串转成 JSON这种单点动作Skill 解决的是从原始数据到最后一份像样的报告这种整条链路。一个 Skill 内部完全可以去调用多个 Tool它们是协作关系不是替代关系。第二Skill 带有按需加载的机制这对大模型的实用性是决定性的。常规的 Prompt 不管你需不需要只要有对话就跟着上下文走白白吃掉大量上下文窗口。而 Skill 的加载逻辑是模型根据用户当前的请求判断哪个 Skill 相关然后才去读取对应的指令和资源。不相关的时候它对模型来说就是不存在的、不占任何算力的。这两点加在一起才是 Skill突然火了的根本原因——它第一次让给大模型加装专业技能这件事变成了一种可标准化、可复用、可分享的工程产物。我们可以把 Skill 理解成模型世界的插件库里装好新工具不用的时候看不出来要用的时候随时调出来。2. 拆开壳子看本质一个 Skill 的内部结构2.1 SKILL.md那份给模型看的说明书任何一个 Skill无论简单复杂核心都离不开一个主文件SKILL.md。这个名字在 Anthropic 的规范里已经变成了事实标准各个平台的实现也都是照着这个范式来的。SKILL.md 的功能一句话总结就是让模型在需要的时候能快速搞清楚这个技能是干什么的、什么情况下用它、具体怎么用。它本质上是一份用 Markdown 写成的、面向模型读者的操作手册。一份合格的 SKILL.md 应该包含这么几个部分技能名称与一句话简述什么工具、什么能力、边界在哪适用场景描述什么类型的请求应该触发这个 Skill什么情况不该触发详细操作步骤从拿到输入到产出结果中间每一步怎么做、遵循什么规则输出格式规范报告结构、字段定义、命名规则、长度要求引用资源路径哪些脚本、模板、数据文件配套使用注意事项和禁区哪些事情绝对不能做容易出错的点注意一个细节这份文件不是给人看的文档是给模型看的行为规范。所以写作风格和传统技术文档差别很大——它需要的是极其明确、不产生歧义的祈使句而不是那种系统应具有较强的可扩展性之类的废话。模型不是收藏夹你写得太含糊它执行起来就放飞自我。这里分享一个我早期踩过的坑我第一版 Skill 的 SKILL.md 写得特别华丽背景意义、设计理念写了一大堆。结果实测的时候发现模型把大段背景当成输出内容的一部分生成的报告前面挂了一大段在当今快速发展的数字化时代...。后来我彻底重写把所有理念性的东西删掉只保留做什么、怎么做、别做什么、输出长什么样效果立竿见影——SKILL.md 是操作手册不是宣传稿。2.2 脚本和依赖资源真正干活的工具SKILL.md 解决的是模型知道该怎么做的问题但很多任务光靠模型空想是做不出来的。这时候就需要配套的资源文件。第一个类型是可执行脚本。比如你希望模型帮你整理一份数据报表模型的文本推理能力再强它也不会真的去跑本地程序。但如果你给它配套一个 Python 脚本把读数据、做统计、生成图表这种确定性工作交给脚本去执行模型只负责调度和最终的文字组织效率和准确率会高出一个量级。第二个类型是模板文件。比如某种特定格式的文档模板、Excel 表格模板、邮件回复模板。模型可以根据模板填充内容保证每次输出格式统一、符合团队规范。第三个类型是参考资料。比如一份技术规范文档、行业术语表、历史案例库。这些资料可以让模型在处理专业问题时有据可查而不是依赖它记忆里的模糊知识。我给这套结构取了个通俗的说法SKILL.md 是大脑脚本是手模板是规矩参考资料是知识库。四者配合才是一个真正能投入生产的 Skill。只有一个 SKILL.md 的 Skill 当然也能跑但它本质上还是在靠模型的自由发挥能力上限有限。2.3 一个 Skill 的标准目录长什么样说了这么多理论直接看一个真实的目录结构最直观。下面是我实际在用的一个会议纪要与行动项生成Skill 的目录meeting-minutes/ ├── SKILL.md # 技能主文件模型首先读取它 ├── scripts/ │ ├── extract_actions.py # 从纪要文本中抽取行动项和负责人 │ └── format_minutes.py # 生成规范格式的纪要 Markdown ├── templates/ │ ├── minutes_template.md # 纪要输出模板 │ └── action_tracker.csv # 行动项跟踪表模板 └── assets/ └── glossary.md # 公司内部术语和部门名称速查表这个结构有两点值得注意。第一脚本和模板要认真区分开。脚本是计算型的工具模板是格式型的约束两个混在一起会让 Skill 的可维护性变差。第二assets 目录平时看着没用但真到了处理跨部门、大量口述内容的任务时一份术语表能显著减少模型犯名不对人的错误。Skill 的执行时机模型怎么知道自己该用了还有一个有必要单独说明的机制Skill 是怎么被触发的。在实际的 Agent 系统中模型的请求处理流程大致是用户发出请求系统把所有可用 Skill 的简要描述名称 一句话功能说明提供给模型模型判断当前任务是否匹配某个 Skill匹配则加载该 Skill 的完整 SKILL.md进入技能模式执行不匹配则走普通对话流程所以这里有个潜在的问题Skill 的描述文字写得好不好直接决定了模型想不想得起来用它。描述太宽泛模型会老觉得什么任务都相关结果什么 Skill 都加载描述太狭窄模型该用的时候又想不起来。这个度我后面会专门讲怎么把握。3. 为什么这东西突然就火成这样3.1 从会聊天到会干活的质变很多人问大模型不是已经很能打了吗为什么还需要 Skill 这种东西答案是模型会聊天和会干活之间隔着一条巨大的鸿沟。聊天只需要知识、逻辑和表达干活除了这些还需要流程约束、工具调用、质量标准和行业规范。举个例子。让通用大模型写一份市场调研报告它能给你一份结构完整、语言流畅的文档把要素都涵盖到。但问题是这份报告无法保证是你老板要的那个格式无法保证引用的数据来自你指定的数据源无法保证结论符合你们部门一贯的分析框架。换句话说它做得像一份报告但做不出是这份报告。Skill 解决的就是这个是的问题。它把组织里的隐性知识——流程规范、输出模板、质量标准、参考案例——显性化地交给模型。模型不再是自由发挥的实习生而是一个上岗前读过你们部门全部作业规程的老员工。这个转变是质变从能聊变成能用。我见过最直观的一个例子发生在内容团队。以前让模型帮忙生成每周竞品分析产出的东西只能说能看后来把竞品分析的 Skill 封装好——指定了数据来源渠道、规定了分析框架产品动态、定价变化、市场动作、风险预警四个板块、固化了输出格式同一个模型产出的竞品报告质量判若两模。3.2 按需加载省的是 Token提的是精度Skill 火起来的第二个工程性原因是它的按需加载机制在成本和质量上同时带来了收益。先算成本账。做个最简单的数学题假设你给模型塞了 10 个领域的操作规范每个规范平均 2000 字总计 2 万字。如果全部作为 System Prompt 常驻那么每一轮对话无论用户问什么这 2 万字都要吃掉。按一个普通任务对话要交互 5 轮估算光这一项就多消耗 10 万字的 Token。而 Skill 机制下这 10 个规范只是以一句话简介的形式挂在系统里每个占不到 50 个字只有用户真正问到相关任务时对应的完整规范才会加载。两者一对比Token 消耗差了接近 40 倍。再算质量账。大模型领域有个经验规律上下文越长模型越容易迷失在中间。你把一堆无关指令塞在上下文里模型在生成时会受到这些无关文本的干扰尤其是当用户请求恰好和某段指令存在表面相关性时模型很容易被带偏。Skill 的按需加载保证了上下文里只出现当前任务真正需要的内容干扰项最少模型注意力最集中输出质量自然更稳定。我自己的实测数据是同一个代码审查任务用常驻超长 Prompt 的方案审查意见的有效率大约在七成改用 Skill 按需加载后有效率提升到了九成以上。这个提升幅度在工程上是极显著的。3.3 社区化分享好 Skill 是可以复制的第三个原因也是最容易被人忽视的Skill 的目录结构非常简单这使得它成为了一种可传播的最小知识单元。你想想以前的 Prompt 工程分享分享的是一段文字拿到手之后还要自己调试适配插件分享分享的是一个有完整代码库的软件项目上手门槛不低。而 Skill 呢它只是一个文件夹。里面有一份 Markdown 文档、几个可选的脚本和模板。拿到别人分享的 Skill解压就能用稍微改改就能适配自己的场景。这种极低的分发成本直接促成了社区生态的爆发。在 GitHub 和各种 AI 导航站上已经出现了大量仓库专门收集整理各类 Skill从周报生成到法律文书审阅从SQL 优化到小红书文案撰写覆盖了你能想到的几乎所有高频场景。很多人把自己的 Skill 开源出来其他人拿去直接跑、跑完反馈、再改进。这个过程让 Skill 的质量像开源软件一样滚雪球式地提升。我自己的体会是这个生态是目前 AI 应用层最有意思的地方——因为它让每个行业的隐性经验第一次有了一个标准化的表达和传播载体。这在以前是没有过的。4. 手把手教你写一个能用的 Skill4.1 先想清楚三件事边界、触发场景、输入输出很多朋友拿到 Skill 的第一步就是打开编辑器写目录文件这其实是错的。Skill 的设计工作80% 应该发生在动笔之前。动手之前先问自己三个问题第一这个 Skill 的边界是什么换句话说哪些任务归它管哪些任务不归它管。边界不清晰后面 SKILL.md 就写不明确模型就会乱触发。举个例子我做周报生成Skill 的时候边界就定为只负责从工作记录中生成周报文本不负责统计工时、不负责汇总考勤、不负责生成月报。边界画清楚模型在遇到边缘请求时才知道怎么拒绝。第二什么请求应该触发它这决定了 Skill 的描述文字怎么写。建议把触发场景从自然场景和显式场景两个维度都写清楚。自然场景就是用户描述自己的需求但没提 Skill 名字的情况比如用户说帮我把这周干的事整理成周报你的描述里就应该包含根据某时间段的工作记录整理周报这种话术显式场景就是用户直接说用周报技能生成这种情况只要技能名匹配就行。第三输入和输出分别是什么输入是原始材料——可能是用户粘贴的散乱文本可能是某个目录下的数据文件也可能是用户口述的零散信息。输出是最终产物——格式是什么、给谁看、长度多少。这个我想强调一点输出的定义一定要具体。一个反例是输出一份完整的周报一个正例是输出一份包含【本周工作】【数据指标】【问题与风险】【下周计划】四个板块、每个板块用三级标题开头、总字数控制在 800-1200 字的周报。4.2 SKILL.md 的关键写法指令要可执行设计想清楚之后才轮到写 SKILL.md。这里我分享几个经过反复验证的写法原则。第一个原则是写给聪明但没经验的新员工看。模型的能力很强但它对你公司的规矩一无所知。所以凡是涉及规范的地方都要假设对方是第一天上班。第二个原则是把判断标准写出来而不是只写要做什么。比如你只写检查报告中的数据是否准确模型不知道怎么才算准确如果你写报告中所有数据必须与 sources 目录下的原始数据表中的数值完全一致任何不一致必须先说明差异原因模型就知道该怎么执行了。第三个原则是给模型一个先做什么、再做什么的流程最好分步骤编号。步骤式的指令比一段式的指令执行稳定度高很多因为模型在处理多步骤任务时容易遗漏中间环节明确编号能显著缓解这个问题。这里放一个简化版的 SKILL.md 示例供参考# 周报生成技能 根据用户提供的工作日志生成符合团队规范的周报。 ## 适用场景 - 用户提供一周内的工作记录要求整理成周报 - 用户说帮我写周报整理下这周的工作 - 用户只提供零散信息需要补充上下文才会产出结论 ## 不适用场景 - 用户要求生成月报/季报用其他技能 - 用户只是询问周报格式问题不需要实际生成 ## 操作步骤 1. 读取用户提供的工作日志如果信息不足先提问补充不要编造工作内容 2. 按【本周工作】【数据指标】【问题与风险】【下周计划】四个板块组织内容 3. 本周工作中的每一项用动词 对象 结果的结构描述例如完成XX模块的接口开发已上线运行 4. 数据指标如有数字必须原文引用没有数字则写本期无量化数据 5. 输出前检查是否存在含糊表述是否存在未说明来源的数据 ## 输出格式 使用 Markdown四个板块用 ## 标题总字数控制在 800-1200 字。这个例子虽然精简但你能看出它的思路告诉模型什么时候用、不用、怎么做、做到什么标准。这就是一份合格 SKILL.md 的全部内核。4.3 配套脚本与参考资料在什么情况下值得加说了半天可能有朋友会问那我到底什么时候需要加脚本和参考资料我的判断标准很简单这个任务里有没有确定性工作。所谓确定性工作就是不需要模型发挥、但必须精确执行的部分算一个数值、转换一种格式、批量处理文件、从大量文本中抽取结构化字段。这类工作交给模型做又慢又容易错写一个脚本稳定可靠。举个例子我做过一个会议纪要生成的 Skill。最开始只有 SKILL.md模型需要把用户丢进来的对话记录整理成纪要。这个版本能跑但每次生成的行动项格式都不太一样有时候是张三负责完成 XX有时候是XX 需要由张三跟进。后来我加了一个简单的 Python 脚本先对原始对话做正则抽取把人名 动词短语这类结构标记出来再把结构化结果交给模型去组织语言。加了这一步之后行动项识别的准确性从大概 75% 提升到了 95% 以上。再说参考资料。什么时候加当一个任务涉及大量模型可能不知道的专有信息时就需要。比如你们公司内部的部门称呼、项目代号、常用的专业缩写。模型不可能知道这些全靠猜就容易出洋相。把这些信息整理成一份资料文件放进 Skill 目录模型在处理时就能参考。4.4 测试、迭代、发布别想一次写对Skill 写完之后直接投入使用是大忌。我的习惯是建一个专门的测试集至少包含 10-15 个典型输入覆盖这么几种情况正常输入用户明确表达了需求模糊输入用户没提 Skill 名字只说需求边界输入任务跟这个 Skill 沾点边但本质上该用别的能力错误输入输入内容根本不归这个 Skill 管每个输入跑一遍把输出记录下来对照自己预期的标准打分。三轮迭代之后整体通过率能到 80% 以上这个 Skill 才算能见人。迭代时最常修的问题是两类一类是 SKILL.md 里指令有歧义模型理解偏了另一类是描述写得不好导致该触发时不触发。修描述的时候有个小技巧把描述中跟别的 Skill 重叠的词删掉只保留区分度最高的特征词。比如你同时有周报生成和日报生成两个 Skill周报和日报这两个词就是最大区分点要保留而工作总结这种两个 Skill 都沾的词最好少用。5. 实践几个月后我总结的坑与经验5.1 依赖环境的坑Skill 里的脚本不是写了就能跑第一个坑几乎每个人都躲不过Skill 里的脚本依赖会翻车。我见过最典型的情况是一个 Skill 里的 Python 脚本依赖某个第三方库分享者在自己环境里跑得好好的别人拿到手一跑就报ModuleNotFoundError。更隐蔽的是版本冲突——A Skill 需要 pandas 1.5B Skill 需要 pandas 2.0两个一起装的时候必炸一个。解决方案有两个方向。第一个方向是在 SKILL.md 里明确写明依赖版本和安装命令让使用者自己处理。第二个方向更稳妥尽量让 Skill 里的脚本只依赖标准库或者把依赖封装成独立的可执行环境。我现在的习惯是凡是需要第三方库的脚本一律顺手附上一个requirements.txt并且在 SKILL.md 的前置条件里写明安装步骤。另外一个容易被忽视的问题是脚本入口的鲁棒性。模型调用脚本时不会像人一样传参那么规范有时候它会用错误的工作目录有时候它会传一个不存在的文件路径。所以脚本要尽量写成接受参数、有默认值、路径用绝对路径或者相对于 Skill 目录的路径。5.2 安全边界Skill 的权限不能是无限制的第二个坑关乎安全问题我强烈建议每个用 Skill 的人都要重视。Skill 里配套的脚本是有实际执行能力的它能读文件、能跑程序、可能的话还能发起网络请求。这就意味着一个设计不当的 Skill可能会让模型执行一些你意想不到的操作。尤其是当你从网上下载别人分享的 Skill 时你没法保证里面的脚本是完全可信的——一个看似无害的数据整理脚本里面可能藏着一行往你系统里写文件的代码。我的安全准则是这样的只在自己可控的环境里跑来源可信的 Skill。GitHub 上的热门 Skill 不是不能用来参考而是用之前一定要过一遍代码。Skill 的脚本默认采用最小权限。比如脚本只允许访问 Skill 目录内的文件需要通过配置明确授权才能访问外部路径。凡是涉及网络请求、系统命令执行的 Skill一律走白名单。宁可不方便也不能裸奔。这不是小题大做。AI 应用的安全问题跟传统软件不同——模型的行为逻辑是动态的它可能根据用户的某句话以你完全想不到的方式去调用技能里的脚本。安全边界提前设好比事后补救靠谱得多。5.3 什么时候不该用 Skill别拿大炮打蚊子Skill 是个好东西但不是所有任务都值得封装成 Skill。我的判断标准是看两个维度频率和复杂度。一个任务如果满足高频 中等以上复杂度 有明确流程规范那它是 Skill 的好候选反过来如果任务只是偶尔用一次或者简单到一句话 Prompt 就能说清楚强行封装成 Skill 就是画蛇添足——不仅开发成本不划算还挺占维护精力。我见过有人把帮我想几个公众号标题也做成了 Skill加了三个模板文件。这个任务本身一两个 Prompt 就能搞定封装成 Skill 之后反而要维护模板、调试输出纯属自我感动。Skill 的价值在于沉淀复杂流程而不是把所有操作都目录化。另外还有一个不该用的场景你的任务需要实时、动态的外部信息。Skill 本质上是静态的规则 静态的脚本如果任务严重依赖实时市场数据、实时价格行情这类外部变量Skill 只能做到把获取数据的逻辑封装好真正能不能跑到准确数据还得看底层的工具链。这时候别指望 Skill 解决一切把它当作流程的一部分就好。5.4 上线之后还要做评估Skill 不是写完就完了最后这点可能是最容易被忽视的Skill 上线之后需要持续评估。很多人把 Skill 写完、测试通过、发到社区就觉得任务结束了。但实际用起来你会发现随着模型版本的更新、使用场景的变化Skill 的表现会慢慢漂移。上一代模型按照你的指令执行得稳稳当当换了新一代模型之后可能同样的话术它就开始自作主张了。所以我现在的习惯是每个关键 Skill 配一个简单的效果台账。每次使用后记录一下输出是否达标、失败的原因是什么、是模型理解偏了还是脚本出错了。攒到一定量之后定期回去翻翻针对高频失败场景做针对性修正。另外建议关注 Skill 的触发率。如果某个 Skill 装了半年触发率极低说明要么描述文字写得让模型想不起来要么这个场景根本用不上力很可能需要重新审视这个 Skill 到底有没有存在价值。最后分享一条我个人的体会。Skill 这个概念本质上并不复杂——它就是把我们平时教人做事的那套东西——规范、流程、工具、资料——系统地交给模型。它的门槛不在技术上而在你有没有把一件事想清楚你到底希望模型按什么样的规则来干活。这个想清楚了Skill 就是水到渠成的事想不清楚再好的工具也白搭。我自己的做法是每做一个 Skill 之前先自己在纸上把流程写一遍写完再看看哪些环节是模型必须遵守的硬规则哪些交给它自由发挥。这样下来的 Skill基本都能得很好的使用反馈。