video-use（browser-use/video-use）：让编码智能体「读」懂时间轴来剪片子

一、导读

video-use 是 Browser Use 团队（YC W25，2024 年由 Magnus Müller 与 Gregor Žunič 创立）开源、MIT 协议的会话式视频剪辑技能包：它不生成视频，只做剪辑，把剪辑决策交给 Claude Code、Codex、Hermes 这类编码智能体。它最反直觉的一处设计是不让模型看像素，只让它读结构化文本——用 ElevenLabs Scribe 的词级转写打包成一份约 12KB 的 takes_packed.md，只在决策点按需生成"胶片条 + 波形"复合图。它在当日涨星榜位列第三（+745），是排除已发布选题与不合格项后涨星最高的合规大模型应用项目；截至 2026-09-24 抓取共 ★26,450。核心结论是：它把"AI 剪辑"从"让模型逐帧看视频"改写成"给模型一份能对齐到词的时间轴文本 + 一条确定性 ffmpeg 渲染管线 + 12 条不许违反的硬规则"，用工程约束换来了可复现与低成本。

二、项目速览

项目	详情
仓库	browser-use/video-use（数据经 GitHub API 于 2026-09-24 抓取）
作者/团队	Browser Use（2024 年创立，创始人 Magnus Müller、Gregor Žunič，YC W25；2025-03 宣布 1,700 万美元种子轮，Felicis Ventures 领投）
主语言	Python（requires-python >=3.10）
Star 总数	26,450（fork 3,159，开放 issue 118，仓库 983 KB）
当日涨星	+745（GitHub Trending daily，2026-09-24 抓取）
License	MIT
首次发布	仓库创建 2026-04-12，最近推送 2026-08-30；0 个 Release、0 个 tag，pyproject.toml 版本号 0.1.0
形态	Agent Skill（SKILL.md 322 行 + helpers/ 六个脚本 + vendored Manim 子技能），不是独立 App
关键依赖	ffmpeg/ffprobe（硬依赖）、ELEVENLABS_API_KEY；Python 包 requests/librosa/matplotlib/pillow/numpy；可选 yt-dlp、Node.js 22+（HyperFrames）、Remotion、Manim

三、为什么是它

问题背景：AI 视频的两条路，一条太贵、一条太糙。 2026 年的 AI 视频生成侧被"算力抽卡"困住：第三方创作者复盘里给出的数字是，一条 15 秒生成视频在高排队期可能消耗约 30 万 token、折合约 15 元，而为保证可用率通常要抽卡 5–10 次，单条实际成本轻松破百元。剪辑侧的 SaaS 工具（Descript、Opus Clip 等）虽然便宜好用，但它们把模型、模板与处理流程都封在云里：素材必须上传，风格由产品预设决定，你无法把自己的编码智能体接进去，也无法把剪辑逻辑做成可版本控制的资产。video-use 选的是第三条路——不做生成，只做剪辑；不提供服务，只提供技能。

定位：它是 Skill，不是 App。 仓库里没有服务端、没有 UI，核心产物是一份 322 行的 SKILL.md（写给智能体读的行为规范）与六个 helper 命令行脚本。安装方式是把整个仓库 symlink 进 ~/.claude/skills/ 或 ~/.codex/skills/，之后用户在任意素材目录里启动自己的编码智能体，说一句"把这些剪成一支发布视频"，剩下的交给 Skill。这意味着它的能力上限由宿主智能体决定，它的下限由那 12 条硬规则兜住——前者持续涨，后者不退化，这是它比"又一个 AI 剪辑工具"更耐用的地方。

