企业官网建设流程全解析

1. 从“只会写代码”到“能剪片子”：这个项目到底在解决什么问题

第一次看到“让 Claude Code 学会做视频”这个说法，我脑子里冒出来的第一个念头是：一个终端里的代码助手，跟视频剪辑能扯上什么关系？后来花了两天时间把这一百多个开源 Skill 挨个翻了一遍，才明白这件事的底层逻辑其实特别朴素——Claude Code 本身只是一个推理内核，它真正的能力边界，取决于你给它挂了多少个“外挂技能包”。

所谓 Skill，你可以把它理解成给这个代码助手装的一个个“插件说明书”。每个 Skill 本质上就是一份结构化的指令文档，告诉模型在遇到某类任务时应该调用什么工具、按什么顺序执行、输出成什么格式。它跟传统意义上的插件不太一样，插件是往程序里塞代码，而 Skill 更像是往模型的“工作记忆”里塞一套标准作业流程。你给它一个“视频转码”的 Skill，它就知道该去调 ffmpeg；你给它一个“字幕生成”的 Skill，它就知道该走语音识别加时间轴对齐那条链路。

这个项目做的事情，就是把散落在各个角落的一百八十个开源 Skill 做了一次系统性分类盘点。这里面有相当一部分是大家耳熟能详的通用能力，比如文件处理、网络请求、数据转换；但真正让我兴奋的是那107 个冷门宝藏——这些项目在代码托管平台上的星标数普遍不到 50，有的甚至只有个位数，但它们解决的都是非常具体的垂直问题。视频处理这条线上，就藏着好几个这样的“小工具”，单独看每个都不起眼，串起来却能拼出一条完整的视频生产流水线。

我为什么觉得这件事值得写一篇长文来聊？因为大部分人对这类工具的认知还停留在“帮我写个函数”的阶段，完全没有意识到，当 Skill 的数量和种类积累到一定程度，这个代码助手实际上已经变成了一个可编程的自动化中枢。你可以用自然语言描述一个视频处理需求，它自己去拆解步骤、选择工具、执行命令、检查结果，中间不需要你写一行胶水代码。这个能力对做内容的人来说意味着什么，不用我多展开。

这篇文章适合三类人看：一是手里有一堆零散脚本、想找个统一调度层的内容创作者；二是对 AI 辅助工作流感兴趣、想看看实际能力边界的技术爱好者；三是单纯好奇“一个代码助手怎么就被玩成了视频工具链”的围观群众。我会把这一百八十个 Skill 的分类逻辑讲清楚，重点拆解视频处理这条线上那些不到 50 星的冷门项目到底能干什么，以及我是怎么把它们串起来跑通的。

2. 一百八十个 Skill 的分类逻辑：为什么这样分比按字母排更有用

2.1 按“能力层级”而不是“功能领域”来分类

拿到这一百八十个 Skill 的清单时，我第一反应是去找官方的分类标准。翻了一圈发现，大部分盘点文章都是按功能领域来分的——文件类、网络类、数据类、媒体类，诸如此类。这种分法看着整齐，但实际用起来有个很大的问题：你很难判断一个 Skill 在你当前的工作流里到底该放在哪一步。

举个例子，“视频抽帧”这个 Skill，按功能领域分它属于“媒体处理”，但实际用的时候，它可能是你整条流水线的第一步（从素材里提取关键帧做封面），也可能是中间某一步（抽帧后做画面分析），还可能是最后一步（生成预览图）。光看“媒体处理”这个标签，你根本不知道它该插在哪。

所以我更倾向于按能力层级来分。这个项目里的一百八十个 Skill，我把它重新梳理成了四个层级：

这个分层方式的好处是，你在设计工作流的时候，脑子里想的是“我现在需要哪一层的能力”，而不是“我需要哪个功能领域的工具”。比如你要做一个“把长视频自动切成短视频片段”的任务，你的思路会是：先用 L1 把素材读进来，用 L3 做场景切分找到自然断点，用 L2 把每个片段转成统一格式，最后用 L4 控制整个批处理流程。每一层需要什么 Skill，一目了然。

2.2 那 107 个冷门 Skill 为什么值得单独拎出来说

