最近我在终端里折腾 Claude Code（后面统一简称 CC）的时间，比在常规编辑器里写代码的时间还长。一开始只是让它帮我清理 Git 分支、重构几个小函数，后来某天突发奇想：能不能让 CC 直接帮我剪视频、加字幕、抽关键帧？试了几天发现这条路真能走通，但前提是得给它配上合适的 Skill。恰好社区里有一份长期维护的开源清单，收录了整整 180 个开源 Skill，我全部翻了一遍，按用途做了分类盘点，结果发现其中 107 个冷门宝藏的星数连 50 星都不到。这篇文章就是这次盘点的完整记录：Skill 到底是个什么东西、我按什么维度给 180 个技能归类、视频类技能有哪些真正能打、以及怎么把手上的 CC 从“写代码工具”变成一个能产视频的终端工作流。

1. Claude Code 为什么需要 Skill 才能“学会做视频”

1.1 从“对话助手”到“技能驱动”：一句话理解 Skill 机制

CC 本质上是一个跑在终端里的 AI 编程助手：它能读你的项目文件、执行 shell 命令、写代码、跑测试。但默认状态下，它更像一个“什么都会一点但什么都不专”的全科生。你问它 Python 语法它能答，你让它“把这段视频裁成 10 秒”它就懵了——不是模型不会，而是它缺少一个“标准化的操作流程”：用哪个命令、带什么参数、输出到哪个目录、怎么处理异常。

Skill 就是这个缺口的标准答案。一个 Skill 通常是一个文件夹，里面至少包含一个SKILL.md的说明文件，以及若干辅助脚本和资源文件。它的作用是：把某类任务的完整做法写清楚，让 CC 在遇到相关请求时自动读取这套说明，然后照着执行。可以理解成给 CC 装了一套“模具”，同一个任务无论来多少次，产出路径都是稳定可预期的。

这套机制最妙的点是它不依赖在线插件市场，也不需要提前编译。本质上就是一个带特定格式的目录，CC 在启动时会扫描指定路径下的 Skill 文件夹，把它们全部纳入自己的能力范围。这个设计让 Skill 的传播变得异常简单：复制文件夹、改两行配置，就能完成一次能力扩展。对比传统的插件体系，Skill 几乎没有“安装”成本，这也是开源社区能在短时间内冒出几百个 Skill 的根本原因。

1.2 SKILL.md 在终端里到底是怎么被触发的

要理解 Skill 怎么工作，最直接的办法就是看一个最小的SKILL.md长什么样。以下是我本地一个视频截取技能的核心文件片段，删掉了大部分细节，只保留触发逻辑：

--- name: video_clip description: 当用户需要裁剪、截取、分割视频片段时使用。支持按时间范围裁剪，也支持按关键帧抽取。 allowed-tools: bash, ffmpeg --- # Video Clip ## 当用户说"把这段视频裁到 30 秒"时 1. 先确认输入视频路径存在 2. 用 ffprobe 获取视频总时长 3. 按用户指定的时间点裁剪，默认保留原编码格式 4. 输出到 `workspace/video_output/` 目录 ## 调用参数 - `input_path`：输入视频路径 - `start_time`：开始时间，如 00:01:30 - `duration`：持续时间，默认 10 秒 ## 注意事项 - 不要修改原始视频文件 - 裁剪结束后用 ffprobe 验证输出文件时长

当用户在对话里提到“把视频裁一下”“截取一段视频”这类意图时，CC 会先匹配 Skill 的name和description，命中后把整个SKILL.md注入上下文，再结合脚本文件执行任务。这里的allowed-tools是一个很关键的声明：它告诉 CC 执行这个 Skill 时可以用哪些外部命令。

另外，Skill 不是只能被动等待触发。你可以在开头写明“当用户说 XX 时使用”，也可以反过来在对话里主动用指令加载某个 Skill，强制 CC 忽略自动匹配，直接按指定技能执行。前者比较省心，适合高频操作；后者更可控，适合链路复杂、需要多步骤配合的场景。我在实际使用中倾向于把“自动触发”和“手动指定”混用：简单任务靠自动匹配，复杂流水线就手动点名。

1.3 为什么视频是 Skill 最容易见效的领域之一

市面上的 Skill 覆盖范围很广，有管数据库的、有写前端组件的、有做运维巡检的。我在分类盘点时发现，视频处理其实是 Skill 机制下性价比最高的领域之一，原因有三点。