涨星动因拆解。 一是抽象层选择带来的成本叙事：第三方测算称，20 分钟、25fps 素材逐帧分析约 3 万帧 × 约 1,500 token ≈ 4,500 万 token（按当时的 GPT-5.5 价格约 225 美元），而 40 分钟素材打包成转写文本后只有约 12KB——这组对比在中文社区被反复引用，是它出圈的主要推力（该测算为第三方口径，非官方基准，见第八节）。二是创作者刚需：口播、播客、教程、访谈这类"语音驱动"内容的剪辑工作量大且高度重复，最容易被文本化替代。三是团队信誉：Browser Use 的主项目是开源浏览器智能体，YC W25 出身、Felicis 领投的 1,700 万美元种子轮（合伙人 Astasia Myers），加上"读 DOM 而非看截图"的既有方法论迁移到视频，让它的设计选择看起来不是拍脑袋。四是可验证的工程纪律：12 条硬规则、按需视觉抽查、渲染后自评、3 轮上限——这些不是营销话术，而是能直接读源码核对的东西。

四、架构原理

4.1 整体架构：素材目录 → final.mp4 的六步流水线

video-use 的架构可以概括为"两条读入通道 + 一份中间产物 + 一条确定性渲染管线 + 一个自评回路"。LLM 从不接触像素流，它只读文本；像素只在两个位置出现：转录所需的音频抽取，以及人工/模型按需发起的 timeline_view 抽查。

素材目录 <videos_dir>/                       （原始素材，永不修改）
        │
        ├─[1] transcribe ── ffmpeg 抽 16kHz 单声道 → ElevenLabs Scribe
        │        └──► <videos_dir>/edit/transcripts/<name>.json   （词级时间戳/说话人/音频事件，永久缓存）
        │
        ├─[2] pack ───── pack_transcripts.py：按静默 ≥0.5s 或说话人切换断句
        │        └──► edit/takes_packed.md        （LLM 的常驻读入通道，约 12KB/40 分钟素材）
        │
        ├─[3] reason ── LLM 只读 takes_packed.md，产出自然语言剪辑策略（4–8 句）
        │        └── 需要确认画面时，才调用 timeline_view.py 生成抽查图（按需读入通道）
        │
        ├─[4] confirm ─ 用户用大白话确认策略          ← 硬规则 11：未确认不得动剪
        │
        ├─[5] plan ──── 编辑子代理输出 edl.json      （每段的源、起止、调色、叠加、beat、理由）
        │
        ├─[6] render ── render.py 确定性管线：
        │      extract_segment（-ss 前置定位 → HDR tonemap → 缩放 → 调色 → 30ms 淡化）
        │   →  concat_segments（concat demuxer + `-c copy`，零重编码）
        │   →  build_final_composite（overlay 逐个 setpts 位移 → 字幕最后压）
        │   →  两遍 loudnorm 响度标准化 ──► edit/preview.mp4 → edit/final.mp4
        │
        └─[7] self-eval ─ 渲染输出在**每个剪切点 ±1.5s** 抽查：闪帧/爆音/字幕被遮挡/叠加错位
                 └── 不过就修 → 重渲 → 重评，最多 3 轮，仍不过则交还给人

两条读入通道的分工是这套架构的核心：常驻通道是便宜的文本（词级精度、可断句、可 diff），按需通道是昂贵的视觉（胶片条 + RMS 波形包络 + 词级标签 + 静默窗口着色）。SKILL.md 对此有明确纪律：timeline_view "不是扫描工具"，只在决策点用。产物则全部落在 <videos_dir>/edit/ 下，共十类：project.md（跨会话记忆）、takes_packed.md、edl.json、transcripts/、animations/slot_<id>/、clips_graded/、master.srt、downloads/、verify/、preview.mp4 与 final.mp4——技能目录永远保持干净，这是硬规则 12。

4.2 分层模块拆解

