导读
把三段口播交给 AI，要求“剪成一分钟”，它要做的远不止删掉空白。哪句开头更直接，哪次重录说得完整，删掉停顿以后会不会把一句话剪成另一层意思，都得先有判断。
video-use 把这些步骤组织成了一个剪辑项目：先把声音变成带时间的文字，确定保留哪些片段，再处理画面、字幕和动效。下面沿着作者公开的演示、工作流和辅助脚本，拆清它们怎样配合。
先看作者提供的演示
项目 README 给出了一个 15 秒演示入口，并说明素材怎样进入剪辑流程、最终视频放在哪里。可以先看作者展示的结果，再结合仓库里的剪辑清单和执行脚本理解每一步。
演示：https://www.tiktok.com/@browser_use/video/7639824093721758989
作者演示与本文的中文口播练习分开看：前者是项目提供的案例，后者是为了说明操作方法而设计的任务。
先分清你手上是哪一种素材
这条路线适合已经拍过的口播、采访、录屏讲解。人物、原声和主要内容都在素材里，接下来做的是选择、重排和包装。
如果手上只有一篇文章，还需要生成旁白和画面，应当走另一条制作路线。不要先安装一堆视频 Skill，再期待它们自动补齐缺失的素材。
第一次可以选三段测试素材：同一个主题、几次不同的表达，合计两三分钟。目标是剪出一版约一分钟的解释，保留原声，先不加音乐。这样容易判断剪辑有没有改善表达。
几个工具各自负责什么
左右滑动查看完整表格
| 环节 | 谁来做 | 留给下一步什么 |
|---|---|---|
| 理解素材和确定结构 | 能运行本地脚本的 AI 助手，配合 video-use Skill | 素材清单、剪辑方案 |
| 识别人声 | ElevenLabs Scribe | 带词级时间和说话人信息的转写文件 |
| 选择切点 | AI 根据转写定位，必要时查看画面和波形 | EDL 剪辑清单，记录源文件和起止时间 |
| 剪切、拼接和处理音视频 | 项目辅助脚本与 FFmpeg | 经过剪切的基础视频 |
| 制作解释性动效 | 按需选 HyperFrames、Remotion 或 Manim | 带明确出现时间的动效片段 |
| 输出和检查 | 渲染脚本加人工检查 | 预览视频、修改清单、最终视频 |
这些工具不用全部装齐。只剪口播并加字幕时，可以先不引入动效引擎。需要展示流程图或功能变化，再选择一种适合的动效实现。
还要确认一个条件：当前项目的转写脚本会先抽取音频，再上传到 ElevenLabs。剪辑在本地，不代表整条链的素材都不出电脑。使用前确认录音可以交给该服务，计费以服务当前规则为准。
第一步：先让它认清素材
把测试文件放进单独的工作文件夹。文件名区分每次录制，例如 take-01、take-02；同一段内容换了文件，也换一个版本名。
环境准备按项目当前的 install.md 检查：Python 依赖、FFmpeg、ffprobe、转写服务凭据，以及 AI 助手能否找到完整 Skill 目录。只复制 SKILL.md 可能不够，项目的 helpers 目录里还有实际执行脚本。
环境可用后，可以先给 AI 这段任务：
左右滑动查看完整代码
请先清点这个文件夹里的三段口播，不修改原文件。
列出文件名、时长、画面方向和音轨情况，确认哪条音轨是人声。
转写前告诉我将使用的服务，以及会上传什么内容。
取得转写后，先给我一份素材摘要和剪辑方案，不要直接生成最终视频。音轨检查很有用。录屏文件可能同时包含麦克风和系统声音；选错音轨，后面拿到的文字可能是空的，或只有背景声。
第二步：按表达选择片段
转写文件要带时间。只有一段完整文字，AI 很难稳定定位某句话在视频里的位置。
video-use 会把各段转写整理成较紧凑的阅读材料，再让 AI 决定用哪次表达、从哪里开始、在哪里结束。它的 EDL 清单保存这些决定，后面的渲染脚本照清单执行。
可以接着这样要求：
左右滑动查看完整代码
目标是一版约一分钟的讲解，观众第一次接触这个主题。
先提出顺序，再列出每个片段的源文件、起止时间、保留理由。
保留结论成立的条件，不删掉“不”“只有”“如果”等会改变意思的部分。
如果素材不足以支持某个结论，标出来，不替我补说法。检查方案时，先看句意。把“如果资料齐全，可以当天整理”剪成“可以当天整理”，视频会更短，承诺却变了。
第三步：把原片时间换成成片时间
假设第二段素材里第 20 秒出现一句话，剪进成片后它可能在第 8 秒。字幕和动效都要跟着成片时间走。
项目渲染脚本会按 EDL 剪切、拼接，处理动效叠加，并在后面叠加字幕。动效文件还要记录在成片里的开始时间和持续时长。不能拿原片的时间直接给成片加字幕。
这一步最好留下三个可单独查看的产物：
- 剪辑清单：为什么选择这些片段。
- 字幕文件：内容、断句和时间是否对应成片。
- 预览视频：实际切换和声音听起来是否自然。
字幕初稿可以来自转写，但人名、数字、产品名要核对。项目包含偏英文的字幕样式示例；中文要重新看断句、字体和手机上的可读性，不能把默认效果当作中文成片标准。
第四步：先看剪辑，再决定加什么
先看没有复杂动效的粗剪。能否听懂，结论有没有说完，哪一段还拖沓，这些问题比转场数量更值得先解决。
需要补充画面时，把要求落实到具体片段：这句话出现时展示三个步骤；这个数字出现时显示它的单位和出处；这个按钮被提到时放大真实操作画面。
动效引擎负责实现这些画面。它不能替你判断原本的结论有没有证据，也不会自动知道哪种画面最适合解释内容。
第五步：看最终导出的文件
至少做三遍检查：正常播放一遍听表达；静音看一遍查字幕和画面；单独检查每个切点附近有没有断字、闪帧和音频爆点。
手机上再看一次字幕，确认没有挡住嘴、按钮或演示区域。保留原声时，重点听每句话的开头和结尾有没有被切掉。
交付可以这样要求：
左右滑动查看完整代码
交付预览视频、剪辑清单和字幕文件。
按时间码列出仍需人工判断的地方，不只回复“已完成”。
这次不要发布到任何平台，也不要覆盖原素材。改一处，尽量只重做相关部分
字幕里错了一个产品名，先修字幕；某个动效挡住人物，先改那段动效。不要一发现问题就重新转写、重新生成整条视频。
但换了录音、源文件或所选音轨，旧转写就不能直接沿用。当前转写脚本会复用已经存在的转写文件，因此素材版本要记录清楚，不能同名替换以后默认缓存还是对的。
一条能继续修改的工作流，应当保留素材、转写、剪辑清单、字幕和最终输出之间的关系。下次改稿才知道从哪一步接着做。
来源与验证范围
流程依据 browser-use/video-use 的 README、SKILL.md、安装说明，以及转写和渲染辅助脚本。本文提供的任务示例是为这篇文章重新编写的，不是原作者的实测记录。
本次核对到的源码提交为 43cfc566833548093455c9d4a46bd69913b7e552。案例来源为项目作者；本站没有独立复现本文的中文练习，不把作者演示扩写为所有中文素材的准确率或速度承诺。
项目：https://github.com/browser-use/video-use
固定版本：https://github.com/browser-use/video-use/tree/43cfc566833548093455c9d4a46bd69913b7e552