第一，视频处理有非常成熟的命令行生态。FFmpeg 这套工具几乎是音视频处理的事实标准，裁剪、转码、抽帧、加字幕、混流，全部可以用一条命令完成。Skill 真正要做的不是重新发明轮子，而是把正确的 FFmpeg 参数组合封装成固定流程。

第二，视频任务的产出是可验证的。写代码类的 Skill 好不好用，还得靠人读代码逻辑判断；视频处理任务则简单得多，生成的视频文件能不能播放、时长对不对、字幕是否对齐，一眼就能看出来。这种“输出即反馈”的特性让调试 Skill 变得很舒服。

第三，视频制作本身是多工序协作。从选题、脚本、素材处理、剪辑、字幕到封面，每个环节都能拆出一个独立 Skill。单个 Skill 只做一件事，组合起来就能形成一条完整的“AI 视频工作流”。这也是为什么 180 个 Skill 里视频/图像相关占了相当大比重的原因。

2. 180 个开源 Skill 从哪来：盘点逻辑与筛选项

2.1 这份开源清单的项目背景

我翻的这份清单来自社区长期维护的一个开源仓库，专门收集与 CC 生态相关的各类 Skill。它不是某个官方发布的正式列表，而是由几十位贡献者持续提交、整理、评审后沉淀下来的索引。仓库里每个条目会指向对应的 Skill 仓库地址、简短描述、当前星数以及最后更新时间。

有个细节值得说明：标题里说的“180 个”是盘点当天的快照数字。这类仓库每天都在变，今天可能是 180，下周可能就 200 了。所以你读这篇盘点时，重点不应该放在“具体是第几个”，而应该放在“怎么给 Skill 分类”和“用什么标准判断一个 Skill 值不值得装”这两件事上，方法比数字更耐用。

我拿到这份清单后，没有直接按它原始的分类阅读，而是全部打散，从零按自己的维度重新归了一遍。主要原因是原始列表的分类粒度参差不齐，有的按语言分，有的按工具分，有的按场景分，放在一起很难比较。

2.2 我重新划分的十大分类与分布

重新分类时，我的原则只有一个：按用户调用时的“意图”分，不按底层技术分。同样是 FFmpeg，如果 Skill 是做批量转码的，我归到素材处理；如果 Skill 是提取音轨做语音识别，我归到字幕工具；如果 Skill 是把视频拆成一帧帧图片喂给视觉模型，我归到内容分析。技术栈相同，但用户使用时的目的完全不同。

下面是我最终确定的十大分类，以及每个分类在盘点当天的大致数量：

这 180 个 Skill 并不是平均分配到每个分类的，开发效率类和编程语言类加起来超过三分之一，毕竟 CC 本身定位是编程助手，生态的初期积累集中在这个方向很正常。但视频与图像、写作与内容这两类的增长速度是最快的，说明已经有不少人开始把 CC 当“通用终端助手”用了，不只是写代码。

2.3 星数不是唯一标准：我筛选冷门宝藏的三把尺子

很多人看到一个仓库只有 20 星，第一反应是“这玩意儿不靠谱”。这个直觉有一半是对的，毕竟星数通常代表实际使用人数，没人用的东西大概率有坑。但另一半是错的：星数少可能是作者没有运营、仓库太新、或者方向过于垂直，不代表技术方案本身不行。

我在筛选那 107 个不到 50 星的冷门 Skill 时，用的不是星数，而是下面三把尺子：

第一，看触发链路是否完整。一个合格的 Skill，SKILL.md里必须清楚写明触发场景、执行步骤和注意事项。只有描述没有步骤的，多半是占位项目；步骤含糊不清的，实际用起来会反复翻车。我会把整份SKILL.md看完，确认它单独拎出来也能指导一个不知道上下文的人完成任务。

第二，看外部依赖是否可控。有的 Skill 写得很好，但要求先安装七八个 Python 包，还要下载几个 G 的模型文件，这种我会直接放弃。相反，有些 Skill 只依赖 FFmpeg 或者系统自带命令，即便作者不维护了，我本地也能一直用下去。依赖越少，Skill 的寿命越长。

第三，看提交历史是否连续。我特别在意一个 Skill 仓库的更新时间线。如果作者在最近三个月内还在修 bug，哪怕星数只有 10，我也愿意试。如果仓库已经一年多没动静，而它依赖的底层工具又经常变更，那大概率已经悄悄失效了。