层	组成	职责与关键接口
宿主层	Claude Code / Codex / Hermes / Openclaw 等任意带 shell 的编码智能体	提供推理与子代理能力；video-use 通过 symlink 到 ~/.claude/skills/ 或 ~/.codex/skills/ 完成注册，无自建运行时
规范层	SKILL.md（322 行，22.6 KB）	行为契约：7 条原则、12 条硬规则、六步流程、剪切技法、调色心智模型、字幕样式、动画经验值、子代理简报模板
工具层	helpers/ 六个脚本，全部是薄 CLI	transcribe.py（单文件 Scribe）、transcribe_batch.py（4 worker 并行）、pack_transcripts.py（JSON→Markdown）、timeline_view.py（抽查图）、render.py（771 行，EDL→成片）、grade.py（375 行，调色预设与自动分析）
产物层	edit/ 目录十类文件	以 edl.json 为中枢：渲染只依赖它，迭代只改它；project.md 承载跨会话记忆
外部服务层	ElevenLabs Scribe、ffmpeg/ffprobe、HyperFrames / Remotion / Manim / PIL	转录与合成确定性下沉到 CLI 与 ffmpeg；动画引擎按 slot 懒安装、按需选择，无默认项

4.3 核心机制与算法原理

① EDL 是唯一的中枢。 剪辑决策全部落成 edl.json：每段含源文件、起止时间、调色预设、叠加动画与在输出时间轴上的位置、beat 标签与理由。LLM 不直接拼 ffmpeg 命令，而是先产出结构化决策，编辑子代理的输出契约在 SKILL.md 里写死为纯 JSON（无散文）：

[{"source": "C0103", "start": 2.42, "end": 6.85, "beat": "HOOK",
  "quote": "...", "reason": "..."}]

契约里同时规定结构原型（发布会=HOOK→PROBLEM→SOLUTION→BENEFIT→EXAMPLE→CTA、教程=INTRO→SETUP→STEPS→GOTCHAS→RECAP、访谈=问答循环、旅拍=抵达→高光→静默→离开），以及三条硬约束：起止必须落在词边界、边缘补 30–200ms、优先选 ≥400ms 静默作切点。把"艺术判断"与"工程约束"分开放，是它能让非确定性模型产出确定性结果的关键。

② 渲染管线：三档质量阶梯 + 两遍响度标准化。 render.py 第一阶段逐段提取，把调色与 30ms 淡化直接烘进片段（硬规则 3），质量按用途分档——final 为 1080p/libx264 fast/CRF 20，preview 为 medium/CRF 22，draft 为 720p/ultrafast/CRF 28（只用于检查切点）。真实命令形如：

# helpers/render.py::extract_segment（节选）
af = f"afade=t=in:st=0:d=0.03,afade=t=out:st={max(0.0, duration-0.03):.3f}:d=0.03"
cmd = ["ffmpeg", "-y", "-ss", f"{seg_start:.3f}", "-i", str(source), "-t", f"{duration:.3f}",
       "-vf", vf, "-af", af, "-c:v", "libx264", "-preset", preset, "-crf", crf,
       "-pix_fmt", "yuv420p", "-r", out_rate, "-c:a", "aac", "-b:a", "192k", "-ar", "48000",
       "-movflags", "+faststart", str(out_path)]

第二阶段是无损拼接：concat demuxer 配 -c copy，不做重编码——这也是它拒绝"单遍 filtergraph 一把梭"的原因（硬规则 2）：一旦要加叠加层，单遍方案会让每个片段被二次编码。代价是所有片段必须共享统一帧率，因此渲染前会解析一次帧率并统一强制下发。

第三阶段是叠加与字幕。每个叠加层用 setpts=PTS-STARTPTS+{t}/TB 把自己的第 0 帧平移到输出时间轴窗口起点，再用 overlay=enable='between(t,{t},{end})' 依次链到基片上；字幕最后压（硬规则 1），否则叠加层会盖住字幕。字幕时间轴须换算：output_time = word.start - segment_start + segment_offset（硬规则 5），否则拼接后必然错位。最后走两遍 loudnorm 做响度标准化。整条链只依赖 ffmpeg 与 EDL，同一份 EDL 重渲染可复现。

