作者:莫潇羽@无忆研习社(www.wuyi.wiki)
转载请注明出处
快速摘要
video-use 是 Browser Use 团队在 GitHub 上开源的一个 Claude Code Skill,核心作用是让 AI 代理自动完成视频剪辑。 把原始素材扔进一个文件夹,在 Claude Code 里用自然语言描述需求,它会自动盘点素材、提出剪辑策略、等你确认,然后去掉口头禅与无效停顿、做色彩调级、在每个切点加 30 毫秒音频淡入淡出、烧录字幕、甚至生成动画叠加层,最后输出一个 final.mp4。
最值得关注的不是功能本身,而是它的实现思路。 传统做法是把视频逐帧喂给多模态模型,一条几分钟的素材就能干到上千万 Token。video-use 反其道而行之,借助 ElevenLabs Scribe 生成词级时间戳的转录文本作为"常驻阅读界面",只在需要确认剪切点时才按需合成一张"胶片条+波形+字词标签"的可视化图像给大模型看。这种"文本为主、视觉按需"的路径,和该团队此前做 browser-use(用结构化 DOM 替代网页截图)是同一套方法论的迁移。
下文会拆解:它解决了什么问题、两层架构如何工作、十二条硬性规则为什么是硬性、完整剪辑流水线的每一步在做什么、以及从零开始的安装配置与第一次对话剪辑的完整操作。 想直接上手的读者可以跳到第七部分。
一、视频创作者的真实痛点,从来不在拍摄
做过视频的人都知道,真正消耗心力的环节其实不是脚本、也不是录制,而是后期剪辑。打开剪辑软件,一帧帧切掉那些"呃"、"嗯"、"哎"、"那个"、"就是说"的口头禅,切掉讲错重说的前半段,然后打点、试听、调色、配字幕、加动效。对于一条只有几分钟的成片,坐在电脑前磨三四个小时属于家常便饭。更糟糕的是,这些劳动绝大多数是重复且没有技术含量的,真正需要创作判断的时刻可能只有十几次决策,却被淹没在几百次机械裁剪里。
过去几年里,行业尝试过各种自动化工具,有的产品能识别静音片段一键删除,有的能自动生成字幕,有的能做模板化包装。但这些工具普遍存在一个结构性问题:它们把"视频剪辑"理解成一串固定动作,做成按钮和菜单让你点。你想让它判断"这一段我讲错了,用下一条的那个更好",它做不到,因为这需要真正的语义理解和上下文判断。
这正是大语言模型开始介入视频领域的原因。随着多模态模型理解能力越来越强,一个朴素的设想出现了:既然 AI 能读懂一段视频在说什么,为什么不能让它直接动手剪?事实上,过去一年确实涌现出一批试图"用 AI 剪视频"的项目,但它们往往撞上同一堵墙,把视频喂给模型这件事成本高得离谱。
我(莫潇羽@无忆研习社)自己测试过一种常见做法,先把视频按每秒一帧或者每秒两帧拆出来,然后把图片序列塞给多模态模型。看起来很合理,但算一笔账就知道,一条十分钟的视频,按每秒两帧算就是一千两百帧,一帧图像的 Token 消耗大约一千五到三千不等,保守估计每次调用要烧掉两百万到三百万 Token,而且模型还只是"看"了画面,没有听懂一句话。这种做法在学术 Demo 里演示一次没问题,真要落到日常创作工作流里,成本和延迟都让人望而却步。
video-use 的出现,刚好把这个行业里绕不开的结构性难题用一种非常巧妙的路径给绕开了。
二、video-use 是什么,以及它背后的团队
video-use 在 GitHub 的仓库地址是 github.com/browser-use/video-use,作者署名是 Browser Use 团队。这个团队之前做的另一个开源项目 browser-use 在社区里相当有名气,目前 GitHub Star 数已经稳定在七万八千以上,核心能力是让 AI 代理自主控制浏览器完成操作任务,包括登录、填表、搜索、提取内容等,被大量 AI Agent 项目当成基础设施引用。
video-use 是他们把同一套思路延伸到视频剪辑领域的产物。它不是一个独立的应用程序,也不是一个需要单独运行的服务,而是一个 Claude Code Skill。什么是 Skill 呢,简单说就是 Claude Code 这个命令行工具支持外部加载的"技能包",本质是一个目录,里面放着 SKILL.md 作为说明书、一些辅助脚本,以及项目依赖。Claude Code 启动时会扫描 ~/.claude/skills/ 下的所有子目录,读取各个 SKILL.md 的前言(frontmatter)元数据,判断当前用户输入是否和某个技能匹配,如果匹配就加载对应规则进入上下文。video-use 的定位就是这样一个"视频剪辑技能包",安装好之后,在任意一个放着视频素材的文件夹里打开 Claude Code,你让它剪视频,它就会自动调用这个技能。
这个设计思路很值得玩味。它没有做成 Electron 桌面软件,也没有做成网页应用,而是和当前最活跃的 AI 编程代理(Claude Code)深度绑定。原因很简单,剪视频这件事本质是一堆 FFmpeg 命令、Python 脚本和文件操作的组合,Claude Code 本身就擅长这些事情。与其自己从头造一个图形界面再教模型用鼠标点击,不如把全部能力以脚本和规则的形式喂给已经很强的代理,让它自己去组织。
从仓库结构看,video-use 的体量并不大,主要文件就是一个长达三百多行的 SKILL.md 规则说明,加上 helpers/ 目录下若干个 Python 脚本(transcribe、pack_transcripts、timeline_view、render、grade 等),再加一个内置的 skills/manim-video/ 子技能用于生成数学可视化动画。代码仓库以 Python 为主(约占 75%),辅以少量 HTML 和 Shell,许可证遵循开源协议。
需要明确一点,video-use 当前还处在相对早期的阶段,仓库里的提交次数不多,Star 数也还在缓慢积累。它更像是一个"方法论样板"而不是一个"成熟产品"。但正因为如此,它的代码和文档非常值得读者细读,因为还没有被后续的 PR 和改动冲淡核心设计意图。
三、功能全景,它到底能做什么
如果只用一段话概括,video-use 能做的事情是,把一堆未经剪辑的原始素材,变成一条可以直接发布的短片。但展开看,这个"剪辑"包含的工作相当细致。
自动识别并删除口头禅与无效停顿。 这是视频博主最常做的重复劳动之一。video-use 通过 ElevenLabs Scribe 获得词级时间戳的转录,在这个转录上做逻辑判断,识别出"呃"、"嗯"、"啊"、"那个"、"就是说"、"对"这类语气词,以及讲错话后的重启(比如"我觉得这个,啊不对,这个项目的重点在于..."),然后计算出每段话之间的静音间隔,最后生成一份"哪些片段保留、哪些丢弃"的决策列表。
为每段素材做色彩调级。 这一步不是套用某个固定滤镜,而是按 ASC CDL(美国电影摄影师协会色彩决策表)的模型做参数化调整,拆成 slope(斜率,控制高光)、offset(偏移,控制阴影)、power(幂次,控制中间调)三个维度。项目内置了两个示例预设,一个叫 warm_cinematic,轻度的青橙分离加降饱和,适合访谈和口播;另一个叫 neutral_punch,只做对比度提升和轻微 S 曲线,不做色相偏移。也支持用户直接传入任意 FFmpeg 滤镜链。
在每个剪切点加 30 毫秒音频淡入淡出。 这是视频剪辑的专业细节。两段素材直接拼接的时候,音频波形在接缝处会产生一个瞬时跳变,听感上就是"啪"的一声爆音。解决办法是在每段的开头做三十毫秒的音频淡入,结尾做三十毫秒的音频淡出。video-use 把这一步变成一条硬性规则,每次渲染都会自动做,不需要你操心。
烧录字幕。 默认样式是两个字一组的大写 Helvetica 粗体,白底黑边,贴近现在主流短视频平台的视觉语言。当然字体、大小、颜色、位置、分块方式都可以在对话里改。字幕的时间轴自动和剪辑后的输出时间对齐,这一点看似理所当然,但实际上在多段拼接场景下非常容易出错,下文会专门讲为什么。
生成动画叠加层。 这一点比较有意思。video-use 支持三种动画生成方案,PIL 用来做简单的叠加卡片(计数器、打字机文字、进度条、简单绘制动画),Manim 用来做正式的数学/物理动画(状态机图、方程推导、图论演示),Remotion 用来做排版重、品牌感强的网页风格动画(基于 React/CSS)。当需要多个动画时,它会并行派生多个子代理,每个子代理负责一个动画,整体墙钟时间约等于最慢的那一个。
自我验证渲染结果。 这是我觉得最不寻常的设计。渲染完成后,系统会在每个剪切点自动抓取一张"胶片条+波形"的合成图,检查有没有画面跳接、是否有爆音漏网、字幕是不是被叠加层遮挡、叠加动画的窗口起点帧对不对。如果发现问题,就回炉重新渲染,最多重试 3 次。只有通过了自检的预览才会展示给用户。
会话记忆。 每次剪辑的策略、选择、遇到的问题、推理过程,都会写进该项目目录下的 project.md 文件。下次再用 Claude Code 打开同一个文件夹,它会读这份文件,总结上次到哪儿了,然后问你要不要接着来。这对长期维护一个视频专栏的创作者特别有用,比如连载 vlog、系列教程、连续播客。
四、核心原理,为什么它敢说"LLM 根本不看视频"
看完功能清单,真正的问题才浮出水面,这套流水线是怎么让 LLM 在成本和延迟都可控的前提下做出剪辑决策的?答案藏在一个听起来有点违反直觉的设计哲学里:video-use 里的大语言模型,从头到尾都没有真的"看"过视频。
4.1 传统思路撞上了算力天花板
我(莫潇羽@无忆研习社)在前面算过一笔账,再重复一次,是因为这个数字非常关键。一条十分钟的视频,按 30 FPS 算一共 18000 帧,抽样到每秒两帧也还有 1200 帧。每帧塞给多模态模型大约消耗 1500 到 3000 Token。最乐观的估计,一次完整剪辑的输入 Token 也要达到 180 万到 360 万。这还只是视觉部分,音频解析、对话上下文、剪辑规则都还没算进去。如果剪辑过程中需要多轮推理(基本上是必然的),Token 消耗会再翻几倍。
更要命的是,即便算力不计成本,一帧帧的视觉信息对剪辑决策的帮助其实也很有限。判断"这句话要不要保留"需要的是语义层的理解,看画面几乎没用;判断"这一帧画面有没有画面跳接"需要的又只是两张相邻的缩略图,完全不需要整段视频。也就是说,大部分帧画面对剪辑来说都是信息噪声,塞进去不仅贵,还会稀释有用信号。
video-use 把这个判断推到了极致,它直接说,既然视频的剪辑决策 90% 来自语音内容,那就只给 LLM 读语音内容;剩下 10% 真正需要看画面的决策点,再去现场合成一张视觉信息。
4.2 第一层:音频转录层,常驻加载
video-use 在会话开始时做的第一件事,是把目录里所有视频跑一遍 ElevenLabs Scribe 转录。Scribe 是 ElevenLabs 推出的语音识别模型,目前最新版本是 Scribe v2,支持 90 种以上语言,具备三个对剪辑来说至关重要的能力。
- 词级时间戳。每一个单词都带精确到毫秒的起始时间和结束时间,不是常规 SRT 那种句子级时间戳。这个细节是视频剪辑精度的命门,如果只知道"这句话从第 12 秒到第 15 秒",你永远不知道应该在第几个单词后面下刀;而有了词级时间戳,就能让 AI 把切点精确到任意一个单词的边界。
- 说话人分离。Scribe 会自动识别多达 32 个不同说话人,并在转录结果里用 S0、S1、S2 这样的标记区分。这对采访、对谈、播客类视频极其关键,因为剪辑决策经常是"先留主持人的这句,再切到嘉宾的回答"。
- 音频事件标签。Scribe 会识别非语言的声音事件,比如
(laughter)笑声、(applause)掌声、(sigh)叹息、(cough)咳嗽。这些事件在 video-use 的剪辑规则里被当作"节拍信号"使用,遇到(laughs)就要延长剪切点,把笑声完整保留,因为笑声本身就是内容的一部分。
转录完成后,video-use 把所有素材的转录打包成一个叫 takes_packed.md 的文件,以短语(phrase)为粒度组织,静音超过 0.5 秒就换行。大概长这样(为便于阅读,我把原始示例翻译为中文语境):
## C0103 (duration: 43.0s, 8 phrases)
[002.52-005.36] S0 网络代理做的事情,九成都是完全浪费。
[006.08-006.74] S0 我们把它修好了。
[007.20-014.88] S0 以前的代理每秒都要截一次图,现在不用了……整份打包文件通常只有 12KB 左右,相比动辄几十兆的原始 JSON 要精简一个数量级。这是大语言模型阅读的"主视图",也是整个流水线中最关键的数据结构。
4.3 第二层:视觉合成层,按需调用
当光靠文本无法做判断时,比如某段静音长达一秒但不知道是因为说话人思考还是画面切换,或者两个镜头拼接后需要确认有没有视觉跳变,这时候 video-use 会调用一个叫 timeline_view 的辅助脚本。
它接收三个参数,视频路径、开始时间、结束时间。然后现场合成一张 PNG 图片扔给 LLM。这张图上有什么呢,可以理解成一个"时间线剖面":
- 最上面是胶片缩略图(filmstrip),按固定间隔抽几帧画面拼成一条;
- 中间是音频波形(waveform),可视化这段时间里声音的起伏;
- 下面是词语标签,每个单词标注在对应时间位置上;
- 静音间隙会用特殊标记标出,作为候选剪切点。
这张图同时把"画面、声音、语言"三个维度压缩到一张可见的视觉工作区里,LLM 看一眼就知道这段是怎么回事。关键是,它只在真正需要的时候被生成,平均一次完整剪辑可能只调用三五次。
打个比方会更好理解。传统逐帧喂视频的做法,相当于你让一个朋友帮你找一本书里的一段话,结果你把整本书的每一页都拍照发给他。而 video-use 的做法,相当于先给朋友一份带页码的目录和全文电子版,让他先根据目录和全文定位,只在确实需要核对版面的时候才请他看某一页的扫描图。
4.4 这套方法论的来源,不是凭空想出来的
这种"文本主视图加按需视觉"的模式,并不是 video-use 首创。Browser Use 团队在他们的前作 browser-use 里就验证过一次。
browser-use 要解决的问题是让 AI 代理操作网页。当时主流做法也是把网页截图发给多模态模型,让模型"看"着屏幕点击。但 Browser Use 团队选择了另一条路,把网页的 DOM 结构提取成一个文本化的结构化描述,每个可交互元素标上编号,LLM 读这份"DOM 地图"就能判断该点哪里。只有在 DOM 无法表达的场景(比如判断视觉布局是否正常)才会调用截图。这个设计让 browser-use 在很长一段时间里成为最轻量、最省钱的浏览器代理方案,也是它 GitHub Star 数能冲到 7.8 万的关键原因之一。
video-use 完全是这套思路的复制粘贴。只不过这次,"结构化 DOM"的位置被换成了"词级时间戳的转录文本",而"网页截图"的位置被换成了"胶片+波形的合成图"。结构一模一样。
这件事的意义其实比 video-use 本身更深远。它提示我们,对于任何需要 LLM 理解复杂媒介的场景,真正重要的不是把媒介原样喂进去,而是先把媒介压缩成一个适合阅读的文本化结构,再让视觉作为辅助。这种压缩不是简单的摘要,而是保留决策所需全部信息、去除噪声的有损编码。这种思路值得任何在做 AI 应用的读者认真借鉴。
五、完整流水线,从素材到成片的八步
现在我们把完整的工作流拆开看一遍。video-use 的 SKILL.md 里把整个流程规定成八个步骤,每一步都有明确的输入输出。
第一步,盘点。进入一个素材目录,系统会用 ffprobe 扫描每个视频文件,拿到时长、分辨率、帧率、编码格式等信息。然后 transcribe_batch.py 并行转录所有源,默认 4 个 worker 同时跑,缓存到 edit/transcripts/ 下(文件名按源文件哈希命名)。接着 pack_transcripts.py 把所有 JSON 转录合并成一份打包的 takes_packed.md。最后会抽一两个时间段跑 timeline_view 获取视觉初印象。
第二步,问题预扫。系统一次性通读 takes_packed.md,标记出明显的口误、念错的词、不合适的表达。这些会作为"避免项"进入后续的剪辑简报,相当于提前把"这段讲错了,不要选"告诉编辑器子代理。
第三步,对话。系统用普通话描述它看到了什么,然后基于素材本身的特点向用户提问。特别要注意的是,video-use 在规则里明确禁止使用固定的问题清单,它强调每次问题都要根据素材形态来设计。例如如果素材是口播访谈,问题可能是"你希望保持对话节奏还是做节奏压缩",如果是旅行 vlog,问题可能变成"需要保留环境音吗,还是全程铺背景音乐"。这种设计避免了"一刀切"的流水线感。
第四步,提出策略。系统会用四到八句话描述它的剪辑方案,包括整体结构(比如 HOOK 开场→PROBLEM 痛点→SOLUTION 方案→EXAMPLE 举例→CTA 号召)、选用哪些 take、剪辑方向、动画规划、调色方向、字幕风格、预计时长。然后它会停下来等你确认。这一条在 video-use 的硬性规则里,没有用户点头,不能动手。
第五步,执行。策略确认后,系统通过一个叫"编辑器子代理"的独立任务生成 edl.json(Edit Decision List,剪辑决策清单)。在含糊不清的剪切点上,子代理会调用 timeline_view 查看。动画则通过并行子代理构建,每个动画一个子代理。色彩调级在每段提取时应用(注意,不是拼接之后统一调,后面会讲为什么)。最后 render.py 把所有东西组合成预览片。
第六步,预览渲染。使用 render.py --preview 生成 720P 快速预览,方便在对话里快速迭代。
第七步,自检。这一步是 video-use 最有特色的设计之一。渲染完成后,系统会在每个剪切点的前后 1.5 秒窗口内跑一次 timeline_view,逐一检查每张合成图,看有没有四类问题:
- 画面在切点处是否有视觉跳变、闪烁、突跳;
- 音频波形在边界处是否出现异常尖峰,说明三十毫秒淡入淡出没起作用;
- 字幕是否被叠加层遮住(这违反硬性规则第一条);
- 叠加动画的起点帧是否对齐(这违反硬性规则第四条)。
同时还会抽查开头两秒、结尾两秒、中间两到三个采样点,检查调色一致性、字幕可读性、整体连贯性。还会用 ffprobe 检查输出时长是否和 EDL 里声明的一致。如果发现问题,自动修复并重新渲染。整个自检循环最多跑 3 次,超过 3 次还没过就上报给用户,避免无限循环。
第八步,迭代+持久化。用户看了预览后,用自然语言给反馈("第三段再紧一点"、"开头那个笑声多留点"),系统重新规划、重新渲染。注意,任何情况下都不重新转录,转录结果是纯函数的输出,同一个文件不会变。确认最终版本后,系统把本次会话的策略、决策和推理追加到 project.md。
整个流程在 SKILL.md 里被总结成一条极简的生产原则:Ask → Confirm → Execute → Self-Eval → Persist(问→确认→执行→自检→持久化)。这五个动词,每一个都有明确的边界,没有任何一个可以跳过。
六、十二条硬性规则,视频剪辑的隐形深坑
video-use 的 SKILL.md 里有一节专门列出"Hard Rules",规定了 12 条无论如何都不能违反的规则。这些规则不是品味问题,而是工程正确性问题,违反它们产生的往往是"静默失败"(silent failure),就是最终视频看起来没错,但实际上有潜在 Bug。下面逐条拆解,顺便也算是给想自己写视频处理管线的读者一份避坑地图。
第一条,字幕必须是滤镜链中最后一步,在所有叠加层之后。理由很直白,如果先烧字幕再叠图层,图层就会盖住字幕。肉眼可能不会立刻发现,因为有时候叠加层是半透明的,你以为字幕还能看,实际上已经被挡掉关键字。
第二条,必须逐段提取再无损拼接,不能用单次滤镜图(filtergraph)一把梭。意思是,正确做法是先把每一段按区间独立抽取成单独的视频文件,对每一段分别做调色和淡入淡出,然后用 -c copy 无损拼接;错误做法是写一个大的 FFmpeg filtergraph 一次性处理所有段落。后者看起来更简洁,但每次加叠加层时都要对整段重新编码两遍,画质会有可察觉的损失。
第三条,每个剪切边界加 30 毫秒音频淡入淡出。具体的 FFmpeg 滤镜写法是 afade=t=in:st=0:d=0.03,afade=t=out:st={dur-0.03}:d=0.03。省了这一步,每一刀都是"啪"一声,观众看不清为什么但就是觉得不舒服。
第四条,叠加层必须使用 setpts=PTS-STARTPTS+T/TB 的时间戳重置。这一条有点技术细节,简单说就是把叠加动画的起始帧(frame 0)对齐到它在输出视频中的显示窗口起点,不然你看到的会是动画中段某一帧,因为它还在按原始时间轴计时。
第五条,主字幕 SRT 必须使用输出时间轴偏移。公式是 output_time = word.start - segment_start + segment_offset。也就是说,词在原始素材里的时间减去段起点,再加上这段在输出中的位移。漏了这一步,字幕会在多段拼接的场景下整体错位,越往后越离谱。
第六条,永远不要在单词中间切断。所有的剪切边界必须对齐到 Scribe 转录里的单词边界。这一条听起来常识,但自动化管线里漏这一步是常见错误,后果是听感上像吞音。
第七条,每个剪切边界都要加 padding,工作区间是 30 到 200 毫秒。原因是 Scribe 给出的时间戳会有 50 到 100 毫秒的漂移,padding 的作用就是吸收这个漂移。快节奏素材 padding 紧一些(30 到 80 毫秒),电影感素材 padding 松一些(100 到 200 毫秒)。
第八条,只用词级 verbatim(逐字)ASR,绝不用 SRT 或短语模式。也绝不用"规范化口头禅"(把"呃"、"嗯"自动吞掉)的功能。前者会丢掉亚秒级的静音信息,后者会丢掉你可能想保留的编辑信号。
第九条,转录结果必须缓存。同一个源文件只转录一次,除非源文件本身变了。这条看似显而易见,但很多快速实现会忘掉缓存,每次对话都重新调一次 API,既慢又烧钱。
第十条,多个动画必须并行,不能串行。通过 Agent 工具一次性派生多个子代理,每个子代理一个动画。总墙钟时间约等于最慢那一个,而不是所有动画时长之和。这对需要在一个视频里加三到五个动画叠加的场景极其重要。
第十一条,策略确认前不得动手剪。这条是整个对话式体验的基石。AI 可以提方案、可以问问题、可以展示分析,但在用户点头之前,不能生成任何 EDL、不能启动渲染、不能写出 final.mp4。
第十二条,所有会话输出写在 <videos_dir>/edit/ 下,绝不污染 video-use/ 项目目录本身。这是一条卫生规则,保证你的素材目录和技能仓库之间的边界清晰。
把这十二条串起来看,你会发现一个有趣的规律,它们绝大多数都是关于"时间"的。音频时间戳、字幕时间戳、动画时间戳、剪切边界、淡入淡出时长、padding 范围。视频剪辑的本质就是在时间维度上做精确的手术,而时间不对齐造成的错误又往往不会立刻报错,只会在成片里以"不对劲"的形式浮现。
七、安装部署全流程,从环境到第一次对话
讲完了原理,来看实际操作。我(莫潇羽@无忆研习社)假设你已经装好了 Python 和 Claude Code,下面从克隆仓库讲起。如果你还没装过 Claude Code,可以去 Anthropic 的官方文档找到安装方法,它是一个基于 Node.js 的命令行工具,支持 macOS、Linux 和 Windows(WSL)。
7.1 环境准备
video-use 需要的基础环境有以下几个:
- Python 3.10 或以上版本。仓库里用
pyproject.toml管理依赖,安装时会自动解析。 - FFmpeg 和 ffprobe。这是 video-use 最核心的外部依赖,所有视频处理都依赖它。macOS 上用
brew install ffmpeg,Linux 上用各家包管理器,Windows 上可以从官方二进制下载并加入 PATH。 - yt-dlp(可选)。如果你希望让它直接从 YouTube、Bilibili 等在线平台下载素材后再剪辑,装一下这个。
- ElevenLabs API Key。转录服务需要。去 ElevenLabs 官网注册账号,在 API 页面创建 key。新账号有免费额度可以测试。
7.2 克隆并链接到 Skills 目录
打开终端,运行下面的命令:
# 克隆仓库
git clone https://github.com/browser-use/video-use
cd video-use
# 把当前目录软链接到 Claude Code 的 skills 路径
# macOS/Linux 写法
ln -s "$(pwd)" ~/.claude/skills/video-use这里用软链接(symlink)而不是复制,是为了方便后续 git pull 升级时直接生效。Windows 用户可以用 mklink /D 创建目录符号链接,或者直接把文件夹复制到 %USERPROFILE%\.claude\skills\video-use。
7.3 安装依赖
继续在 video-use 目录下:
# 以可编辑模式安装 Python 包
pip install -e .
# 安装系统依赖(macOS 示例)
brew install ffmpeg
brew install yt-dlp # 可选Linux 用户可以换成 apt/yum/dnf 对应的包管理器。pip install -e . 的好处是,你对 helpers/ 目录下任何脚本的修改都会立刻生效,不需要重新安装。
7.4 配置 API 密钥
把示例环境变量文件复制一份:
cp .env.example .env然后用文本编辑器打开 .env,填入:
ELEVENLABS_API_KEY=你在 ElevenLabs 创建的 Key注意这个文件不要提交到任何公开仓库,.gitignore 里已经有它了,但自己用的时候也要留心。
7.5 第一次对话剪辑
假设你有一个目录 ~/projects/my_first_cut/,里面放着三五个原始拍摄文件,比如 take01.mp4、take02.mp4、take03.mp4。操作流程是:
cd ~/projects/my_first_cut
claude这会在当前目录启动 Claude Code 会话。然后在对话里输入:
把这个目录里的素材剪成一条两分钟左右的产品介绍视频,
风格偏温暖电影感,字幕用大写两字一组,开头留三秒空镜。Claude Code 会识别到 video-use 技能的 frontmatter 匹配当前任务,自动加载 SKILL.md。然后它会做我们前面讲过的那些事情,扫描所有文件用 ffprobe 拿元数据,后台并行调用 Scribe 转录(这一步要等一会儿,大约每分钟素材几秒到十几秒不等),生成打包转录,然后开始和你对话。
你会看到类似这样的输出(简化版):
盘点完成:
- 3 个源文件,总时长 18 分 42 秒
- 主说话人 1 位(S0),可能是你本人
- 已检测 2 处明显重启,7 处 500ms 以上静音,适合做切点
- 抽样帧看到室内白墙背景,自然光,偏冷色温
我的建议是:
- 结构用"钩子→痛点→方案→举例→号召"
- 选 take02 的开场(最干净),take01 的方案陈述,take03 的结尾
- 调色走 warm_cinematic 微调,给场景加点暖意
- 字幕两字一组大写,白底黑边
- 预计最终时长 115 秒
是否按这个方案继续?你可以说"继续",也可以说"开头我想要更有悬念一点,不要直接说产品名"。之后就是策略执行、自检、预览展示的循环。直到你满意,在最后一次对话里确认一下"出最终成片吧",系统就会渲染出 edit/final.mp4。
整个过程中,素材目录旁边会多出一个 edit/ 子目录,里面的结构长这样:
my_first_cut/
├── take01.mp4
├── take02.mp4
├── take03.mp4
└── edit/
├── project.md # 会话记忆
├── takes_packed.md # 打包转录
├── edl.json # 剪辑决策清单
├── transcripts/ # 转录缓存
├── animations/ # 动画源文件和渲染
├── clips_graded/ # 调色后的每段片段
├── master.srt # 字幕文件
├── verify/ # 自检用的合成图
├── preview.mp4 # 预览片
└── final.mp4 # 成片这种目录布局的好处是,素材和剪辑产物完全解耦,原始文件纹丝不动,所有派生物都集中在 edit/ 下,删了重剪也很方便。
八、EDL 格式拆解,剪辑决策清单长什么样
EDL(Edit Decision List)是整个流水线的核心数据结构。它的本质是一份 JSON 文件,完整描述了"这部成片由哪些源片段按什么顺序拼起来,每段做什么处理"。我把 video-use 使用的 EDL 示例贴出来讲一下:
{
"version": 1,
"sources": {
"C0103": "/abs/path/C0103.MP4",
"C0108": "/abs/path/C0108.MP4"
},
"ranges": [
{
"source": "C0103",
"start": 2.42,
"end": 6.85,
"beat": "HOOK",
"quote": "九成网络代理做的事都是浪费",
"reason": "最干净的一条,在 38.46 秒的口误之前就结束"
},
{
"source": "C0108",
"start": 14.30,
"end": 28.90,
"beat": "SOLUTION",
"quote": "我们把它修好了",
"reason": "唯一一条没有开头卡顿的表达"
}
],
"grade": "warm_cinematic",
"overlays": [
{
"file": "edit/animations/slot_1/render.mp4",
"start_in_output": 0.0,
"duration": 5.0
}
],
"subtitles": "edit/master.srt",
"total_duration_s": 87.4
}这份文件里的几个字段值得细说。sources 是文件名到绝对路径的映射。ranges 是剪切段落列表,每段都带 beat(叙事节拍)、quote(引用内容)、reason(选择理由)三个字段,这三