这轮筛选下来，我的整体感受是：50 星以上的 Skill 属于“被验证过可用”的；50 星以下则需要自己承担试错成本，但里面确实藏着不少让人眼前一亮的设计，特别是那种“只解决一个很窄但很痛的问题”的技能，大而全的项目反而不容易做到。

3. 视频类 Skill 的核心细节拆解：哪些真正能打

3.1 字幕生成与翻译：最值得优先安装的一类

在全部视频类 Skill 里，字幕生成与翻译类是我个人最推荐优先安装的。原因很简单：需求高频、链路清晰、产出立即可用。一条完整的字幕处理链路通常是：先从视频中抽取音轨，然后调用本地或远端的语音识别模型转成带时间戳的文本，再按时间戳生成 SRT 或 VTT 字幕文件，最后可选地调用翻译接口生成双语字幕。

这个过程中最容易踩坑的是音轨抽取和时间戳对齐。直接从视频里分离音轨很简单，但很多视频本身就有背景音乐，如果识别模型对音乐敏感，转写文本里会出现大量无意义字符。好的 Skill 会在这时候做两件事：一是用降噪命令预处理音轨，二是设置一个音量阈值，低于阈值的片段直接跳过。

时间戳对齐同样是个细节活。语音识别输出的时间戳通常是基于音频帧的，与视频画面的时间基准可能差几十毫秒，单独看无所谓，但字幕一旦压制进视频，偏差会被明显放大。我个人用得比较顺手的方案是在 Skill 里掺入一个强制校准环节：生成 SRT 后，用媒体编辑库重新计算每一条字幕的起止时间，确保与视频关键帧对齐。

3.2 视频转写与会议纪要：长视频的分块策略

视频转写和字幕生成看起来相似，实际区别很大。字幕生成要求时间戳精确到每一句话；转写纪要则更关注内容的层次结构，往往还需要把长视频切成主题段落，每个段落提炼中心思想。

长视频的转写难点是输入长度。一段 60 分钟的视频，识别出来的文本可能会到一两万字，直接塞进对话上下文，CC 的处理质量会明显下降。好的转写类 Skill 会主动做分块：默认按 10 分钟一个块拆解，输出每块的摘要，再汇总成全文纪要。

我在测试这类 Skill 时发现，分块边界的选择直接影响纪要质量。如果恰好把一个话题从中间切断，前后两块都会产生不完整的理解。于是我自己写了一个小优化：先做一次粗粒度转写，定位静音段和话题转换点，然后再按这些天然边界分块。这样得到的纪要结构完整度明显更高。

这类 Skill 对视频创作者的意义在于，它的产出是可以直接变成创作素材的。我经常把一个采访视频丢给 CC，让它生成带时间码的要点列表，然后根据要点列表定位素材，省掉从头到尾看片的功夫。

3.3 FFmpeg 批处理封装：参数组合的实践沉淀

FFmpeg 批处理类 Skill 是数量最多也最容易被低估的一类。很多人觉得既然会写 FFmpeg 命令了，就没必要用 Skill。但真实场景是：FFmpeg 的参数组合太灵活了，不同编码器、不同容器、不同目标平台，参数方案完全不同。Skill 的价值不在“能执行命令”，而在“把最优参数组合沉淀下来”。

以最常见的“为网络平台压缩视频”为例，一个成熟的 Skill 不会简单执行ffmpeg -i input.mp4 output.mp4，它会先探测源文件的编码格式和码率，然后根据目标平台的分辨率限制，自动选择是否缩放、是否转成 H.264、音频是否重采样。涉及具体参数时，我常用的方案是：

• 视频编码用libx264，画质控制用 CRF 模式，区间在 18 到 28，值越小画质越高、文件越大；
• 音频统一转成 128kbps 的 AAC，兼顾听感和体积；
• 编码速度的 preset 用medium，平衡速度和压缩率，如果目标只是快速预览再用veryfast。

这类 Skill 能跑顺的前提，是作者对 FFmpeg 有足够深入的理解。因为参数一旦选错，轻则文件变大，重则播放器不兼容。我筛选 FFmpeg 类 Skill 时，会专门看它有没有处理异常退出码的逻辑，比如中途被杀掉后，是否会自动清理半成品文件。

3.4 内容分析与镜头拆解：让模型真正“看懂”视频

比“处理视频文件”更进一步的是“理解视频内容”，这类 Skill 通常会结合视觉模型或者镜头检测算法。最常用的场景是：把一个完整视频拆成数百个关键帧，按镜头切换点分组，再结合语音识别文本，自动生成一份带画面内容的素材清单。

