★ FEATURED ARTICLE 这段时间我把 Claude Code 从“只会写代码的命令行工具”硬生生用成了“半个视频工作室”。起因很简单我在做一期教程视频时发现最花时间的不是拍摄和文案而是中间那堆机械操作——抽帧、截片段、加字幕、统一音量、转码。于是我开始翻开源社区里的 Skill 技能包一边装一边测前前后后整理出 180 个跟视频链路相关的开源 Skill其中一个数据让我很意外107 个 star 数在 50 以下也就是超过一半其实处在“冷门”状态。这篇文章没有别的目的就是把这 180 个技能包按生产链路重新分类讲讲哪些类别值得装再重点聊聊那些不足 50 星却非常能打的冷门包最后给一套能直接上手的安装和跑通流程。适合正在用或打算用 Claude Code 做内容生产的人也适合想扩展 Agent 能力边界、又不想配一堆重型服务的同学。1. 为什么 Claude Code 能“做视频”Skill 机制与能力边界1.1 Skill 到底是什么从提示词模板到可执行工作流先说清楚一个概念。Skill技能包在 Claude Code 里不是一个插件也不是一个独立的程序它本质上是一个“给模型看的说明书 可执行脚本的集合”。目录放在项目根目录的.claude/skills/下每个技能包里面有一个SKILL.md文件文件开头用 YAML 写名称和描述正文写完整的操作步骤旁边可以放scripts/、assets/这些子目录放真正会执行的脚本。你可以把 Skill 理解成你雇了一个很聪明的命令行助手本来他只会写代码现在你往他工位上放了一摞“片子怎么剪、字幕怎么压、封面怎么切”的作业手册每份手册还配了专用工具箱。当他读到用户需求时会根据手册开头那句 description 判断“这个活儿我该不该接”一旦匹配上就按手册正文的步骤调用对应脚本干活。它跟直接在对话框里说“帮我剪个视频”的区别就像临时百度菜谱和固定写在墙上菜谱的区别。直接说模型确实也能干但它每次都要现场回忆 ffmpeg 该怎么拼、参数该怎么办容易翻车而且你没法把一套成熟流程沉淀下来反复用。Skill 把“命令 步骤 脚本”固化成可复用资产团队之间拷一个目录就能共享这价值比啥都实在。1.2 视频方向为什么值得专门盘点视频生产这条线堪称 Agent 自动化的天然试验场。道理很简单视频处理的每个环节——拼接、转场、配音、字幕、转码——在命令行里都有对应的成熟工具全都是一串串稳定的命令。模型最擅长的恰恰是理解需求、生成命令、读输出、再决定下一步。你说它懂镜头语言吗未必懂但剪辑本来也不需要它懂镜头语言需要它把“把 A 段放前面B 段放后面中间加个淡入淡出”翻译成 ffmpeg 滤镜。这一步它是真能干。传统手工剪辑流程里最耗时的其实是等待和重复素材来回拖、字幕一句一句调、格式一处一处转。Skill 把这一连串动作编排成流水线后Claude Code 可以在一条指令下把片子处理完。我这次盘点的范围是以视频链路为核心关键词筛选出来的凡是 SKILL.md 描述里出现视频、音频、字幕、分镜、转码、封面这类词的都算筛完剩 180 个。我把它们按生产链路重新分成了八类下面这张表就是分类全景。2. 180 个开源 Skill 全景分类按视频生产链路拆解2.1 我的分类框架为什么按“生产链路”切一开始我也想按工具分类ffmpeg 类、AI 生成类、字幕类后来发现不行。因为用户在实际使用中从来不是按工具找技能而是按“我现在卡在哪个环节”找技能。比如你做口播视频卡在“文案还没有分镜”这时候你需要的不是一个转码包而是一个能把文案转成分镜表格的技能包。所以我按生产链路来切脚本创意 → 分镜设计 → 素材准备 → 音频配音 → 字幕文字 → 剪辑合成 → 封面与适配 → 发布与归档。2.2 八大类 Skill 的数量与定位类别数量定位典型场景视频生成与画面合成24从无到有产出画面片段文生视频、图生视频、本地模型出片脚本与分镜18文案转镜头清单口播稿拆成画面分镜表剪辑与合成30多片段拼接、转场、倍速、裁剪ffmpeg 封装、批量合成字幕与文字26语音转写、SRT 生成、翻译、烧录自动加字幕、双语压制音频与配音22文本转语音、BGM、人声分离配音链路、音轨统一素材与视觉20抽帧、封面、缩略图、修复找关键帧、做封面平台适配与发布15分辨率和安全区适配、导出参数竖屏裁剪、平台合规元能力与编排25视频理解、批量处理、多 Skill 编排先看片再决定怎么剪表格里 30 个的剪辑与合成类数量最多原因很现实剪辑是视频生产里最“工业化”的环节工具成熟、规则明确、可自动化程度最高。它基本就是各种 ffmpeg 封装按时间点截取、按清单拼接、给片段加转场、把横画面裁成竖屏、把视频切成章节。这类技能包安装成本低稳定性高应该作为你让 Claude Code 学会做视频的第一站。字幕与文字类也有 26 个这跟现在短视频的观看习惯强相关——超过一半人习惯无声刷视频字幕做得好不好直接决定完播率。技能包通常做三件事把音频转写成文字、把文字按断句切成 SRT、把字幕烧进画面。有的还附带翻译和术语替换功能。音频与配音类 22 个覆盖文本转语音、背景音乐响度匹配、人声和伴奏分离。如果你做的是教程或口播这 22 个里往往能找到一条现成的“配音链路”。脚本与分镜类听起来最不“技术”反而我觉得最值得注意。它做的是把一段口播稿拆成“序号、画面、景别、时长、字幕”的分镜表。这一步在人肉流程里通常要开表格软件、对着脚本逐行复制属于纯纯的体力活给 Agent 干正合适。素材与视觉类做的是抽帧找到关键画面、生成封面、批量统一缩略图有时还包含老素材修复、画质增强这类锦上添花能力。平台适配与发布类严格来说不是“做视频”但它是视频能发出去的最后一公里比如把横屏工程压成竖屏 1080P 的发布版、检查字幕会不会被平台底部按钮挡住、导出不同平台的尺寸参数。元能力与编排类则是用来“管视频”的比如让 Claude Code 先看一遍视频理解内容、再决定怎么批量处理。2.3 高星技能包的选型启示180 个里面star 数 50 以上的大概是 73 个剩下 107 个都在 50 星以下。73 个高星包确实占了大部分注意力它们通常有三个共同点SKILL.md 结构完整、README 写得清楚、附带了示例输入输出。这些特质本身就是筛选好技能的标准。但我要泼一盆冷水高星并不等于好用尤其对视频链路来说。因为视频生产是高度组合式的你可能只需要“抽帧”这一个动作但高星包往往是个大而全的万能工具箱装它等于拖进来一堆你永远用不到的依赖。我自己的做法是反过来先用高星包建立对“优秀 SKILL.md 长什么样”的体感然后真正安装时优先选轻量、单一职责的冷门包。而且高星包之间的同质化挺严重你做素材准备的抽帧功能和做封面生成的抽帧功能可能是两套实现没必要为了某个子功能专门装一个全家桶。一句话按链路需求选区段不要按 star 数选全家桶。3. 冷门宝藏挖掘记107 个不到 50 星的 Skill 筛选实录3.1 为什么星少不代表不行先破除一个迷信star 数是“被看见的需求”的刻度不是“好不好用”的刻度。通用工具需求大被转发收藏多star 自然高但视频链路里很多细分痛点如果不是当事人就根本不会搜到所以它们天然就是冷门。这类冷门包的来源大概有三种个人作品集的副产品、项目开发过程中抽出来的小工具、刚发布还没来得及传播。它们的共同特点是“小而尖”只解决一个具体问题依赖也少恰恰是最适合放进 Claude Code 流水线的那一类。反过来说星少还有一种情况是仓库根本没写说明文档或者描述写得含糊纯属“酒香巷子深”这种包只要验证过能用捡到就是赚到。我举个例子你就能体会。之前看到一个处理“多音轨访谈字幕对齐”的冷门包作者明显是剪辑访谈节目剪到崩溃才写了它。star 只有二十几个但它解决的问题极其具体把两条不同音轨里同一句话的时间轴自动对齐然后合并成一份双语 SRT。这种需求在通用工具箱里根本找不到而它在作者的场景里已经被反复用了几百次稳定得很。3.2 我筛冷门包的三条硬标准我盘完 107 个冷门包之后真正进到我“值得一试”清单的不到三十个。筛选标准看着简单执行起来很严。第一条SKILL.md 完整度。必须写清楚触发场景、输入文件格式、输出文件位置、依赖工具清单。触发条件写得含含糊糊的或者正文只有一句“见脚本”的直接过掉。第二条依赖可控。优先选只用 ffmpeg、标准 Python 库、常见命令行工具的包。依赖某些重模型或者非公开服务的除非使用场景真的离不开否则不碰因为你装完可能配置一小时。第三条有真实使用痕迹。仓库里有没有样例输入输出、测试文件、作者自己生成的产物截图。没有任何使用痕迹、也没有说明的一律不进候选。补一条更实际的最近提交时间超过一年的要降权处理。视频工具链更新太快ffmpeg 的滤镜参数和模型接口都是一年一变太久不动的包很可能需要你自己改代码才能跑。3.3 几类值得下场的冷门方向按这三条标准我把我实际用下来觉得惊喜的方向列几个都是具体场景供你照着找同类。细粒度字幕轴处理。别小看“对字幕时间轴做微调”多音轨对白分离、逐句对齐、双语 SRT 合并这些需求在大体量视频里极其普遍但通用工具箱不会专门做于是成了冷门包的舒适区。我试过一个不到 50 星的包把一段访谈的双语字幕自动合并成一条 SRT效果稳定省了大概四十分钟人工。分镜表格生成。一个冷门包把口播稿拆成“序号、画面、景别、时长、字幕”五列输出为 CSV这类包没门槛但确实省掉大量复制粘贴时间尤其适合每期都按固定结构的博主。平台安全区与遮挡检测。短视频平台底部都有按钮和主题字幕压在按钮上是大忌。有的冷门包专门做“安全区检查”自动检测文字区域是否越界。这个需求太小众头部工具懒得管反而冷门包做得精细。增量拼接与章节标记。针对录播课、直播回放这种长视频一个不重编码的切片和章节化技能包非常实用。它按录音停顿或静音段自动切点把一段很长的直播切成带章节标记的完整回放全程不失真。这些方向共同特点是需求真实存在、过程机械化、通用工具没覆盖。4. 让 Claude Code 真正学会做视频安装、配置与完整实操流程4.1 Skill 的标准安装方式与目录规范把技能包弄到 Claude Code 里本身不难但要放对位置。Claude Code 会自动扫描项目根目录下的.claude/skills/每个子目录算一个技能。标准的目录结构是这样的.claude/skills/video-shorts/ ├── SKILL.md ├── scripts/ │ ├── cut_clip.py │ └── render.sh └── assets/SKILL.md 的开头是 YAML 格式的信息块name 一定用短横线风格description 是触发匹配的关键。举个实际的例子--- name: video-shorts description: 当用户想把长视频剪成多条竖屏短视频时使用。输入 MP4 或 MOV 文件输出裁剪后的多条竖屏 MP4。 --- # 操作步骤 1. 读取输入文件路径检查是否存在。 2. 调用 scripts/cut_clip.py --input path --segments [开始,结束]... 3. 对输出文件统一转码为 h264aac 的 mp4。安装过程分三步把技能包目录复制到.claude/skills/下看一眼 SKILL.md 里写的依赖装好 ffmpeg 和对应 Python 包在 Claude Code 里重开会话然后说一句“现在有哪些 skill”看看能不能认出来。如果没认出来大概率是 YAML 块写错或者目录层级不对skills 目录下面必须直接是 skill 名目录。这里必须多说一句description 写得好不好直接决定这个包会不会被触发。我见过不少人装完技能包抱怨“没反应”点开一看 description 写得跟自我介绍一样——“这是一个视频工具”——模型当然不知道什么时候该用它。正确的写法是把触发场景、输入类型、输出内容全塞进去越具体越容易命中。4.2 一条完整短视频生产链路的实操走查光讲规范有点干我拿一条实际跑通的链路举例。场景是把一段 20 分钟的口播录屏做成 3 条 30 秒竖屏切片期间自动加字幕和统一声音这就是冷门包里最常见的组合用法。第一步先把音频转写成带时间戳的文字。这一步用任意本地语音转写模型都行核心是让输出里带每句话的开始和结束时间后面切高光要依赖它。转写完成后 Claude Code 会拿到一份类似“00:05:12 这里有个爆点”的时间线。第二步从时间线里选高光片段。让 Claude Code 根据 SKILL.md 里的评分规则比如关键词密度、音量峰值、时长阈值挑出 3 个 30 秒的区间输出成 JSON。第三步截取与竖屏裁剪。对每个区间做一次 ffmpeg命令大概长这样ffmpeg -ss 00:05:20 -i input.mp4 -vf crop540:960:0:180,scale1080:1920 -t 30 -r 30 -c:v libx264 -crf 18 -c:a aac -b:a 128k clip1.mp4这里-ss放在-i前面是快速定位不精确但够用。crop540:960:0:180的意思是保留原始画面中间 540×960 的区域再放大到 1080×1920而不是直接 scale。直接 scale 会把横画面横向压扁crop 只裁中间人物主体不会被拉伸。第四步字幕生成与烧录。把第二步选中的文本按字幕规范切成 SRT每行不超过两行然后和第三步生成的视频合成。字幕烧录用字幕滤镜能直接嵌进画面省得用户端再加载字幕后。第五步统一响度。口播素材经常一会儿大声一会儿小声用 loudnorm 滤镜把三段都归一化到 -14 LUFS这也是短视频平台普遍采用的响度标准。第六步合并输出。三段都处理完后用 concat 协议拼成一个 mp4一条 30 秒的切片就这么出来了。这个流程里 Claude Code 做的事情是调度和检查它按 SKILL.md 的步骤生成命令、执行、读取返回结果确认有没有报错、再决定下一步。真正干活的是 ffmpeg 和脚本这也是为什么我一直强调选 Skill 的本质是在选“被封装好了的脚本链”。4.3 参数配置与运行效率优化实操里最容易被忽略的是参数。拿码率举例同样一条 1080P 视频直接发布用-crf 23加maxrate 8M就能压得比较小但要先切片段、再烧字幕、过一遍响度处理的中间产物建议用-crf 16到 18接近无损免得二次编码把画质磨损掉。音频则统一 AAC 128kbps 就够了人声清晰体积也小。如果你要算文件大小可以这么估视频码率 4500kbps 加音频 128kbps一分钟就是(4500 128) × 60 / 8 / 1000约 35MB。运行效率上最大的坑是上下文超时。Claude Code 会话有上下文限制一个长视频转写任务如果全部塞进去对话最终肯定会卡死。给 Skill 写 SKILL.md 时就应该规定超过一定时长的视频走独立脚本后台跑模型只负责启动和轮询进度。拿我常用的流程举例转写字幕的脚本被设计成生成一个 log 文件Claude Code 每隔一段时间去读 log读到了“完成”就继续下一步这样会话不占用大量上下文长视频也稳。另一个我养成的习惯是给 Skill 加 dry-run 模式。我先让 Claude Code 打印出它将要执行的所有命令看完没问题再真跑。一个技能包只有在能“先知道会干什么”的前提下才值得信任尤其当它操纵的是你电脑上的真实文件时。5. 实战避坑指南8 个高频问题与排查思路5.1 高频问题速查表跑了这么多技能包我把踩过和见过的坑汇总成一张表按频率排序问题现象可能原因排查与解决Skill 不触发description 表达太泛模型没把用户需求跟它匹配上重写 description把触发场景、输入文件类型、期望输出写具体重开对话脚本提示权限不足可执行文件没加执行权限给 scripts 目录加执行权限重新验证ffmpeg 找不到环境变量 PATH 没包含 ffmpeg安装后重启终端或者在脚本里写绝对路径字幕时间轴整体偏移音频转写时采样率或通道和原片不一致先统一转成 44.1kHz 16bit 单声道再做语音转写输出视频体积爆炸没设置码率上限逐段编码累积中间产物用 CRF最终产物加 maxrate 限制长视频任务中途卡死一次性塞进对话上下文超限让脚本后台运行模型轮询日志Python 依赖冲突系统环境和技能包要求版本不一致建独立虚拟环境在 SKILL.md 里写明启用命令Skill 误触发description 里场景词太宽加排除词例如“仅当用户提到从本地视频文件中制作时使用”这些问题的共性是“模型没走对剧本”或者“脚本本身有环境依赖”前者靠改 description 和重启解决后者靠环境隔离解决。真正专业的使用者会把技能包的运行环境固定下来比如在 SKILL.md 里写明用哪个虚拟环境宁可模板长一点不能每次靠猜。5.2 两个相对隐蔽的坑最后说两个不是速查表能覆盖的隐蔽坑。第一个坑是技能包脚本动了你不想让它动的文件。Claude Code 默认会把 skill 脚本当成可信工具让它跑它就可能在你项目目录里乱建文件、覆盖同名文件。我的对策是在 SKILL.md 里规定好输入输出目录让脚本只能读指定目录、只能把结果写到output/并且先把 dry-run 跑一遍。几十秒的检查能避免一次事故。第二个坑是多个技能包共用临时目录导致串数据。两个脚本如果都把中间文件放在同一个临时路径并行处理时一个会覆盖另一个。我见过一次“生成的字幕是上一个视频的”排查半天发现就是同名临时文件相互覆盖。给每个技能包分配独立临时目录文件名加前缀是成本极低收益极高的习惯。还有一个原则性问题别把复杂判断逻辑全堆在 SKILL.md 的文字描述里。模型上下文是稀缺资源描述越长执行越容易偏离。正确的姿势是描述负责“触发和传参”脚本负责“具体决策和执行”两边分工明确技能包才耐用。最后分享一点个人体感。这段时间翻完这 180 个技能包我最深的感触是星数这个数字代表的是别人顺手留下的收藏不代表它在你的工作流里能不能跑通。真正值钱的是 SKILL.md 那几页纸和旁边那几十行脚本它们把“一个人好不容易摸出来的流程”固化成了以后每次都能复用的能力。也正因为这样我才特别建议你去认真看看那 107 个不足 50 星的冷门包。别嫌它们小很多人做视频卡住的恰恰就是这种“小”地方。装一个包之前先跑一个最小样例给它 10 秒素材让它出 3 秒结果跑通了再上真实项目。这套验证习惯比收藏一百个高星包都管用。
阅读完成 · 觉得有帮助？