③ 调色：预设只是地板。 grade.py 内置四个预设——subtle（对比度 1.03、饱和 0.98）、neutral_punch（对比度 1.06 + 轻 S 曲线）、warm_cinematic（对比度 1.12、饱和 0.88、三段 colorbalance 冷暖分离）、none；auto_grade_for_clip() 采样片段帧的亮度/对比/饱和统计后给一记克制修正。纪律是"推理画面而非套预设"：一次只改一个变量、看一眼、再改，心智模型用 ASC CDL。硬性要求是调色必须在逐段提取阶段完成，不能在拼接后做。

④ 自评回路与动画并行。 渲染完成后不直接交付，而对输出成片在每个剪切点 ±1.5s 生成抽查图，逐张检查四类问题：切点闪帧/跳变、波形尖峰（30ms 淡化没兜住的爆音）、字幕被叠加遮挡、叠加层错帧。任一失败就修→重渲→重评，上限 3 轮，仍不过则把问题交还给人。多处动画则并行处理：每个动画占一个 animations/slot_<id>/ 目录、由独立子代理完成，总墙钟约等于最慢的一个而非累加（硬规则 10）；缓动函数明确禁用线性插值。

4.4 性能与设计取舍

取舍	为什么这么做	代价
读转写文本，不看像素	词级精度、可 diff；SKILL.md 称打包文本约为原始 JSON 的 1/10 token	无语音轨素材（纯 BGM、风光、ASMR）直接失效
视觉按需抽查	只在决策点花钱，避开"每帧都看"的账单	依赖模型自律，靠"不是扫描工具"的措辞约束
逐段提取 + 无损拼接	叠加层不引发二次编码，切点可逐段校验	中间文件增多，必须统一帧率与像素格式
字幕最后压、输出时间轴换算	避免遮挡与错位两类静默失败	滤镜链顺序被写死，牺牲灵活性
转写结果永久缓存	改方案、改调色、重出竖版都零转录成本	仅在源文件变化时失效
动画并行子代理	多段动画总耗时≈最慢一个	并发与内存占用上升
策略确认闸门	防止智能体自作主张	多一轮人机往返，不适合无人值守直出
3 轮自评上限	防止"修不好的循环"烧时间	可能带已知缺陷交付并显式提示

4.5 与其他架构路线的差异

与逐帧多模态分析路线相比，二者差的不是模型而是抽象层：video-use 先把视频降维成"词级时间戳 + 静默结构"，再让模型在这一层决策——这与 Browser Use 主项目"读 DOM 而非看截图"是同一套哲学。

与 Descript / Opus Clip 等 SaaS相比：SaaS 把模型、模板、处理封在云上，素材必须上传、风格由预设决定、逻辑不可版本控制；video-use 把决策权交给用户自己的智能体，素材与成片留在本地，edl.json 与 SKILL.md 都是可提交进 Git 的文本资产。代价是你要自备宿主智能体、ffmpeg 与 ElevenLabs 凭据。

与 HyperFrames / Remotion / Manim 相比：这些是叠加层动画引擎，只负责"画一段动效并渲染成视频"，不做剪切决策；video-use 把它们当可插拔插槽，按内容选引擎（产品 UI 动效走 HyperFrames、React 复用走 Remotion、公式与状态机走 Manim、计数器类简单卡走 PIL + PNG 序列），并明确反对"因为是网页就默认 Remotion"。

与 Auto-Editor 或手写 ffmpeg 脚本相比：那些方案把规则写死，没有语义判断层，"哪些话值得留、哪个 take 更好"无从谈起；video-use 把这一层交给 LLM，同时用 12 条硬规则钉死最易出错的部分。

五、应用场景

场景一：把长播客/访谈剪成精简版

痛点：一集 20 分钟播客的手工剪辑通常要 1.5–2 小时，且大部分时间花在机械劳动上——去口癖（umm/uh）、删静默、挑最佳 take、压字幕。 做法：把整段素材丢进目录，先批量转写与打包，再让智能体读 takes_packed.md 给出 4–8 句策略，确认后由 EDL 驱动渲染。

