开源Claude Code Skill盘点：如何让AI自动剪辑视频、挖掘冷门宝藏

第一次让 Claude Code 帮我剪出一条完整的口播视频，我盯着成品愣了半天：转场、字幕、背景音乐居然全都齐了，中间没有任何人手写的剪辑逻辑，我只是往对话里压了一条指令。秘诀不在模型变聪明了，而是我提前给它装了一套开源社区的 Skill。这篇文章就聊聊我这阵子整理 180 个开源 Claude Code Skill 的过程，重点说一下视频方向怎么落地，以及那 107 个不到 50 星的冷门宝藏，为什么反而比高星项目更值得装。

先把丑话说在前面：这不是什么“用提示词就能一键出片”的玄学，而是一套有目录、有说明书、有脚本的工程化玩法。你不需要会写复杂代码，但需要理解 Skill 的装载方式、运行逻辑和常见坑位。读完你应该能自己现场组装一个“会做视频”的 Claude Code 环境。

1. 先搞懂：Skill 到底是什么，为什么能让 Claude Code 做视频

1.1 Skill 的物理结构：一个文件夹加一份说明书

很多朋友第一次听说“Skill”会下意识把它理解成插件或者 MCP 服务，这是最常见的误区。Skill 本质上是一个存放在.claude/skills/目录下的文件夹，里面装着一份叫SKILL.md的 Markdown 说明书，外加若干脚本和模板。它的核心作用，是把一个领域的“干法”写成 Claude Code 能直接读取的操作手册。

举个例子，你写一个“视频粗剪”Skill，它的SKILL.md开头通常长这样：

--- name: video-quick-cut description: 把一组视频片段和图片自动剪辑成带字幕、转场和背景音乐的短视频， 适用于 vlog、口播和产品演示。当用户提到素材剪辑、加字幕、生成短视频时使用。 ---

Claude Code 在工作时，会先扫描所有可见的 Skill，读取它们的description字段，判断当前任务匹配哪个 Skill，匹配后再把整个SKILL.md内容加载进上下文。所以这个description就是 Skill 的“求职简历”，写得好不好，直接决定 Claude Code 会不会想起它。

注意：Skill 不是代码插件，它给模型提供的是“流程和知识”，真正干活要靠 Skill 目录里的 Python、Shell 脚本以及系统里的外部工具。这个定位决定了它很轻、很好改、也很好分享。

1.2 为什么“做视频”这件事特别适合交给 Skill

Claude Code 本身能写代码、能执行命令，所以它天然具备调用外部工具干活的能力。但模型默认不“懂”视频制作的完整流程：先看素材、再列脚本、决定转场、生成字幕、压制导出、检查色彩和音画同步……每个环节有大量约定俗成的参数和经验，单靠对话很难一次性覆盖完整。

Skill 的价值就是把这一套流程沉淀成文档。我这次整理到的视频类 Skill，基本都把“应该先做什么、后做什么、用什么参数、遇到什么报错怎么处理”写进了SKILL.md。比如有的 Skill 明确要求“先用 ffprobe 检查每个素材的时长和编码，再决定是否需要转码”，这种经验型约束，纯粹靠提示词是没法稳定复现的。

类比一下：Skill 相当于给一个能力很强的实习生发了一本《老员工干活手册》。实习生本来就聪明，手册又告诉他每一步怎么走、有哪些坑，他上手自然又快又稳。没有手册，他也能干，但结果会忽好忽坏。

1.3 冷门不等于没用：不到 50 星的真香逻辑

这次盘点的 180 个 Skill 里，有 107 个 Star 数不到 50，属于典型的“冷门宝藏”。很多人看到仓库没几个 Star 就直接跳过，我原来也这样，后来发现这个逻辑在 Skill 生态里不成立。

原因很简单：高 Star 的 Skill 往往为了照顾大多数用户，做得大而全，什么都能干一点，但对你的具体场景总隔着一层。低 Star 的 Skill 很多是作者为了解决自己手头一个非常具体的问题写的，比如“只负责把采访长视频里的静默段切掉”“只负责把一句脚本变成分镜表”“只负责生成符合平台比例的字幕样式”。这种 Skill 单点极强，装上就能用，反而更容易直接融入你的工作流。

