资讯动态

5分钟跑通video-use:一句话“剪成片子“,AI真的能出成片吗

发布时间:2026/10/16 11:43:42 来源:尧图企业网站定制
5分钟跑通video-use一句话剪成片子AI真的能出成片吗【免费下载链接】video-useEdit videos with coding agents项目地址: https://gitcode.com/GitHub_Trending/vid/video-use导读把一段口播素材丢进文件夹对终端里的 AI Agent 说一句剪成片子几分钟后final.mp4躺在素材旁边的edit/目录里——去掉口头禅、裁掉废镜头、自动调色、烧好字幕甚至还能叠上一段动画。这正是 browser-use 团队开源的 video-use 正在做的事。它没有 GUI、没有预设菜单却在一众AI 剪视频方案里跑出了自己的路LLM 不看视频它读视频。这篇文章会沿着源码把这条路线从头走一遍最后回答那个最尖锐的问题AI 到底能不能真的出成片先对齐概念video-use 不是一个剪辑软件在动手之前需要先搞清楚它的定位因为它和我们熟悉的剪映、Premiere 完全不是一类东西。video-use 是一个跑在 Claude Code / Codex 这类 Shell 级 Agent 里的技能Skill它把视频编辑拆解成转录、打包、推理、渲染、自检等步骤由 LLM 负责所有动脑子的部分ffmpeg、PIL、Manim 这些工具负责动手的部分。仓库根目录的 README.md 第一句写得很直白Introducing video-use — edit videos with Claude Code. 100% open source.它在社区的热度可以从近期的讨论窥见一斑头条上有video-use 1.2 万星用 Claude Code 剪视频的传播CSDN 上也有多篇实战文章反复强调它的几个关键事实——读取约 12KB 的文本转录稿而非数万帧画面来实现词级剪辑、依赖 ElevenLabs 的词级时间戳、需要 Claude Code/Codex 等 Shell 级 Agent 环境、无 GUI、不适用于纯无人值守流水线。这些说法都不是营销话术往下看源码每一个都能对得上。理解 video-use可以借用 browser-use 的思路browser-use 给 LLM 呈现的是结构化的 DOM 而不是一整张网页截图让模型用最小的 token 代价理解页面状态video-use 做的则是同一件事的视频版——给 LLM 呈现结构化的转录文本而不是逐帧图像流。这是一个非常反直觉但极其聪明的设计决策也是全文理解的核心线索。前置准备一个终端、两个依赖、一个 API Key跑通 video-use 不需要 GPU也不需要装什么庞大的视频处理套件。按 install.md 的约定这台机器上只需要存在三样东西video-use 仓库本体克隆到某个稳定路径官方建议~/Developer/video-use不要放在/tmp这类临时目录ffmpeg连同ffprobe在$PATH上——这是硬性依赖所有裁剪、转码、抽帧都靠它yt-dlp则是可选的只在需要从 URL 拉取素材时用ElevenLabs API Key写进仓库根目录的.env——用于 Scribe 语音转录没有 key 就什么都剪不了因为转录是整条流水线的起点。安装脚本在 README 里给得十分克制uv sync或pip install -e .装 Python 依赖brew install ffmpeg装编码器然后复制.env.example填上 key。依赖清单在 pyproject.toml 里可以看得很清楚只有requests、librosa、matplotlib、pillow、numpy五个基础库动画引擎Manim是可选的 extras——连 Heavy 的转录模型都不用本地跑全部交给云端 Scribe。第三步是把仓库注册成 Agent 的技能。Claude Code 下就是一条软链接git clone https://github.com/browser-use/video-use ~/Developer/video-use ln -sfn ~/Developer/video-use ~/.claude/skills/video-use # Claude Code # ln -sfn ~/Developer/video-use ~/.codex/skills/video-use # Codex cd ~/Developer/video-use uv sync cp .env.example .env # 填入 ELEVENLABS_API_KEY注意 install.md 里的一个细节软链接要链接整个仓库目录而不是只链 SKILL.md因为helpers/里的脚本必须和技能描述文件待在相邻的位置Agent 才能按裸名transcribe.py、render.py直接调用。安装完成后用一条真实命令验证链路而不是只做文件存在性检查python ~/Developer/video-use/helpers/timeline_view.py --help /dev/null echo helpers OK ffprobe -version | head -1如果你用的是 README 开头那段一键安装提示词Set up https://github.com/browser-use/video-use for me...Agent 会替你完成克隆、装依赖、注册技能、索要并写入 API Key 的全部工作然后等你把素材丢进文件夹。整个准备过程熟练的话确实就是 5 分钟的量级。首个任务素材进文件夹一句剪成片子开工安装就绪后工作流简单得有点朴素cd进素材目录启动claude然后说一句edit these into a launch video。接下来 Agent 会按 SKILL.md 里定义的八步流程走完整个剪辑周期这里每一步都有真实脚本兜底清点素材Inventoryffprobe探测每个文件的时长、分辨率、色彩参数接着用transcribe_batch.py以 4 个并发 worker 并行转录目录下所有视频helpers/transcribe_batch.py 里find_videos会扫mp4/mov/mkv/avi/m4v等常见扩展名最后pack_transcripts.py把所有转录结果打包成一份短语级 Markdown。问题预扫描Pre-scan通读打包后的转录稿标出口误、错误开头、需要避开的表达喂给后面的编辑子 Agent。对话Converse用大白话向用户描述看到的内容提问素材类型、目标时长、审美方向、节奏偏好、必须保留的片段——没有固定 checklist每次问的问题由素材本身决定。提出策略Propose strategy用 4–8 句话给出结构、选 take 方向、剪辑方向、动画方案、调色方向、字幕风格和预估时长然后等用户确认。执行Execute产出edl.json剪辑决策表在模棱两可的时刻用timeline_view.py下钻查看画面动画交给并行子 Agent 构建。预览render.py --preview出 720p/1080p 快速预览。自检Self-eval对渲染产物而非源素材在每个剪切点 ±1.5s 窗口内跑timeline_view检查跳帧、爆音、字幕被遮挡、动画错位等问题失败则修复重渲最多循环 3 次仍不过就向用户坦白。迭代与持久化根据用户自然语言反馈重剪重渲但绝不重新转录转录有缓存每轮结束把策略、决策、推理记录追加进edit/project.md作为下一次会话的长期记忆。注意第 4 步和第 7 步它们定义了 video-use 的边界Ask → Confirm → Execute → Self-Eval → Persist。它不是一条素材进、成片出的无人值守流水线而是一套人机协作的编辑循环——Agent 永远不在策略确认前动手也永远不在自检通过前把结果拿给你看。看输出LLM 到底是怎么看视频的这是整个项目最值得展开的部分也是它和AI 视频生成最本质的区别。video-use 的剪辑不是生成而是编辑对已有的原始素材做取舍、排序、修饰。而要让 LLM 能做编辑决策首先得让它理解素材——关键洞察在 README.md 的 How it works 一节The LLM never watches the video. Itreadsit.为什么因为对当前主流多模态模型来说视频帧是 token 黑洞。README 算了一笔账一段普通素材按 3 万帧、每帧 1500 token 估算就是4500 万 token 的噪声而 video-use 的做法是两层信息通道把体量压缩到12KB 文本 几张按需生成的 PNG。第一层也是永远加载的一层音频转录。transcribe.py把视频抽成 16kHz 单声道 WAVhelpers/transcribe.py 里extract_audio那一段 ffmpeg 命令上传 ElevenLabs Scribe开启diarize说话人分离、tag_audio_events笑声/掌声等音频事件标注、timestamps_granularityword词级时间戳得到每个词精确到毫秒的时间边界。随后pack_transcripts.py把原始 JSON 打包成短语级 markdown——按 ≥0.5s 的静音或说话人切换断句每条短语带[起始-结束]时间戳。这就是 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.第二层按需下钻的层视觉合成图。timeline_view.py接受一个时间区间输出一张 filmstrip缩略图胶片条 波形 词标签 静音区间着色的合成 PNG——它只在你需要确认某个剪接点、比较多条 take、检查剪切边界时才会被调用绝不作为扫描工具全量跑。SKILL.md 明确警告Not a scan tool — use it at decision points, not constantly。这两层信息合起来给了 LLM 一个结构化 DOM 版的视频认知音频给语义和词边界画面按需给空间信息静音间隙直接变成剪辑候选点。下图就是timeline_view输出形态的示意可以看到胶片条、说话人轨道、波形、词标签、静音带≥400ms 即可作为安全剪切点和剪切候选线全部叠在一张图里顺带一提仓库里还附了一张宣传主视觉 static/video-use-banner.png 和一份 poster.htmlHow an LLM Understands Video 信息页后者几乎是这套Dont show pixels, show transcript理念的海报级注脚。成片背后的四条流水线理解了读视频的机制再来拆解输出成片的具体动作。所有剪辑决策最后都落成一份edl.json——编辑决策列表它把 AI 的推理和 ffmpeg 的执行彻底解耦。这是全项目最精巧的中间产物LLM 只负责产 JSON渲染器只负责按 JSON 干活。{ version: 1, sources: {C0103: /abs/path/C0103.MP4, C0108: /abs/path/C0108.MP4}, ranges: [ {source: C0103, start: 2.42, end: 6.85, beat: HOOK, quote: ..., reason: Cleanest delivery, stops before slip at 38.46.}, {source: C0108, start: 14.30, end: 28.90, beat: SOLUTION, quote: ..., reason: Only take without the false start.} ], grade: warm_cinematic, overlays: [ {file: edit/animations/slot_1/render.mp4, start_in_output: 0.0, duration: 5.0} ], subtitles: edit/master.srt, total_duration_s: 87.4 }① 词级剪辑。每条range的 start/end 都必须落在转录词边界上SKILL.md 的硬规则 6Never cut inside a word并配 30–200ms 的剪切 padding硬规则 7因为 Scribe 的时间戳有 50–100ms 的漂移padding 用来吸收误差。剪切点优先选在 ≥400ms 的静音处150–400ms 的短语边界需要视觉确认150ms 则视为不安全。那些(laughter)、(applause)之类的音频事件会被视为节拍——笑点本身就是节拍剪切要延伸到笑点之后把反应收进来这是 SKILL.md 里明确的剪辑手艺而不是预设规则。② 自动调色。helpers/grade.py 的默认模式是auto用 ffmpeg 的signalstats对目标区间抽帧采样算出平均亮度、动态范围、饱和度再输出一段有界修正滤镜——所有调整被硬性限制在±8%以内目标只是干净但不显调色痕迹绝不套创意 LUT。它还有neutral_punch轻微对比度 S 曲线、warm_cinematic青橙分离的复古感注释明确写着过于激进不适合标准发布内容等预设。而调色真正讲究的地方在 helpers/render.py调色必须在逐段提取时烘焙进每个片段而不是整片合成后再调——否则叠加动画时会双重编码画质白白损失两轮。③ 字幕烧录。render.py --build-subtitles会从各源转录里挑出落在每个剪切区间内的词按 2 词一组、遇标点断行、全大写的方式切块这正是 README 说的 2-word UPPERCASE chunks by default并用输出时间轴偏移计算时间码output_time word.start - segment_start segment_offset保证多段拼接后字幕不漂移。烧录时字幕 filter 必须放在整个滤镜链的最后硬规则 1否则会被动画叠加层盖住。另外 helpers/render.py 里SUB_FORCE_STYLE的注释还揭示了一个有趣的工程细节MarginV90不是审美选择而是平台安全区规则——TikTok/IG Reels/Shorts 的 UI 会占据画面底部约 25–30%字幕必须抬到那个区域之上。④ 渲染与自检。render.py的完整链路是逐段提取带调色 30ms 音频淡入淡出防爆音→ 无损-c copyconcat 拼接 → 叠加动画setptsPTS-STARTPTST/TB把动画首帧移到叠加窗口起点→ 字幕最后应用 → 响度归一化到-14 LUFS / -1 dBTPYouTube、抖音、Instagram 的通用社交标准用两遍 loudnorm 精确测量。整个渲染阶段的代码helpers/render.py几乎就是 SKILL.md 十二条硬规则的逐条实现包括 HDR 源iPhone 默认 HLG自动 tonemap 到 Rec.709、竖屏素材按高度缩放保持方向等。动画部分值得一提多个动画槽位由并行子 Agent各自独立构建硬规则 10可选的引擎有 HyperFramesHTML/CSS 组合、RemotionReact 组合、Manim数学图表、PILPNG 序列简单卡片仓库还随带了一份完整的 Manim 技能文档在 skills/manim-video/。总耗时约等于最慢的那个动画而不是它们的和。成败判定什么素材适合什么不适合最后回到那个最现实的问题什么样的素材能交给它什么样的素材交过去会翻车基于源码机制答案其实相当清晰。适合的是音频即内容的素材。社区实测中最常出现的场景是去口头禅——把umm、uh、false start 和镜头间的死空全部剪掉这与 README 的第一条卖点完全一致。多 take 口播选最佳 take 拼接、talking head、教程、访谈、旅行 vlog、路演 demo 都在它的能力圈内因为这类素材的剪辑决策几乎都落在说什么、哪条说得最好、停顿多久上而这些信息全部存在于词级转录里。SKILL.md 甚至内置了针对多 take 选段的编辑子 Agent 简报模板按 beatHOOK → PROBLEM → SOLUTION → BENEFIT → EXAMPLE → CTA而不是按素材顺序组装。不适合的有三类边界非常明确没有清晰语音的素材纯 BGM 的氛围片、风光延时、音乐节拍混剪。整套机制以转录为起点音频里没有词takes_packed.md就是空的LLM 失去主阅读视图只能靠按需抽帧盲猜——效率和效果都会崩。需要像素级审美的内容模型看的是文本和按需抽帧它判断不了这一帧的光影过渡是否丝滑、这个转场是否高级。SKILL.md 自己也承认调色预设里没有任何创意风格创意 LUT 是被明确排除的。纯无人值守流水线策略必须经人确认成片必须过自检才交付转录还要花钱虽然缓存避免了重复计费。社区讨论中反复强调的不适用于纯无人值守流水线正是这一点——它不是批处理服务而是一个需要对话协作的编辑搭档。成本方面也值得心里有数转录走 ElevenLabs Scribe 云端 API按用量计费是唯一的显性成本ffmpeg、PIL、Manim 全部本地免费。transcribe.py的缓存逻辑helpers/transcribe.py 中transcribe_one开头如果产物已存在直接返回保证了同一素材永远只转录一次重剪重渲不重复花钱。所以回到标题的问题AI 真的能出成片吗能但前提是你理解了它的看法。video-use 用 12KB 文本换掉了 4500 万 token 的画面噪声用Ask → Confirm → Execute → Self-Eval的循环代替了一键生成的幻觉产出的是一份可以被edl.json完整回溯的、可修复的成片——它是 LLM 按文本时间轴读出来的剪辑师而不是按像素看出来的导演。把它用在对的素材上它是一把锋利的刀用错了地方它只是一只昂贵的鹦鹉。这大概也是这个项目最诚实的地方它从不假装自己是 AGI 剪辑师它只是把 LLM 恰好擅长的事读文本、做取舍和工具恰好擅长的事ffmpeg 逐帧执行严丝合缝地焊在了一起。【免费下载链接】video-useEdit videos with coding agents项目地址: https://gitcode.com/GitHub_Trending/vid/video-use创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