这一百八十个 Skill 里，有七十三个是相对主流的，星标数从几百到几千不等，功能也比较通用。剩下的一百零七个，星标数普遍在 50 以下，有的甚至只有两三个星。按常规逻辑，这些项目应该被归为“不成熟”或者“实验性”那一类，但我实际用下来发现，恰恰是这些冷门 Skill 解决了很多主流工具不愿意碰的“脏活累活”。

主流工具追求的是通用性，一个视频转码工具要支持几十种格式、上百个参数，代码量自然就上去了，维护成本也高。而那些冷门 Skill 往往只做一件事，比如“把 SRT 字幕的时间轴整体偏移 0.5 秒”或者“从视频里提取所有 I 帧的元数据”。这种需求太窄了，大项目看不上，但对于真正在做视频处理的人来说，这种小工具才是日常使用频率最高的。

我统计了一下这一百零七个冷门 Skill 的分布，大致是这样的：

• 视频处理相关：二十三个，涵盖抽帧、转码、字幕、水印、拼接、裁剪等细分场景
• 音频处理相关：十一个，包括降噪、变速、格式转换、音量归一化
• 图像处理相关：十八个，涉及批量缩放、格式转换、水印添加、色彩空间转换
• 文本与数据转换：二十六个，主要是各种格式互转和结构化提取
• 系统与文件操作：十九个，偏向底层文件管理和进程控制
• 其他杂项：十个，包括时间计算、随机数生成、编码转换等

这个分布很有意思，视频、音频、图像加起来五十二个，占了将近一半。这说明什么？说明做内容处理的人，对这类“小而专”的工具需求最旺盛。因为内容处理本身就是一堆琐碎步骤的集合，每个步骤都不复杂，但组合起来就很繁琐，正好是这些冷门 Skill 的用武之地。

2.3 分类之后怎么用：建立自己的 Skill 索引

光分类还不够，你得有一套自己的索引方式，才能在需要的时候快速找到对应的 Skill。我的做法是给每个 Skill 打三个标签：输入类型、输出类型、依赖工具。

比如一个“视频抽帧”的 Skill，输入类型是“视频文件路径”，输出类型是“图片文件列表”，依赖工具是“ffmpeg”。这样当我在设计一个工作流的时候，只要看当前步骤的输入输出能不能对上，就知道该选哪个 Skill。

这个索引方式还有一个好处：能帮你发现缺失的环节。比如你发现从“语音转文字”到“字幕时间轴对齐”之间，缺少一个“把纯文本按语义分段”的 Skill，那你就可以去这一百八十个里面找，或者自己写一个补上。整个工作流的设计过程，就变成了一个拼图游戏，每一块拼图都有明确的接口定义。

3. 视频处理这条线：从素材到成品的完整 Skill 链路拆解

3.1 素材预处理阶段：那些不到 50 星但每天都在用的工具

做视频的第一步永远是把素材整理成可处理的格式。这个阶段最烦人的不是技术难度，而是格式的碎片化。手机拍的、相机录的、屏幕录制的、从各种平台下载的，编码格式、分辨率、帧率、色彩空间全都不一样。你不可能用一套参数处理所有素材，必须先把它们统一。

这一百八十个 Skill 里，专门做素材预处理的冷门项目有七八个，我挑三个最常用的说一下。

第一个是“视频元数据提取”这个 Skill，星标数只有十二个。它的功能特别简单：读取一个视频文件，输出它的编码格式、分辨率、帧率、时长、码率、色彩空间、音频轨道信息。就这么一个功能，但它是所有后续处理的基础。你不知道素材的帧率，就没法做帧率转换；你不知道色彩空间，就没法做色彩校正。这个 Skill 底层调的是 ffprobe，但封装了一层结构化输出，直接给你 JSON 格式的结果，方便后续步骤解析。

第二个是“批量格式归一化”，星标数二十三个。它的逻辑是：你给它一个目录，它扫描里面所有视频文件，按照你指定的目标格式（比如 H.264 + AAC + MP4 容器）批量转码。关键参数有三个：目标分辨率、目标帧率、目标码率。我的经验是，分辨率不要盲目追求 4K，要根据最终发布平台来定。如果是在手机端观看为主，1080p 足够了，4K 只会让你的处理时间翻四倍，画质提升在手机屏幕上根本看不出来。