当然，低 Star 也意味着维护可能不活跃、测试不充分。后面我会单独讲怎么快速鉴定一个冷门 Skill 到底值不值得装。

2. 180 个 Skill 是怎么筛出来的：分类、口径和筛选标准

2.1 我用的筛选口径

说实话，网上叫“Skill”“Claude Skill”“视频 Skill”的仓库非常多，质量参差。为了不让盘点变成垃圾堆，我给自己定了四个硬性指标，任何一个不满足就直接淘汰：

1. 必须有SKILL.md文件，且文件里有完整的name和description字段。没有这两个字段的，Claude Code 根本识别不了。
2. description必须能一眼看出“什么时候该用”。那种写得含糊其辞的，实际使用时会频繁误触发或漏触发。
3. 有具体的脚本、模板或命令示例，不能只有一堆泛泛而谈的“你应该怎么做”的鸡汤式文档。
4. 有明确的许可证说明。这关系到你能否把它塞进自己的商业项目里。

按这个口径筛完，我手上就攒出了 180 个真正能“落地”的 Skill，然后按应用场景分成八个大类。

2.2 八大分类的分布与代表方向

我筛出的分布大概是这样的：

视频剪辑、字幕音频、素材生成这三类加起来就是“让 Claude Code 做视频”的核心底座，占了差不多一半。剩下那一半看起来跟视频没关系，但实际组合起来相当能打：脚本生成类提供内容，效率类负责素材管理，数据类帮你复盘成片效果，整个链路就闭环了。

2.3 判断“冷门宝藏”的四个信号

Star 数低不等于冷门，冷门也不等于宝藏。我在 107 个低星项目里捡“宝”的时候，主要看四个信号：

• 看它的description是否聚焦一个具体痛点。聚焦的往往比什么都干的更靠谱。
• 看文档里有没有“我在什么情况下写了这个 Skill”的背景说明。带真实使用场景的，通常真的跑通过。
• 看脚本是不是“可读”的。哪怕只有几十行，结构清晰、有注释的，比大而全但没人看得懂的黑盒强。
• 看最近半年有没有更新记录。哪怕只是修了一个小 bug，都说明作者还在用。

按这四个信号筛下来，我留下了一大批不到 50 星的精品。后面会展开聊其中的代表。

3. 让 Claude Code 做视频的完整实操：从零写一个视频 Skill 并跑通

3.1 准备工作：环境与依赖

想让 Claude Code 真的干视频活，系统里得先有几样东西。我不建议让 Skill 在运行时装依赖，那样容易失败而且权限要得莫名其妙。

• Claude Code 本体，确保claude doctor之类的诊断命令能跑通。
• ffmpeg 和 ffprobe，这是视频处理和探测素材信息的核心工具。Skill 里大量命令都要调它们。
• Python3，很多 Skill 的辅助脚本是用 Python 写的。
• 字幕字体文件，尤其是中文场景，必须准备一个系统能识别的中文字体，否则渲染出来全是方块字。

提示：检查 ffmpeg 是否可用，可以跑ffmpeg -version，只要正常输出版本号就行。很多视频导出失败的坑，其实都出在 ffmpeg 版本太老、不支持某个编码器上。

3.2 手写一个 SKILL.md：以“粗剪加字幕”为例

下面这个例子是我在实际项目里用过的简化版本。它的任务是：拿到一堆素材后，先检测素材信息，再拼接成片，最后烧录字幕并导出。

先在项目根目录建立下面的目录结构：

项目目录/ └── .claude/ └── skills/ └── video-quick-cut/ ├── SKILL.md ├── scripts/ │ ├── inspect.py │ └── concat.py └── templates/ └── subtitle.ass

然后写SKILL.md：