cd ~/Videos/podcast-raw
python ~/Developer/video-use/helpers/transcribe_batch.py .          # 4 worker 并行转录并缓存
python ~/Developer/video-use/helpers/pack_transcripts.py --edit-dir ./edit
python ~/Developer/video-use/helpers/render.py edit/edl.json -o edit/final.mp4 --build-subtitles

收益与量化：转录按量计费且永久缓存，第三方创作者复盘给出的量级是"20 分钟播客几美分、90 分钟素材首跑几美元"，改方案与重出片因缓存命中几乎零边际成本；同一来源称手工剪一集的时间被压缩到"设置加确认约 10 分钟"（该数字为创作者自述，非官方基准）。工程侧可核对的收益是：切点自动吸附词边界、每段 30ms 淡化消除爆音、字幕按输出时间轴生成、成片前经 ±1.5s 抽检。 适用边界：素材必须有清晰语音轨；多人抢话、强噪环境会拉低转录质量；不适合纯音乐、风光、ASMR 等无语音内容。

场景二：多 take 产品发布片，挑最佳 take + 并行动画

痛点：一次拍摄往往留下十几条 take，人工比对"哪条 hook 更好"极其耗时；片头/转场/数据卡又要另开工程。 做法：为编辑决策单独开一个子代理，按结构原型组装，并用并行子代理生成多段动画叠层。

你是剪辑一支技术发布视频的编辑。按 beat 而非素材顺序挑选每条 beat 的最佳 take。
输入：takes_packed.md + 产品背景 2 句 + 演讲人风格 + 目标时长 90s
约束：起止落在词边界；边缘补 30–200ms；优先 ≥400ms 静默；
输出：纯 JSON 数组（source/start/end/beat/quote/reason），附一行总时长自检

收益与量化：动画并行使总墙钟约等于最慢的一段而非累加（硬规则 10）；字幕样式内置 bold-overlay（2 词大写、白字描边、MarginV=35），渲染后由自评回路在 ±1.5s 窗口查闪帧、爆音与遮挡，3 轮内收敛。 适用边界：品牌色、字体、视觉语言必须由人给，SKILL.md 明确禁止默认继承；复杂合成、绿幕、三维特效超出 ffmpeg 能力范围。

场景三：教程/技术讲解叠加动画

痛点：讲公式、状态机、数据流时，纯口播信息密度不足，而手工做图又贵。 做法：按内容选动画引擎并把它当作独立插槽：先决定引擎与调色板，再在 edit/animations/slot_<id>/ 内搭建与渲染，最后把渲染产物路径写回 EDL 的 overlay 字段。

# 按需抽查画面，决定叠加位置与时长
python helpers/timeline_view.py raw/C0103.mp4 2.0 9.0 -o edit/verify/cut3.png --n-frames 10
# 单段调色试色（任意 ffmpeg 滤镜串）
python helpers/grade.py edit/clips_graded/seg_03.mp4 -o /tmp/g.mp4 --filter 'eq=contrast=1.08:saturation=1.05'

收益与量化：时长经验值让动画不至于一闪而过或拖沓（简单卡 5–7s、复杂图 8–14s）；叠加层用 PTS 位移对齐到输出时间轴，配合"视觉回报帧与旁白关键词对齐"的规则，避免动画与讲解脱节；skills/manim-video/ 内置 14 篇 Manim 参考文档，公式与图表类动画不必从零查文档。 适用边界：HyperFrames 需 Node.js 22+，Remotion/Manim/yt-dlp 均为首次使用时懒安装；动画引擎只负责出画面，剪辑与字幕仍由主流程负责。

场景四：一源多版（横版/竖版/长短版）

痛点：同一支内容要出完整版、精简版、竖版短视频，传统流程要重剪三遍。 做法：以 edl.json 为单位复制并改动，转写结果直接复用；竖屏素材由 render.py 按高度缩放保持方向（scale=-2:1920），不需要重做工程。

