video-use：用 Claude Code 对话式编辑视频的开源工作流

一句话结论：video-use 不是“让模型直接看完整视频”，而是把剪辑问题压缩成模型擅长处理的结构化文本，再在关键决策点补充少量视觉证据。
事实边界：本文基于公开的 README 与 SKILL.md 解读 video-use 的设计和使用方式；未展开核验的内部实现细节，不作为确定事实描述。
目标读者：想把 Claude Code、FFmpeg 与转录系统组合成实际生产力工具的开发者、内容创作者、AI 工作流设计者。
前置知识：命令行基础、视频容器与编码基本概念、对 FFmpeg 有粗略认知。

学习目标

读完这篇文章后，你应该能回答 4 个问题：

1. 为什么 video-use 选择让 LLM “读” 视频，而不是“看” 视频？
2. 这个项目里哪些是艺术风格选择，哪些是必须遵守的生产正确性规则？
3. 一次从原始素材到 final.mp4 的完整工作流是怎样的？
4. 如果你想把类似思路迁移到别的多媒体任务，最值得复用的方法是什么？

先看结论

如果你只想快速判断 video-use 值不值得研究，可以先记住这 5 点：

1. 它是剪辑工具，不是 Runway、Pika、Sora 那类生成式视频模型。
2. 它的核心创新不是新模型，而是输入界面设计：把视频压缩为转录文本，把图像检查延迟到必要时。
3. 它把 Claude Code 放在“剪辑决策协调者”的位置，把 FFmpeg、字幕、动画、转录都当作可编排工具链。
4. 它强调先提策略、等确认、再执行、再自检，而不是直接开始切片。
5. 真正值得学的，不只是“怎么剪视频”，而是怎么把高成本模态问题重写成低成本结构化推理问题。

1. 它到底在解决什么问题

1.1 传统视频剪辑，难点不只是“会不会用软件”

很多人以为视频剪辑的门槛在软件操作，其实更大的门槛在于三件事：

1. 你要反复定位语气词、卡壳、重录片段和无效停顿。
2. 你要在音画都不穿帮的前提下决定切点。
3. 你要在字幕、调色、动画叠加和导出规范之间保持一致性。

对于开发者或内容创作者来说，真正想要的不是“再学一门剪辑软件”，而是“给出一句自然语言指令后，系统能提出合理方案并执行”。

1.2 它和生成式视频工具不是一类产品

video-use 的公开定位很明确：把已有素材剪成成片，而不是凭空生成新视频。

这意味着它更适合下面这些场景：

• 口播视频去掉 umm、uh 和空白停顿
• 多段素材拼成产品发布视频
• 教程、访谈、旅行片段的结构化重组
• 在现有视频上添加字幕、调色与简单动画层

它不擅长的方向同样明确：

• 从零生成镜头内容
• 复杂多轨道非线性剪辑
• 需要大型图形界面精修的后期项目
• 不允许云端语音转录的严格离线环境

1.3 为什么这类工具值得关注

因为它展示了一个很有代表性的 AI agent 设计方向：

• 不追求把所有事情交给一个“万能多模态模型”
• 而是把问题拆成模型擅长的推理层与传统工具擅长的执行层
• 最终让自然语言变成可审阅、可确认、可迭代的生产流程

2. 核心创新：让 LLM “读” 视频，而不是“看” 视频

2.1 为什么不能直接把视频帧丢给模型

项目 README 用一句很有冲击力的话概括了这个问题：

Naive approach: 30,000 frames × 1,500 tokens = 45M tokens of noise
Video Use: 12KB text + a handful of PNGs

这背后不是简单的“省钱”，而是三个工程判断：

1. 大多数剪辑决策首先来自语音而不是画面。
   去掉填充词、删掉死空间、保留笑点、避免切断句子，本质上都依赖语音边界和停顿。

2. 大多数视频帧对剪辑决策是噪声。
   在决定“这里该不该剪”之前，模型不需要看完整分钟级画面，它只需要在关键点看到足够证据。

