1 万 Star 的 video-use，让 Claude Code 帮你剪视频

先说一个反直觉的设计。

你让 AI 去剪视频，最直觉的做法是什么，把视频拆成一帧一帧的图片，喂给多模态模型，让它「看」视频。但这里有个要命的成本问题。一段 10 分钟的视频，30 帧 × 600 秒 = 1.8 万帧，每帧大概 1500 token，算下来 2700 万 token。换算成 API 费用，剪一个视频可能要烧掉几百上千块。

这还没算上，多模态模型看视频的效果其实很差，它分不清镜头切换的精确时刻，对不上音频和画面的时间戳。

browser-use/video-use 给出了一个完全不同的答案，LLM 根本不看视频，它读视频。截止 2026 年 6 月 28 日，1.06 万 Star，1506 Fork，MIT 协议。

它把视频翻译成文字，让 LLM 在文字层面上做剪辑决策。这个思路一旦想通，你会发现它优雅得近乎作弊。

12KB 文本，干掉 45M token 的噪音

这是整个项目最核心的技术洞察，值得单独讲透。

video-use 的 README 里有一组对比，直击灵魂。

Naive approach， 3 万帧 × 1500 token = 45M token of noise. Video Use, 12KB text + a handful of PNGs.

朴素方案是 4500 万 token 的噪音，它的方案是 12KB 文本加几张 PNG。这个数量级的差距，不是优化，是换了一条路。

它怎么做到的。两层架构。

第一层，音频转写，永远加载。 它用 ElevenLabs Scribe 把每个素材做一次词级时间戳转写，连同说话人分离和音频事件（笑声、掌声、叹气）一起，打包成一个大约 12KB 的 takes_packed.md。这是 LLM 的主阅读视图。

长这样。

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

你看，每一句话都有精确到 0.01 秒的时间戳，有说话人编号，有持续时长。LLM 读这个文件，就知道哪句话在什么时候说的、谁说的、中间停顿了多久。剪辑决策需要的所有时间信息，都在这里了。

第二层，视觉合成图，按需调用。 timeline_view 这个工具，会在需要的时候生成一张胶片条加波形加文字标签的合成 PNG。它只在决策点调用，比如含糊的停顿、多次重拍对比、切点合理性检查。不是每帧都生成。

这个设计的精妙之处在于，它把「理解视频」这个重活，降维成了「理解带时间戳的文本」。而后者，恰恰是 LLM 最擅长的。

README 里有一句话点破了它的思想渊源，Same idea as browser-use giving an LLM a structured DOM instead of a screenshot, but for video。browser-use 当年是给 LLM 一个结构化的 DOM 而不是截图，来操作浏览器。video-use 是同样的思路，给 LLM 一个结构化的转写文本而不是视频帧，来剪辑视频。

同一家团队，同一个哲学。

一条完整的剪辑流水线

光能读懂视频还不够，得真能剪。video-use 的流水线覆盖了一个像样的剪辑流程该有的环节。

它先剪掉口癖和废镜头，umm、uh、假开头、拍摄间的空白，全砍掉。然后自动调色，每个片段套调色链，暖色电影感、中性、或者你自定义的 ffmpeg 链。每个切点加 30ms 音频淡入淡出，保证听不到爆音。按你的风格烧录字幕，默认是两词一组的全大写块，可完全自定义。

还能生成动画叠加，通过 HyperFrames、Remotion、Manim 或 PIL，每个动画派一个并行子 Agent 去做。

最有意思的是它的自检环节。渲染完之后，它会在每个切点边界对渲染后的输出跑一次 timeline_view 自检，抓视觉跳帧、音频爆音、隐藏字幕这些问题。发现问题就自动修，最多重试 3 次。只有过了自检，才把预览给你看。

Transcribe ──> Pack ──> LLM Reasons ──> EDL ──> Render ──> Self-Eval
                                                              │
                                                              └─ issue? fix + re-render (max 3)

这条流水线里有个细节我很喜欢，它把编辑决策表（EDL）作为中间产物。LLM 推理完输出一个 EDL，渲染引擎照着 EDL 执行。这种「决策和执行分离」的设计，让整个过程可审查、可干预。你不喜欢某个切点，改 EDL 就行，不用重跑 LLM。

它的工作方式，是「先问后切」