--- name: video-quick-cut description: 将多个视频片段和图片合成为带字幕和背景音乐的短视频。 当用户提到素材剪辑、拼接、加字幕、生成短片、做 vlog 时使用。 --- # 视频粗剪指南 ## 工作流程 1. 先用 ffprobe 检查每个素材的分辨率、帧率、时长和编码格式。 2. 对编码不一致的素材，先统一转成 h264 编码，避免拼接失败。 3. 生成 concat 列表文件，用 ffmpeg concat demuxer 拼接。 4. 按用户要求生成字幕文件，优先 .ass 以便控制样式。 5. 添加背景音乐，注意设置 -shortest 和音频归一化。 6. 导出为 mp4 容器，视频流 h264，音频流 aac，最后检查文件完整性。 ## 关键参数 - 通用交付格式：h264 + aac + mp4 - 画质优先时使用 CRF 18，预览时使用 CRF 23 - 竖屏短视频默认 1080x1920；横屏知识类视频默认 1920x1080 ## 常见问题 - 字幕乱码：检查字体路径，优先使用 Skill 目录自带的字体。 - 拼接失败：多半是分辨率或编码不一致，先统一转码再拼接。 - 导出文件无法播放：确认音频编码为 aac，而不是 pcm。

写完之后重启会话，这个 Skill 就会被 Claude Code 扫到。你在对话里说“把这两天拍的素材粗剪成一条带字幕的口播视频”，它就会自动匹配这份说明，按里面的流程开始执行。

3.3 实操场景：从一句指令到一条成片

我最常用的一句话是：“用 video-quick-cut 这个 Skill，把clips文件夹里的素材剪成一条 60 秒以内的竖屏视频，加上中文字幕和背景音乐。”整个过程中 Claude Code 会依次做这些事：

• 自动识别我提到的 Skill，把SKILL.md里的流程当作执行准则。
• 调用ffprobe列出素材信息，发现其中两个素材分辨率不一致。
• 按自动化流程先把那两个素材转码成 1080x1920 的 h264 文件，再写入 concat 列表。
• 根据口播内容生成一份.ass字幕文件，并把中文字体路径写进样式里。
• 挑一段背景音乐，用-shortest让成片长度跟着视频走，同时把音量压到不盖过人声的水平。
• 导出完成后调用 ffprobe 复核文件，确认编码、时长、音视频轨都完整。

这套流程跑完，我基本不用再手动打开剪辑软件。过程里它还会问我一些关键决策，比如“背景音乐音量以多少为准”“字幕保留哪些说话片段”，这就把“剪辑师”的活儿变成了“提需求”的活儿。

3.4 参数怎么定：分辨率、码率、编码器选择的逻辑

很多冷门 Skill 的价值不在流程，而在那些参数选择背后的逻辑。举个最常见的例子：同样的素材，导出的参数不同，文件大小和画质能差出好几倍。我在整理 Skill 时发现，靠谱的 Skill 都会在文档里解释参数逻辑，而不是让你死记硬背。

以 CRF 为例。CRF 是 h264 编码里的画质控制参数，数字越小画质越高、文件越大。CRF 18 被称为“视觉无损”，适合最终交付；CRF 23 是默认的“平衡点”；CRF 28 以上压缩痕迹就会比较明显。如果你的 Skill 只在“压缩视频”时用 CRF 28、在“交付成片”时用 CRF 18，那就是好 Skill。

编码器的选择也很有讲究。优先级是：能用硬件的用硬件（比如h264_videotoolbox或h264_nvenc，取决于你的平台），能用新编码器的看播放场景。绝大多数视频平台对 h264 兼容性最好，所以“通用交付”默认 h264 不会错。如果你导出的是中间文件、后面还要再剪，可以考虑prores或者ffv1这类无损格式，代价是文件巨大。

4. 视频背后的冷门玩法：四个分类里的隐藏宝藏

这一节把 107 个低星项目里比较有代表性的捡出来讲讲。名字我都按它们的功能重新改了，方便你理解，也方便你在开源平台用关键词去搜同类。

4.1 剪辑合成泛化：一些单点能力极强的低星 Skill

这批冷门货里，让我眼前一亮的是一个“静默段自动切除”的 Skill，仓库里不到 30 颗星。它做的事很专一：扫描一段长视频的音频波形，把所有超过 0.8 秒的静音标记出来，然后自动剪掉。对做访谈、口播、网课的人来说，这东西能省掉大量机械操作时间。

另一个不到 20 星的“分镜转时间线” Skill 也很有意思。它接收一段文字分镜表，自动生成 ffmpeg 的 filter 脚本，把每个镜头的时长、转场类型、缩放动画一次性铺到时间线上。你不用懂 filter_complex 语法，它负责把“第 2 镜，3 秒，淡入”翻译成命令。

