企业官网建设流程全解析

让 Claude Code 学会做视频，这句话乍一看容易误解。它不是让 AI 直接替你渲染出一部大片，而是通过 Skill 机制，把视频处理里那些最重复、最繁琐、最耗人力的环节，变成它能自己调用的“工具箱 + 操作手册”。我最近把开源社区里跟视频相关的 Skill 挨个过了一遍，累计筛出大约 180 个项目，其中 107 个 Star 数不到 50，属于典型的冷门宝藏。

说句实话：数量不等于价值，真正值得装进自己工作流的，两只手数得过来。但正是这些低热度的项目，解决了我工作中最痛的一环——从脚本素材到成片输出的自动化。这篇文章会把我的盘点逻辑、筛选标准、SKILL.md 的写法，以及用 ffmpeg 和 Whisper 这类常见开源工具搭一条真实视频处理流水线的参数方案完整整理出来。适合想把 AI 编程助手真正用进视频生产流程的个人创作者、视频运营，以及所有对 AI 助手扩展机制感兴趣但不知道怎么下手的人。

1. 先弄明白 Skill 机制，再谈让 AI 做视频

1.1 Skill 不是插件，是“操作手册 + 工具箱”

在动手之前，我建议所有人先把 Skill 这个东西的本质搞清楚。它不是一个传统意义上的软件插件，你装上就能多一个按钮；它更像是一份写给 AI 的操作手册，外加一套可以直接调用的脚本工具。

一个标准 Skill 目录大致长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ ├── extract_audio.sh │ └── make_srt.py └── assets/

其中 SKILL.md 是这个 Skill 的灵魂。它通常包含元信息（这个 Skill 叫什么、什么时候该用、输入是什么、输出是什么），以及一步步的“工作流程”。模型读到这份文件之后，就知道在什么场景下、用什么样的工具、按什么顺序执行。

我常拿“新员工入职”来类比：你给一个实习生交代任务，光说“你去把这段视频整理一下”是没用的，你需要告诉他怎么打开剪辑软件、找哪个文件、用什么参数导出、最后交付什么格式。Skill 就是这份 SOP。它把你在某个领域的操作经验固化下来，让 AI 一看到对应任务就能按步骤干活。

理解了这一点，你就明白为什么视频方向会长出这么多 Skill——因为视频制作本身就是一个超级复杂的流程体，每一步都可以拆出来单独做一个能力模块。

1.2 为什么视频方向能冒出 180 个 Skill

视频相关的 Skill 数量多，本质上是因为视频处理链条太长了。从视频生成、拍摄素材管理、转码、抽帧、剪辑、字幕识别、翻译、摘要、封面制作、切片分发，再到平台上传，每一环都有对应的技能需求。

而且这些环节有一个共同特征：它们很难靠大模型一步到位完成。比如“把这段一小时直播里最精彩的 30 秒剪出来”，模型自己不懂怎么解析视频流，它必须借助外部命令行工具先完成检测、转写、分析，再基于结果做决策。这正好是 Skill 最擅长的场景——把大模型的理解能力跟外部工具的确定性操作结合起来。

那 180 这个数字是不是意味着视频处理已经被社区开发透了？我的判断恰恰相反。这 180 个里，大量是重复造轮子。同样的抽帧需求，可能有七八个人各自写了一版；同样调用 Whisper 转字幕，也有好几个人做了高度相似的封装。真正值得精心维护、有独特思路的，不会超过二十个。

这也是我做这次盘点的出发点：不是把 180 个全装进来，而是把所有分类维度、技术路线摸清楚，从中挑出真正能放进生产链路的那几个。

2. 盘点方法：180 个开源 Skill 是怎么分类的

2.1 我用来筛 Skill 的三个硬指标

面对大量低星项目，如果没有筛选标准，很容易陷入“什么都想装”的焦虑。我给自己定了三个硬指标。

第一，必须有完整的 SKILL.md，而不是只有一串脚本。脚本只代表“你能做什么”，SKILL.md 才决定“AI 知不知道什么时候做、怎么做”。没有操作说明的脚本，对 AI 来说几乎等于不存在。

