video-use：让 Claude Code 按台词时间轴剪视频，而不是逐帧看画面
video-use 为编码代理提供了用于剪切、排列、添加字幕和渲染视频项目的命令。
秒懂
- 它是什么？
- video-use 把视频剪辑变成一场对话：用 ElevenLabs 转录生成文字时间轴，让编码智能体只读文本和按需生成的缩略图，就能完成粗剪、调色、字幕和动画叠加。本文拆解它的工作方式、安装步骤，以及它在什么场景下会失灵。
- 适合谁用？
- video-use 适合已经习惯用 Claude Code、Codex 这类终端智能体处理文件的用户，尤其是需要批量剪辑口播、访谈或教程视频，且能接受 ElevenLabs 转录依赖的人。不适合追求精细手动控制、需要实时预览、或不愿意把原始素材交给第三方 API 的剪辑师。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 17 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 token 浪费，不是剪辑本身
video-use 的定位很明确：给编码智能体一套剪辑视频的命令，让它像操作文件一样操作视频。它不提供图形界面，也没有预设模板。你只需要把原始素材丢进一个文件夹，然后对 Claude Code 说一句“把这些剪成宣传片”。它真正解决的问题是成本。视频是一堆帧，LLM 直接看帧会消耗巨量 token。README 算了一笔账：3 万帧乘以每帧 1500 token，等于 4500 万 token 的噪声。video-use 的做法是让 LLM 读一份约 12KB 的文字转录，只在需要判断时生成几张缩略图。这个思路和 browser-use 给 LLM 一个结构化 DOM 而不是截图是同构的。
两层信息输入：转录为主，视觉为辅
video-use 的机制分两层。第一层是音频转录，始终加载。每个视频源调用一次 ElevenLabs Scribe，得到带词级时间戳、说话人分离和音频事件的文本，例如“(笑声)”“(掌声)”。所有素材被打包进一个 takes_packed.md 文件，LLM 的主要阅读视图就是这段文本。第二层是视觉合成，按需调用。timeline_view 命令能生成任意时间范围的胶片条、波形图和词标签 PNG，只在需要判断模糊停顿、比较多个镜头或检查剪切点时使用。这种设计让 LLM 永远不直接看视频流，而是通过文字和少量图像来推理。
安装与首次运行：依赖 ElevenLabs 密钥
安装过程需要三个步骤。首先克隆仓库并软链接到智能体的 skills 目录，例如 ln -sfn ~/Developer/video-use ~/.claude/skills/video-use，Codex 则链接到 ~/.codex/skills/。然后安装依赖，用 uv sync 或 pip install -e .，同时需要 brew install ffmpeg，yt-dlp 可选。最后配置环境变量，复制 .env.example 为 .env，填入 ElevenLabs API 密钥，README 甚至写错了变量名（显示 ELEVE，应该是 ELEVENLABS_API_KEY），但意图明确。安装后，智能体会要求你粘贴密钥，之后你只需 cd 到素材目录并启动 claude，然后说一句“把这些剪成宣传片”。所有输出都放在 <videos_dir>/edit/ 下，技能目录保持干净。
工作流程：从转录到自检的六步管线
管线是固定的：转录，打包，LLM 推理，生成 EDL，渲染，自检。转录后生成文字时间轴，打包成 takes_packed.md。LLM 基于这些文本提出剪辑策略，等你确认后才动刀。生成 EDL（编辑决策表）后渲染出 final.mp4。关键在自检环节：系统会对渲染输出在每个剪切边界运行 timeline_view，检查画面跳变、音频爆音和字幕遮挡。如果发现问题，就修复并重新渲染，最多循环三次。只有通过自检，你才看到预览。这个循环把质量检查从人工前置到机器，但代价是渲染次数可能翻倍。
功能清单：去口头禅、调色、字幕、动画
video-use 内置了四项核心功能。第一是剪掉口头禅和死区，例如“umm”“uh”和句子间的空白。第二是自动调色，支持暖色调电影感、中性冲击感或自定义 ffmpeg 链。第三是字幕烧录，默认两词大写块，可自定义样式。第四是动画叠加，通过 HyperFrames、Remotion、Manim 或 PIL 生成，每个动画由一个并行子代理负责。此外还有 30ms 音频淡入淡出，避免剪切时的爆音。这些功能都封装在 helpers/ 目录的脚本里，SKILL.md 列出了 12 条硬性生产规则，其余艺术判断交给 LLM 自由发挥。
局限与失败模式：转录错误会直接传导到剪辑
最大的局限是它完全依赖 ElevenLabs 的转录质量。如果转录把某个词的时间戳对错了，剪辑就会在错误的位置下刀。README 没有提供任何转录错误的兜底机制。另一个问题是自检循环最多三次，如果三次都没通过，你只能看到失败的结果，没有降级方案。还有，它需要智能体有 shell 访问权限和 skills 目录支持，不是所有编码代理都满足。最后，所有素材都要上传到 ElevenLabs，对隐私敏感的项目这是硬伤。
替代方案：ffmpeg 手动剪辑与专业 NLE
最直接的替代是纯 ffmpeg 命令行剪辑。你可以用 ffmpeg -ss 和 -to 参数手动指定剪切点，配合 concat demuxer 拼接片段。这种方式没有转录层，也没有自检，但完全本地运行，不依赖任何 API，也不会产生 token 成本。缺点是你要自己看视频找时间码，效率低。另一个方向是专业非线性编辑软件，例如 DaVinci Resolve，它有图形时间线和自动语音转字幕功能，但那是给人类操作者用的，不是给 LLM 的。video-use 的独特之处在于它把剪辑决策权交给 LLM，而替代方案要么让 LLM 直接看帧（贵），要么让人手动操作（慢）。
编辑结论
video-use 适合已经习惯用 Claude Code、Codex 这类终端智能体处理文件的用户，尤其是需要批量剪辑口播、访谈或教程视频，且能接受 ElevenLabs 转录依赖的人。不适合追求精细手动控制、需要实时预览、或不愿意把原始素材交给第三方 API 的剪辑师。在采用前，先确认你的智能体支持 skills 目录机制，并检查 .env 中 ElevenLabs 密钥的配额是否足够。若你的工作流不依赖字数统计或字幕，可以跳过转录层，直接用 ffmpeg 命令配合时间码手动切，但那样就失去了它最大的卖点：让 LLM 基于文字边界做决定。
社区笔记