开源 AI 视频编辑器实战：用结构化命令连接视频生成、对话剪辑与浏览器导出
拿到 AI 生成的视频之后，怎样把它变成一条完整作品？
实际制作中，我们通常还需要挑选片段、调整顺序、裁切时长、添加配音和字幕。如果每次修改都要在生成工具与剪辑软件之间反复切换，素材管理和工程续作就会变得繁琐。
我们正在开发的 Timeline Studio，就是围绕这条工作流构建的开源浏览器视频编辑器。项目提供多轨时间线，并逐步接入 AI 创作、Agent 编辑和浏览器端导出能力。
最近，Anna 版本已经接入视频生成能力，ChatCut 也可以使用。本文结合项目实现，介绍如何把自然语言需求转换为可检查的编辑操作，以及这套机制如何与素材和导出流程衔接。
1. 先把工作流拆成三个层次
在实现上，可以把整个过程分为三层：
text
创作与规划层
理解需求，选择素材，提出编辑计划
↓
编辑执行层
校验操作，计算变化，修改工程
↓
媒体处理层
解码、预览、推理、合成与编码每一层处理的问题不同。
创作与规划层可以借助模型理解自然语言；编辑执行层需要明确的规则和稳定的状态变化；媒体处理层则需要处理浏览器 API、异步任务和设备资源。
例如，"把开头缩短一点"属于创作意图。进入执行层后，它必须转换成明确操作：修改哪个片段、保留哪个源素材区间，以及工程时长会发生什么变化。
这种分层能够让模型能力与编辑器规则分别演进。
2. 工程数据需要区分素材和片段
视频文件与时间线片段不是一一对应的。
同一个视频可以被切分成多个片段，每段拥有独立的裁切范围、速度和效果。因此，工程至少需要表达：
| 对象 | 主要职责 |
|---|---|
| 素材 | 保存原始媒体及其元数据 |
| 主画面片段 | 引用素材，记录裁切、速度和画面属性 |
| 定时片段 | 表达音频、字幕、画中画等对象的时间范围 |
| 工程 | 组织轨道、画幅、版本及整体编辑状态 |
执行操作时需要稳定的片段 ID。用户说"第二段"，系统先根据当前工程解析具体对象，再使用 ID 执行后续修改。
Timeline Studio 提供工程、轨道和片段的分层检查入口。Agent 可以先读取整体结构，再获取目标片段的时间映射、属性和关联信息。
这样既能控制上下文规模，也能减少根据界面位置猜测工程状态的问题。
3. 用 JSON 表达可执行的编辑计划
下面展示一个本地命令计划。
假设已经检查过工程，当前 revision 为 12，目标片段为 visual-123，并且它的源素材范围允许裁切到第 2～6 秒：
json
{
"schemaVersion": 1,
"project": "/projects/input.timeline",
"baseRevision": 12,
"dryRun": false,
"operations": [
{
"id": "trim-001",
"type": "visual.trim",
"clipId": "visual-123",
"sourceIn": 2,
"sourceOut": 6
}
],
"output": {
"project": "/projects/output.timeline"
}
}几个字段分别承担不同职责：
schemaVersion：明确计划协议版本。baseRevision：记录生成计划所依据的工程版本。operations：列出需要执行的操作。id：标识一次操作，用于处理重复请求。output.project：指定新的输出工程路径。
模型可以生成这类计划，其他程序也可以生成。执行器统一处理校验和状态变换。
这种方式让编辑能力不依赖某一种对话入口，也便于定位错误：是需求解析出了问题，还是操作参数不合法，或者当前工程已经发生变化。
4. 结构校验之后，还要检查工程语义
JSON 能够解析，只说明数据结构可读。
真正执行时，还需要回答：
- 目标片段是否存在？
- 裁切范围是否有效？
- 目标轨道是否被锁定？
- 工程版本是否匹配？
- 多个操作组合后，关联对象的时间是否仍然合法？
Timeline Studio 为此提供了语义预览流程：
bash
# 读取工程状态
npm run agent -- project.inspect /projects/input.timeline
# 计算计划产生的变化，不写出工程包
npm run agent -- project.diff /projects/plan.json
# 应用计划，写出新工程
npm run agent -- project.run /projects/plan.jsonproject.diff 复用正式执行所使用的命令注册表、版本检查和状态变换逻辑，返回预计发生的变化。
因此，用户审阅的内容可以对应到具体片段、属性和时长，而不只是模型生成的一段说明。
本地执行要求使用新的输出路径，保留输入工程，便于比较和恢复。
5. 浏览器编辑需要处理状态过期
本地文件处理之外，浏览器还有一个问题：用户可能在 Agent 规划时继续编辑。
例如：
text
Agent 读取工程
↓
用户手动切分片段
↓
Agent 返回基于旧工程的计划如果直接执行，计划中的目标和时间关系可能已经不成立。
浏览器接口使用 stateToken 标识读取到的编辑状态。提交编辑预览时携带该令牌，预览完成后取得 previewId。应用前，再检查工程是否仍与预览状态一致。
状态不匹配时，需要重新读取和规划，避免旧计划覆盖新修改。
成功应用的编辑通过正常历史机制提交，用户仍然可以继续手动调整和撤销。这使对话操作能够融入已有编辑流程。
6. CLI、MCP 与浏览器入口共享编辑规则
如果每个入口各写一套裁切、排序和字幕同步逻辑，维护成本会迅速增加。
项目将核心命令注册、校验和工程状态变换集中在共享引擎中。本地 CLI 与 STDIO MCP 调用同一套服务；浏览器 WebMCP 适配层将经过审阅的计划转换到共享引擎，并提交到实时编辑器。
可以把它理解为：
text
CLI ─────────┐
STDIO MCP ───┼─→ 共享命令与状态变换
WebMCP 适配 ─┘共享规则也有助于明确能力边界。
浏览器能够访问实时媒体、模型推理和完整编辑器导出流程；本地渲染目前支持限定的组合范围。接入方需要根据实际支持情况选择执行路径，不能把所有能力都视为任意入口可用。
7. 视频生成结果先进入素材库
生成视频与修改时间线，是两个独立动作。
任务完成后，用户可能需要比较多个结果，也可能决定暂时不用。因此，Timeline Studio 的生成连接器将完成的媒体先提交到"我的资产"，再由用户选择是否插入时间线。
连接器需要完成的工作包括：
text
提交任务
↓
跟踪服务状态
↓
获取输出媒体
↓
检查媒体类型与元数据
↓
提交到素材库不同服务的请求、认证和任务协议由各自适配器处理，素材接收流程由共享宿主负责。
这里也需要准确区分失败阶段。生成失败、结果下载失败和素材提交失败，对应的恢复动作不同。界面应保留这些阶段的信息，避免用户为一次下载失败重新生成视频。
8. 裁切和变速需要统一时间映射
一个片段至少涉及源素材时间和时间线时间。
假设片段使用源视频第 10～18 秒，以 2 倍速播放，那么它在时间线中持续：
text
片段时长 = (18 - 10) / 2 = 4 秒恒定速度下：
text
源时间 = 源素材起点 + 片段局部时间 × 播放速度存在速度曲线时，需要累计速度随时间的变化。
预览取帧、切分、缩略图和导出都应使用一致的时间映射。否则，用户在时间线上选择的剪切位置，可能与最终成片不一致。
这是编辑器的基础规则，也直接影响 Agent 操作是否准确。命令参数必须明确使用哪一种时间坐标，不能只给出一个含义不明的秒数。
9. 预览与导出分别优化
预览强调响应速度，需要及时处理播放、暂停和定位。导出强调完整性，需要按指定帧率计算每一帧并完成编码。
Timeline Studio 的预览使用原生媒体路径，导出使用独立的确定性离线渲染路径，通过 WebCodecs 等能力处理画面和音频，并提供兼容回退。
两条路径采用不同的调度方式，但共享时间映射和编辑参数的含义。
浏览器中的资源也需要约束。解码帧、合成结果和编码队列不能无限增长，需要通过有界处理控制内存。
长视频缩略图采用渐进准备，优先覆盖当前可见区域；用户拖动播放头时暂停后台缩略图任务，把处理资源交给实时预览。
这些工程细节直接影响用户能否在 AI 完成初稿之后继续顺畅剪辑。
10. 当前进展与源码
Timeline Studio 目前已提供浏览器多轨编辑、AI 辅助创作、Agent 编辑接口和视频导出等能力，ChatCut 也已经可以使用。
仓库所介绍的 Anna 版本已经接入 MiniMax H3、Seedance 2.5 等视频生成模型，欢迎通过仓库中的入口体验。
我们希望逐步完善从生成素材、对话编辑到成片导出的完整流程，让每一步都有明确状态，生成后的内容也能继续调整。
项目源码、运行方式和体验入口：