企业官网建设流程全解析

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 的约定，这台机器上只需要存在三样东西：

1. video-use 仓库本体，克隆到某个稳定路径（官方建议~/Developer/video-use，不要放在/tmp这类临时目录）；
2. ffmpeg（连同ffprobe）在$PATH上——这是硬性依赖，所有裁剪、转码、抽帧都靠它；yt-dlp则是可选的，只在需要从 URL 拉取素材时用；
3. 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 里定义的八步流程走完整个剪辑周期，这里每一步都有真实脚本兜底：

1. 清点素材（Inventory）：ffprobe探测每个文件的时长、分辨率、色彩参数；接着用transcribe_batch.py以 4 个并发 worker 并行转录目录下所有视频（helpers/transcribe_batch.py 里find_videos会扫mp4/mov/mkv/avi/m4v等常见扩展名）；最后pack_transcripts.py把所有转录结果打包成一份短语级 Markdown。
2. 问题预扫描（Pre-scan）：通读打包后的转录稿，标出口误、错误开头、需要避开的表达，喂给后面的编辑子 Agent。
3. 对话（Converse）：用大白话向用户描述看到的内容，提问素材类型、目标时长、审美方向、节奏偏好、必须保留的片段——没有固定 checklist，每次问的问题由素材本身决定。
4. 提出策略（Propose strategy）：用 4–8 句话给出结构、选 take 方向、剪辑方向、动画方案、调色方向、字幕风格和预估时长，然后等用户确认。
5. 执行（Execute）：产出edl.json剪辑决策表，在模棱两可的时刻用timeline_view.py下钻查看画面，动画交给并行子 Agent 构建。
6. 预览：render.py --preview出 720p/1080p 快速预览。
7. 自检（Self-eval）：对渲染产物而非源素材，在每个剪切点 ±1.5s 窗口内跑timeline_view，检查跳帧、爆音、字幕被遮挡、动画错位等问题；失败则修复重渲，最多循环 3 次，仍不过就向用户坦白。
8. 迭代与持久化：根据用户自然语言反馈重剪重渲，但绝不重新转录（转录有缓存）；每轮结束把策略、决策、推理记录追加进<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 单声道 WAV（helpers/transcribe.py 里extract_audio那一段 ffmpeg 命令），上传 ElevenLabs Scribe，开启diarize（说话人分离）、tag_audio_events（笑声/掌声等音频事件标注）、timestamps_granularity=word（词级时间戳），得到每个词精确到毫秒的时间边界。随后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.html（"How an LLM Understands Video" 信息页），后者几乎是这套"Don't 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 的硬规则 6："Never 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的注释还揭示了一个有趣的工程细节：MarginV=90不是审美选择，而是平台安全区规则——TikTok/IG Reels/Shorts 的 UI 会占据画面底部约 25–30%，字幕必须抬到那个区域之上。

④ 渲染与自检。render.py的完整链路是：逐段提取（带调色 + 30ms 音频淡入淡出防爆音）→ 无损-c copyconcat 拼接 → 叠加动画（setpts=PTS-STARTPTS+T/TB把动画首帧移到叠加窗口起点）→ 字幕最后应用 → 响度归一化到-14 LUFS / -1 dBTP（YouTube、抖音、Instagram 的通用社交标准，用两遍 loudnorm 精确测量）。整个渲染阶段的代码（helpers/render.py）几乎就是 SKILL.md 十二条硬规则的逐条实现，包括 HDR 源（iPhone 默认 HLG）自动 tonemap 到 Rec.709、竖屏素材按高度缩放保持方向等。

动画部分值得一提：多个动画槽位由并行子 Agent各自独立构建（硬规则 10），可选的引擎有 HyperFrames（HTML/CSS 组合）、Remotion（React 组合）、Manim（数学图表）、PIL+PNG 序列（简单卡片），仓库还随带了一份完整的 Manim 技能文档在 skills/manim-video/。总耗时约等于最慢的那个动画，而不是它们的和。

成败判定：什么素材适合，什么不适合

最后回到那个最现实的问题：什么样的素材能交给它，什么样的素材交过去会翻车？基于源码机制，答案其实相当清晰。

适合的，是"音频即内容"的素材。社区实测中最常出现的场景是去口头禅——把umm、uh、false start 和镜头间的死空全部剪掉，这与 README 的第一条卖点完全一致。多 take 口播（选最佳 take 拼接）、talking head、教程、访谈、旅行 vlog、路演 demo 都在它的能力圈内，因为这类素材的剪辑决策几乎都落在"说什么、哪条说得最好、停顿多久"上，而这些信息全部存在于词级转录里。SKILL.md 甚至内置了针对多 take 选段的编辑子 Agent 简报模板，按 beat（HOOK → 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