第三个是“音频轨道分离与标准化”，星标数只有八个。这个 Skill 做两件事：把视频里的音频轨道单独提取出来，然后做音量归一化（LUFS 标准）。为什么要单独做这一步？因为很多素材的音频电平不一致，有的片段声音大，有的片段声音小，直接拼接的话观感很差。归一化到统一的 LUFS 值之后，整个视频的听感会一致很多。这个 Skill 底层用的是 ffmpeg 的 loudnorm 滤镜，但把参数计算和批处理逻辑都封装好了。

这里有个坑要注意：音频归一化不要放在视频转码的同一步做，因为 ffmpeg 在处理视频滤镜和音频滤镜时，如果同时进行，可能会因为处理速度不匹配导致音画不同步。正确的做法是先分离音频、单独归一化、再合并回去。这个经验是我踩了两次坑才总结出来的。

3.2 内容分析阶段：把非结构化数据变成可操作的结构

素材预处理完之后，下一步是“理解”这些素材。视频本质上是一堆像素和音频采样点的集合，对人来说一目了然，对机器来说就是一堆数字。内容分析阶段要做的，就是把这些数字变成结构化的信息：哪里有人说话、说了什么、画面里有什么、场景什么时候切换。

这一百八十个 Skill 里，内容分析类的冷门项目大概有十五个，我重点说三个在视频流水线里最关键的。

语音转文字这个 Skill 星标数四十七个，算是冷门里比较热门的了。它的功能是把视频里的音频转成带时间戳的文本。底层调的是 Whisper 模型，但封装了音频提取、分段、识别、时间轴对齐的完整流程。关键参数有两个：模型大小和语言。模型越大识别越准，但速度越慢。我的建议是，如果素材主要是中文，用 medium 模型就够了，large 模型在中文上的提升没有英文那么明显，但速度慢了一倍不止。

场景切分这个 Skill 星标数只有十九个，但我觉得它是整个视频处理链路里最有价值的一个。它的原理是分析视频帧之间的差异，当画面变化超过某个阈值时，就认为是一个新的场景。输出是一系列时间点，标记了每个场景的起始和结束位置。这个信息有什么用？太有用了。你要做视频摘要，就在场景边界处切；你要做封面选取，就从每个场景里挑一帧；你要做片段拼接，就按场景来组织。没有这个 Skill，你只能按固定时间间隔切，切出来的片段经常在句子中间断开，观感很差。

关键帧提取这个 Skill 星标数三十一个。它跟场景切分不一样，场景切分找的是“画面变化大的地方”，关键帧提取找的是“画面信息量最大的地方”。底层用的是图像熵或者边缘检测算法，从每个场景里挑出最具代表性的那一帧。这个 Skill 我主要用来做视频封面和预览图，比随机抽帧的效果好很多。

3.3 成品输出阶段：拼接、转码、字幕烧录的细节处理

所有分析做完之后，最后一步是把处理结果输出成成品。这个阶段看起来简单，实际上坑最多。因为前面所有步骤的误差都会在这里累积，一个参数没对齐，输出就废了。

视频拼接这个 Skill 星标数二十六个。它的功能是把多个视频片段按顺序合并成一个。听起来很简单对吧？但实际操作中，如果两个片段的编码参数不一致（分辨率、帧率、像素格式、色彩空间），直接拼接会导致播放器解码错误。这个 Skill 的做法是：先检测所有片段的参数，如果有不一致的，先统一转码再拼接。这个预处理步骤很关键，我见过太多人直接 concat 然后播放器花屏的案例了。

字幕烧录这个 Skill 星标数只有十四个。它的功能是把 SRT 或 ASS 字幕文件硬编码到视频画面里。关键参数是字幕样式：字体、大小、颜色、描边、位置。我的经验是，字幕字号不要小于画面高度的 4%，否则在手机上看会非常吃力。另外，描边一定要加，不然字幕在浅色背景上会看不清。这个 Skill 底层用的是 ffmpeg 的 subtitles 滤镜，但把样式参数做成了预设，不用每次手写滤镜字符串。

批量导出这个 Skill 星标数九个。它的功能是：你给它一个时间轴文件（标记了每个片段的起止时间和输出文件名），它自动完成切割、转码、命名、归档的全流程。这个 Skill 是我用得最多的一个，因为做短视频剪辑的时候，经常需要从一个长视频里切出几十个片段，手动操作根本做不过来。它的时间轴文件格式很简单，就是三列：起始时间、结束时间、输出文件名。你可以用任何文本编辑器写，也可以从场景切分的结果自动生成。