镜头拆解的技术核心是场景检测。视频里的硬切点往往是画面差异度突变的帧，算法可以通过计算相邻帧的颜色直方图差异来定位。差异超过阈值就标记为一个新镜头。阈值设得太低，会把同一个镜头里的微小抖动拆成好几个镜头；太高又可能漏掉真正的切换。我调试时习惯先从默认阈值开始，观察拆解结果再微调，而不是直接追求一次到位。

这类 Skill 对长视频创作者尤其有用。我做一个视频时，最讨厌的就是几十个小时的素材堆在硬盘里，既不记得拍了什么，也没法快速定位某个画面。有了镜头拆解 Skill，我只需要让 CC 跑一遍素材，就能得到一份带时间码的镜头清单，看起来就像给每个镜头拍了一张身份证照片。

3.5 短视频脚本与选题辅助：创作链路的前置环节

还有一类视频 Skill 根本不碰视频文件，它们管的是创作链路的“上游”：选题、脚本、分镜。这类 Skill 看起来很轻，实际用起来对工作流的提升反而是最大的。

比较成熟的选题类 Skill 会内置一套创作逻辑：先问你目标平台和观众画像，再基于当前热点词库生成若干选题方向，每个方向附带搜索关键词和角度建议。脚本类 Skill 则更细，会根据目标时长反向计算每部分字幕的行数和字数比例，再输出镜头描述和旁白文案。

这里有一个我常用的参考数字：短视频口播的语速大概是每分钟 240 到 280 字，所以一条 60 秒的脚本，正文部分控制在 220 到 260 字之间最合适，留点气口给停顿和音效。好的脚本 Skill 会把这类参数写进SKILL.md，而不是泛泛地说“请生成一段短视频脚本”。

说到底，剪辑只是视频制作的后半段，选题和脚本才是决定视频能不能火的前半段。让 CC 在这些环节介入，等于给创作者配了一个永远不累的选题助理。

4. 五档速查：从 18 个高星主力到 107 个冷门宝藏

4.1 第一档：18 个准系统级主力 Skill

这 18 个 Skill 是星数最高、社区验证最充分的一批，单个仓库基本都在 300 星以上。它们的特点是普适性强、几乎每个 CC 用户都能从中受益，属于装了就赚到的那种。

这 18 个主力 Skill 里有相当一部分是开发效率类，比如自动生成代码规范、批量重构、智能生成提交说明；也有几个是通用内容类的，比如网页内容总结、长文本翻译、结构化信息抽取。它们能拿到这么高的星数，不是因为功能炫技，而是因为它们在日常工作中被使用的频率足够高，踩过的坑足够多，作者维护得足够勤快。

如果你是完全的新手，我的建议是：别一开始就装一堆花哨的 Skill，先把这 18 个里你能用得上的主力装好，跑熟，等真正理解了 Skill 的运作逻辑，再去探索其他档位。

4.2 第二档：28 个高频实用 Skill

星数在 100 到 300 星之间的这 28 个 Skill，属于“很有用但不那么出名”的中间层。它们往往解决某个特定场景下的高频问题，覆盖面不如第一档广，但在垂直场景里的深度通常更好。

我印象比较深的是几个跟数据清洗相关的 Skill，专门处理导出的混乱表格：去重、补全缺失字段、统一日期格式、拆分复合列，全部在终端里一步到位。还有几个跟 CI/CD 相关的，能根据项目的配置文件自动生成部署脚本，并且会主动检查语法错误。

第二档是日常使用体验最好的区间。第一档的 Skill 太通用，有时反而需要我额外交代很多参数；第二档则更“懂行”，它默认帮你处理了行业里约定俗成的细节，对话时更省心。

4.3 第三档：27 个垂直领域潜力股

星数在 50 到 100 星的第三档，开始出现明显的领域分化。比如面向特定框架的代码生成、面向特定行业的数据分析模板、面向特定平台的发布辅助。这些 Skill 的受众天然就不大，星数低不代表质量差，纯粹是目标用户基数决定的。

我把它们叫“潜力股”，原因是这些 Skill 往往直击一个非常具体的痛点，做得也完整，只是还需要更多用户验证、更多 issue 反馈来打磨。选择这一档的 Skill 时，我会重点关注 issue 区的讨论质量：用户报的 bug 作者有没有回复、有没有在后续版本修复。这两个指标基本能反映一个项目是否还在健康运转。

4.4 第四档：107 个冷门宝藏的挖掘方法