cp edit/edl.json edit/edl_vertical.json    # 改切点与输出规格
python helpers/render.py edit/edl_vertical.json -o edit/final_vertical.mp4 --preview   # 720p 快速校对
python helpers/render.py edit/edl_vertical.json -o edit/final_vertical.mp4

收益与量化：转写缓存使多版本迭代的增量成本≈0，唯一成本是渲染时间；三档质量阶梯（CRF 20/22/28）让"校对用 720p、交付用 1080p"成为一条命令的差别；draft 档专用于快速检查切点。 适用边界：多版本意味着多份 EDL 要各自维护，project.md 的跨会话记忆是唯一线索，把版本命名写进 project.md 是必要的自律。

场景五：常驻出片流水线

痛点：内容团队每周固定产出多支短视频，希望"素材进、成片出"，而不是每次坐在桌前重开一轮对话。 做法：按官方 README 的路径，把智能体跑在自己的 VPS 或 Telegram 上（官方推荐经 Browser Use Box 常驻），素材落到约定目录后由同一套 Skill 处理；会话记忆靠 project.md 逐次追加。 收益与量化：重复劳动被压缩为一次策略确认；转写缓存与 EDL 让"同一素材的第二次出片"只需改决策不改管道。 适用边界：不支持多人协作，仍是单人单智能体工作模式；策略确认闸门意味着它不适合完全无人值守的直出；凭据（ELEVENLABS_API_KEY）需写在仓库根 .env 并 chmod 600，且素材音频会上传到第三方转录服务，合规敏感场景需先行评估。

六、快速上手

git clone https://github.com/browser-use/video-use ~/Developer/video-use
cd ~/Developer/video-use && uv sync            # 或 pip install -e .
brew install ffmpeg                            # ffmpeg/ffprobe 为硬依赖
ln -sfn ~/Developer/video-use ~/.claude/skills/video-use     # Codex 则链到 ~/.codex/skills/
cp .env.example .env && chmod 600 .env         # 填入 ELEVENLABS_API_KEY
cd ~/Videos/我的素材 && claude                  # 在该目录启动智能体，说："把这些剪成一支发布视频"

官方给的最小验证闭环是：对单个真实文件跑一次 transcribe.py，确认转录 JSON 落盘后再让智能体进入策略阶段——不要用"文件存在"当作安装成功的证据。

七、横向对比

维度	video-use	Descript	Opus Clip	逐帧多模态剪辑方案	手写 ffmpeg / Auto-Editor
剪辑决策者	用户自己的编码智能体	内置产品逻辑 + 人工	内置模型	多模态大模型看像素	无（规则写死）
素材位置	本地目录，成片本地	云端	云端	依实现	本地
模型/密钥	用户自带（ElevenLabs + 宿主订阅）	厂商提供	厂商提供	用户自带	不需要
成本结构	转录按量（可缓存）+ 宿主订阅 + 本地渲染	订阅制（第三方报价约 16 美元/月档）	订阅/按量	极高 token 成本	仅算力
可复现性	高：edl.json + 固定管线，同 EDL 可重渲	低：依赖云产品版本	低	低：模型采样不可控	高，但无语义判断
与智能体生态	原生：Skill + 子代理 + 命令行工具面	无	无	视实现	无
最适场景	口播/播客/教程/多 take 发布会	播客与长视频结构化编辑	长视频切条分发	视觉驱动素材	机械去静默、批量转码

口径：Descript 价格取第三方评测报价（未核对官网，待确认）；其余为一手文档与源码行为。

八、局限、风险与社区观察

一、产品成熟度低于星数。 仓库 2026-04-12 创建、最近推送 2026-08-30，0 个 Release、0 个 tag，pyproject.toml 版本仍是 0.1.0；测试目录只有两个 unittest 文件（渲染帧率与方向），未见 CI 配置。以 2026-09-24 为观察点，最近一次推送距今约三周多。对个人创作够用，但把它放进生产流水线前应锁定 commit。

