video-use ：把浏览器那套搬到了视频上

让 AI 剪视频，正常人的第一想法是让它把画面看一遍。browser-use 团队做的 video-use 没走这条路。它的核心设计就一句话：模型从不看视频，它读视频。

具体做法是，把原始素材丢进一个文件夹，打开 Claude Code 或者 Codex，说一句把这些剪成发布视频，剩下的交给 agent。清点素材、挑 take、去填充词、调色、烧字幕、加动画，最后吐出 edit/final.mp4。截至 2026 年 9 月 12 日，这个仓库挂着 24,753 个 Star。

真正让人停下来的是它的账本。README 里算得很清楚：一段 30,000 帧的素材逐帧喂给模型，大约 4500 万 token；video-use 的做法是调一次 ElevenLabs Scribe 转写，把所有 take 压成一个约 12KB 的 takes_packed.md，读它只要几千 token。差了四个数量级。

这套思路本身不新鲜。browser-use 当年给模型的是结构化 DOM 而不是网页截图，现在只是把对象从网页换成了视频。新鲜的是它把剪辑工程里那些脏活写成 12 条硬规则，再交给 ffmpeg 执行。不过 Star 数从来不等于工程完成度，这个仓库到今天只有 21 次提交。

它是怎么读视频的

整个系统分两层。第一层是音频转录，每个源文件调一次 ElevenLabs Scribe，拿回词级时间戳、说话人分离和笑声叹息这类音频事件标记，然后打包成 takes_packed.md。第二层是按需视觉，只有碰到模糊停顿、重拍对比或者切点校验的时候，才调 timeline_view 生成一张带胶片条、波形和词标签的 PNG。

这个分工决定了它的剪辑逻辑是音频优先。剪切候选来自词边界和静音间隙，大于等于 400ms 的静音通常最干净，150 到 400ms 需要看一眼画面，小于 150ms 直接判定不安全。笑声、包袱、强调节拍要往反应之后延伸，说话人交接之间要留一口气。

上面这套分工画成图就是下面这个样子，先顺着三层往下看，重点落在右下方那条自检回环上。

回环是自检。渲染完之后，agent 会在每个切点前后各 1.5 秒再跑一次 timeline_view，检查有没有视觉跳切、波形爆刺、字幕被动画盖住。发现问题就改 EDL 重新渲染，最多 3 轮，3 轮还不行就标记给你，而不是无限修下去。

12 条硬规则里我最认同的是字幕最后烧。滤镜链里字幕必须在所有叠加层之后应用，否则动画一压上来就把字幕遮住了，而且这是静默失败，你可能导完片都没发现。类似的还有每个切点 30ms 的淡入淡出，不做的话每一刀都能听见一声爆响。

还有一条很琐碎但很关键：每个剪切边缘要留 30 到 200ms 的 padding。原因是 Scribe 的时间戳本身有 50 到 100ms 漂移，padding 用来吸收这个漂移。能写进 SKILL.md 的这类规则，基本都是踩过坑才会有的。

剩下的部分给 agent 留了很大自由度。调色可以选 warm_cinematic、neutral_punch，也可以直接丢一条自定义 ffmpeg 滤镜链；动画可以走 HyperFrames、Remotion、Manim 或者 PIL，多个动画用并行子 agent 同时跑，总耗时约等于最慢的那个。说了这么多设计，真正的问题是它装起来有多麻烦。

装起来麻烦吗

三样东西必须先到位：ffmpeg 和 ffprobe 在 PATH 里，一个 ElevenLabs API key，Python 加 uv。ffmpeg 是硬依赖，没有它整个执行层就塌了；API key 是转写的通行证，Scribe 按音频时长计费，免费额度够试玩，长素材就要掏钱。

官方给的做法是偷懒的：把一段安装提示粘给 agent，让它自己 clone、装依赖、注册 skill，只在需要 key 的时候问你一次。

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.

手工装也不复杂，把仓库 clone 下来，软链进你正在用的 agent 的 skills 目录，再装依赖，几行命令就能搞定：

git clone https://github.com/browser-use/video-use ~/Developer/video-use
ln -sfn ~/Developer/video-use ~/.claude/skills/video-use
cd ~/Developer/video-use && uv sync
brew install ffmpeg          # 必需
cp .env.example .env          # 填入 ELEVENLABS_API_KEY

注册成 skill 之后，日常用法是在素材目录里起一个会话，然后说人话。一次完整的会话大概长下面这样：

cd /path/to/your/videos
claude
# > edit these into a launch video

agent 会先清点素材、生成 takes_packed.md、采样几张视觉快照，然后用自然语言描述它看到了什么，反过来问你几个问题。第 11 条硬规则在这里起作用：策略没被你确认之前，它一刀都不许动。确认后才生成 edl.json，所有产物落在素材目录的 edit/ 下面，仓库目录保持干净。

Windows 用户有两处要提前知道。Issue 125 报告 helper 脚本在非 UTF-8 的 stdout 上打印箭头会 UnicodeEncodeError 崩溃，而 Issue 10 的修复只把 pack_transcripts 的输出改成了 UTF-8，没有覆盖全部脚本。中文路径加上中文素材名，但要触发这个 bug 其实不难。

什么片子适合它剪

判断标准很简单：人声清楚的片子赢，靠画面节奏的片子输。因为它的全部剪切决策都建立在转写文本上，画面只在决策点被看一眼。口播、教程、访谈、多 take 的产品发布，这四类它处理得最顺。

