以网页自动化项目 browser-use 为人所知的团队，近日又在 GitHub 上开源了一个新项目 video-use。它的目标听起来很直接：让 Claude Code 等编程 Agent 能够处理视频剪辑任务。项目上线后热度不低，GitHub Star 数已达 23k，日增接近 500。
不过，真正值得关注的并不是「AI 能剪视频」这个结果。近两年自动剪辑工具并不少见，video-use 的特殊之处在于它选择了一条与常见多模态方案不同的路线：不把视频切成一帧帧图片交给模型观看，而是把视频转成带时间戳的文本，再由大模型基于文本做出剪辑决策。
核心思路：先转写，不先看画面
如果要让 AI 理解视频，常见做法是把视频拆成帧，再交给多模态模型识别画面。但 video-use 反其道而行：它将视频内容转写为文本，而且是带精确时间戳的音频转写。每一句话从何时开始、何时结束、由谁发出，中间是否存在停顿、语气词或笑声，都会被记录下来。
所有素材会被打包成一份约 12KB 的 takes_packed.md 文本文件，供大模型阅读。只有在需要确认画面细节时，例如判断一个模糊停顿点，或比较两个相似镜头，系统才会生成名为 timeline_view 的 PNG 图。这张图将影片条、音频波形和文字标注合在一起，只在关键决策点按需调用。
- 原始素材不会以海量视频帧形式喂给模型
- 大模型主要阅读的是带时间戳的转写文本
- 画面信息只在必要时以少量 PNG 图辅助判断
README 中给出了一组对比：如果按每 30,000 帧、每帧 1,500 tokens 计算，会产生 45M tokens 的噪声；而 video-use 的做法是 12KB 文本加少量 PNG。这背后其实是对视频编辑本质的判断：很多剪辑点来自说话边界和静默间隔，画面节奏往往跟着音频走。因此，大模型更需要知道「某个语气词出现在第 6.08 秒」，而不是逐帧观看整段视频。
从转写到渲染：一条带自检的剪辑流水线
video-use 的处理流程可以概括为：转写、打包、模型推理、生成 EDL、渲染、自评估。转写环节使用 ElevenLabs Scribe，可得到词级时间戳、说话人分离，以及笑声、掌声、叹气等音频事件标记。随后，系统将素材整理成 takes_packed.md，作为大模型的阅读视图。
大模型读取打包文本后，结合用户指令决定如何剪辑，并输出结构化的 EDL，也就是编辑决策列表。FFmpeg 根据这份清单执行实际渲染：剪切点会加入 30ms 音频淡入淡出，以避免爆音；字幕则按自定义样式烧录进视频。最终输出为 edit/final.mp4。
比较有意思的是最后的自评估环节。Agent 会对渲染完成的视频进行检查：在每个剪切边界生成 timeline_view，查看画面是否跳帧、音频是否有 pop、字幕是否越界。如果发现问题，会自动修正并重新渲染，最多循环 3 次。最终用户看到的输出，是经过自检的版本。
这种流程与软件工程中「写代码、跑测试、根据结果修复、再运行」的模式类似，只是被检查的对象从代码变成了视频。
Skill 文件承载剪辑经验，与 Agent 框架解耦
video-use 被设计成一个 Skill，可以接入任何具备 shell 访问权限的编程 Agent。用户在 README 中只需提供一段 setup prompt，Agent 就可以自行完成仓库克隆、依赖安装、FFmpeg 配置、Skill 注册等步骤。过程中，用户只需要提供一次 ElevenLabs API Key。
安装完成后，用户把原始素材放进一个文件夹，在终端中进入该目录并启动 Agent，然后提出类似「把这些剪成一个发布视频」的指令。Agent 会先扫描源文件，给出编辑策略，例如哪些片段需要去掉、中间部分如何拼接、字幕采用什么样式，等待用户确认后再执行。
这种「先说明想法、等待确认、再执行」的交互方式，与成熟 AI 编程工具的工作方式相似。Agent 并不擅自操作，而是先提出可确认的编辑计划。
执行过程中，Agent 依据的是 SKILL.md 文件。README 提到，其中包含 12 条硬性规则，例如每个剪切点必须做淡入淡出，色彩分级必须处理 Gamma 映射；其余部分则留给 Agent 判断，比如选择暖色调还是冷色调，字幕使用大写还是正体。
对行业的启示：把视频问题转成文本问题
一个很典型的场景是去掉视频中的「嗯」「啊」「就是说」等填充词。传统做法需要编辑者反复听音频、定位位置、手动剪切和对齐。而在 video-use 的流程里，转写系统已经给出所有词语的位置和时间戳，Agent 只需在文本中定位这些词，提取对应时间戳，生成剪切指令，再由 FFmpeg 执行。
整个过程中，Agent 并没有真正「听」音频，也没有逐帧观看视频。它做的是文本匹配和时间计算，但最终效果可以接近人工剪辑。这也是 video-use 最有价值的地方：它不是简单展示一个视频剪辑能力，而是展示了一种将复杂媒体处理转化为结构化文本处理的方法。
这一思路与 browser-use 的设计哲学一致。browser-use 在网页自动化中给大模型提供的是结构化 DOM 树，而不是浏览器截图；video-use 给大模型提供的是带时间戳的转写文本，而不是原始视频帧。两者都指向同一个判断：大模型更擅长处理结构化文本，而不擅长直接处理原始像素或大量冗余媒体数据。
对于 AI 工具开发者而言，这种「结构化文本优先」的设计或许比 video-use 本身更值得关注。它提示了一种降低多模态任务成本、提高可控性的路径：不是把所有原始信息都塞给模型，而是先把任务转成模型最擅长处理的形式。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/bu-kao-kan-pian-jian-shi-pin-videouse-ba-shi-pin-bian-ji