4. 把 Skill 串起来：一条完整的视频处理流水线是怎么跑通的

4.1 流水线设计思路：从需求倒推步骤

前面把各个阶段的 Skill 都拆开讲了一遍，现在说怎么把它们串起来。我拿一个实际需求来举例：把一段一小时的访谈视频，自动切成十个一分钟左右的短视频片段，每个片段配好字幕和封面。

这个需求拆解下来，需要以下步骤：

1. 读取源视频，提取元数据（分辨率、帧率、时长）
2. 分离音频轨道，做音量归一化
3. 对归一化后的音频做语音转文字，得到带时间戳的文本
4. 对视频做场景切分，得到场景边界时间点
5. 结合语音文本和场景边界，找出语义完整的片段切分点
6. 按切分点切割视频，输出十个片段
7. 为每个片段生成字幕文件（从语音文本里截取对应时间段）
8. 把字幕烧录到每个片段里
9. 从每个片段里提取关键帧作为封面
10. 批量导出，按规范命名

这十个步骤，每一步都对应一个或多个 Skill。你不需要写代码，只需要在 Claude Code 里用自然语言描述这个流程，它会自动去调用对应的 Skill。当然，前提是这些 Skill 都已经安装好了。

4.2 关键环节的参数计算与选择过程

这里面有几个参数需要你手动决定，我一个个说。

场景切分的阈值。这个阈值决定了画面变化多大才算一个新场景。设得太低，一个镜头内的轻微晃动都会被当成新场景，切出来一堆碎片；设得太高，快速剪辑的片段会被合并成一个场景，切分点就不准了。我的经验值是0.3 到 0.4 之间（具体取决于 Skill 的实现，有的是 0-1 的归一化值，有的是像素差异百分比）。访谈类视频画面变化小，可以设低一点，0.25 左右；动作类视频画面变化大，要设高一点，0.5 左右。

片段时长的约束。需求里说“一分钟左右”，但实际切分的时候不能严格按 60 秒切，因为那样很可能在句子中间断开。正确的做法是：先按场景边界找出所有候选切分点，然后在这些切分点里选最接近 60 秒的。如果两个候选点一个在 55 秒一个在 68 秒，选哪个？我的经验是宁短勿长，因为短了可以补内容，长了在短视频平台上会被压缩或者截断。

字幕时间轴的偏移量。语音转文字出来的时间戳，跟视频画面之间往往有几毫秒到几百毫秒的偏差。这个偏差来自音频提取和识别的处理延迟。我的做法是：先输出一版带字幕的视频，人工看一遍，记下字幕比画面快还是慢，然后整体偏移对应的毫秒数。这个 Skill 支持传入一个偏移参数，单位是毫秒，正数表示字幕延后，负数表示字幕提前。

关键帧提取的数量。每个片段提取几张封面？我的建议是三到五张。太少了选择不够，太多了你挑不过来。提取的时候按画面信息量排序，取前五张就行。

4.3 实操现场记录：从零跑通一条流水线

下面是我实际跑这条流水线的过程记录，你可以照着复现。

第一步，确认环境。Claude Code 已经安装并配置好，ffmpeg 已经装好并且加入了系统路径。这两个是基础依赖，没有的话先去装。

第二步，安装需要的 Skill。我用到的是这几个：视频元数据提取、音频分离与归一化、语音转文字、场景切分、关键帧提取、视频切割、字幕生成、字幕烧录、批量导出。一共九个 Skill，都是从那 107 个冷门项目里挑出来的。

第三步，把源视频放到工作目录下，命名为source.mp4。

第四步，在 Claude Code 里输入指令。我的指令是这样的：

读取 source.mp4 的元数据，然后按以下流程处理： 1. 分离音频并归一化到 -16 LUFS 2. 对归一化后的音频做语音转文字，输出带时间戳的 SRT 文件 3. 对视频做场景切分，阈值设为 0.3 4. 结合语音时间戳和场景边界，找出十个语义完整的片段切分点，每个片段时长控制在 50 到 70 秒之间 5. 按切分点切割视频，输出到 output 目录 6. 为每个片段生成对应的字幕文件 7. 把字幕烧录到视频里，字幕字号设为画面高度的 4.5%，白色字体带黑色描边 8. 从每个片段提取三张关键帧作为封面 9. 所有输出文件按 segment_01、segment_02 的格式命名