终于说到重头戏：107 个星数不到 50 的冷门宝藏。这批 Skill 占了全部技能的近六成，是最容易被忽略、也最容易给人惊喜的部分。它们的共同特征是“窄”：只解决一个非常具体的问题，不试图取悦所有人。

冷门的原因通常有三种。第一种是仓库刚发布，还没有被社区发现，这种最值得盯，早期使用还能赶上作者高频迭代的阶段；第二种是方向太小众，比如某个特定播放设备专用的转码参数集，普通人用不上，但真遇到对应需求时会觉得是救星；第三种是作者压根不擅长宣传，README 写得潦草，但代码本身能跑。

挖掘冷门 Skill 的正确方法，不应该漫无目的地扫列表，而是先明确自己缺什么能力，再按关键词过滤。比如我的目标是“批量给视频加水印”，那就直接在列表里搜 watermark，再把候选仓库逐个打开看。用需求逆向找工具，比顺着列表顺藤摸瓜高效得多。

4.5 我的低星 Skill 试用清单

说了这么多方法论，给一份我实际用过的低星 Skill 参考清单，帮你建立直观感受：

需要强调的是，这些 Skill 的参考意义不在于我推荐的具体项目，而在于你可以看到：40 星以下的 Skill 一样能解决实际工作里的具体问题。星数不该成为你使用一个 Skill 的决定性门槛，真正该关注的是它和你的需求是否匹配。

5. 实操上手：把 CC 跑成一站式视频流水线

5.1 安装一个 Skill 的标准动作

Skill 的安装极简，核心就是把对应文件夹放到 CC 会扫描的目录里。以我常用的方式为例，CC 会默认扫描用户目录下的 skills 子目录，也就是~/.claude/skills/。离线下载好的 Skill 是一个压缩包，解压后把整个文件夹丢进这个目录就行，关键点在于文件夹的名词需要先确认，这个名称会在触发时被用作标识符。

装好之后，最稳的验证方式是直接用一句话测试触发。比如我刚放入一个视频截取 Skill，就在 CC 对话里随便指定一个临时视频文件让它截取 5 秒，看它能否自动调起这个 Skill 并返回正确结果。这一步能同时验证三个东西：目录权限是否正确、SKILL.md的解析是否正常、依赖的外部命令是否可用。

5.2 手动编写一个最小可用 Skill 的完整示范

如果你找不到完全匹配需求的 Skill，可以自己写一个。这个门槛没有想象中高，一个最小可用的技能只需要一个 Markdown 文件。下面是一个“提取视频音轨并转成 MP3”的完整示例：

--- name: extract_audio description: 从视频文件中提取音轨并转换为 MP3，适用于需要单独处理音频的场景。 allowed-tools: - bash - ffmpeg - ffprobe --- # 提取视频音轨 ## 任务流程 1. 使用 ffprobe 检查输入视频是否存在音轨，若没有音轨则提前中止并告知用户 2. 使用 ffmpeg 将音轨导出为 MP3 文件，编码质量设置为 320kbps 3. 输出文件命名规则：与原视频同名，后缀改为 .mp3，放到当前目录的 audio_out/ 下 4. 导出完成后再次使用 ffprobe 验证音频文件的时长与源视频一致 ## 常见问题 - 如果视频存在多个音轨，默认提取第一个，并在结果中提醒用户手动指定其他音轨 - 如果提取后文件大小为 0，说明音轨损坏，需要告知用户重新导出原始视频

这个示例虽然简单，但完整覆盖了 Skill 的三个核心要素：前置检查、执行步骤、结果验证。你可能会问第一步检查音轨是不是多余的，我遇到过不止一次视频文件实际没有音轨，直接转码会生成一个几十秒的静音文件，白白浪费时间。这也是 Skill 和普通对话的最大区别：Skill 把这类边界检查写进了流程，而不是每次都要靠人现场提醒。

5.3 一条可以明天就照抄的最小视频流水线

理论讲了半天，给一条真正可以直接抄作业的最小流水线，目标是：“把一段源视频变成 3 条短视频切片，每段配上对应的字幕文件。”

整个流程分成五步。第一步，确认 FFmpeg 环境可用，运行版本检查命令，确保不是 4.x 的老版本，老版本在部分编码参数上兼容性差。第二步，用视频截取类 Skill 把原始视频切成 3 段，每段不超过 60 秒，落在一个新建的切片工作目录里。第三步，用字幕类 Skill 对每段视频生成时间轴字幕，语种按原视频语言自动检测。第四步，用批处理类 Skill 把生成的 SRT 字幕统一转换成标准 UTF-8 编码，避免在后期软件里出现乱码。第五步，人工抽查其中一个切片的字幕时间轴和画面是否对齐。