明确不适合的也有几类：需要多轨 B-roll 精细合成的，需要 AE 级别特效的，以及纯图片幻灯片。它不提供实时预览，你拿到的永远是自检通过之后的成片，想微调单个切点得自己调 timeline_view 再反馈，这个节奏跟传统剪辑软件完全不同。

中文用户还有一个绕不过去的坑。Issue 118 报告字幕烧录有两处损坏：一是在 README 写明的 macOS 安装方式下直接崩溃，二是非拉丁文字渲染成豆腐块。也就是说，中文口播想做硬字幕，现阶段大概率要你自己介入处理字体。坑点说到这里，但真正决定要不要长期跟的，其实是维护状态。

维护节奏比 Star 数更值得看

看提交历史比看 Star 数有用得多。21 次提交里，gregpr07 一个人占了 9 次，ShawnPana 4 次，其余六人各 1 到 2 次。Bus factor 基本等于 1，项目命运挂在 browser-use 创始人 Gregor Žunič 一个人身上。

节奏也是脉冲式的。4 月 12 日一天内把 v1、autograde、self eval loop、poster 全推上去，之后 4 月 23 日、5 月 10 日、6 月底、8 月 30 日各来一波，中间是大段静默。8 月 30 日那波三连提交修的是渲染层：保留源帧率、修正竖屏方向判定、拒绝上传静音音轨。

Issue 区的信噪比很差。97 个未关闭的里面，Xaya siis、Edição、fish、Hi 这类垃圾帖占了一大片，维护者显然没在清理。真正的信号藏在里面：Issue 118 字幕双重损坏、125 Windows 编码崩溃、121 希望加一个 preflight 命令检查 ffmpeg 和叠加依赖、64 要求源保真的输出配置和自动切点质检。

外部评价反而比 Issue 区干净。台湾的 slash-invest 在 2026 年 6 月的实测里给了个很克制的结论：要的就是用 AI agent、在本机、把讲话为主的片快速做成初剪，那 video-use 这个位置切得算干净；英文博客 mushroom.cv 的 TL;DR 则提醒，ElevenLabs 不免费，按量计费。数据摆完了，接下来是我的真实判断。

值不值得跟

先说它跟同类项目的位置。你可能会问，都是自动剪，它跟 auto-editor 有什么区别？开源世界里做自动剪辑的替代品不止一个，但路线差别很大：

auto-editor 是纯波形派，看的是音量不是内容，一条命令切掉静音，完全免费离线，但在正常音量下说出来的填充词对它来说就是普通语音，它删不掉。FunClip 走的是转录加 LLM 的路线，跟 video-use 更接近，重心却放在选片段而不是整套成片流水线。Descript 是商业闭环，体验最好，代价是订阅费和云端。

所以判断很直接。如果你的痛点只是把空白剪掉，装一个 auto-editor 就够了，不用付 API 费也不用等 agent 思考。如果你要的是从一堆废素材里挑出最好的说法，顺便配好调色、字幕和动画，那目前同类项目里没有第二个把这条链路打通得这么完整的。

它最聪明的地方不是剪辑本身，是把编码 agent 当成了剪辑软件的宿主。视频文件不上云，剪辑决策写在一个你可以手工改的 edl.json 里，执行交给 ffmpeg。这意味着一旦 agent 判断不对，你能直接改决策重新渲染，而不是被锁在某个 SaaS 的时间线里出不来。

但它现在的状态，我更愿意叫它一个完成度很高的 demo。21 次提交、Bus factor 等于 1、字幕在非拉丁语系上还是坏的、Windows 上会崩，这些都指向同一件事：它还没到能长期依赖的程度。做一次性的发布视频，现在就能用；要接进团队的固定产线，建议再等两三个月看维护节奏。

还有一点容易被忽略：它绑定了 ElevenLabs。转写是整条链路的地基，而地基是别人的付费 API，并且只支持词级逐字模式。SKILL.md 里明确禁掉了 Whisper 的 SRT 短语模式和本地 CPU 跑 Whisper，理由是丢失亚秒级间隙数据、归一化掉填充词。这个取舍技术上说得通，但也意味着换 ASR 供应商不是改一行配置的事。

趋势上我偏乐观。browser-use 团队有把工具做大的历史，MIT 协议、一键 setup prompt、把 skill 注册进任意 agent 的设计，都说明他们想铺生态而不是只做个玩具。真正需要观察的是往后三个月，提交是继续脉冲式停摆，还是开始有第二个人稳定接手。判断给完了，该看资源入口。

资源地址

地址就这些，但真正该说的结论还没收口：这东西到底该不该进你的日常工作流。

剪之前先想清楚你要的是哪一种剪辑

如果你每周都要出一条口播，而且已经在用 Claude Code，video-use 值得花半小时装一次。它省掉的不是剪辑软件的学费，是把 90 分钟素材剪成 8 分钟这段纯体力活。

如果你追求的是画面上的精细控制，或者素材里根本没什么人说话，那它帮不上太多忙。这类需求还是回到 DaVinci 或者剪映里手工磨，别指望一个读文本的 agent 替你做视觉节奏。

我的建议是先拿一段两分钟的英文口播素材试跑一遍，确认转写、切点、字幕、调色四件事都在你接受的范围里，再决定要不要上长素材。Scribe 按分钟计费，试错成本是真实存在的。

再补一句：它把 AI 剪视频这道题的解法换了个方向。不比谁看的帧多，比谁喂给模型的上下文更干净。这个思路比项目本身活得更久。