1. 先搞清楚：Skill 到底是什么，为什么它能"教会" Claude Code 做视频
过去一个月，我把代码托管平台上能搜到的 Claude Code Skill 几乎翻了一遍，去重、筛掉空壳项目之后，整理出 180 个能实际使用的开源 Skill。分类盘点的过程中有个数字特别扎眼：其中 107 个星标不到 50，属于典型的长尾冷门区。但真正让我觉得"这套机制值得认真聊聊"的，是这些 Skill 里有一批把视频制作链路做得极其专业的小项目——它们能让 Claude Code 从一个擅长写代码的助手，变成一个能独立完成脚本、分镜、配音、剪辑、字幕、封面全流程的"视频小作坊"。
如果你还没搞懂 Skill 是什么，很容易把这篇内容理解成"又一个收藏夹清单"。所以我先把最核心的机制讲透，后面那些分类、宝藏、实操才会有落点。
1.1 Skill 文件夹里到底装着什么
Skill 不是一段提示词，它本质上是一个文件夹。一个标准的 Skill 目录里，核心文件叫SKILL.md，顶部用 YAML 写两个关键字段：name和description。description是模型判断"当前任务要不要加载这个 Skill"的依据；正文则是加载之后要照着执行的操作手册。这个目录里还可以放references（参考资料）、scripts（辅助脚本）、examples（示例输出）这些可选子目录。
用生活里的事类比一下：这就像给一个很聪明但没做过饭的实习生，在关键时刻递上一本你们店自己的出餐手册。他看完整本手册也不会变成米其林主厨，但他端出来的菜至少符合你们店的流程、口味和摆盘标准。Skill 做的就是这个事——它不教 Claude Code"通用知识"，而是把你所在领域的操作规范和踩坑经验，变成它能在关键时刻翻开的活页夹。
1.2 它和系统提示词、脚本插件的边界在哪里
很多人容易把 Skill 理解成"高级提示词"，这话对了一半。提示词是每次对话都要带进上下文的一段文字，无论用不用得上都在占 token；Skill 是按需加载的——只有当任务描述和它的description对得上时，模型才会把这份 SOP 注入当前上下文。这决定了 Skill 在长流程、多步骤任务里特别划算：你不用在每次对话里都背一遍所有领域的知识，而是让模型在需要的瞬间"翻到对应那页"。
Skill 和普通脚本的边界也很清楚：普通脚本是"死"的，你写死什么它执行什么，遇到意外情况不会变通；Skill 是"活"的，它给模型一套步骤和判断标准，再由模型去调用命令行工具、读写文件、根据中间结果调整下一步。简单说，Skill 负责教模型"该怎么做"以及"什么时候这么做"，真正执行脏活累活的是它调起的命令和工具。
1.3 制作视频为什么是最适合讲透 Skill 的场景
我做这次盘点的出发点就是视频。原因很朴素：视频制作是典型的多阶段、多专业复合流程——选题、写脚本、分镜、生成素材、配音、剪辑、加字幕、出封面、按平台规范导出，每一步都有行业知识门槛。而 Claude Code 天生就能读写文件、执行命令，这正是视频工程的土壤。它缺的从来不是执行能力，而是专业流程知识；Skill 补的恰恰是这个缺口。
拿 FFmpeg 举例：让模型凭空写一条竖屏视频转码命令，它大概率能写出来，但参数未必适合分发，可能漏了兼容性设置，可能不考虑黑边问题。可如果有一份 Skill 在触发时告诉它："竖屏统一 1080x1920、编码用 H.264、像素格式必须 yuv420p、画面裁切按这个公式处理"，那产出的结果就完全是另一回事了。这也是我下面要把 180 个 Skill 拆开给你看的原因：分类不是目的，搞清楚哪些 Skill 能帮你把一条链路完整串起来，才是目的。
2. 我盘到的 180 个开源 Skill 长什么样：九个类目一次看全
2.1 我的盘点口径：180 个是怎么筛出来的
先说清楚统计口径，免得你觉得这个数字是拍脑袋来的。我这次沿着公开仓库、技术讨论帖、个人维护的文档库做了收集，筛选标准有三条：目录结构完整且有SKILL.md、描述和正文内容一致、不是复制粘贴的占位项目。去重之后最终留下 180 个。按星标数量排序，73 个在 50 星以上，剩下 107 个全部低于 50 星——这个分布本身就很有意思，后面专门用一节讲。
必须诚实承认，这份清单肯定不是全网完整全集。Skill 生态更新太快，今天搜到的项目明天可能就重构了。但作为一个横截面，它足够代表"开源 Claude Code Skill"目前的主流分布，也足够支撑下面的分类判断。
2.2 九个类目一览
我按用途把这 180 个 Skill 分成了九组，它们分别解决不同场景的问题：
| 类目 | 它解决什么问题 | 盘点中常见的形态 |
|---|---|---|
| 视频与媒体处理 | 剪辑、转码、字幕、音频清理 | FFmpeg 命令模板、字幕样式方案、批处理脚本 |
| 文案与脚本创作 | 选题、口播稿、宣传文案、脚本结构 | 带框架的写作模板、钩子结构提示 |
| 图像与设计 | 封面、配图、抠图、参数调整 | 绘图提示词模板、参数清单、校验步骤 |
| 数据分析与复盘 | 播放数据整理、效果对比、报告生成 | 数据抓取脚本配合汇总表格流程 |
| 文档与研究 | 资料综述、结构化笔记、引用整理 | 摘要模板、信息核查步骤 |
| 编程与工程 | 调试、重构、写测试、代码审查 | 分支流程、命令清单、回归检查 |
| 部署与运维 | 环境配置、容器、CI 流程 | 检查清单和回滚方案 |
| 效率与生活 | 日程、邮件、会议记录整理 | 模板化处理流程 |
| 知识管理 | 笔记关联、周报生成、信息归档 | 整理规则加输出格式 |
表格只能看出分布，真正需要展开的是和视频制作直接相关的几类，因为它们才是"让 Claude Code 学会做视频"的主力军。
2.3 视频制作链路里最值得优先收藏的几类
最值得单独说的是媒体处理类。这类 Skill 的价值在于把 FFmpeg 里那些又长又容易写错的参数固化成了模板。你自己写命令时，翻文档、试参数可能要半小时；而一份好的媒体处理 Skill 会直接给你一条能跑的完整命令，还告诉你为什么必须加-pix_fmt yuv420p（为了播放器兼容）、为什么竖屏要按scale + force_original_aspect_ratio + crop处理（为了不留黑边）。这些都是普通文档里不会讲透的细节。
其次是脚本创作类。这类 Skill 表面看只是写作模板，但它在视频链路里的作用被严重低估。口播视频有没有钩子、论证和行动号召之间的节奏怎么铺，直接决定完播率。把"钩子-论证-行动号召"固化成模板后，Claude Code 每次写的脚本结构都会稳定，你只需要做内容层面的微调，而不是每次都重新调教它的语气。
素材生成类和复盘类也值得提一下。素材生成类一般负责把一块纯色背景变成可用的标题卡，或者按分镜表自动生成一整排绘图提示词，省去大量重复沟通；复盘类则负责把播放数据拉下来整理成表格。很多人只盯着"做视频"那一下，忽略了"做完之后怎么迭代"，而复盘类 Skill 恰好补齐了这条闭环。
3. 73 个高热度之外的 107 个低星宝藏：我怎么挑、怎么用
3.1 为什么星标低不等于质量差
星标反映的是"当时有多少人刚好需要这个项目"，不代表"这个项目做得有多好"。我在盘点里看到一个很典型的规律：73 个高星项目里，一半以上是综合合集、框架类项目，覆盖面广但每个场景都不深；真正在小场景里死磕、把参数调好、把坑都踩过一遍的项目，反而因为名字难搜、作者不宣传、解决的问题太小众，安安静静躺在低星区。
打个比方，一个 3 星的 Skill，很可能就是某个人给自己团队的月度视频流程写的。里面包含他失败过 20 次的全部参数修正、他们团队内容风格的完整约定、还有针对输出格式的专门适配。他没做任何推广，你搜不到很正常，搜到就是捡到宝。所以我从来不以星标作为第一筛选条件，而是先看内容本身。
3.2 四个"认货"的硬指标
这 107 个低星项目里确实也有不少浑水摸鱼的，所以判断"宝藏"不能只靠运气。我给自己定了四个硬指标。
第一，说明文档写得像不像"过来人的操作手册"。好的SKILL.md会在description里写清楚具体触发场景，正文有编号步骤、有示例命令、甚至有一两个常见错误的处理说明；差的通常只有一句"帮助做视频"这种废话。第二，有没有防呆细节。比如是否要求自动创建输出目录、文件名是否带日期、失败时是否给出排查命令。第三，依赖是否收敛。好的低星 Skill 尽量只依赖 FFmpeg 这类常见工具，而不是让你先装一套十几个服务的环境。第四，有没有"活"的痕迹。星标少不要紧，但最近半年还在更新、有人提 issue 会回复，基本可以确定是活项目。
3.3 我反复使用的四类冷门形态
按这四个指标过完，我手里低星但好用的 Skill 大致是四种形态。
第一种是单点深入型，只解决一件事，比如"把长视频按静音段自动切成竖屏切片并加字幕"。它不追求覆盖全流程，但这一件事做得非常彻底，核心命令打磨了好几轮。第二种是平台适配型，针对某个视频平台的规格做了一套完整转码参数。读它的SKILL.md等于白捡一份参数手册，比平台帮助中心的表格还好用。第三种是工作流缝合型，它自己不直接产视频，而是把脚本、分镜、素材清单、剪辑草稿串成一条链。我用它的时候，相当于拿到一份可以随时铺开的生产线。第四种是脏活复盘型，把播放数据拉下来做成汇总表。高星项目通常不屑于做这种活，反而是小星项目做得认真。
3.4 找小星好货的三个渠道套路
这批低星宝藏不是靠运气撞出来的，我有固定的搜索套路。首先，搜关键词别总用"Skill"和"Claude"这种大词，要换成场景词，比如 "subtitles"、"ffmpeg"、"b-roll"、"video script" 这类具体需求词，命中率会高很多。其次，顺着高星项目往下游找，很多高星项目都有大量派生版本，这些派生版本往往在原作者基础上针对具体业务做了改进，问题是很少有人会给它们单独宣传。最后，用更新时间排序而不是星标排序，很多新发布的优质 Skill 星标还没涨起来，内容却已经完整了。
另外还有一个隐蔽渠道：在技术讨论区搜"求某功能怎么做"的帖子，评论区经常有人提到"我写了个现成的"，但这种内容很快会沉底，用通用搜索引擎也不容易索引到，需要有点耐心去翻。
4. 给 Claude Code 装一套"视频制作"Skill：目录、配置与一个好用的示范
4.1 装在哪里、目录长什么样
Skill 装起来没有想象中复杂，位置只有两种。一种是项目级，放在当前项目根目录的.claude/skills/下，只对这个仓库生效；另一种是用户级，放在~/.claude/skills/下，所有项目都能用。视频制作这种跨项目通用的能力，我建议放用户级；如果某个 Skill 是专门给某个产品做固定风格视频用的，那放项目级更合理。
一个 Skill 目录的典型结构是这样：
skills/ └── vertical-short-video/ ├── SKILL.md ├── references/ │ └── platform-specs.md └── examples/ └── example-output.mp4核心只有SKILL.md，其余都是可选的参考素材。Claude Code 启动时会扫描这些目录，但不会把内容全部读进上下文，只在触发时才加载对应文件，这也是这套机制省 token 的根本原因。
4.2 SKILL.md 的写法比你想的更讲究
很多人第一次写SKILL.md都会犯同一个错误：把description写得太抽象。比如写"帮助制作视频"，那模型几乎无法判断什么时候该用它；更糟的是它可能在错误的场合被触发。合格的description要包含三类信息：触发场景、输出的东西、边界条件。触发场景写清"当用户要求把图文改造成竖版口播短视频时"，输出写清"1080x1920、30 秒以内的 MP4 文件"，边界写清"横屏长视频请勿使用"。
正文部分的组织方式也有讲究。专业一点的 Skill 遵循一个共同结构：先给流程总览，让模型知道一共有几步；然后逐步展开，每步给出具体动作、关键命令和判断标准；最后放验证步骤，比如用 ffprobe 检查输出文件；再补一段"常见错误及处理"，把最可能翻车的几个点提前写进去。这套结构等于替模型把"事前规划、事中执行、事后验证"全部安排好了。
4.3 一个可直接抄的竖版短视频 Skill 模板
下面这个模板是我筛完 180 个项目后整理出来的最小可用版本，你可以直接复制去改造成自己的。
--- name: vertical-short-video description: 当用户要求把图文内容改造成竖版口播短视频，或直接制作 30 秒以内的竖屏视频时使用。输出为 1080x1920、带配音和字幕的 MP4 文件。横屏长视频场景请勿使用。 --- # 竖版口播短视频制作流程 1. 写口播脚本：控制在 80-100 字，钩子开头，核心观点居中，结尾给行动引导。 2. 拆成 3-5 个镜头：每镜 3-6 秒，输出分镜表，包含镜头号、画面内容、字幕文字。 3. 生成画面：优先使用纯色背景加 drawtext 文字卡，减少对外部素材的依赖。 4. 生成配音：每镜头一段 wav 文件，用纯英文文件名命名，如 clip_01.wav。 5. 逐镜头渲染统一规格片段： ffmpeg -y -f lavfi -i "color=c=0x1e293b:s=1080x1920:d=6" -vf "drawtext=text='镜头文案':fontsize=72:fontcolor=white:x=(w-text_w)/2:y=(h-text_h)/2" -r 30 -c:v libx264 -pix_fmt yuv420p clip_01.mp4 6. 用 concat 滤镜组装视频和配音： ffmpeg -y -i clip_01.mp4 -i clip_02.mp4 -i clip_03.mp4 -i voice_01.wav -i voice_02.wav -i voice_03.wav -filter_complex "[0:v][3:a][1:v][4:a][2:v][5:a]concat=n=3:v=1:a=1[v][a]" -map "[v]" -map "[a]" -c:v libx264 -pix_fmt yuv420p -c:a aac -shortest final.mp4 7. 用 ffprobe 检查最终文件，确认分辨率、时长、音轨数都符合预期，不符合就回溯修正。注意步骤 6 的写法有个门槛：所有片段的分辨率、帧率必须一致，所以步骤 5 的逐镜头渲染不能跳过。步骤 7 一开始容易被忽略，但它恰恰是防止"看似成功、实际不能用"的关键。
4.4 安装后怎么判断它真的被触发
装好之后怎么验证它生效了？最简单的方法是直接发一句触发型指令："按竖版短视频 Skill 的流程，把下面这段要点做成 30 秒视频。"然后观察 Claude Code 的行为。如果它真的用上了 Skill，你会看到它在执行过程中主动引用步骤编号，比如"按第 3 步，这里用 drawtext 生成文字卡"，并按照步骤顺序逐步推进。
如果它只是泛泛地回答你、没有走入具体流程，那问题几乎一定出在description上：要么太抽象，要么触发场景的描述和你的说法对不上。这个时候不要怀疑机制，去改描述，把触发词写得和你平时说话的用语一致。比如你平时习惯说"剪一条口播"，那描述里最好带上"口播、竖版、短视频"这几个词。
5. 一次完整实测复盘：从"它不会做视频"到稳定出片，我踩过的坑
5.1 这次实测的目标与初始条件
为了验证这套 Skill 到底能不能真正干活，我设定了一个具体任务：用完全本地生成的素材，做一条 30 秒竖版口播视频，内容是一个小工具的介绍。限制条件是不能用外部素材网站，所有画面都用 FFmpeg 能生成的元素完成，配音交给本地语音合成程序，输出必须是 1080x1920、带字幕、音画同步的 MP4。目标很直接：只看 Claude Code 在 Skill 的指导下能不能独立走完全程。
5.2 执行链路的真实回放
整个过程可以分成五步回放。第一步是脚本，Skill 把口播压到了 80 字以内，严格按"抛问题、给方案、引导行动"三拍走完。第二步是分镜，它输出了一张结构清晰的分镜表，我照着表格内容给你还原一下：
| 镜头 | 时长 | 画面设计 | 字幕 |
|---|---|---|---|
| 1 | 5 秒 | 深色背景 + 白色大字"还在手动处理？" | 还在手动处理？ |
| 2 | 6 秒 | 换色背景 + 文字"一键搞定重复流程" | 一键搞定重复流程 |
| 3 | 6 秒 | 换色背景 + 文字"现在就试试" | 现在就试试 |
第三步是素材与配音，它用 drawtext 生成了三张文字卡，同时在本地合成三段语音文件。第四步是组装，它把三条片段和三段音频用 concat 滤镜合并成了最终视频。第五步是校验，它主动跑了 ffprobe 确认了输出参数，整个过程只有一个地方需要我介入修正。
5.3 五个翻车现场和它们的根因
当然，这不是我第一次跑就成功的。连着翻车五次之后，我把根因记了下来，这些比成功过程更有价值。
第一次翻车在文件名上：我给素材文件用了中文名，脚本路径解析直接出了问题，画面全部丢失。教训很粗暴：所有输出路径和文件名统一用 ASCII 字符，Skill 里应该写明"文件名必须为纯英文"。第二次是横竖混拼：三段片段里有横屏有竖屏，拼完之后画面变形。根因在分镜阶段没有统一分辨率，只在最后组装时才发现。第三次是字体问题：drawtext 指定的字体路径在机器上不存在，命令直接报错。这提醒我好的 Skill 应该先探测系统可用字体，或者干脆退回 ASS 字幕方案。第四次是少了-shortest：三段视频总时长 18 秒，配音却只有 15 秒，导致最后几秒全是静音黑场，而这个几分钟就能发现的问题居然到输出才注意到。第五次是性能问题：第一次尝试生在 4K 分辨率，中间文件巨大，转码慢到怀疑人生，而实际分发根本用不到这个规格。
5.4 复盘之后的 Skill 升级版本
这五件事的价值在于：它们全部可以写回 Skill 里，变成一个"防复发"的固定步骤。我在模板的末尾加了一条强制校验清单：输出文件名必须纯英文；所有片段统一 1080x1920 和 30 fps；组装命令必须带-shortest；完成前必须用 ffprobe 检查分辨率、时长、音轨。修改之后第二次跑通全程只花了第一次三分之一的时间，而且我只是在关键节点回答了几个确认性问题。
这里我也想泼一点冷水：不要神话这套机制。Claude Code 有了 Skill 也不会变成剪辑师，画面审美、节奏把控、内容取舍仍然需要人来做。Skill 真正解决的是把重复劳动的出错率降下来，把专业操作的门槛降下来，让你能把精力留给真正需要判断力的部分。
6. 让 Claude Code 持续"长本事"：Skill 库的日常维护与自造技巧
6.1 我用 Git 管理个人 Skill 库
装了几个 Skill 之后，我很快就发现知识库也会"长毛"：改了一版命令，过两周忘了，下次又用旧版本。所以我现在的习惯是把~/.claude/skills/整个目录纳入版本管理，每改一个文件就写一句话说明。这个成本几乎可以忽略，但收益很明显：哪天 Claude Code 升级导致某个 Skill 失效了，我能清楚知道上次正常运行时这个文件长什么样，几分钟内就能对比出是谁出了问题。
目录组织上我分成两层：通用能力放在用户级，比如字幕清理、文件批处理这类谁都能用的；项目相关的能力放在项目级，比如某个具体产品的固定开场动画。这套分法和写代码的分层思想完全一致，目的就是让"可复用的"和"一次性"的互不污染。
6.2 从零写一个 Skill 的最少步骤
很多人觉得自己写 Skill 很高深，其实流程非常朴素。我的最短路径是五步：第一步，先不写任何东西，直接人工跑通一次完整流程；第二步，把这次跑通过程里的顺序、关键命令、判断标准整理成SKILL.md；第三步，用一个最小例子测试触发，比如一句话能不能让它走进你设计的步骤；第四步，迭代description，尤其是把"什么时候不要用它"写进去；第五步，补充异常处理，把你踩过的坑变成固定检查项。整个过程通常半小时以内，但换来的是一次性解决一类问题。
我经常说一句话：写 Skill 不是写代码，是写"你做这件事时脑子里的那份清单"。你不需要一次写完美，先写一个 20 行的粗糙版本，用的时候发现缺什么就补什么，几轮之后它自然就变厚了。
6.3 三个反模式与我的绕行方案
最后列三个我见过最多、也自己踩过的反模式。第一是巨型 Skill：正文超过 100 行还舍不得拆，结果每次加载都吃掉大量上下文，模型反而容易漏步骤。我的原则是一个 Skill 只负责一个完整流程，超了就拆成多个互相配合的 Skill。第二是依赖过深：有的 Skill 写死了只有自己机器上才有的路径、密钥和服务，换台机器就完全失效。好的 Skill 应该有降级方案，不依赖专属环境也能跑通主干流程。第三是写完从不验证：Claude Code 和底层工具都在版本迭代，上个月能用的命令这个月可能就变了，每隔一段时间用最小用例重新跑一遍，比自己盲目信任要可靠得多。
我现在接到任何重复性的内容生产任务，第一反应都不是写提示词，而是先花十分钟写一个最小的 SKILL.md。哪怕它只能覆盖我这一次的需求，下次再遇到同类任务，我的成本已经从四十分钟降到了五分钟。这个账，怎么算都划算。