这条流水线全程在终端里完成，不需要打开任何图形剪辑软件，操作熟练的话，整个链路跑完用不了几分钟，比手动处理至少省一半时间。关键是这套链路一旦跑通，之后每次批量做视频只需要换输入文件，其他步骤全部可以复用。

5.4 权限与安全：装 Skill 前必须想清楚的三件事

Skill 虽然方便，但它本质上是让 AI 在终端里执行你给的脚本，安全边界必须心里有数。我自己在安装和使用时，始终守着三条纪律。

第一，不装来源不明的 Skill。我会优先选择社区多人验证过、或者我能完整读完源码的 Skill。如果一个 Skill 的脚本里出现下载远程代码到本地执行的逻辑，我会格外警惕，必须逐行确认它下载的是什么、要放到哪里。宁可少装一个功能，也不给自己的工作环境埋雷。

第二，给 Skill 限定可访问的目录范围。CC 的对话里有相关的权限控制选项，我会把默认工作目录限定在当前项目文件夹内，并单独设置一个输出目录。这样即使某个 Skill 的脚本有意外行为，也不至于波及系统目录或者个人文档。

第三，定期检查 Skill 依赖。我见过例子：一个 Skill 依赖的外部工具更新后不兼容，导致原本正常的任务突然失败。现在我会在安装每个 Skill 时，专门记录它依赖的命令列表，每月快速核对一遍版本变化的兼容性。核心原则只有一条：权限越小越好，脚本越透明越好。

6. 常见问题速查与我的踩坑记录

6.1 一张表解决大部分常见问题

我在折腾这 180 个 Skill 的过程中，积累了一些比较典型的故障记录，整理成一张速查表，遇到同类问题可以直接对照处理：

6.2 我踩过的三个具体坑

第一个坑是大小写敏感问题。某个 Skill 的目录名首字母大写，而我在对话里用的触发词是全小写，结果死活匹配不上，折腾半天才发现目录名和触发词必须大小写完全一致。在类 Unix 系统上这个坑尤其明显，它在判断时会区分大小写，这类问题在 Windows 下反而不容易出现。

第二个坑是上下文过长。我让 CC 分析一个短视频的完整镜头列表，输出长度远远超出正常对话窗口承受范围，结果后面的指令被截断。后来解决方案是给 Skill 增加一个“分段输出”的模式，默认只输出前 20 个镜头，超过的部分自动写入 JSON 文件供按需查询。这也是为什么我在前面强调 Skill 必须内置限制输出长度的逻辑。

第三个坑是依赖的隐含版本要求。有个视频处理 Skill 声明依赖 FFmpeg，但实际用了某高版本才有的滤镜参数，我在低版本环境里跑直接报错。现在安装新 Skill 后会主动运行一遍它内置的自检脚本，把依赖版本验证前置，不在任务执行到一半时才暴露问题。

6.3 一个冷门但对效率提升明显的技巧

最后分享一个我自己摸索出来的用法：给 Skill 设置“预执行检查”。很多任务失败不是执行阶段出错，而是输入文件本身不合格。我习惯在 Skill 的SKILL.md里加一条固定规则：无论用户要求什么，先对输入文件执行完整的探测命令，把时长、编码格式、分辨率、音频流信息全部打出来，确认无误后继续。

这个检查步骤看起来多花了几秒钟，但对批处理任务来说，它省掉了大量“跑了一半才发现输入有问题”的时间。尤其是当一个视频文件夹里同时包含竖屏和横屏视频，或者混着 MOV 和 MP4 格式时，不先做探测，后续转码参数的默认值大概率会出错。这条技巧是我在踩了若干次坑之后总结出来的，适配到所有类型的 Skill 上都成立：好的流程一定是从检查输入开始的，而不是默认输入没问题。

我现在已经离不开这套终端视频工作流了，每次要处理视频素材时，第一反应不是打开剪辑软件，而是让 CC 先跑一遍全流程。如果你也打算尝试，我的建议很直接：先挑一个视频类 Skill 装起来跑通一次，再根据实际反馈调整参数，别一上来就指望一条流水线解决所有问题。把这个最小闭环跑熟了，后面扩展新能力只是不断往系统里加新模具的事。