ARTICLE · 1061293
AI自动剪辑实测:video-use对话式剪辑 vs 传统剪辑工具对比
剪一个10分钟的口播视频，人工粗剪往往要花掉大半天；而如果让LLM直接“看”视频，一段素材逐帧投喂大约是30,000帧 × 1,500 tokens ≈ 45M tokens——成本比视频本身还贵。browser-use团队开源的video-use给出了另一个答案：让LLM读视频而不是看视频，把45M tokens的噪声问题压缩到约12KB文本，一句话对话就能出片。这篇文章实测它的设计、用法，并和SaaS剪辑工具、逐帧多模态方案做一次正面对比。
一、它解决什么真实痛点
先说清楚问题的本质。
口播、访谈、教程这类视频的剪辑，80%的时间花在“找废料”上：语气填充词（umm、uh）、说错重来的假开头、take之间的死空间。这些活儿不需要艺术品味，只需要耐心和精确到词边界的时间轴操作。
问题在于，LLM恰恰没有时间轴操作能力。它是文本推理机器，你让它剪视频，通常有两条路：
1. 逐帧多模态方案：把视频帧直接喂给Gemini/Claude这类多模态模型。噪声巨大、成本爆炸，而且模型对“第几秒切”这种精确定位天然不可靠。
2. SaaS智能剪辑：Opus Clip、剪映这类工具。零配置一键出片，但剪辑逻辑是黑盒，你想“去掉所有技术细节只保留demo部分”，它做不到。
video-use卡在中间的位置：把剪辑决策交给LLM，把时间轴精确性交给文本转写。口播粗剪这个场景，人工觉得枯燥，SaaS不够灵活，逐帧方案太贵——这就是它的生存空间。
二、核心设计：LLM读视频，不是看视频
这是整个项目最值得看的部分，即使你不剪视频。
两层信息架构
Layer 1 —— 音频转写（常驻上下文）。每个素材跑一次ElevenLabs Scribe（ElevenLabs家的语音转写服务），拿到：
词级时间戳（精确到每个词的起止时间） 说话人分离（谁是S0、谁是S1） 音频事件标注（ (laughter)、(applause)、(sigh)）
所有take打包进一个约12KB的takes_packed.md，长这样：
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.
这就是LLM的主要阅读视图。模型看到的是带时间戳的剧本，不是像素。
Layer 2 —— 视觉合成（按需调用）。timeline_view可以为任意时间区间生成一张PNG：胶片条 + 音频波形 + 词标签。只在决策点才调用——歧义停顿要不要切、两次重拍选哪条、切点处画面是否跳变。
打个比方：这就像给新人剪辑师一份带时间码的场记单，而不是把整部片子扔给他从头看到尾。场记单常驻手边，监视器（timeline_view）按需打开。
这套思路和browser-use给LLM结构化DOM而非截图是同一哲学：给模型结构化文本，让它看像素。
完整流水线
Transcribe ──> Pack ──> LLM Reasons ──> EDL ──> Render ──> Self-Eval
│
└─ issue? fix + re-render (max 3)
EDL（Edit Decision List，剪辑决策表）是剪辑行业的经典格式——描述“哪段素材的哪个区间放到成品哪个位置”，ffmpeg照单渲染。渲染不是重点，自检才是：渲染完成后，在每个切点边界跑timeline_view检查画面跳动、音频爆音、字幕遮挡，发现问题自动修复重渲，最多3次，通过才给你看预览。
💡 设计模式的可迁移性
「结构化文本常驻 + 按需视觉校验」这个两层架构，不只是剪辑技巧——处理超长音频、海量日志、监控视频流，任何超长非结构化媒体的Agent，都可以套这个模式。先压缩成文本主视图，视觉只在决策点按需调取。
三、安装与使用：Skill模式接入任意Agent
video-use的定位是Agent Skill（技能插件）而非独立应用——它不是一个带界面的软件，而是一套可以注册进任何有shell权限的Agent的技能包。
最省事的装法是把官方Setup prompt直接丢给Claude Code，让Agent自己装：
Set up https://github.com/browser-use/video-use for me.
Read install.md first to install this repo, wire up ffmpeg, register the skill
with whichever agent you're running under, and set up the ElevenLabs API key —
ask me to paste it when you need it. Then read SKILL.md for daily usage, and
always read helpers/ because that's where the editing scripts live. After
install, don't transcribe anything on your own — just tell me it's ready and
wait for me to drop footage into a folder.
也可以手动三步装完：
# 1. Clone并symlink进Agent的skills目录
git clone https://github.com/browser-use/video-use ~/Developer/video-use
ln -sfn ~/Developer/video-use ~/.claude/skills/video-use # Claude Code
ln -sfn ~/Developer/video-use ~/.codex/skills/video-use # Codex
# 2. 安装依赖
cd ~/Developer/video-use
uv sync # 或 pip install -e .
brew install ffmpeg # 必需
brew install yt-dlp # 可选，用于下载在线素材
# 3. 配置API key
cp .env.example .env
$EDITOR .env # ELEVENLABS_API_KEY=...
日常使用极简：cd到素材目录，启动Agent，说一句话：
cd /path/to/your/videos
claude
edit these into a launch video
工作流程是「提案-确认-执行」：Agent先盘点素材、提出剪辑策略、等你点头，然后输出edit/final.mp4。所有产物隔离在/edit/目录，skill目录保持干净。会话记忆持久化到project.md，下周接着剪不用重新理解项目。
想把剪辑服务挂在VPS上随时随地用？通过Browser Use Box部署，或者接Telegram——这套skill不绑死Claude Code，Codex、Hermes、Openclaw都能挂。
⚠️ 装之前确认两件事
1. ElevenLabs API key是硬依赖，转写数据要出境，敏感素材慎重。
2. ffmpeg必须装，Linux用户把brew install换成对应包管理器命令。
四、剪辑硬规则与自由度边界
video-use内建12条不可协商的生产级硬规则，同时把艺术品味留给LLM和用户。这条边界划得很清楚。
硬规则包括：
- 剔除填充词和死空间
：umm、uh、假开头、take之间的沉默，一律切掉 - 30ms音频淡入淡出
：每个切点做30ms的音频fade——切点爆音是手工剪辑最容易翻车的地方，30ms短到听不出来，长到消掉爆音 - 统一调色
：每个片段自动调色，预设warm cinematic、neutral punch，也支持任意自定义ffmpeg滤镜链 - 字幕烧录
：默认2词大写分块风格，完全可定制 - 动画叠加
：通过HyperFrames、Remotion、Manim或PIL生成动画，每个动画由并行子Agent独立spawn，互不阻塞
比喻一下：这就像一家餐厅后厨——食品安全规范（硬规则）不许厨师商量，但菜品味道（剪辑品味）由厨师和客人决定。先看素材、先问、再剪，对内容类型零假设，是它明确写进设计原则的立场。
五、对比维度一：成本与上下文效率
把三个方案放在同一张桌子上：
逐帧方案的问题不只是贵——大量无关帧会稀释关键信息，模型在45M tokens的噪声里找切点，就像在一本没有页码的书里找某一句话。video-use的12KB转写文本相当于一本带页码和索引的目录，上下文成本降低三个数量级以上。
结论：长视频（半小时以上）场景下video-use的成本优势最明显，而且词级时间戳保证了SaaS难以做到的词边界精准切口。SaaS胜在零配置——如果你每月只剪三条片子，订阅费可能仍比折腾API key划算。
六、对比维度二：可控性与工程化能力
video-use最被低估的能力是剪辑逻辑变成自然语言可编程：“剪成launch video”和“去掉所有技术细节只保留demo部分”，对它来说只是换一句prompt，底层基础设施完全复用。这在SaaS里是不可想象的——SaaS给你的是菜单，video-use给你的是厨房。
自检闭环是另一个差异化：渲染后在每个切点边界跑timeline_view自评估，捕获画面跳变、音频爆音、字幕遮挡，自动修复。SaaS工具出了问题，你只能导出来手动补。
代价也明确：你得理解ffmpeg滤镜链、EDL这些概念，出错时调试门槛远高于SaaS的“重新生成”按钮。
七、缺点与技术局限
实测视角下必须泼的冷水：
1. 强依赖语音。剪辑决策以音频转写为主视图，纯视觉内容（vlog空镜、风景montage）价值大打折扣——视觉层只用于校验，不用于理解。官方README说“works for travel”，但架构上语音才是主角。
2. ElevenLabs硬依赖。转写绑定Scribe服务，无本地Whisper fallback，数据出境且多一笔外部账单。
3. Agent质量决定剪辑质量。品味完全依赖底层LLM，不同模型、不同会话产出不稳定。自检只保证技术正确性，不保证好看。
4. 端到端延迟不可控。LLM推理 + EDL生成 + 渲染 + 最多3轮自检重渲，一个会话的总时长远慢于SaaS的一键出片。
5. 工程成熟度早期。开源初期，无GUI、无进度可视化，排错要靠读Agent日志，非程序员基本不可用。
⚠️ 最大的认知误区
不要把它当成“AI剪辑软件”来期待。它是一个面向程序员的、可编程的剪辑流水线——如果你想要的是剪映那种开箱即用，现在还不是入场时机。
八、适用场景与选型建议
该用的场景：口播/访谈/教程等语音主导内容的批量粗剪；需要可编程、可复现的剪辑流水线；已有Claude Code等Agent工作流、想加一条视频产线的开发者。
不该用的场景：纯视觉叙事（旅拍、混剪）——转写核心架构发挥不了作用；紧急出片需求——自检循环耗时不可控；团队非技术成员使用——无GUI且调试门槛高。
还有一个务实建议：混搭。用video-use做粗剪和批量去废料，用Opus Clip/剪映做最终精修，两者互补而非替代。
独立创作者 · 量大 · 会写代码
选video-use，粗剪自动化后产能翻倍
偶尔剪片 · 要快
选剪映/Opus Clip，别折腾环境
做AI应用的工程师
不剪视频也值得读源码，两层信息架构是通用设计模式
纯视觉内容创作者
两者都不理想，video-use架构不适配，等视觉原生方案
一句话总结：video-use不是要取代剪辑工具，而是证明了“结构化文本 + 按需视觉”这条路在视频领域能跑通——这个信号，比final.mp4本身值钱。
— END —