
我最近看到 browser-use/video-use 这个开源项目,它把视频剪辑这件事,重新翻译成了 Agent 可以阅读、判断、执行和自检的工程流程。

这点比“自动剪辑”四个字重要。
因为大模型本身并不适合直接看完几万帧视频,再凭感觉决定哪里该剪。那样 token 成本高,信息噪音大,而且很难稳定复盘。video-use 的核心思路刚好相反:不要让 LLM 暴力看视频,而是先把视频变成它最擅长处理的材料。
也就是文本、时间轴、结构化剪辑决策。
按照项目 README 的描述,video-use 的使用方式很像一个剪辑型 skill:你把原始素材放进一个文件夹,打开 Claude Code、Codex 或其他有 shell 能力的 Agent,然后用自然语言说:把这些素材剪成一个 launch video。它最终会在素材目录旁边生成 edit/final.mp4。
takes_packed.md,让 Agent 用文本方式读完整个素材。
3. 在需要判断画面的时候,再调用 timeline_view 生成局部视觉合成图。
4. 让 Agent 产出 EDL,也就是剪辑决策表。
5. 用 ffmpeg 渲染,生成预览和最终视频。
6. 在每个剪切点做自检,发现跳帧、爆音、字幕遮挡等问题就修。

README 里有一个很有代表性的对比:朴素做法是把大量视频帧丢给模型,等于制造几千万 token 的噪音。video-use 的做法是两层读取。
第一层是音频转写。每个词都有时间戳,停顿、口误、重复、笑声、掌声都会变成可读信号。对口播、访谈、教程这类内容来说,剪辑的主要决策本来就来自语言节奏。
第二层是按需视觉检查。只有在判断停顿、重拍、切点是否自然的时候,才生成局部 timeline 视图。这个视图把胶片帧、波形、词标签和静音间隔放在一起,帮助 Agent 做关键判断。
我的理解是:这和 browser-use 的思路很像。浏览器 Agent 不应该只盯着网页截图,它应该读 DOM。视频 Agent 也不应该只盯着帧,它应该读一套可操作的时间轴。
我最在意的不是它能不能一次剪出一个“爆款视频”。我更在意它的 hard rules。
edit/ 下面,skill 项目目录保持干净。这些规则听起来不像“创意”,但它们决定了 AI 剪辑能不能稳定工作。

如果把它放进我的自媒体工作流里,我不会一开始就指望它替代精剪。更合理的位置是:粗剪。
我录一批原始口播素材,先让 Agent 做 inventory,转写、识别重复表达、选出最佳 take、剪掉废话和停顿,输出一个结构完整的 preview.mp4。然后我再进入精剪:确认节奏、补视觉、处理封面、平台适配。
这样分工就很清楚:Agent 负责把素材从“不可读的视频堆”变成“可检查的剪辑工程”。人负责最终的判断、审美和平台发布。
第一,它依赖转写质量。项目默认需要 ElevenLabs API key,说明语音识别是整个流程的底座。如果转写错了,后面的剪辑判断也会跟着偏。
第二,它不是无确认自动执行。项目 SKILL 里写得很清楚:先 inventory,提出策略,等用户确认,再执行。这一点反而是优点。剪辑不是纯机械任务,策略确认是必要的。
第三,它解决的是“剪辑工程化”,不是审美外包。节奏、视觉风格、字幕样式、动画选择,仍然需要创作者给方向。
第四,隐私和成本要算清楚。素材转写、API、云端模型、视频素材本身,都可能涉及成本和数据边界。
很多人现在谈 AI 视频,容易盯着生成式视频模型。但对个人创作者来说,真正高频的痛点不是凭空生成一段视频,而是处理自己已经录下来的素材。
素材太多,废话太多,重拍太多,粗剪太耗时间。
video-use 指向的是另一个方向:不要先追求 AI 拍大片。先让 AI 把你的真实素材变成可读、可剪、可复盘的生产资料。
github仓库地址
https://github.com/browser-use/video-use