这些小而专的 Skill 的共同特征是：作者大概率是被同一个痛点折磨了很多次，才决定把它写成 Skill。所以它们的流程往往比高星大而全的还要顺滑。

4.2 字幕与音频的冷门货：自动对齐、口音优化、BGM 选择

字幕方向我最喜欢的是一个“字幕时间轴自动对齐”的 Skill，作者是个做双语字幕的兼职翻译。它不生成字幕内容，只负责把一份 SRT 的时间轴对齐到已有音频的语音节奏上，解决“字幕快了半拍”的问题。这种场景非常具体，主流工具反而没它好用。

音频方向的冷门宝藏有一个“音乐情绪匹配” Skill，大概 40 颗星。它维护了一张情绪标签和音乐特征（BPM、调性、能量值）的对照表，让 Claude Code 根据视频内容选择合适的 BGM，而不是随手抓一首歌硬塞进去。配合 ffmpeg 的 loudnorm 滤镜做响度标准化，成片的声音质感会明显上一个大台阶。

4.3 素材生成的隐藏能力：封面、静图动效、文字排版

做视频的人最烦的其实是封面。一个低星“封面生成器” Skill 专门解决这个问题：它根据标题关键词自动生成 3 个不同构图的封面方案，每个方案都包含主标题、副标题、底色和对比度建议，再调用本地绘图工具或在线绘图接口出图。虽然它没有设计师的手感，但能给你一个可以继续微调的底稿。

还有一类“静图转动态”的 Skill，用 ffmpeg 的缩放和裁剪滤镜实现 Ken Burns 效果，让一张静态产品图慢慢推进、平移，看起来像拍摄镜头。做图文类短视频的时候，这类 Skill 能把“一张图配一段解说”直接变成“一条会动的片子”。

4.4 让人意外的效率类：素材归档、批量转码、镜头语言检查

最后说一个我私心最爱的冷门货：“镜头语言检查” Skill。它本身不导出视频，而是在你剪完片子之后，逐条检查你的镜头顺序和时长，提醒你是否出现“连续三个特写”“空镜太长”“切点卡在句子中间”这类新手问题。这个检查逻辑来自作者自己踩过的剪辑坑，不到 10 颗星，但给我省了大量返工时间。

另一个“素材自动归档” Skill 会把一个杂乱下载目录里的所有媒体文件按拍摄日期、文件类型、时长区间重命名归档，顺带生成一份 JSON 清单。虽然不直接产出视频，但它让 Claude Code 在后续剪辑时能快速找到素材位置。

5. 挑 Skill 和用 Skill 的避坑指南

5.1 五分钟快速鉴定一个 Skill 值不值得装

装 Skill 之前，我建议先花五分钟做一次“体检”。打开仓库往下拉，先看两个东西：SKILL.md的 frontmatter 和 README 里的“使用说明”。

frontmatter 的description如果是一句完整的话，说明作者认真想过触发场景。如果只是“help with video”这种敷衍描述，实际的触发率会非常低。README 里如果写了环境依赖、运行示例、已知限制，这个 Skill 大概率是作者自用之后才公开的，质量比较可信。反之，如果只有漂亮的截图没有任何能跑通的指令，建议跳过。

还要看它授权给 Claude Code 的权限边界。比较理想的 Skill 只用相对安全的命令，比如 ffprobe 探测、文件重命名、生成中间文件。如果一个 Skill 一上来就要你安装一堆依赖、修改全局配置、甚至关闭权限确认，我建议先拆开它的脚本逐行看看。

重点：装 Skill 前先问自己，它要做的这件事，我真的能接受 Claude Code 在本机直接执行吗？凡是涉及删除文件、覆盖源文件、访问私人目录的操作，都要额外警惕。

5.2 权限和安全：别让 Skill 替你乱跑命令

Claude Code 对每条命令都有权限确认机制。很多人嫌麻烦直接允许所有命令，这是最危险的做法。我的习惯是：第一次跑新 Skill 时，把执行权限设为“逐个询问”，观察它的命令流。跑通了、确认没有意外操作，再放宽到“本次会话允许”。

更保险的做法是在容器或临时环境里先试跑。让 Skill 在一个隔离目录操作，它就不会误伤你的源素材。很多低星 Skill 本质是作者的个人脚本，不会有恶意，但“写着玩”和“写得严谨”是两回事，脚本里直接覆盖原文件、没做任何备份的情况我见过不少。