第二，依赖项必须常见且可离线跑通。我会检查它调用的核心工具是不是 ffmpeg、Whisper、ImageMagick 这类主流开源命令行工具。如果一个 Skill 依赖某个只在一个偏僻仓库里维护的私有库，我会直接淘汰——因为这类依赖最终的结局往往是某天突然跑不起来。

第三，输入输出边界要清晰。好的 Skill 会明确写清楚接受什么输入（比如一个视频文件路径、一个 SRT 字幕文件），产出什么结果（比如一个 JSON 报告、一个带字幕的新视频）。凡是“你看着办”型的说明，在生产环境中会变成灾难。

在这三个指标基础上，我还会额外看一个软指标：作者自己有没有真的用过这个 Skill。判断方式是看 README 里是否给出了真实运行样例，或者 SKILL.md 里有没有针对异常情况的处理说明。自己跑过的人，写出来的东西明显更接地气。

2.2 我的五类切法：按任务分，不按工具分

给 180 个项目分类时，我一开始试图按照工具来分，比如“用 ffmpeg 的”“用 Whisper 的”“用 Python 的”，但很快发现这条路走不通。同一个工作流往往要串起多个工具，按工具分类会让每个项目塞进好几个桶里，没有参考意义。

真正好用的分法，是拿“用户想要的结果”当锚点。我最后用了五个大类：

这个分类方式有一个好处：它跟你的真实需求一一对应。你是做短视频二创的，就重点看“内容理解与二创”和“视频剪辑”；你是做播客转录的，直奔“音频处理”；你要做自动字幕翻译，那“字幕与时间轴”里的项目可能一个都别错过。

分类盘点不是搞学术，是为了让使用者在需要某个能力的时候，能直接锁定到对应的项目群，而不是重新从 180 个坑里爬一遍。

2.3 星数不到 50 的“冷门宝藏”为什么不能忽略

很多人筛选开源项目时直接按 Star 数量排序，这当然是一种省力策略，但对于 Skill 这个品类来说，会漏掉一大批真正有价值的东西。

冷门的理由很多，而且几乎都跟质量无关。有的作者只是把项目当作自己的个人工作流发布，压根没想过推广；有的 Skill 是面向某个极其窄的场景写的，比如“检测视频里是不是有动态字幕并单独抽出来”，这类需求太小众，凑不够热度；还有的是作者写文档太烂，SKILL.md 里只有代码没有上下文，导致别人用不起来。

但我发现，这类冷门项目里往往藏着一个独特巧思。比如某个 30 星的项目，能够根据视频音量曲线自动切掉开头 5 秒的无语音部分；另一个 40 星的项目，可以把直播录像按照静音段切成多个片段，并自动为每个片段命名。这种方案不是为了通用框架设计的，而是作者真正在处理一批视频时被逼出来的解法，反而更贴近实战。

我筛选冷门项目时有个习惯：先看 SKILL.md 里的“异常处理”章节。如果一个作者连“如果 ffmpeg 找不到怎么办”“如果视频没有音轨怎么办”都写进去了，说明他踩过坑，这个项目就可以试用。

3. 核心实操：给 Claude Code 配一条视频处理流水线

3.1 第一步：目录结构与安装位置

看完了理论和盘点，接下来就是真正动手配流水线。我先说目录规划。

Skill 一般可以放在两个层级：用户级和项目级。用户级的 Skill 放在当前用户配置目录下的 skills 子目录里，所有项目都能用，适合放通用能力，比如“生成字幕”“抽关键帧”；项目级的 Skill 放在项目根目录下的 .claude/skills 里，随项目走，适合放业务相关内容，比如“本频道视频的片头片尾规则”。

我的建议很直接：视频处理相关的 Skill 先统一放用户级，因为它的工具链是全局复用的，不要把它绑死在单一项目里。等某个流程稳定跑通了，再考虑要不要复制到项目级做定制。

安装 Skill 本身并不复杂，本质上就是把它解压到对应目录。真正要验证的是：AI 能不能意识到有这个 Skill 存在，并且愿意在合适的时候调用它。我往往会用一个触发句来测试，例如：

请把 /tmp/test_video.mp4 按我们的标准流程处理一遍。

