先说个很多人都问过我的问题Claude Code 到底能不能“做视频”我的答案是能但跟你想的不太一样。它不会像剪辑软件那样给你预览窗口也不会像渲染农场那样一帧一帧算画面它是靠一堆开源 Skill 把“做视频”这件大事拆成几十道小工序然后在终端里指挥各种工具替你跑完。最近我把开源平台上跟视频相关的 Skill 翻了一遍筛出了 180 个能看的其中 107 个 star 数不到 50——按很多人的习惯这种“冷门货”根本不会点进去但恰恰是这些低星 Skill 里藏着真正干活的工具。这篇文章我会把这 180 个 Skill 按功能分类讲清楚再把 107 个低星宝藏的判断逻辑、筛选方法、实测坑位都摊开说。如果你是刚接触 Claude Code 的新手可以把它当一份“视频方向技能索引”如果你已经在用 Skills 做自动化那后半部分的避坑清单和组合链路应该能帮你少走不少弯路。1. 从“聊天写代码”到“指挥制片团队”Skills 到底改变了什么很多人第一次听说 Claude Code 能做视频时脑子里浮现的是“在对话框里输入一句话它就给你吐出一个 mp4”。真有这种工具但 Clude Code 走的完全是另一条路它是个跑在终端里的智能体能读写文件、执行命令、调用外部程序所以“做视频”这件事在它这里变成了“调度 ffmpeg、处理字幕文件、生成配音脚本、检查输出参数”这类可执行的工序集合。1.1 视频行业缺的不是渲染是“工序拆解”一条短视频从零到一至少要经历选题、写稿、分镜、找素材、配音、字幕、粗剪、特效、压轴质检、导出发布这么十几个环节。任何一个环节都不能靠“让模型直接生成”解决因为模型没有眼睛也没法直接操作非线性编辑软件。但模型擅长的是把指令翻译成文件和命令。比如你告诉它“这段文案要分成三个镜头”它能输出一份结构化的分镜表你告诉它“把这段音频音量统一”它能写出一条带参数校验的 ffmpeg 命令。Skill 的作用就是把这种“你平时口头交代、它平时容易自由发挥”的过程固化成一整套标准作业流程。它不是一个插件而是一份“岗位说明书 操作手册 工具箱”的组合包。1.2 Skill 的形态与装载位置一个最常见的 Skill 结构是这样一个文件夹里放着 SKILL.md 主文件、若干辅助脚本、模板和示例文件。SKILL.md 的开头有 frontmatter里面写着这个技能叫什么、什么时候该被调用、能解决什么问题正文则是具体操作步骤、调用规则、注意事项。装载位置也很简单把整个 Skill 文件夹放进 Claude Code 的技能目录里就可以。客户端在会话开始时会扫描这个目录所以描述写得是否清楚直接决定它在面对相关任务时会不会主动调用这个 Skill。我见过很多写得很用心的技能包因为 frontmatter 里 description 写得太宽泛结果从来没被触发过这属于最常见的浪费。1.3 为什么拿视频当“试金石”之所以拿视频来检验 Skill 生态是因为视频任务天然覆盖了文本、时间轴、命令行、音视频格式、外部依赖这五类最常见的技术场景。一个能把视频链路跑通的 Skill它的严谨程度一定高于普通“写文案”类技能。反过来你也能通过它暴露出的短板判断整个 Skills 机制当前处在什么成熟度。我自己在筛选这 180 个 Skill 时明显感觉到凡是敢碰视频的都是作者被真实需求“教育”过的质量下限普遍偏高。这也是我推荐大家从这个方向入手的理由。2. 180 个 Skill 不是一天看完的我的筛选口径与分类框架如果你现在去开源平台搜 video、ffmpeg、subtitle、storyboard 这些词会看到数量远超想象的结果。问题是很多项目只是名字里带“video”实际上根本不是 Skill 格式还有些虽然格式对但连 README 都没有装上也不知道怎么用。所以我先给自己定了一套筛选口径再往里分类。2.1 我的筛选口径筛选其实很机械但每条都有它的理由必须包含 SKILL.md且 frontmatter 里的 name 和 description 是完整的。缺这个文件Claude Code 就没办法自动发现它。有可执行的支持脚本或明确给出的命令模板。光有一堆文字说明没有能落地的东西我不认为它能算一个“可用”的 Skill。README 里至少有一个完整示例。没有示例等于作者没替使用者踩过坑装上去大概率要自己补课。不依赖某个特定商业平台的私有接口。这一步是为了排除那些写着写着就变成“某个平台专属脚本”的伪技能。脚本里没有明显的危险操作尤其是一上来就 curl 远程脚本然后直接执行的。按这套口径过完最后剩下 180 个。我把它们分成九类脚本与分镜、字幕与转写、剪辑指令封装、配音与音乐、素材与画面生成、格式转换与压缩、特效与视觉风格、质检与合规检查、工作流与批处理。2.2 九大类数量分布我做了个表把这些分类的体量、活跃程度和典型使用场景列在一起方便你按需索引。分类数量大致热度典型用途剪辑指令封装36高把 ffmpeg 常用操作包成安全命令脚本与分镜30中高文案拆条、口播稿、分镜表生成字幕与转写28中语音转文字、字幕文件生成与校准配音与音乐20中低TTS 调用、BGM 推荐与音频处理素材与画面生成18高配图、封面、画面描述的批量产出格式转换与压缩16低封装格式互换、码率控制、批量转码特效与视觉风格14低字幕样式、转场描述、调色参数建议质检与合规检查10最低字幕错别字、黑边检测、音量峰值检查工作流与批处理8中多 Skill 串联、批量文件夹处理2.3 星星多不等于好用星星少不等于不能用这 180 个里107 个 star 数低于 50。如果按“只装高星项目”的习惯你会错过一半以上真正能干活的东西。原因我在第 4 节会详细拆这里先记住一个反直觉的结论视频工具类 Skill 是典型的高价值、低关注领域——因为作者往往是给自己写的解决的是自己剪辑流程里某个特别痛的问题根本没想到要推广。3. 九个分类逐一拆解哪些能力真正能直接干活光看分类表没有感觉我把每一类的“手感”讲一下。我没有写具体仓库名因为这类项目迭代太快我说的是这 180 个里反复出现的功能模式和它们的共同问题。3.1 脚本与分镜类拉片、拆条、写口播这类 Skill 是做视频链路的第一站也是目前成熟度最高的。出现频率最高的能力有三个一是把长文案按“口播节奏”拆成多条短视频脚本二是把一条完整视频的文字记录拆成带时间建议的分镜表三是按平台格式输出标题、封面文案、标签组合。我实测下来这类 Skill 的优点是输出结构非常稳定缺点是很多作者在 prompt 里塞了大量平台运营话术导致生成结果“模板味”很重。我的建议是装一个分镜结构稳定的然后把里面跟运营相关的内容删掉只保留格式框架。3.2 字幕与转写类把“声音”变成“时间轴”字幕类 Skill 通常做两件事调用本地语音转写工具把音频变成带时间戳的文本再把这些文本整理成 srt、ass 或 vtt 格式。这里有个隐藏难点是时间轴校准——同一条语音不同模型转出来的断句位置差异很大所以很多 Skill 还内置了“按静音段切分再对齐”的脚本逻辑。我对这类 Skill 的评价是能省 80% 的重复劳动但别指望它一次就完美。因为转写引擎对专业术语和人名的识别始终有误差所以好的字幕 Skill 必须包含“人工校对清单”这一步而不是直接宣称“自动生成字幕”。3.3 剪辑指令封装类FFmpeg 的正确打开方式ffmpeg 对大多数人来说是一堵墙参数又多又拗口。剪辑指令封装类 Skill 做的就是把常用能力包成“伪命令”你给它“把这段 30 秒掐头去尾加字幕烧录转成 h264”这样的需求它返回一条可运行、带参数说明的完整命令。这类 Skill 数量最多但真正好用的寥寥。原因在于很多作者只是把一堆 ffmpeg 命令堆在文档里没有做参数校验也没有考虑输入文件的实际编码格式。我见过一个很典型的失败案例命令本身没问题但没检查输入素材是隔行扫描还是逐行扫描结果输出视频出现横纹。好的封装类 Skill 一定会先跑 ffprobe 探测源文件信息再决定后续参数。3.4 配音、音乐、素材生成类找素材不用再开十个网页做视频最耗时间的其实是找素材。这类 Skill 会做三件事调用本地 TTS 或云端 TTS 接口生成配音根据脚本关键词给出 BGM 风格和时长建议为分镜表批量生成图片或封面提示词。它们的共同问题是依赖项太多。大部分配音 Skill 需要你自己配置 API 密钥或本地模型第一次跑通往往要半个小时。但跑通之后收益很大尤其批量生成配音和封面文案时能把手动操作压缩到原来的十分之一。3.5 格式转换、质检与工作流类越是冷门越在这里面最后这一批数量不多但几乎全部是低星宝藏。格式转换类 Skill 擅长处理批量转码、封装格式互换、码率压缩质检类 Skill 会检查字幕错别字、黑边、音量峰值、时长异常工作流类 Skill 则负责把上面几类串成一条流水线。我印象最深的一个质检类 Skill它做的事情非常简单用 ffprobe 读出一堆视频的分辨率、码率、帧率然后跟一个配置文件里的目标值做对比输出一张差异表。就这么个功能手动做一次要十分钟自动化之后一句命令就够。这类 Skill 的 star 基本都在 20 以下因为“质检”这个词在搜索里很难被命中属于典型的“搜不到但用起来真香”。4. 50 星以下的宝藏为什么值得翻判断一个冷门 Skill 是否能用接下来回答一个最关键的问题我凭什么敢说 107 个低星 Skill 里有很多宝藏以及——你自己去翻的时候要怎么判断一个低星项目值不值得装4.1 低星不等于差三类典型的“被埋没”我把这些低星 Skill 分成三种情况你对照一下就明白了。第一种是“适用面窄但解决的是真问题”。比如前面说的质检类 Skill它只服务一种特定的视频生产流程普通人用不上但真正需要的人会天天用。star 数是大众投票的结果小众刚需天然拿不到高票。第二种是“作者自己用的顺手工具顺便开源”。很多视频创作者的编程水平不一定高但他们写的 Skill 非常务实——就是针对自己周更视频的固定流程。这种 Skill 的文档往往只有作者自己能懂但拆开看里面的思路特别值得学习。第三种是“刚发布还没来得及被搜到”。视频类 Skill 的爆发其实也就是最近这段时间大量高质量项目刚上传不久star 还在个位数。等它涨到几百星的时候往往作者已经不再维护了所以低星窗口期反而是“最新鲜”的时期。4.2 我筛选低星 Skill 的六条检查清单翻多了之后我总结了一套检查清单比看 star 数可靠得多看 SKILL.md 的结构是否完整。frontmatter 有 name、description正文有步骤、有示例这种作者至少是认真写过的。看脚本是否自带参数校验。好脚本会检查输入文件是否存在、依赖命令是否安装而不是盲跑。看是否声明依赖和版本。写明“需要 ffmpeg 5.0 以上”的比什么都不写的靠谱。看最近提交时间。三个月内有提交的说明作者还在用超过一年没动的除非问题特别简单否则装上去大概率要自己修。看授权声明。没有 LICENSE 的文件严格来说不能直接商用做视频的人尤其要留意。看有没有危险命令。凡是要 curl 远程脚本再执行的我直接跳过。4.3 star 数什么时候才需要在意star 少不一定是坏事但有一种情况必须警惕功能宣称得很全、截图很精美、但仓库没有任何使用痕迹比如 issues 里一个讨论都没有。这种可能只是作者“做了一个看起来不错的东西”但自己都没跑通。反过来star 少但作者在自己的视频里反复提到这个 Skill、issue 区有真实使用反馈那反而说明它是经得起用的。所以我的结论是star 数可以当参考但它只是“多少人看见过”的指标不是“多少人用过还觉得好”的指标。对于工具类项目后者的价值远大于前者。5. 实战链路用 4 个 Skill 组合做出一条完整短视频盘点归盘点最后还是要落回到“能不能真的做出一条视频”。我搭了一条当前最顺手的组合链路用四个 Skill 分别负责脚本、分镜、字幕、导出。下面把链路和关键提示词写给你。5.1 链路设计阶段使用的 Skill 类型输入输出1. 拆条脚本与分镜一篇长文案3 条口播脚本 分镜表2. 配音配音与音乐口播脚本每条音频文件3. 字幕字幕与转写音频文件对齐后的 srt 字幕4. 成片剪辑指令封装素材目录 字幕最终 mp4这条链路的关键不是每个 Skill 多厉害而是阶段之间的交接格式必须稳定脚本 Skill 输出的必须是纯文本文件配音 Skill 才能直接读配音 Skill 输出的文件名必须包含顺序号字幕 Skill 才能按顺序对齐。5.2 典型提示词假设你已经在技能目录里装好了这四类 Skill实际使用时不需要什么花哨操作直接在终端里描述你的目标我有一个 3000 字的公众号文章放在 docs/article.md。 请按“钩子-主体-结尾”的节奏拆成 3 条 60 秒以内的口播脚本 每条脚本输出到一个单独 md 文件放在 work/scripts/ 目录下。等脚本确认无误再进入配音阶段读取 work/scripts/ 下的 3 个脚本文件 逐条生成配音输出到 work/audio/文件名用 01_、02_、03_ 前缀。 配音完成后把每个音频文件的时长写入 work/timing.json。最后合成用 work/audio/ 下的音频和 work/timing.json 生成对应字幕 再读取素材目录 work/clips/ 下的画面素材 按分镜顺序把音频、字幕、画面合成一个竖屏 1080x1920 的 mp4输出到 work/output/final.mp4。5.3 组合运行时的两个注意事项第一不要一次性把所有阶段当成一条超级长的提示词发出去。Claude Code 的上下文会被大量说明文字占用四五个 Skill 的说明书如果同时被加载留给实际素材处理的空间就不够了。我更习惯一个阶段一个阶段地推进每步确认输出质量再进下一步。第二注意素材命名规范。很多链路跑不通问题不在 Skill 本身而是素材文件名里有空格、中文括号、特殊符号导致脚本解析出错。我现在的习惯是进入工作流之前先统一改成“数字前缀 下划线”的命名法能省掉大量莫名其妙的报错。6. 冷门 Skill 的坑我帮你们踩过了实测避坑清单最后这部分写给真想动手的人。我在试这 107 个低星 Skill 的过程中踩了不少坑有些是 Skill 本身的问题有些是使用习惯的问题整理成清单希望你不用再走一遍。6.1 装了不生效先查 description最常见的“装上没反应”九成是 frontmatter 里的 description 写得跟实际功能对不上。Claude Code 判断什么时候该调用一个 Skill靠的是描述文本和当前任务的语义匹配。我遇到过一个字幕 Skill描述里写的是“视频转文字”实际功能却是“文字转 srt”——方向反了自然永远不被触发。解决办法很简单自己动手改 description把它改成真实功能的一句话描述。6.2 依赖缺失与 ffmpeg 版本差异视频类 Skill 几乎绕不开 ffmpeg但很多作者只测试过自己机器上的版本。我遇到过三个版本相关的坑一是老版本不支持某些滤镜参数二是不同发行版里 ffmpeg 编译选项不一样导致某些编码器找不到三是音频采样率不匹配导致合成后音画不同步。解决思路是装 Skill 之前先跑一遍作者给的示例命令如果示例都跑不通直接放弃这个 Skill不要浪费时间调试。6.3 上下文被“说明书”吃光一些低星 Skill 的 SKILL.md 写得特别长恨不得把 ffmpeg 全文档都塞进去。好处是信息全坏处是当 Claude Code 加载它时这部分内容会占掉大量上下文窗口。我实测过一个 3000 行说明的 Skill 会让后续对话明显变“笨”。所以我现在对 SKILL.md 超过一定长度、又没有配套脚本的 Skill 一律不装因为它的设计思路就不适合智能体工作。6.4 权限与安全检查低星 Skill 里偶尔会出现直接从网络拉脚本执行的写法。这种不是不能用但如果脚本是压缩包或者经过混淆的你就完全失去了对“它到底在我机器上跑了什么”的控制。我给自己定了一条死规矩凡是让我 curl 到未知域名再执行的项目一律先下载下来人工审一遍脚本内容。哪怕作者没有恶意这种写法也说明他缺乏安全意识项目质量很难保证。6.5 我的最终建议盘完这 180 个 Skill我最大的体会是不要抱着“装一个全能的”心态去找而是先把自己的视频流程画出来标出现阶段最耗时的环节然后去对应分类里找一两个最贴合的工具。冷门 Skill 的真正价值不是让你一下子拥有完整生产线而是用最小的成本解决你当前最痛的那一步。我自己现在固定使用的其实就是四个一个脚本拆条、一个字幕校准、一个 ffmpeg 封装、一个批量质检。它们加起来 star 数可能不到 100但我每条视频的后期时间从三个小时压缩到了四十分钟。这也是我写这篇盘点的初衷——在 star 数之外还有很多好东西值得被看见。