另外，Skill 里如果需要联网请求某个接口或者下载模型，建议你自己手动执行一遍，确认它请求的是什么、返回的是什么，再交给 Claude Code 自动化调用。

5.3 兼容性问题：版本、上下文、依赖冲突

Skill 生态迭代很快，格式也在变化。我整理的时候发现，一部分老的 Skill 用的是早期的 frontmatter 风格，字段要求跟新版不完全一致，结果就是装进去没有任何反应。遇到这种情况，先确认你的 Claude Code 版本，再看看 Skill 的更新时间和作者说明。

还有一类问题跟模型上下文窗口有关。SKILL.md本身会占用上下文，如果它写得过长，会把有限的上下文挤占掉。我筛选时对“超过 30 秒阅读时长”的长文档会额外谨慎，一般优先选择“流程清晰、参数明确、废话少”的 Skill。一个 200 行的SKILL.md往往比一个 2000 行的“人生指南”高效得多。

依赖冲突也很常见。比如两个 Skill 都要用 Python 包，一个要pandas 1.x，一个要pandas 2.x。建议每个 Skill 尽量在独立虚拟环境里跑，或者至少把“安装依赖”的步骤做成 Skill 文档里明确标注的“前置步骤”，而不是在脚本里偷偷pip install。

5.4 常见问题速查表

6. 我踩过的坑：真实问题的排查实录

6.1 装了 Skill 半天不生效，问题出在描述没写对

我第一次装视频 Skill 的时候，来回试了快一个小时，Claude Code 就是不理它。后来我把description里那句“适用于 vlog、口播和产品演示”改成“当用户提到素材剪辑、加字幕、生成短视频时使用”，立刻生效了。原因在于模型是根据任务语义去匹配描述的，描述里全是抽象词汇，不出现用户会用的话，匹配概率就低。后来我整理每个 Skill 时，都会顺手把它的description改成“包含触发词”的版本。

6.2 视频导出总失败：编码器与容器不匹配

有一次我用一个低星 Skill 导出成片，ffmpeg 报了很长的错误，最后定位发现是它默认用了h265编码加mp4容器。理论上这个组合没问题，但播放器和后续剪辑软件兼容性参差不齐，导致反复失败。把编码器改成h264之后，所有问题烟消云散。现在我的原则是：通用交付一律 h264，除非你明确知道下游工具支持 h265。

6.3 中文标题变成方块：字体路径问题

字幕渲染成方块字，几乎是每个中文用户都会遇到一次的坑。问题不在于 ffmpeg 不支持中文，而在于它找不到合适的字体。我在 Skill 里强制要求“在templates/目录里放一份字体文件，并在.ass样式中使用文件的绝对路径”。这样无论换到哪个环境，字体都不会丢。

6.4 长视频超过模型输出限制：切段拼接的方案

让 Claude Code 一口气处理一小时的视频，很容易在中间环节超时。后来我总结出一个稳妥的“三段式”：先用 Skill 里的脚本把长视频切成若干 30 秒左右的小段并逐段处理，再把处理好的小段接入第二个 Skill 做统一拼接，最后用一个检查脚本整体校验。虽然听起来多了一步，但实际失败率远低于一次性处理。

6.5 我个人折腾完这一圈的经验

整理完这 180 个开源 Skill、实际跑通了十几个视频类项目之后，我最大的体会是：冷门宝藏真正的价值，不在于它有多少颗星，而在于它能不能精确补上你工作流里的那个洞。我会建议你按“先补最痛的点”的顺序来装，比如你总在剪静默段，就先装静默切除；你总被字幕对齐折磨，就先装时间轴对齐。装两个解决实际痛点的 Skill，比装二十个看起来高大上的 Skill 有用得多。

我现在的习惯是，每用顺一个低星 Skill，就会 fork 一份，把它改造成贴合自己素材规范的版本，再把自己遇到的报错和解决方案追加到它的文档里。用着用着，这些 Skill 就成了真正属于自己的“手艺手册”。如果你也整理出了更好用的冷门 Skill，不妨顺着这个思路继续深挖，视频创作者的工作流自动化，目前还远没到天花板。