如果它只是简单回答“好的，你想怎么处理”，没有任何调用 Skill 的迹象，那就说明 Skill 没有被正确加载，或者是 SKILL.md 的触发说明写得不够清晰。

3.2 第二步：写一个能用的 SKILL.md（模板）

一个能直接落地的 SKILL.md，我会尽量控制在 60 到 100 行以内，并且严格分成四个区域：元信息、工具清单、工作流步骤、输出规范。下面是我最常用的一份模板，你可以直接抄：

--- name: video-insight description: 输入一段视频路径，自动抽帧、转写字幕、生成场景摘要。当用户要求处理视频、提取字幕、分析录像内容时使用。 --- # 视频理解工作流 ## 前置条件 - 本机已安装 ffmpeg 和 whisper - 输入视频小于 2GB，时长不超过 60 分钟 ## 步骤 1. 用 ffmpeg 抽取音频为 16kHz 单声道 wav，命令如下： ffmpeg -i <input> -vn -ar 16000 -ac 1 <output>.wav 2. 用 whisper 将音频转写为 srt 字幕，中文使用 small 模型： whisper <audio> --model small --language zh --output_format srt 3. 按每 5 秒 1 帧抽帧，保存到 frames/ 目录： ffmpeg -i <input> -vf fps=1/5 frames/frame_%04d.jpg 4. 读取字幕文件，按时间段归纳出 3-5 条场景摘要。 ## 输出规范 - 返回 Markdown 报告，包含：视频基本信息、字幕文件路径、关键帧路径、场景摘要 - 如果视频没有音轨，跳过转写，只做抽帧和画面分析 ## 注意事项 - 只有视频确实有音轨时才运行 Whisper - 输出的 srt 文件和 frames 目录必须放在与输入视频同级的 processing 目录下

这份模板的可贵之处，不在于写得多高级，而在于它有明确的边界。“这些情况我不处理”这种描述比“尽力而为”值钱得多。AI 拿到一份 SKILL.md 时，它最怕的是指令含糊导致反复猜测。

3.3 第三步：用常见开源工具串起抽帧与字幕

SKILL.md 里的命令，是整条流水线能不能跑起来的关键。这里我把我实际用得最多的一组命令拆开讲，每个参数都有它的作用。

第一步，抽音频。视频文件通常带着画面轨，但语音识别只需要声音，所以命令是：

ffmpeg -i input.mp4 -vn -ar 16000 -ac 1 audio.wav

-vn表示不要视频轨，-ar 16000把采样率压到 16k，这是 Whisper 输入的最优值，-ac 1合并成单声道，一方面减少计算量，另一方面避免双声道相位抵消导致的人声变糊。

第二步，语音转写。常用的开源转写工具是 Whisper，我建议直接用命令行参数一次到位：

whisper audio.wav --model small --language zh --output_format srt --output_dir subs

第三步，抽关键帧。这里的策略是宁多勿少：

ffmpeg -i input.mp4 -vf fps=1/5 frames/frame_%04d.jpg

fps=1/5表示每 5 秒输出一张。为什么选 5 秒？对于大多数口播和演示视频，5 秒一帧足够覆盖画面变化，再密就会产生大量几乎完全相同的图，纯属浪费。

第四步，如果需要把字幕烧录进视频：

ffmpeg -i input.mp4 -vf "subtitles=subs/output.srt:force_style='FontSize=18'"

force_style用来控制字体大小，24 适合全屏观看，18 适合作为素材后期二次编辑时参考。做这条命令时要注意，字幕文件路径里的冒号需要转义，否则 ffmpeg 会把它当成协议分隔符，这是我当时踩得最深的坑。

3.4 第四步：一次完整的实操回放

为了测试这套 Skill 是否靠谱，我用一段 12 分钟的录屏做了完整回放。录屏内容是某产品演示会议，有完整的语音、有画面切换、也有几段长时间没人说话的空档。

