最近不管是在技术社群还是朋友圈总能看到有人在聊 Skill。一会儿是Claude 的技能又更新了一会儿是这个 Skill 也太好用了吧甚至还有不少人在分享自己写的 Skill。说实话我第一次看到这个词的时候也是一愣Skill 到底是啥是提示词是插件还是又一轮 AI 圈的概念炒作带着这个疑问我花了一段时间去扒官方文档、看社区案例自己也动手写了几个 Skill 用在实际项目里。这篇文章就是把我的理解、踩过的坑、和一些实操心得一次性讲清楚。读完你至少能搞明白三件事Skill 是什么、它解决了什么问题、以及怎么自己动手做一个能真正跑起来的 Skill。1. Skill 到底是个啥从AI 会聊天到AI 会干活1.1 一句话定义外加一个生活类比先给个直接的定义Skill技能是一种把怎么做好某件事的完整方法打包起来让 AI 在需要的时候自主加载和执行的模块。它通常包含一份说明文件比如 SKILL.md、必要的脚本或资源文件以及可选的验证脚本。AI 在执行相关任务时会先读取说明按说明调用脚本、处理数据、完成整个工作流。这个概念听起来可能有点抽象但类比一下就很好懂。你去一家新公司入职光靠一腔热情肯定没法直接上手干活。你得先拿到一份《岗位手册》里面写着你是做什么的、具体流程是什么、遇到什么情况该怎么处理、有哪些工具可以用。然后你对照手册调用公司已有的系统、工具一步步完成工作。Skill 在 AI 世界里的角色就是这份岗位手册。换句话说没有 Skill 的 AI 像一个什么都知道一点但从没上过手的实习生。它有知识、有常识但你让它把这份文档整理成标准化周报或者批量压缩图片并生成预览图它就容易卡壳不是不知道周报长啥样而是不知道你的团队周报格式是什么、压缩到什么尺寸、要不要保留 EXIF 信息。Skill 把这些经验变成了一份可执行的操作规范AI 照着做就行。1.2 拆开看一个 Skill 包里面到底有什么如果你打开一个实际发布出来的 Skill 项目通常会看到这样的目录结构skill-name/ ├── SKILL.md # 技能说明书AI 最先读的文件 ├── scripts/ # 可执行脚本Python、Shell、JS 等 │ ├── main.py │ └── helper.py ├── assets/ # 静态资源比如模板、参考样本 │ └── template.md └── tests/ # 验证脚本用于确认技能可用 └── test_main.py这里面最核心的就是SKILL.md。它通常分为两个部分文件头部的元信息YAML 格式以及正文的操作指引。元信息里最关键的是name和description前者是这个技能的唯一标识后者描述了什么时候该用这个技能。正文则是具体的操作步骤、使用约束、示例输入输出等。为什么这玩意儿现在这么受关注因为过去做 AI 应用我们是把流程写死在代码里的。你告诉模型你是客服它就只能当客服想让它改改话术还得动代码。Skill 把知识、规则、工具调用组合成了一个自包含的模块模型在运行中根据用户请求按需加载对应的技能。这就让同一套模型昨天能处理合同审核今天能处理数据分析明天还能帮你生成合规的财务报表——不需要改模型只需要换不同的 Skill。1.3 Skill 和 Prompt、Plugin、MCP 到底啥关系这是很多人搞混的地方。我当时也是绕了半天才理清这里直接给你做一个对照表名称本质特点类比Prompt / 提示词给模型的指令文本一次性、不可复用、每次都随请求发送口头交代任务Skill结构化技能包说明脚本资源按需加载、可复用、可验证、可分享岗位手册 工具箱Plugin / 插件外部功能扩展通常带 UI 或 API偏应用层面用户手动触发或自动触发给软件装上的新功能模块MCPModel Context Protocol标准化协议连接模型与外部数据/工具专注于连接解决的是工具调用通道USB 接口协议这么说吧Prompt 是跟 AI 说该怎么做Plugin 是帮 AI 加一个它本来没有的功能MCP 是打通 AI 和外部系统之间的通道而 Skill 是把怎么做一件事的经验结构化打包让 AI 自主调用。Skill 和 MCP 不是替代关系反而是协作关系。一个 Skill 在处理流程中完全可以调用 MCP 提供的工具去读写数据库、操作浏览器、获取外部 API 数据。Skill 管的是怎么一步步完成MCP 管的是每一步能用什么外部能力。所以说Skill 不是新瓶装旧酒而是在 Prompt 和工具之上又加了一层组织调度。2. 为啥大家都在用Skill 解决的真实痛点2.1 大模型最大的尴尬知道不等于做到先说一个所有 AI 重度用户都会遇到的尴尬场景。你去问 ChatGPT 或者 Claude如何用 Python 批量压缩文件夹里的图片它可以给你写出一段非常完美的代码甚至还能解释每一步的原理。但如果你让它直接把这个文件夹里的 2000 张图片全部压成 1280px 宽、质量 80、保持目录结构、输出到另一个文件夹它就犹豫了它先要确认你有没有安装 Pillow再想办法找到你的文件夹路径还得考虑覆盖策略、异常处理、进度反馈……这一系列问题恰恰是从知道到做到之间的巨大鸿沟。传统 Prompt 工程试图靠把要求写得足够详细来跨越这个鸿沟但效果有限。因为提示词是一次性的你每次都要重新描述所有约束。更麻烦的是提示词没有验证能力模型说我处理完了你根本没法确认它是否真的按你的标准处理了。Skill 的出现本质上就是把知道变成做到的桥梁。它将一个任务的完整执行流程固化下来包括脚本、参数、边界条件、失败处理甚至验证方式。模型不再需要现场临场发挥只需要读取一份写得足够清晰的说明书照着执行就好。这种思路很像工厂里的标准作业程序SOP但不同的是Skill 不只是给人看的文档而是同时给人审阅、给模型执行的活文件。2.2 Skill 的三个核心价值可复用、可验证、可分享先说可复用。你写过一个生成周报的 Skill下次新来一个同事或者你换了台电脑、换了 AI 工具只要把这个文件夹复制过去就又能用。这不像 Prompt每次都要重新复制粘贴一大段话也不像传统的自动化脚本别人拿过去不知道怎么用、什么时候用、改哪里。然后是可验证。Skill 可以附带验证脚本。比如你做了一个文档翻译的技能它不只给出翻译结果还会跑一遍翻译质量的检查脚本看看有没有漏翻术语、格式是否完整。这意味着你可以在发布技能之前先做一轮自动化验收不通过就不让上。这种带测试的提示词工程一下子让 AI 应用从玄学调参走向了工程化。再说可分享。因为 Skill 是文件夹形式天然适合用 Git 管理也适合在社区分发。现在很多官方社区和应用商店里已经出现了一堆现成技能从图像批量抠图到SQL 优化助手再到项目复盘报告生成器都有。你不需要从零写拿来改改就能用。这很像早期 WordPress 的插件生态——一个功能一个插件全世界的人都能安装。Skill 做的就是把这种生态复制到了 AI 应用层。2.3 哪些场景真的值得上 Skill不是所有任务都适合做 Skill。我的经验是满足反复做、流程长、标准明确这三个条件的任务最适合。举几个典型的例子。第一类是内容生成类日报周报、会议纪要、项目复盘、Release Notes。这类任务每个公司都有自己的格式和风格要求且是高频重复劳动非常适合固化成 Skill。第二类是数据处理类批量改图片尺寸、CSV 清洗、JSON 转 Excel、日志归类。这类任务依赖脚本执行Skill 刚好把解释需求和执行脚本结合起来。第三类是专业领域操作类比如代码审查、数据库索引优化、合规检查。这类任务不仅要求 AI 具备某领域的知识还要求它按特定流程执行Skill 里的规则和检查清单就派上了用场。不适合的呢纯闲聊、一次性创意思考、或者需求每天都变的任务做 Skill 就是在浪费时间。因为 Skill 的优势在于标准化如果一个任务本身无法标准化你花在维护技能上的时间会超过直接对话干活的时间。记住这个判断标准你就能避免为了技能而技能的陷阱。3. 手把手做一个 Skill从零到能跑3.1 场景选择别一上来就搞复杂的我第一次做 Skill 的时候就犯了一个典型错误想做一个全能项目管理助手结果又是写甘特图又是接日历又是做风险预警搞了整整一天最后模型调用的时候频频出错根本没法用。后来我学乖了先挑一个简单、边界清晰的任务练手。这里我以**批量压缩图片并生成缩略图**为例完整演示一遍。选择这个场景有两个好处第一它逻辑非常明确输入是文件夹路径输出是处理后的图片目录第二它强依赖脚本执行能充分体现 Skill 和纯 Prompt 的差异。你需要先想清楚几个问题图片压到多宽质量参数是多少保留原文件名还是加后缀输出到原目录还是新目录是否处理子目录这些需求不明确后面写描述和脚本都会很痛苦。所以我建议你做任何 Skill 之前先在文档里写一段需求声明哪怕只有三五行也能帮你省掉大量返工时间。3.2 目录结构与文件规范确定好场景后我们先建立目录结构。按照当前社区比较公认的规范来image-compressor/ ├── SKILL.md └── scripts/ └── compress_images.py如果你后面还需要模板或者测试文件可以继续添加assets/和tests/目录。但第一次做能简单就简单。目录命名要全小写用连字符分隔单词不要用空格或下划线。这个细节容易被忽略但很多加载器对目录名有约定命名不合规可能导致技能无法被正确识别。给个建议每个 Skill 文件夹都要自包含。什么意思就是你不要依赖另一个 Skill 里的文件或全局安装的某个特定终端配置。别人把这个文件夹拷走在任何标准环境里都能用这才是合格的技能包。3.3 写 SKILL.md决定生死的描述和指令SKILL.md 是整个 Skill 的灵魂。模型什么时候调用它取决于描述模型怎么调用它的逻辑取决于指令正文。先看一个我实际用过的简化版本--- name: image-compressor description: 批量压缩图片并生成缩略图。当用户提供图片文件夹路径、希望减小图片体积、 需要调整图片尺寸或将图片批量转换为 WebP/JPEG 格式时使用。 不要用于单张图片裁剪也不要用于图片内容识别或 OCR。 --- # 图片批量压缩与缩略图生成 ## 适用场景 - 用户有一个包含大量图片的目录需要统一压缩或调整尺寸。 - 需要将图片转换为指定格式并保留原始目录结构。 ## 执行步骤 1. 使用 python3 scripts/compress_images.py --input 输入目录 --output 输出目录 --width 1280 --quality 80 2. 脚本执行完毕输出统计信息须向用户说明处理了多少张图片、总节省空间、输出位置。 3. 若脚本返回非零退出码把错误信息原文展示给用户不要自行掩盖。 ## 约束 - 始终保留原始文件不原地覆盖。 - 输出目录不存在时脚本自动创建。 - 不要处理超过 500MB 的目录如需处理先询问用户。写这个文件有几个关键点。第一description里要写清楚什么时候用同时写明什么时候不要用。很多人觉得描述越全越好其实不是。描述的作用是帮模型做意图匹配说得太泛模型会在不该用的时候调用说得太窄模型该用的时候又想不到。第二步骤指令要写得像给一个靠谱实习生看的 SOP而不是给 AI 写作文。每一条都要直指动作包含具体的命令、参数、成功标准。我见过不少 SKILL.md 写得像产品宣传稿什么本技能旨在赋能用户……全是废话。模型讀起来也懵。第三命令要写完整路径前缀。scripts/compress_images.py前面不用加./但在脚本内部要用相对路径时要格外小心。因为模型执行命令时的工作目录可能跟你写说明时假设的不一样。这问题我踩过后面在避坑部分细说。3.4 辅助脚本与依赖有了说明文件还得有真正的执行者。写一个 Python 脚本来完成压缩工作。为了减少依赖我直接用 Pillow 库。在项目里加一个requirements.txt里面写上pillow。#!/usr/bin/env python3 批量压缩图片并根据参数调整宽度。 用法: python3 compress_images.py --input dir --output dir --width 1280 --quality 80 import argparse import os from pathlib import Path from PIL import Image SUPPORTED_EXTS {.jpg, .jpeg, .png, .bmp, .tiff, .webp} def compress_images(input_dir: str, output_dir: str, width: int, quality: int): input_path Path(input_dir) output_path Path(output_dir) if not input_path.exists(): raise SystemExit(f输入目录不存在: {input_path}) total_files 0 total_saved 0 errors [] for img_path in input_path.rglob(*): if img_path.suffix.lower() not in SUPPORTED_EXTS: continue relative img_path.relative_to(input_path) target output_path / relative.with_suffix(.jpg) target.parent.mkdir(parentsTrue, exist_okTrue) original_size img_path.stat().st_size try: with Image.open(img_path) as im: # 转换颜色模式RGBA/P 模式先转 RGB否则存成 JPEG 会报错 if im.mode in (RGBA, P, LA): im im.convert(RGB) # 如果原图本身小于目标宽度不放大 if im.width width: h int(im.height * width / im.width) im im.resize((width, h), Image.LANCZOS) im.save(target, JPEG, qualityquality, optimizeTrue) except Exception as e: errors.append(f{img_path}: {e}) continue new_size target.stat().st_size total_saved original_size - new_size total_files 1 print(f处理完成: {total_files} 张图片) print(f节省空间: {total_saved / 1024 / 1024:.2f} MB) if errors: print(f失败文件: {len(errors)} 个) for err in errors[:20]: print(err) if __name__ __main__: parser argparse.ArgumentParser(description批量压缩图片) parser.add_argument(--input, requiredTrue, help输入目录) parser.add_argument(--output, requiredTrue, help输出目录) parser.add_argument(--width, typeint, default1280, help目标宽度) parser.add_argument(--quality, typeint, default80, helpJPEG 质量) args parser.parse_args() compress_images(args.input, args.output, args.width, args.quality)这个脚本不复杂但有几个细节值得注意。一是rglob(*)递归遍历所有子文件夹这样可以处理多层目录结构。二是Image.LANCZOS重采样方式比默认的NEAREST效果好得多缩略图边缘不会有锯齿。三是 RGBA/P 模式转 RGB这是 JPEG 格式的限制。如果你不转透明背景的 PNG 在保存成 JPG 时会直接抛异常。四是optimizeTrue参数它让 Pillow 在保存时做一遍优化虽然速度慢点压缩率会好不少。关于要不要输出到原目录这个问题我建议一律输出到新目录。原地覆盖太危险了一旦压缩参数不满意原始文件又没了哭都来不及。3.5 验证脚本怎么写验证脚本不是强制的但我强烈建议加。它的作用是在你发布或更新一个 Skill 后快速确认说明文件和脚本没有互相矛盾。拿上面的例子来说你可以准备一个包含三种不同格式图片的测试目录然后跑一遍验证脚本检查输出目录里的文件数量、格式、宽度是否符合预期。验证脚本不要求很复杂能覆盖核心路径就行。我一般用 Python 写逻辑就是建临时目录生成测试图片调用目标脚本断言输出结果。实测下来这个习惯能帮你避免很多低级错误。有一次我更新了描述里的参数却忘了更新脚本的默认值要是没有验证脚本模型就会被说明书误导传一个脚本不认识的参数进去。3.6 把 Skill 装到本地工具里并实际调用写完之后怎么用如果你在用 Claude Code 或类似支持 Agent Skills 的工具流程很简单把image-compressor文件夹放到指定的技能目录比如~/.claude/skills/或者在项目根目录下建.claude/skills/放进去。然后你可以直接输入/skills看到已加载的技能列表再给模型一个自然语言请求比如把 test_images 文件夹里的所有图压缩一下输出到 compressed_images。模型会先读取 SKILL.md匹配description然后按正文里的执行步骤运行脚本。你不需要手动告诉它先读取脚本再执行说明文件会引导它。如果用的是其他平台或者自研 Agent加载方式可能不同但原理一致给 Agent 一份 Skill 清单让它按需加载。关键点是测试的时候你要多试几种说法。比如图片太大了帮我压一压和把图片统一处理成适合网页展示的尺寸两种说法都应该能触发同一个 Skill。如果你的描述写得太生硬模型有一定概率匹配不上。4. 常见问题与避坑指南4.1 模型死活不调用我的 Skill这是最让人抓狂的问题Skill 文件写得没毛病脚本也能跑但模型就是不用。问题基本出在description上。我见过三种典型情况。第一描述太泛。比如这个技能处理图片——模型根本不知道什么时候算处理图片是有压缩需求裁剪需求还是调色需求第二描述太窄。你只写了批量压缩没写减小体积节省存储空间用户实际说的是别的同义词模型自然联想不到。第三描述里没有排除场景。你不写不要用于单张裁剪模型就会在用户想裁一张头像时也强行走你这个技能。优化方向很明确用用户实际会说的说法来覆盖触发条件同时明确写出不适用范围。建议你把描述写好后自己先模拟十种不同的用户表达看看模型能不能正确触发。4.2 说明文件和工作目录不一致很多 Skill 翻车都翻在这个隐蔽的地方。比如你在 SKILL.md 里写了python3 scripts/compress_images.py --input xxx但模型执行时的工作目录可能不在 Skill 目录下它就会报文件不存在。我一开始以为是模型不够聪明后来发现是规范问题SKILL.md 里的命令应该用绝对路径或者用统一的变量引用技能目录。部分平台加载 Skill 时会注入一个环境变量或前缀标识当前技能目录你要查阅对应文档确保命令用的是技能目录下的 scripts而不是当前工作目录下的 scripts。另外一个相关问题是脚本内部的相对路径。比如脚本要把临时文件写到./tmp实际上它会写到模型当前的工作目录而不是技能目录。正确做法是在脚本里根据__file__计算绝对位置或者把输出路径作为参数传进去。4.3 脚本跑起来了但结果不符合预期脚本没报错但输出质量不行。这种情况我一般先查三个地方。第一参数默认值是否合理。比如压缩质量设成 95那几乎不压缩用户的感觉就是你没干活。第二有没有处理边缘格式。不要假设所有人都只用 JPGPNG、WebP、HEIC 都是现实世界会出现的格式。第三是否静默失败。很多脚本出错时只打印一行错误然后继续跑最后用户只看到一个完成却不知道有一半文件失败了。我建议脚本要做得话痨一点每完成一个阶段输出进度失败时列出失败原因结束的时候输出汇总统计。AI 拿到这些信息才能向用户说明到底发生了什么。记住Skill 执行过程中模型需要依据脚本输出向用户汇报输出越结构化汇报越准确。4.4 安全和权限怎么控制Skill 的本质是让 AI 执行脚本这就意味着你给了一个 AI 调用系统命令的入口。如果你从网上下载了一个来路不明的 Skill它完全可以在脚本里做任何事包括读你的私钥、上传数据到第三方服务器。这跟随便运行 GitHub 上的代码是一个风险级别甚至更高因为模型会按说明书很自然地帮你执行你甚至来不及审查。我的建议是第一只从可信来源下载 Skill。第二下载后逐行读脚本看不懂的脚本坚决不用。第三尽量让 Skill 工作在一个隔离的环境里比如容器、独立的低权限用户或者至少限制网络访问。第四自己用的 Skill 不要硬编码敏感信息进脚本。如果必须用 API Key通过环境变量注入而不是写在文件里。4.5 Skill、MCP、Plugin 到底怎么选很多刚开始接触的人会纠结学了 Skill还用不用 MCP我的看法是它们解决的是不同层面的问题。如果你的核心诉求是把外部数据源、第三方系统接到 AI 上比如让 AI 能查数据库、操作你的 CRM那 MCP 是更合适的方案因为它本身就是为连接而生的标准协议。如果你的诉求是把一套反复要用的工作流程固化下来不管输入端来自 MCP 还是普通文件还是用户手动粘贴的内容Skill 都更适合。当然成熟的项目往往是混合的。Skill 做流程编排MCP 做工具调用。比如你的 Skill 里要求查一下 CRM 里这个客户的最近订单记录那就可以通过 MCP 调 CRM 接口。这种组合已经成为目前 AI 工程化落地的主流形态以后只会越来越常见。以上就是我做 Skill 这段时间以来积累的全部核心经验。如果只让我留一句话那就是Skill 的本质不是给 AI 更多知识而是给 AI 一套可以照着执行的作业手册。写的时候多想想那个刚入职的靠谱实习生到底需要什么信息才能独立干活你的 Skill 就好用了。我前前后后写了十几个技能真正留下来天天在用的也就三四个但这三四个节省的时间远超我写它们花掉的时间。如果你最近也在研究这玩意儿别光看文章自己去写一个试试哪怕只是把每天都要做的某个重复动作固化成一个十行脚本的 Skill你也能立刻感受到它和普通提示词之间那条清晰的界线。