video-use 不是那种你扔个视频进去它就闷头剪的黑箱。它的设计原则里有一条，Ask → confirm → execute → self-eval → persist，先问、确认、执行、自检、持久化。

你对它说「edit these into a launch video」，它会先清点素材，提出一个剪辑策略，等你 OK 了才开始动刀。这是对内容创作者的尊重，毕竟剪辑是创作行为，不是机械操作。

它的 12 条硬规则和「艺术自由」的边界也划得有意思。它有 12 条不可妥协的生产规则，比如切点要在词边界、音频不能有爆音、字幕不能被遮住。这些是技术正确性，没得商量。但在这之外的「品味」层面，它给你自由。

这种态度挺克制的。它知道自己是个工具，不该替你做所有的创作决策。

跨 Agent，不绑死 Claude Code

虽然 README 标题写的是 edit videos with Claude Code，但它不绑死 Claude Code。它是一个标准 Skill，能接进任何有 shell 访问能力的 Agent，Codex、Hermes、OpenClaw 都行。

安装方式也符合 Skill 的范式。你可以丢一段 setup prompt 给你的 Agent，让它自己搞定 clone、依赖、ffmpeg、Skill 注册、ElevenLabs API key 这一套。也可以手动装，git clone 加 symlink 加 uv sync。

依赖很轻。核心是 ffmpeg，必装。yt-dlp 可选，用来下载在线素材。ElevenLabs API key 是唯一的付费依赖，因为转写要用它的 Scribe 服务。

还有一个进阶玩法，通过 Browser Use Box 跑在自己的 VPS 或 Telegram 上，做 always-on 的编辑。这个适合有持续视频产出需求的创作者。

它剪不了什么，得提前知道

这个项目很巧，但它不是万能剪辑师，有几个边界得说清楚。

第一，它依赖音频转写，所以纯视觉的视频不太适合。 它的设计哲学是「音频为主，视觉跟随」。切点来自语音边界和静音间隙。如果你的视频是纯风景延时、纯视觉混剪、没有对白，它的优势发挥不出来。

第二，ElevenLabs Scribe 是付费 API。 虽然转写成本低，但它是按量计费的。大量素材的批量处理，这笔费用得算进去。目前它只支持 ElevenLabs 这一个转写后端，不能换本地的 Whisper。

第三，项目还很新，没有 release。 2026 年 4 月 12 日创建，到现在两个多月，0 个 release，0 个 tag。还在快速迭代期，API 和行为可能变动。生产环境用要盯紧。

第四，自检不是万能的。 它在切点边界做视觉自检，能抓跳帧和爆音。但更复杂的剪辑美学问题，节奏感、情绪起伏、叙事逻辑，它判断不了。这些还是得人来把关。

第五，它的输出是 final.mp4，不是项目文件。 它给的是渲染好的成片，不是 Premiere 或 DaVinci 的工程文件。如果你想后续在专业软件里精修，得从 EDL 手动迁。

模态降维，是 Agent 时代被低估的工程本能

我对 video-use 的欣赏，不在于它能把视频剪得多好看，而在于它展示了一种可复用的工程判断。

视频剪辑这个任务，传统思路是让 AI 直接处理视频流，这条路又贵又难走。video-use 的做法是，把视频翻译成 LLM 最擅长的文本格式，让 LLM 在文本世界里做决策，再把决策翻译回视频操作。

这个判断值得提炼成一个可命名的模式，模态降维（Modality Downshift），不在原始模态上硬刚，而是把任务转换到 LLM 舒适区去决策，再把决策翻译回原模态执行。browser-use 把浏览器降维成 DOM，video-use 把视频降维成转写文本。它的通用公式是「找一个 LLM 已经很擅长的中间表示，让决策在中间表示上发生」。

为什么这个模式重要。因为多模态模型再强，处理原始模态的 token 成本和延迟都是文本的几十倍。当所有人都在卷「让 AI 直接看视频」的时候，有人跳出来说「别看了，读文本更划算」，这种反共识的工程本能，往往才是真正的突破。以后遇到任何「让 LLM 处理非文本数据」的任务，都值得先问一句，能不能找一个文本中间表示降维。

如果你是一个内容创作者，手里有大量口播、访谈、教程类的 raw footage，懒得自己剪，试试 video-use。把素材扔进文件夹，跟 Claude Code 说一句「edit these」，等它给你 final.mp4。

12KB 文本代替 45M token 的噪音，这就是模态降维的样子。