第五步，等待执行。整个过程大概跑了二十分钟，其中语音转文字占了十五分钟（因为用的 medium 模型），场景切分和视频切割加起来五分钟。

第六步，检查输出。十个片段都在 output 目录里，每个片段有视频文件、字幕文件、三张封面图。我抽查了三个片段，字幕时间轴基本对齐，画面切割点都在场景边界附近，没有出现句子中间断开的情况。

这里有个细节：语音转文字那一步，如果视频时长超过半小时，建议先切成十分钟一段再转，不然内存占用会很高，而且一旦中间出错就要从头再来。这个 Skill 本身支持分段处理，但需要你手动指定分段时长。

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

5.1 视频处理链路中的典型故障速查表

5.2 那些文档里不会写的避坑经验

第一个坑：不要相信“自动检测”的参数。很多 Skill 都提供了自动检测源视频参数的功能，但自动检测经常出错，尤其是对于可变帧率（VFR）的视频。我的做法是：先用元数据提取 Skill 手动确认一遍关键参数，然后在后续步骤里显式指定这些参数，不要依赖自动检测。

第二个坑：中间文件要保留。我一开始为了省磁盘空间，每完成一步就删掉中间文件。结果有一次字幕烧录出问题，想重新生成字幕，发现语音转文字的中间结果已经被删了，只能从头再跑一遍二十分钟的识别。从那以后，我所有的中间文件都保留，直到最终成品确认没问题再清理。

第三个坑：批量处理一定要加错误重试。处理几十个片段的时候，偶尔会有一两个因为各种奇怪的原因失败（磁盘 IO 波动、内存不足、临时文件冲突）。如果没有重试机制，整个批处理就会中断。我的做法是在批量导出 Skill 里配置重试次数为 3，重试间隔为 5 秒。这个配置在 Skill 的文档里没有写，是我自己试出来的。

第四个坑：字幕烧录的字体大小要按比例算，不要用固定值。我一开始设的是固定 24 号字，结果在 1080p 视频上看着正好，在 4K 视频上就小得看不清。正确的做法是按画面高度的百分比来设，我一般用 4.5%，这样不管分辨率怎么变，字幕的视觉大小都是一致的。

第五个坑：场景切分的阈值不是固定的。不同类型的视频要用不同的阈值。访谈类 0.25，vlog 类 0.35，动作类 0.5，动画类 0.4。这个经验值是我处理了几十种不同类型的视频之后总结出来的，你可以根据自己的素材特点微调。

5.3 性能优化的几个实用技巧

并行处理。如果你要处理多个视频文件，不要一个一个串行跑，用任务队列 Skill 把它们并行起来。我的机器是八核，一般同时跑四个任务，再多了磁盘 IO 会成为瓶颈。并行处理能把整体处理时间缩短到原来的三分之一左右。

硬件加速。ffmpeg 支持硬件加速编解码，如果你有独立显卡，转码速度能提升三到五倍。这个需要在 Skill 的配置里指定硬件加速参数，具体参数取决于你的显卡型号。我用的配置是-hwaccel auto，让 ffmpeg 自动选择可用的硬件加速方式。

缓存中间结果。语音转文字是最耗时的步骤，如果你需要对同一个视频做多次处理（比如调整切分点后重新生成片段），不要把语音转文字也重新跑一遍。把第一次的识别结果保存下来，后续步骤直接读取。这个 Skill 支持指定输出文件路径，你只要把路径固定下来就行。

合理设置超时时间。批量处理的时候，如果某个任务卡住了，没有超时机制的话整个队列都会堵住。我的做法是给每个任务设置一个超时时间，一般是预估处理时间的三倍。超时后自动跳过并记录日志，等所有任务跑完再统一处理失败的任务。

6. 这套 Skill 体系的扩展玩法

6.1 从视频处理延伸到其他内容形态

这套 Skill 体系的底层逻辑是“把非结构化数据变成结构化数据，再按规则重组”，这个逻辑不局限于视频。我后来把这套思路迁移到了播客处理上：用音频分离 Skill 提取音轨，用语音转文字 Skill 生成文稿，用文本分段 Skill 按语义切分，最后用批量导出 Skill 生成每段的音频文件和对应的文字稿。整个流程跟视频处理几乎一模一样，只是把视频相关的 Skill 换成了音频相关的。