我把视频路径发给配好 Skill 的 Claude Code，然后让它“按标准流程处理”。它立刻启动了流程：先抽音频，16k 单声道 wav 文件大概花了十几秒；接着调 Whisper 转写，small 模型跑了大约两分钟，生成了一份带时间轴的 SRT；然后抽帧，12 分钟视频按 5 秒 1 帧抽出了 144 张图；最后它读取字幕文件，在返回的 Markdown 里给了 5 条场景摘要，还把第 3 分 20 秒到第 4 分 05 秒那段“无语音空档”识别出来，建议我在剪辑时切掉。

整个过程的体验非常接近一个助手在干活，而不只是输出一段代码让用户自己复制去执行。这就是 Skill 的价值所在：它把“读指令、想逻辑、对接工具、汇总结果”这个闭环完整跑通了。如果不用 Skill，你需要不停地在对话里贴命令、解释需求、等待确认，效率至少差一个数量级。

4. 参数与工具选型：让结果可复现

4.1 ffmpeg 常用参数速查表

视频处理的核心工具 ffmpeg，参数非常多，但实际高频用到的就那几个。我把常用任务整理成了一个速查表，每一条都标注了关键参数的作用，方便你直接拿来用。

这个表不是为了写完整手册，而是解决你 80% 日常需求的那部分。我每一条都实际跑过，尤其要提醒的是“截取片段”这一行，-ss的位置不同，解码方式不同，放在-i前虽然快，但有的版本会产生几帧误差。如果你要做精确到帧的剪辑，把-ss放到-i后面更保险，代价是解析时间更长。

4.2 Whisper 模型选型与参数建议

Whisper 的模型大小直接影响转写速度和准确率，也是很多人在配置 Skill 时纠结最多的地方。我的建议很简单：中文口播视频，直接用 small 起步；如果视频里有大量专业术语，再升级到 medium；tiny 和 base 只适合做粗听，不适合进生产流程。

除了模型大小，还有一个参数我强烈建议用：--word_timestamps True。它能帮你拿到每个词的时间戳，而不是只有整句的时间范围。这个时间戳在做字幕逐字对齐、自动混剪时非常关键。

注意一点：Whisper 对系统资源尤其是内存和显存的消耗并不低，配置 Skill 时要给一个内存限制判断。我在 SKILL.md 的前置条件里就写“输入视频不超过 60 分钟”，超过这个时长的，要求先分段再处理，否则很容易把机器跑死。

4.3 全自动不是目标，混合流程才是

我见过很多人一上来就追求“一条视频丢进去，成品直接出来”，结果被各种边界情况搞到崩溃。视频处理有个特点：确定性任务可以全自动，判断性任务必须留人工入口。

什么是确定性任务？抽音频、转字幕、检测静音、拼接片段，这些都是有标准答案的，交给工具和脚本一点问题都没有。什么是判断性任务？“选哪段作为高光”“哪个画面更适合做封面”“这句话要不要保留”，这些依赖语义理解和审美判断，现阶段最好让 AI 生成候选，人来拍板。

所以我的流水线设计是：AI 把所有中间产物准备好，把候选方案列出来，最后让用户做确认。这个“最后确认一步”省不了。实测下来，纯自动流程的返工率大概在 30%，而加了人工确认的混合流程，返工率能压到 5% 以内。真正高效的自动化，不是让你彻底甩手，而是让你把精力集中在最后那一下决策上。

5. 常见问题与排查技巧实录

5.1 Skill 没被加载时的排查顺序

在实际配置 Skill 的过程中，最常遇到的问题就是：明明把 Skill 目录放好了，AI 却好像完全不知道它的存在。遇到这种情况，我建议按下面这个顺序排查。

第一步，检查目录位置和命名。Skill 目录放错了层级，或者文件夹名字写错，AI 根本扫描不到；第二步，检查 SKILL.md 的元信息格式。有的版本要求 YAML 区域必须严格放在文件最顶部，前面哪怕多了一个空行或注释，元信息解析都可能失败；第三步，重启会话。这一点经常被忽略，Skill 的加载多数发生在会话启动阶段，运行中的会话不会自动拾取新文件；最后一步，换一个触发描述。如果你 SKILL.md 里的 description 写得太抽象，比如“处理视频文件”，AI 在遇到具体需求时不会主动关联到它。要把触发场景写具体，比如“当用户给出视频文件路径并希望提取字幕时使用”。

