browser-use团队新作：让编程Agent帮你剪视频，核心设计思路有点意思

我用browser-use做过一段时间网页自动化，对它的设计思路算是比较熟悉。最近刷GitHub Trending发现browser-use团队搞了个新活------video-use，让Claude Code之类的编程Agent直接剪视频。23k星，日增接近500，热度不低。 "AI剪视频"这个方向这两年工具太多了，我第一反应是又一个噱头项目。但点进去看了README和SKILL.md之后，发现有点东西------不是"能剪视频"这个能力，是它处理视频的方式。

不给大模型看视频，让它"读"视频

先说最关键的架构决策。你要让AI理解一段视频，直觉上怎么做？把视频拆成一帧帧的图片，丢给多模态模型，让它"看"。 video-use反着来。它把视频转成文本------不是视频内容的文字摘要，而是带时间戳的音频转写。每一句话什么时候说的、谁说的、中间有没有停顿或语气词，全部精确标注。

csharp 复制代码

## 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.

所有素材打包成一份大约12KB的文本文件。大模型读这个文件来做剪辑决策。只有在需要确认画面细节时------比如某个模糊的停顿点、两个相似镜头的对比------才生成一个叫做timeline_view的PNG图。这个图把影片条、音频波形和文字标注合在一起，只在关键决策点按需调用。 README里有句话我觉得挺到位：

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

确实，视频编辑的本质就是音频驱动------剪切点来自说话边界和静默间隔，画面跟着音频节奏走。既然如此，大模型最需要的不是"看到"每一帧画面，而是精确知道"这个'嗯'出现在第6.08秒"。这个思路和browser-use一模一样。browser-use给LLM的是结构化的DOM树，不是浏览器截图。video-use给LLM的是带时间戳的转写文本，不是视频帧。同一个设计哲学在不同场景的复用，这个点比"能剪视频"本身更值得学。

装一个试试

安装过程比我预想的简单。video-use设计成了一个"Skill"，可以插到任何有shell访问权限的编程Agent里。README里给了一段setup prompt，直接粘给你的Agent就行：

vbnet 复制代码

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.

Agent自己搞定clone、依赖安装、Skill注册，中间只需要你提供一次ElevenLabs的API Key。顺便说一句，这个Key要去elevenlabs.io后台申请，入口藏得有点深，我找了好一会儿。装完之后，把原始素材放到一个文件夹，打开Agent对话：

bash 复制代码

cd /path/to/your/videos
claude  # or codex, hermes, etc.

然后跟Agent说"把这些剪成一个发布视频"。它会扫描源文件，提出编辑策略，等你确认，最后在同级目录输出edit/final.mp4。有个细节我觉得做得不错------Agent不会上来就动手剪。它会先说"这三个素材，我的计划是先去掉开头结尾的废话，中间部分这么拼接，字幕用两词一组的大写样式"，然后等你点头。你说OK了它才真动。这个"先说想法→等你确认→再执行"的交互模式，和好的AI编程工具一样。有想法先说，不擅自行动。

管道 + Skill：它怎么剪、按什么规则剪

video-use的处理管道拆开看，有几步比较值得说。

matlab 复制代码

Transcribe → Pack → LLM Reasons → EDL → Render → Self-Eval
                                            ↑
                                     issue? fix + re-render (max 3)

转写：用ElevenLabs Scribe，拿到词级别时间戳、说话人分离、音频事件标记（笑声、掌声、叹气）。

打包：所有素材的转写压缩成一份takes_packed.md，这就是大模型的"阅读视图"。

推理：大模型读打包文本，结合用户指令，决定怎么剪。

EDL（编辑决策列表） ：LLM输出一个结构化的剪辑清单------哪里切、怎么转场、字幕时间码。

渲染：FFmpeg按EDL执行。每个剪切点加30ms音频淡入淡出（防止爆音），字幕按自定义样式烧录。

自评估 ：这一步最有意思。Agent对渲染出来的视频做自我检查------在每个剪切边界生成timeline_view，看画面有没有跳帧、音频有没有pop、字幕有没有越界。发现问题就自动修，重新渲染，最多循环3次。你看到的输出是通过自检的版本。有点像写代码跑测试。写完→跑→看结果→改→再跑。只不过测试的对象从代码变成了视频。 Agent执行这些步骤时，读的是SKILL.md------video-use的核心规则文件。README提到它包含12条硬性规则，其余部分Agent有"艺术自由"。硬性规则没例外（每个剪切点必须淡入淡出、色彩分级必须处理Gamma映射），艺术自由的部分Agent自己判断------暖色调还是冷色调，字幕大写还是正体。这让我想起之前Agent Skills生态的发展趋势（写过一篇相关文章）------skill文件承载领域知识，和技术栈解耦。video-use把这事做得更干净：Skill就是编辑经验，跟Agent框架无关。

一个具体场景：去口语填充词

说一个最普通的场景，去掉视频里的"嗯""啊""就是说"。传统做法：打开视频编辑器，听音频，找到每个填充词的位置，手动剪切，对齐。一遍下来可能半小时。 video-use的做法：Scribe已经转写了所有内容并标记了时间戳。Agent在文本里定位"嗯""uh""umm"，拿到对应时间戳，生成剪切指令。FFmpeg执行。整个过程中Agent没有"听"过音频。它只是在做文本匹配+数学运算。但输出效果和一个有经验的视频编辑手动剪的一样。这就是"把视频问题转成文本问题"的降维打击。

从browser-use到video-use

说回设计层面。 browser-use的核心洞察：LLM擅长处理结构化文本，不擅长处理原始像素。所以给LLM结构化DOM，不给浏览器截图。 video-use把同样的思路搬到了视频编辑：LLM擅长处理结构化文本（带时间戳的转写），不擅长处理原始视频帧。所以给LLM文本，不给帧。 "结构化文本优先"------同一个设计哲学，跨了网页自动化和视频编辑两个完全不同的领域。我目前还没实际用video-use跑过一段视频。从源码结构和设计文档看，架构干净，思路清晰。