1. 从"只会写代码"到"能剪片子"：一个被低估的能力缺口
大多数人第一次用 Claude Code 的时候，脑子里想的都是"帮我写个函数""帮我改个 bug""帮我读一下这个仓库"。这很正常，因为它的默认定位就是一个终端里的编程助手。但用久了你会发现一个尴尬的事实：它能把一个视频处理脚本写得漂漂亮亮，却没办法真正"看懂"一段视频，更别说帮你把一堆素材剪成一条能发出去的成片。
这个缺口不是模型能力的问题，而是工具链的问题。Claude Code 本身是一个通用 agent 框架，它的能力边界取决于你给它挂了多少"技能"。就像一把瑞士军刀，刀片本身很锋利，但你要开瓶盖就得有开瓶器，要剪线头就得有小剪刀。Skill 就是这些可插拔的刀片。
我最近花了两周时间，把社区里能找到的开源 Skill 做了一次系统性盘点，一共梳理出 180 个，其中 107 个是那种"星标不到 50、但功能相当能打"的冷门货。这篇文章不讲虚的，我会把视频处理这条线单独拎出来，从分类逻辑、选型思路、实际拼装到踩坑经验，完整走一遍。不管你是想让 Claude Code 帮你做字幕、转码、抽帧、拼接，还是想搭一条半自动的视频生产流水线，这篇都能给你一个可以直接抄的起点。
先说清楚一件事：这里的"做视频"不是指让 AI 生成视频画面，那是另一条技术路线。我们讨论的是视频的工程化处理——剪辑、转码、字幕、封面、批量处理、格式转换这些脏活累活。这些活人做起来枯燥，但恰好是 agent 最擅长的：规则明确、步骤固定、可验证。
2. 180 个 Skill 的分类逻辑：为什么不能按"功能"分
2.1 按功能分类是个陷阱
一开始我也是按功能分的：视频类、音频类、图像类、文本类、网络类……分到一半就发现不对劲。同一个 Skill 经常横跨好几个类别，比如一个"批量处理"的 Skill 既能处理视频也能处理图片，你把它塞进哪个抽屉都不合适。更麻烦的是，按功能分类会让你忽略掉真正重要的东西——这个 Skill 是怎么和 Claude Code 交互的。
后来我换了个思路，按"交互模式"来分，一下子清晰了。所谓交互模式，就是这个 Skill 被调用时，它和 agent 之间的数据是怎么流动的。这么一分，180 个 Skill 自然落到了五个大类里。
2.2 五类交互模式的实际划分
第一类是命令包装型。这类 Skill 本质上是把某个命令行工具（比如 ffmpeg、ImageMagick）包装成一个 agent 能理解的接口。它的特点是输入输出都是文件路径，agent 负责拼参数、调命令、检查结果。视频处理里绝大多数 Skill 都属于这一类，因为视频处理的底层工具链太成熟了，ffmpeg 一个工具就能覆盖 80% 的需求。
第二类是 API 调用型。这类 Skill 不依赖本地工具，而是去调某个在线服务。比如语音转文字、图像识别、云端转码。它的优势是不占本地资源，劣势是依赖网络和额度。做视频字幕的时候，如果本地没有好的语音识别模型，这类 Skill 就是刚需。
第三类是数据处理型。这类 Skill 不直接产出成品，而是做中间数据的转换。比如把 SRT 字幕转成 ASS、把时间轴对齐、把元数据提取成 JSON。它们看起来不起眼，但在流水线里是粘合剂，缺了它们整个链条就断了。
第四类是编排型。这类 Skill 自己不做具体的事，而是负责调度其他 Skill。比如"批量处理一个目录下所有视频"这种 Skill，它内部会去调用转码 Skill、抽帧 Skill、字幕 Skill。编排型 Skill 是搭流水线的关键，也是最容易被低估的一类。
第五类是校验型。这类 Skill 负责检查产物是否合格：视频有没有损坏、字幕时间轴有没有重叠、分辨率是否符合要求。在自动化流水线里，校验型 Skill 决定了你能不能放心地让 agent 无人值守地跑。
提示：分类的目的不是归档，而是帮你快速判断"我缺的是哪一环"。如果你发现自己的流水线总是卡在某个环节，先看看是不是缺了对应交互模式的 Skill。
2.3 冷门 Skill 为什么值得挖
那 107 个不到 50 星的冷门 Skill，恰恰集中在第三类和第五类。原因很简单：数据处理和校验这种活，做出来不炫酷，没人愿意给它点星，但真正搭过流水线的人都知道，这些才是决定成败的地方。一个能把 SRT 时间轴精确对齐到帧的 Skill，价值远高于一个花哨的"一键生成大片"Skill。
我在盘点的时候给自己定了个规矩：凡是星标超过 500 的，先放一边，因为那些你大概率已经知道了；重点看 50 星以下的，尤其是那些 README 写得朴实、但代码里全是细节处理的。这批 Skill 的作者通常是真的被某个问题折磨过，才写出来分享的，实用度反而更高。
3. 视频处理这条线：从素材到成品的完整拆解
3.1 视频处理的六个必经环节
把视频处理拆开看，不管多复杂的项目，本质上都逃不过这六个环节：获取、转码、剪辑、字幕、包装、导出。每个环节都有对应的 Skill 可以挂。
获取环节包括从各种来源拿到素材、抽帧、提取音频。转码环节处理格式统一、分辨率调整、码率控制。剪辑环节做拼接、裁剪、变速、加转场。字幕环节涵盖语音识别、时间轴对齐、样式渲染。包装环节加封面、水印、片头片尾。导出环节做最终编码、封装、校验。
这六个环节里，转码和字幕是 Skill 最密集的地方，也是坑最多的地方。下面我挑几个关键环节展开讲。
3.2 转码环节：ffmpeg 包装型 Skill 的选型要点
转码看起来简单，无非是ffmpeg -i input.mp4 output.mp4，但实际用起来参数多到让人头大。一个好的转码 Skill 和一個差的转码 Skill，差别就在它帮你封装了多少"合理默认值"。
我试过的转码 Skill 大概有二十多个，筛选下来主要看三点。第一，它有没有预设（preset）机制。比如"网页播放""移动端""归档"这种预设，一键切换参数组合，比让你手填 CRF 值友好太多。第二，它有没有硬件加速的自动探测。不同机器上可用的编码器不一样，好的 Skill 会先探测再选，差的 Skill 直接写死 libx264，在有的机器上慢得让人想砸键盘。第三，它有没有进度反馈。转码是个耗时操作，如果 Skill 不输出进度，agent 就只能干等，你也不知道它是不是卡死了。
这里有个经验：优先选那些把 ffmpeg 参数暴露成结构化配置的 Skill，而不是让你直接写命令行字符串的。前者 agent 更容易理解和修改，后者一旦参数写错，报错信息能让你怀疑人生。
3.3 字幕环节：本地识别和在线识别的取舍
字幕是视频处理里最耗时的环节，也是 Skill 差异最大的地方。核心矛盾在于：本地语音识别模型（比如 Whisper 系列）准确率不错、不花钱、不依赖网络，但吃 CPU/GPU，长视频跑起来慢；在线识别服务快、省资源，但要联网、有额度限制、隐私上要打个问号。
我的建议是分场景。如果是短素材（几分钟以内）、对隐私不敏感，用在线识别的 Skill 更省事。如果是长视频、或者素材涉及不该外传的内容，老老实实用本地识别，哪怕慢一点。本地识别 Skill 里，重点看它有没有做分段处理和断点续传——一个两小时的视频如果跑到 90% 崩了要从头再来，那体验是灾难性的。
还有一个容易被忽略的点：识别出来的字幕是纯文本，但视频字幕需要时间轴。好的字幕 Skill 会把识别和时间轴对齐一起做掉，差的 Skill 只给你文本，时间轴要你自己想办法。选的时候一定要看清楚。
3.4 编排环节：把零散 Skill 串成流水线
单个 Skill 再好用，也只是零件。真正的价值在于把它们串起来。编排型 Skill 就是干这个的，它通常提供一个"任务描述"接口，你告诉它"把这个目录下所有视频转成 1080p 并加字幕"，它自己去调对应的 Skill。
这里的关键是错误处理。流水线跑起来最怕的不是某个环节失败，而是失败了没人知道，最后产出一堆半成品。好的编排 Skill 会在每个环节后做校验，失败了要么重试要么跳过并记录，绝不会让脏数据流到下一环。
我自己的做法是，在编排 Skill 外面再套一层校验 Skill，专门检查最终产物。这样即使编排逻辑有 bug，最后一道关卡也能兜住。
4. 冷门宝藏 Skill 的挖掘方法：怎么找到那 107 个
4.1 搜索关键词的组合技巧
找 Skill 和找其他开源项目不一样，因为 Skill 这个词本身太泛了。直接搜 "video skill" 出来的结果质量参差不齐。我总结了几组有效的关键词组合。
第一组是工具名 + skill。比如 "ffmpeg skill""whisper skill""imagemagick skill"。这类搜索能直接命中命令包装型 Skill，精准度高。
第二组是动作词 + skill。比如 "transcode skill""subtitle skill""batch skill"。这类搜索覆盖面广，但需要人工筛选。
第三组是场景词 + agent。比如 "video pipeline agent""media processing agent"。这类搜索容易找到编排型 Skill，虽然数量少但价值高。
第四组比较偏门，是问题词 + skill。比如 "fix subtitle timing skill""repair video skill"。这类搜索能找到校验型和修复型 Skill，正是那批冷门宝藏的聚集地。
4.2 判断一个冷门 Skill 值不值得用的四个信号
星标低不代表质量差，但确实需要更仔细地判断。我看四个信号。
信号一：README 里有没有具体的失败案例。如果一个 Skill 的文档里写了"这个工具在 XX 情况下会失败，建议这样处理"，说明作者是真的用过、踩过坑。这种 Skill 可信度高。
信号二：代码里有没有参数校验。打开源码看看，如果它对输入参数做了边界检查、类型检查，说明作者考虑过异常情况。如果直接拿参数就用，那大概率是个玩具。
信号三：最近有没有提交。视频处理依赖的底层工具（ffmpeg 等）更新很快，一个两年没动过的 Skill 很可能已经和最新版本不兼容了。
信号四：issue 区的氛围。如果 issue 里有人提问、作者认真回复，说明这个项目还活着。如果全是"求更新"没人理，那就别浪费时间了。
4.3 一个真实的挖掘案例
我印象比较深的是一个做"字幕时间轴微调"的 Skill，星标只有十几个。它的功能很窄：把识别出来的字幕时间轴整体平移一个偏移量，或者按比例缩放。听起来简单，但实际做视频的人都知道，语音识别出来的时间轴经常整体偏早或偏晚，手动调几百条字幕能调到崩溃。
这个 Skill 的作者在 README 里写了一段话，大意是"我做这个是因为我受不了手动调时间轴了"。就冲这句话，我把它加进了流水线。实测下来，它处理一条两小时视频的字幕偏移，几秒钟就搞定，准确度比手动调高得多。这就是典型的冷门宝藏：功能单一、解决真痛点、作者有真实需求。
5. 实际拼装：搭一条半自动视频处理流水线
5.1 流水线的整体设计
说了这么多理论，来点实际的。我搭的这条流水线目标很明确：把一批原始素材，自动处理成带字幕、统一格式、可直接发布的成片。整个流程分五步，每步挂一到两个 Skill。
第一步，扫描素材目录，识别出所有视频文件，提取基本信息（时长、分辨率、编码格式）。这一步用数据处理型 Skill。
第二步，统一转码。把所有素材转成统一的中间格式（我选的是 H.264 + AAC，兼容性最好），分辨率统一到 1080p。这一步用转码 Skill。
第三步，语音识别生成字幕。这一步用字幕 Skill，本地识别。
第四步，字幕时间轴对齐和样式渲染。这一步用数据处理型 Skill 加字幕渲染 Skill。
第五步，最终导出和校验。这一步用导出 Skill 加校验 Skill。
5.2 每一步的参数配置和理由
转码这一步，我用的参数是 CRF 20、preset medium、音频 128k AAC。CRF 20 是画质和体积的平衡点，再低画质提升不明显但体积涨得快，再高画质损失肉眼可见。preset medium 是编码速度和压缩率的平衡，slow 虽然压缩率更高但耗时翻倍，对批量处理不划算。
字幕识别这一步，我设了分段长度为 10 分钟。原因是本地识别模型对长音频的处理容易出现内存问题，分段处理既能控制内存，又能在某段失败时只重跑那一段，不用从头来。
时间轴对齐这一步，我加了一个自动偏移检测。原理是拿识别出的第一句话和视频开头的人声起始点做对比，算出一个全局偏移量，然后整体平移。这个技巧能解决 80% 的时间轴偏移问题，剩下的 20% 才需要手动微调。
5.3 编排脚本的写法
编排我用的是一个支持任务描述的 Skill，配置大概长这样：
pipeline: - name: scan skill: media-scanner input: ./raw output: ./work/manifest.json - name: transcode skill: video-transcoder input: ./work/manifest.json output: ./work/transcoded params: crf: 20 preset: medium resolution: 1920x1080 - name: subtitle skill: whisper-local input: ./work/transcoded output: ./work/subtitles params: segment_minutes: 10 language: zh - name: align skill: subtitle-aligner input: ./work/subtitles output: ./work/aligned - name: export skill: video-exporter input: ./work/aligned output: ./final - name: verify skill: media-verifier input: ./final这个配置的好处是每一步的输入输出都是显式的文件路径，任何一步失败你都能定位到具体是哪个目录出了问题。而且每一步都可以单独重跑，不用整条链重来。
注意：编排脚本里的路径尽量用相对路径，并且保证每一步的输出目录在跑之前是干净的。我踩过一次坑，上一步的残留文件被下一步当成输入，结果产出里混进了旧素材，排查了半天才发现。
6. 踩坑实录：那些文档里不会写的教训
6.1 编码格式不统一导致的连锁失败
最开始搭流水线的时候，我没做格式统一，直接拿原始素材往下跑。结果字幕环节频繁失败，报错信息还很模糊。排查了很久才发现，有些素材的音频轨道是分离的，有些是单声道的，识别 Skill 对音频格式有隐含要求，格式不对就直接崩。
教训就是：流水线的第一步永远是格式归一化。不要假设输入素材是干净的，现实中的素材什么妖魔鬼怪都有。转码这一步看似多余，实际上是在给后面的环节铺路。
6.2 时间轴对齐的"看起来对"陷阱
字幕时间轴对齐有个很坑的地方：它可能"看起来对"但实际是错的。比如整体偏移了 0.5 秒，粗看没问题，但观众会觉得字幕和口型对不上，又说不出哪里不对。这种问题在自动校验里很难发现，因为校验 Skill 只能检查时间轴有没有重叠、有没有超出视频长度，检查不了"感觉对不对"。
我的解决办法是加一个人工抽检环节：随机抽三段，每段看 10 秒，确认字幕和语音同步。这个环节花不了几分钟，但能避免成片发出去才发现问题的尴尬。
6.3 批量处理时的资源耗尽
批量处理最容易忽略的是资源管理。我试过一次跑 50 个视频的批量转码，没做并发控制，结果机器内存被吃满，系统直接卡死。后来改成串行处理，虽然慢一点，但稳定。
如果一定要并发，建议限制并发数在 CPU 核心数的一半以内，并且给每个任务设内存上限。视频处理是内存密集型操作，并发太高只会互相拖累。
6.4 冷门 Skill 的维护风险
前面说了冷门 Skill 的好处，但也要说风险：它们可能随时停止维护。我用的一个字幕对齐 Skill，作者某天突然把仓库归档了。虽然代码还能用，但以后 ffmpeg 大版本更新可能就不兼容了。
应对办法是：关键环节的 Skill 一定要能自己接手。选的时候看看代码量，如果核心逻辑就几百行，那即使作者不维护了，你自己改改也能用。如果一个 Skill 依赖一大堆外部服务，那风险就高得多。
7. 关于 Skill 选型，我个人的几条硬标准
盘点了这么多 Skill，我慢慢形成了几条自己的选型标准，分享出来供参考。
标准一：优先选单一职责的。一个 Skill 只做一件事，做得好，比一个什么都能做的 Skill 更可靠。因为单一职责的 Skill 出问题时，你能快速定位；大而全的 Skill 出问题，你连从哪查都不知道。
标准二：优先选输入输出是文件的。文件是天然的检查点，你能随时打开看中间产物。如果 Skill 之间靠内存或管道传递数据，一旦出错你什么都看不到。
标准三：优先选有明确错误码的。好的 Skill 失败时会告诉你为什么失败，差的 Skill 只给你一个"执行失败"。在流水线里，错误信息就是你的排查线索。
标准四：优先选能单独运行的。一个 Skill 如果必须依赖其他三个 Skill 才能跑，那它的调试成本会高得离谱。能单独跑的 Skill，你可以先把它调通再接入流水线。
标准五：优先选文档里有"已知问题"章节的。敢于写自己缺点的作者，通常也更靠谱。那些把文档写得天花乱坠、只字不提限制的 Skill，用起来往往处处是坑。
这套标准不一定适合所有人，但至少能帮你过滤掉一大批华而不实的选项。视频处理这个领域，稳定比炫酷重要得多。一条能稳定跑通的朴素流水线，价值远高于一条花哨但三天两头出问题的流水线。
最后分享一个小技巧：每次接入新 Skill 之前，先拿一个 30 秒的短视频做端到端测试。跑通了再上真实素材。这个习惯帮我省下了无数次返工的时间。