排查完仍然失灵，那就用最笨但最可靠的办法：直接新建一个空会话，问一句“你当前可用的技能有哪些”。如果列表里没有目标 Skill，说明它没被加载，回到前面四步逐项检查；如果列表里有，但执行时没触发，问题就出在 description 的触发描述上，改得更具体一些。

5.2 脚本跑不动时的通用自救法

视频处理 Skill 依赖命令行工具，所以不小比例的问题都出在环境层面，而不是 Skill 本身逻辑层面。

最常见的是 ffmpeg 未安装或不在 PATH 里。很多 Skill 的脚本内部直接写ffmpeg，但用户机器上根本没有全局安装，或者安装路径特殊，导致一执行就报 command not found。解决办法是检查你的 PATH 并补齐，或者把 ffmpeg 的完整路径写进 Skill 的工具清单里。

其次是输出目录不存在。抽帧、生成字幕这些操作都会创建目录，但很多 Skill 脚本没有 mkdir 这一步，目录一旦不存在就全盘失败。我在写自己的 Skill 时都会在开头加一句mkdir -p来保证目录就位，这一步看似多余，却省掉了大量排查时间。

再有一个专门针对长视频的问题：超时。当视频时长超过 20 分钟，Whisper 转写可能要跑 5 分钟以上，有些系统或者前端会有超时中断。我的通用自救法是给 Skill 加一个“分段策略”，先把视频按每 10 分钟切成小段，逐个处理，再把字幕合并。代价是拼接处会有一点时间轴偏差，但对于摘要场景，完全可以接受。

5.3 冷门 skill 与生产环境的隔离

前面说了那么多冷门宝藏的好处，但真要往生产环境放，我有一条铁律：第一遍运行，绝对不要在全局或者正式项目目录里跑。

我的做法是给第三方 Skill 单独建一个 test 目录，输入一个只有 30 秒的小样，执行一次完整流程，检查三件事：它生成的中间文件有没有写到奇怪的路径；它有没有尝试修改配置或用户目录之外的内容；它的输出格式是否符合预期。

这一步特别重要，因为开源社区里相当一部分 Skill 是作者为自己的机器写的，控制台输出、中间文件路径、临时目录名全都写死成作者本地的绝对路径。如果你不做隔离测试，第一次跑可能就直接在系统目录里留下一堆垃圾文件。

隔离测试通过之后，我才会把它正式装到用户级目录，并且把依赖项清理干净，尽量让 Skill 只依赖 ffmpeg、Whisper 这类常见工具，降低后续失效的概率。

5.4 我总结的 5 条避坑经验

折腾了一圈，我有五条切身体会，每条都是真金白银换来的。

第一，别迷信大项目，也别完全鄙视小项目。真正好用的 Skill 跟星数关系不大，跟项目作者自己用不用关系很大。第二，SKILL.md 里一定要写“不要做什么”，只写“做什么”的 Skill 会被 AI 发挥到不可控。第三，所有视频处理任务，优先把音频抽出来作为主分析通道，画面分析的成本高且收益不稳定。第四，抽帧密度宁密勿疏，关键帧漏掉一个，后面所有分析全受影响。第五，给所有 Skill 的执行步骤设定输出目录，并把中间文件统一管理，否则一个月后你会发现硬盘里到处都是零散的 srt 和 jpg。

这五条看起来都很朴素，但我在翻阅那 180 个项目时，发现大量项目恰恰是倒在这些细节上。能长期用的好 Skill，往往不是功能最花哨的，而是边界最清晰、出错最少的。

盘点完这 180 个视频相关 Skill，我个人最大的体会是：所有能真正跑起来的作品都有一个共同点——作者是真的在用一个具体场景解决问题，而不是急着做一个通用框架。那些把场景抠得太细、参数写得太活的项目，往往反而难以上手。

最后再分享一个实际操作中的小技巧：不要只装别人写的 Skill，把你自己经常要重复的那套手工命令整理出来，照着前面那份 SKILL.md 模板写一个自己的版本。等你能熟练把一段 10 步的手工操作压成一个“给个文件路径就自动跑完”的流程时，带来的效率提升，会比装任何第三方 Skill 都来得更明显。