3. 文本是最便宜、最稳定、最可搜索的推理界面。
   一旦视频被转换成带时间戳的文本，LLM 就能像读日志、读 DOM、读结构化数据那样去推理。

2.2 Layer 1：始终加载的转录层

video-use 的第一层输入来自 ElevenLabs Scribe。公开说明里提到，它会提供：

• 词级时间戳
• 说话人分离（speaker diarization）
• 音频事件标记，例如 (laughter)、(applause)、(sigh)

这些转录结果会被整理成一个更适合 LLM 阅读的 takes_packed.md。README 中给出的示例是：

## C0103  (duration: 43.0s, 8 phrases)
  [002.52-005.36] S0 Ninety percent of what a web agent does is completely wasted.
  [006.08-006.74] S0 We fixed this.

这一步的意义很大：

• 模型能直接看到每句内容对应的时间范围
• 切点可以对齐到单词边界，而不是粗略句子边界
• 多段素材可以先统一压缩为一个文本阅读面

2.3 Layer 2：按需触发的可视化层

只有当文本不足以做决定时，video-use 才会调用 timeline_view 生成复合图。公开描述中，这个视图通常包含：

• 胶片条
• 波形
• 单词标签
• 某个时间窗口的上下文

这意味着模型不会“全程看视频”，而是只在这些时刻查看图像：

• 某个停顿到底是语义停顿还是尴尬空白
• 两个片段的衔接会不会产生明显跳切
• 某个字幕、动画或叠加层是否遮挡画面

2.4 这个设计为什么聪明

如果把 browser-use 的成功经验抽象出来，你会发现两者思想相同：

• browser-use 给 LLM 的不是整页截图，而是结构化 DOM
• video-use 给 LLM 的不是完整视频帧，而是结构化转录文本

也就是说，真正的创新点不是“把视频交给大模型”，而是为大模型设计一种更便宜、更稳定、更适合决策的观察界面。

3. 从素材到成片：完整工作流长什么样

3.1 管线总览

3.2 它最重要的流程约束，不是技术而是交互

SKILL.md 里最值得注意的一条不是某个滤镜参数，而是这条流程原则：

Ask → confirm → execute → iterate → persist

翻成更工程化的话，就是：

1. 先盘点素材，不急着动刀。
2. 先用自然语言提出剪辑策略，不直接执行。
3. 用户确认后，再生成剪辑结果。
4. 渲染后先自检，不满意就重试。
5. 把会话状态持久化，下一次接着做。

这套顺序的价值在于，它让“自然语言剪辑”不至于退化成黑盒自动化。

3.3 公开文档中出现的关键输出物

根据 SKILL.md，一次编辑会话的主要产物通常位于 <videos_dir>/edit/：

这也解释了它为什么更像一个“工程化工作流”，而不是一个单一脚本。

4. 不是所有规则都能改：12 条生产正确性约束

video-use 的设计里，一个非常成熟的地方在于它明确区分了两类东西：

• 可以自由发挥的艺术选择：风格、节奏、字体、色彩、动画语言
• 不能违反的正确性规则：否则输出会悄悄坏掉，甚至看起来“差不多”，实际已经不可靠

下面这 12 条是 SKILL.md 公开写出的硬规则，值得逐条理解：

为什么这一节比“功能清单”更重要

因为很多 AI 工具文章喜欢强调“能做什么”，却不解释“为什么这样做才不会出错”。

如果你想把这套思路迁移到别的多媒体项目，这 12 条硬规则比“支持哪几种调色预设”更值得学习。前者是方法论，后者只是产品表层。

5. 它能做什么，以及这些能力意味着什么

5.1 删除填充词和死空间

README 中最明确的能力之一，就是去掉 umm、uh、false starts 和片段间空白。

这件事看似简单，其实很考验三点：