二、硬依赖第三方转录服务。 没有 ELEVENLABS_API_KEY 就无法工作，即所有素材音频都要出本地上传到云；第三方解读称社区呼声最高的功能是本地 Whisper 回退，当时尚未实现（该说法为第三方口径，待确认）。对隐私与合规敏感的素材，这条路目前不通。

三、时间戳精度是概率问题，不是保证。 SKILL.md 自陈 Scribe 时间戳存在 50–100ms 漂移，靠 30–200ms 切点填充吸收；遇到语速极快、重音密集的素材，切点仍可能落在不理想的位置。

四、能力边界由 ffmpeg 划定。 它擅长剪切、调色、字幕、叠加与响度，不擅长复杂合成、绿幕抠像、三维特效；纯视觉驱动素材（无语音轨）直接失效。这意味着它替代的是"重复劳动"，不是"剪辑师"。

五、非确定性带来的协作成本。 同一素材两次运行可能得到不同 EDL，因此策略确认闸门（硬规则 11）不可关闭。

六、广度与深度的取舍。 仓库把 Manim 拆成 vendored 子技能并附 14 篇参考文档，说明它在"能覆盖"与"做透一层"之间选择了广度优先。

七、社区信号。 第三方在 2026-07-03 的复盘中称其"约 13,000 星、GitHub Trending 挂了快一周"，与本次 API 抓取的 26,450 星（2026-09-24）相比，两个多月的量级变化可作为热度参考，但两处口径与时点不同，不作精确换算。生态上它是 Browser Use 产品矩阵的一环，采用前需意识到开源部分与商业云服务是分层的。

九、小结与行动建议

video-use 真正的贡献不是"又一个 AI 剪辑工具"，而是一次抽象层示范：与其让模型看像素，不如给它一份能对齐到词的文本、一条确定性的渲染管线、以及一组不许违反的硬规则。对内容团队，它把最枯燥的机械劳动压缩成一次策略确认。

1. 先用一支 5–10 分钟口播素材跑通闭环：转录 → 打包 → 策略确认 → 渲染 → 自评，确认 edit/ 目录十类产物都按预期落盘，再谈批量。
2. 把它当"决策层"而非"成片工具"：SKILL.md 里的 12 条硬规则与你的品牌规范一起进 Git，形成可复用的剪辑规范，而不是每次重新对话。
3. 隔离凭据与素材：.env 权限收紧到 600、仓库外运行、敏感音频先评估上传合规，必要时等本地转录方案。
4. 建立自己的验收清单：切点无爆音、字幕未被遮挡、时长与 EDL 一致、竖版方向正确——不要只依赖 3 轮自评，它检查不了语义与语气。
5. 明确不适用场景：无语音素材、绿幕与复杂合成、需要"感觉派"共创的剪辑，以及要求完全无人值守直出的流程。

资料来源（抓取日期 2026-09-24）：GitHub Trending daily/weekly 榜单与 GitHub REST API（browser-use/video-use 元数据、目录树、Releases/Tags——均为空）；仓库一手文档 README.md、SKILL.md（322 行）、install.md、pyproject.toml、.env.example、tests/，以及 helpers/ 六个脚本源码（render.py 771 行、grade.py 375 行、timeline_view.py 392 行、transcribe.py 241 行、pack_transcripts.py 206 行、transcribe_batch.py）；Browser Use 官方融资公告与 YC 公司档案、Felicis 投资说明（1,700 万美元种子轮，2025-03）；第三方复盘：腾讯云开发者社区《browser-use 开源 video-use》（2026-07-03，45M token 与 12KB 对比、成本与工时口径、不适用场景）、Venture Harbour 的 AI 剪辑工具评测（Descript 价格档位）；竞品信息取自 Opus Clip、Descript 官方与第三方对比文章。所有一手行为均以源码为准，第三方测算与自述数据已逐处标注来源与性质；无法核实处标"待确认"，未作补全。