再进一步，图片处理也是同样的逻辑。批量缩放、格式转换、水印添加、色彩空间转换，这些 Skill 组合起来，就是一个图片批处理流水线。我甚至用这套体系做过一次电子书处理：把 PDF 拆成单页图片，对图片做 OCR 提取文字，把文字按章节重组，最后输出 Markdown 格式的电子书。整个过程没有写一行代码，全靠 Skill 组合。

6.2 自己写 Skill 的门槛比想象中低

这一百八十个 Skill 里，有相当一部分是个人开发者写的，代码量并不大。我翻过几个冷门 Skill 的源码，核心逻辑也就一两百行。Skill 的本质是一份指令文档加一个执行脚本，指令文档告诉模型什么时候调用这个 Skill，执行脚本告诉模型具体怎么执行。

如果你有一个反复用到的处理步骤，完全可以自己写一个 Skill 封装起来。比如你经常需要把视频里的某一段截取出来并转成 GIF，这个操作在 ffmpeg 里就是一行命令，但每次都要手写参数很麻烦。写成一个 Skill 之后，你只需要说“把第 30 秒到第 45 秒转成 GIF”，它就知道该怎么做。

写 Skill 的关键是把参数和逻辑分离。参数是每次调用可能变化的部分（比如起始时间、结束时间、输出格式），逻辑是固定不变的部分（比如调用哪个工具、按什么顺序执行）。把这两者分开之后，你的 Skill 就能复用到各种不同的场景里。

6.3 冷门 Skill 的维护与更新策略

那 107 个冷门 Skill 里，有一部分已经很久没有更新了。这很正常，个人项目嘛，作者可能早就去做别的事情了。但这不意味着这些 Skill 就不能用了。我的策略是：核心逻辑稳定的 Skill 可以直接用，依赖外部服务的 Skill 要谨慎。

什么叫核心逻辑稳定？比如视频抽帧、格式转换、文件操作这类，底层依赖的是 ffmpeg 这种成熟工具，只要 ffmpeg 的接口不变，Skill 就能一直用。什么叫依赖外部服务？比如某个 Skill 调用了某个在线 API 做语音识别，那这个 API 一旦变更或者收费，Skill 就废了。

对于前者，我直接拿来用，遇到问题自己改改脚本就行。对于后者，我会优先找本地实现的替代方案。比如语音转文字，我用的就是本地 Whisper 模型的 Skill，不依赖任何在线服务，虽然速度慢一点，但稳定性和隐私性都好很多。

还有一个经验：定期把你常用的 Skill 做个备份。这些冷门项目随时可能从代码托管平台上消失，作者删库跑路的事情我遇到过不止一次。备份的方式很简单，把 Skill 的整个目录复制一份到你的本地仓库里就行。

7. 我在这套体系里踩过的最大一个坑

说了这么多经验和技巧，最后分享一个我踩过的最大的坑。刚开始用这套体系的时候，我特别兴奋，觉得终于可以全自动处理视频了。于是我把所有能装的 Skill 都装上了，一共装了一百多个。结果第一次跑任务就出问题了：Claude Code 在规划执行步骤的时候，面对一百多个可用的 Skill，完全不知道该选哪个。它一会儿试试这个，一会儿试试那个，一个简单的视频转码任务跑了半个小时还没跑完。

后来我才明白，Skill 不是越多越好，而是要跟你的实际需求匹配。你装了一百个 Skill，模型的选择空间就有一百个，决策成本非常高。正确的做法是：只装你当前工作流需要的 Skill，一般十到二十个就够了。需要新能力的时候再装新的，不需要的就卸掉。

这个经验让我重新思考了“工具丰富度”和“执行效率”之间的关系。工具多了确实能覆盖更多场景，但每个工具的存在都会增加决策的复杂度。找到一个平衡点，让工具集刚好覆盖你的核心需求，同时保持足够的简洁，这才是用好这套体系的关键。

我现在的工作流里只保留了十五个 Skill，覆盖视频处理的完整链路，外加几个通用的文件操作 Skill。跑一个一小时的视频处理任务，从素材到成品大概二十五分钟，其中语音转文字占了大头。这个效率对我来说已经足够了，毕竟以前手动做同样的工作，没有三四个小时根本下不来。