1. 转录是否足够细，能定位到单词边界
2. 系统是否知道某个停顿是“强调”还是“失误”
3. 渲染时是否处理了音频边界，避免出现 pop

因此，video-use 的价值不在于“它能删停顿”，而在于它把“删停顿”变成一条可重复执行、可自检的工程流程。

5.2 自动调色

公开说明中提到三类方向：

• warm_cinematic
• neutral_punch
• 任意自定义 ffmpeg 滤镜链

这里最重要的不是预设名称，而是项目对调色的态度：

• 调色是按片段执行，而不是最后整体补救
• 预设只是起点，不是强约束
• 风格属于艺术判断，但不要破坏肤色和画面一致性

5.3 字幕烧录

README 给出的默认风格是：

• 2-word
• UPPERCASE
• fully customizable

而 SKILL.md 进一步提醒了字幕系统真正容易翻车的地方：

• 字幕必须最后叠加
• 字幕时间不能沿用原片时间，而要映射到输出时间轴

这说明字幕在这里不是附属功能，而是和剪辑决策、片段拼接紧耦合的一个输出系统。

5.4 动画叠加层

公开资料提到 3 类动画引擎：

关键点不在“支持 3 种引擎”，而在“每个动画都是独立槽位，可并行生成”。这很像构建系统里的并行任务调度。

5.5 自我评估

这套工作流里最不像传统剪辑软件、最像 AI agent 的能力，是“渲染后自检”。

公开文档里提到，自检重点会覆盖：

• 切点处是否有明显视觉跳跃
• 音频边界是否仍然有异常峰值或爆音
• 字幕是否被叠加层遮挡
• 叠加层时间是否对齐

这一步的价值很大，因为它让系统不是“生成结果然后交付”，而是“生成结果后先审自己一遍”。

6. 怎么开始：安装、准备素材、发出第一条指令

6.1 安装步骤

以下命令来自项目公开 README，本文不改写原始安装方式：

# 1. Clone and symlink into Claude Code's skills directory
git clone https://github.com/browser-use/video-use
cd video-use
ln -s "$(pwd)" ~/.claude/skills/video-use

# 2. Install deps
pip install -e .
brew install ffmpeg           # required
brew install yt-dlp           # optional, for downloading online sources

# 3. Add your ElevenLabs API key
cp .env.example .env
$EDITOR .env                   # ELEVENLABS_API_KEY=...

6.2 准备素材并进入会话

cd /path/to/your/videos
claude

然后在会话里输入一条自然语言指令，例如：

edit these into a launch video

6.3 第一次使用时，你需要提前想清楚什么

为了让策略阶段更高质量，你最好先明确这几个信息：

• 目标视频时长是多少
• 横屏、竖屏还是方形
• 是偏发布会风格、教程风格还是访谈风格
• 哪些瞬间必须保留，哪些表达必须删掉
• 是否要字幕、是否要动画、是否需要统一调色

如果这些问题没有先想清楚，系统仍然可以工作，但最终结果更可能只达到“能看”，而不是“贴近你的表达目标”。

7. 一次理想的编辑会话，应该怎么推进

你可以把一次 video-use 会话理解成 7 个阶段：

1. 盘点素材：识别有哪些源文件、时长如何、说话人是否清晰。
2. 批量转录：得到词级时间戳与音频事件。
3. 打包阅读面：生成 takes_packed.md，让模型先阅读文本。
4. 提出策略：例如“保留 Hook，缩掉重复句，做温暖色调，字幕用短块大写”。
5. 等待确认：用户拍板后才真正执行。
6. 渲染与自检：做 preview，检查切点、音频、字幕与动画对齐。
7. 定稿与持久化：通过后导出 final.mp4，并把上下文写入 project.md。

这也是为什么 video-use 更像“会对话的剪辑工作流”，而不是“一个自动生成视频的命令”。

8. 这套方案的风险、限制与排错思路

8.1 最常见的风险点

8.2 它当前不解决什么问题

基于公开文档，下面这些方向暂时不应被理解为其核心能力：

• 复杂多轨道编辑台
• 完整替代专业 GUI 剪辑软件
• 完全离线的端到端工作流
• 针对所有素材类型都有现成模板

8.3 一个很实用的判断标准

如果你的素材主要问题是“删废话、缩空白、加字幕、统一风格、补一点动画”，它很值得试。
如果你的项目核心是“精细 keyframe、复杂遮罩、多轨合成、逐帧修补”，那它更像前处理或粗剪工具，而不是终局工具。

9. 从 video-use 可以迁移出的 3 个方法论

9.1 用结构化文本替代原始多模态洪流

这是整篇文章最值得带走的一点：

• 不要默认“多模态任务就应该把所有原始模态都喂给模型”
• 先问自己：有没有一种更稀疏、更便宜、更可索引的中间表示？

对视频来说，这个中间表示是词级转录。
对浏览器来说，这个中间表示是 DOM。
对日志分析来说，这个中间表示可能是事件流和聚合摘要。

9.2 把“模型推理”与“传统工具执行”拆开

Claude Code 负责：

• 理解需求
• 制定策略
• 判断哪里该剪
• 自检是否达标

FFmpeg、转录服务、字幕系统和动画工具负责：

• 精确执行
• 高性能处理
• 结果输出

这是一种比“让模型直接做一切”更稳妥的系统设计。

9.3 让系统先验证自己，再把结果给人

很多 AI workflow 的问题不是“生成不了”，而是“生成了但没人复查”。

video-use 提醒我们：
真正接近生产可用的 agent，不是只会产出，而是会在交付前先跑一轮针对性的自检。

10. 练习与自测

10.1 建议你亲手做的 3 个练习

1. 找一段 3-5 分钟口播视频，只做“去填充词 + 去空白 + 字幕”，观察文本驱动剪辑是否已经足够。
2. 在同一段素材上分别尝试“无调色”和“轻度调色”，比较按片段调色与整片后处理的差异。
3. 做一个包含 PIL 文字卡片的小动画槽位，理解为什么动画时间对齐比动画本身更重要。

10.2 发布前自测清单

• 你能清楚解释为什么它要先看转录文本，而不是先看完整视频吗？
• 你能区分“风格建议”和“硬规则”吗？
• 你知道字幕为什么必须最后叠加吗？
• 你知道为什么切点不能落在单词中间吗？
• 你知道什么情况下它更适合作为粗剪工具，而不是最终后期工具吗？

如果这 5 个问题都能回答清楚，说明你已经不只是“会用”，而是开始理解它的系统设计了。

11. 常见问题

Q1：支持哪些视频格式？

理论上，重点取决于底层 FFmpeg 能处理哪些格式，因此常见的 mp4、mov、avi、mkv、webm 都在常规讨论范围内。

Q2：它为什么要依赖 ElevenLabs Scribe？

因为它的很多剪辑决策依赖词级时间戳、说话人分离与音频事件，而这些信息正是第一层阅读面的一部分。

Q3：能不能完全离线？

基于公开资料，转录环节需要配置 ElevenLabs API Key。所以它不是一个纯离线工作流。

Q4：它和生成式视频模型最大的区别是什么？

它处理的是“已有素材怎么剪”，不是“没有素材怎么生成镜头”。

Q5：我应该把它当成什么？

更准确的理解是：
它是一个由 Claude Code 协调的对话式视频编辑工作流，而不是单一模型、单一脚本或完整 GUI 剪辑软件替代品。

相关资源

• GitHub：browser-use/video-use
• 公开技能说明：SKILL.md
• 转录能力说明：ElevenLabs Speech to Text
• 视频处理基础工具：FFmpeg

文档信息

• 类型：技术笔记 / 架构解读 / 工作流教程
• 难度：进阶
• 更新日期：2026-04-16
• 阅读建议：先看第 2、4、9 节，再决定是否深入实践