OpenCut 是一个开源视频编辑器，目标覆盖浏览器、桌面和移动端，经常被称为开源版 CapCut。但当前主仓库正在从头重写，直接克隆 main 得到的是开发中的新架构，并不等于已经稳定可用的正式版。
项目地址：OpenCut-app/OpenCut
快速答案
如果只是想现在剪视频，优先使用官方仍在运行的 Classic 版本；如果想研究新版的 Rust 核心、插件架构、MCP 和无头渲染，再搭建主仓库开发环境。
新版规划包含：
- 编辑器 API；
- 第三方插件；
- Web、桌面和移动端共用 Rust 核心；
- 面向 AI Agent 的 MCP Server；
- 自动化批量渲染的 Headless 模式；
- 编辑器内脚本面板。
这些是正在推进的方向，不应当全部视为当前稳定功能。
本地开发环境
官方使用 moonrepo 的 proto 管理固定版本的开发工具。安装 proto 后，在仓库根目录执行：
|
|
Web 开发服务默认使用 localhost:5173，API 开发服务默认使用 localhost:8787。桌面端使用：
|
|
桌面构建还要参考 apps/desktop/README.md 中的平台依赖。Windows 用户尤其要先确认 Rust、系统编译工具和 WebView 运行环境是否齐全。
为什么不建议直接拿新版做生产工具
主仓库 README 明确说明架构仍在设计，暂时没有准备好接受外部贡献。对普通用户而言，可能遇到三类问题：
- 功能入口存在，但保存、导出或时间轴行为还会变化；
- 文档和命令随重写快速调整；
- 浏览器演示能运行，不代表桌面端和移动端已经达到同等稳定性。
因此不要把唯一的视频工程交给开发版本。测试前先备份素材，导出后重新播放检查音画同步、分辨率和帧率。
OpenCut 适合谁
| 需求 | 建议 |
|---|---|
| 立即替代日常剪辑软件 | 先试 Classic 或其他成熟工具 |
| 学习开源视频编辑器架构 | 使用新版主仓库 |
| 开发视频插件或自动化 | 关注插件 API 与 Headless 模式 |
| 让 AI Agent 自动剪辑 | 等 MCP 和编辑器 API 稳定后再评估 |
Classic 和重写版怎么选择
OpenCut 当前最容易产生的误解，是把官网能用的 Classic、主仓库的重写版和未来规划混为一谈。可以按目标选择：
只想剪视频
先打开官方 Classic 版本，用一段可公开的短素材测试导入、裁切、音频、字幕和导出。不要先搭建主仓库，也不要把唯一工程文件交给开发版。
想研究源码
使用主仓库，重点阅读 apps/、Rust 核心和 Moon 任务配置。开发服务可以分别启动，更适合定位问题，但各模块接口仍可能调整。
想参与插件或自动化
持续关注 Editor API、插件架构、Headless 模式与 MCP Server 的实际实现。README 中列出的方向不等于接口已经冻结，正式开发前应查看对应代码、Issue 和 Release。
开发环境准备
运行 proto use 前，应确认以下基础条件：
- Git 能正常检出仓库；
- 操作系统具有编译 Rust 依赖的工具链；
proto命令已加入PATH；- 端口
5173和8787未被占用； - 桌面端所需 WebView 和系统 SDK 已安装；
- 磁盘有足够空间存放依赖和构建缓存。
proto use 会按照仓库中的 .prototools 安装固定版本工具。不要看到自己已经安装 Node.js 或 Rust 就跳过，它的目的正是减少开发者之间的版本差异。
分别启动服务有什么好处
OpenCut 把 Web、API 和桌面端拆成不同任务：
|
|
排错时建议开三个终端，分别保留日志。若页面打不开，先看 Web 服务；页面能打开但项目或素材操作失败，再检查 API；只有桌面窗口异常时，最后排查桌面端运行环境。
Web 服务检查
访问 http://localhost:5173，打开浏览器开发者工具，检查控制台错误和发往 localhost:8787 的请求。若请求地址不对，先查本地环境变量与仓库文档，不要直接把 CORS 关闭。
API 服务检查
确认 8787 正在监听，并观察 API 终端是否有启动失败、数据库初始化或权限错误。端口冲突时先找占用进程，不要随意改端口后只重启其中一个服务。
桌面端检查
桌面模式通常比浏览器多一层原生依赖。Web 版正常而桌面版失败时，问题多半在系统 SDK、WebView、文件权限或打包配置，而不是编辑器界面本身。
测试视频编辑器要看哪些项目
导入
准备不同编码和分辨率的短素材，至少包含横屏、竖屏、可变帧率和单独音频。记录哪些格式可以导入，哪些只是能显示缩略图但无法播放。
时间轴
测试切割、拖动、撤销、重做和多轨同步。开发版最容易出现的问题不是按钮消失，而是操作后时间轴状态与预览不一致。
导出
检查输出分辨率、帧率、时长、音画同步和文件大小。导出完成并不代表结果正确，应使用播放器完整播放，并用媒体信息工具核对编码参数。
项目恢复
关闭页面或桌面程序后重新打开，验证项目是否保存、素材路径是否仍有效、撤销历史是否符合预期。没有通过恢复测试前，不要处理长项目。
自托管时的边界
浏览器端视频编辑会消耗 CPU、GPU、内存和本地存储。即使部署在自己的服务器上，渲染工作也可能发生在客户端。评估自托管方案时要确认：
- 素材究竟上传到服务器还是只停留在浏览器；
- 项目文件保存在哪里；
- 导出由浏览器、桌面核心还是服务端完成；
- 是否存在临时文件清理机制；
- 多用户是否会看到彼此的项目或素材。
不要仅凭“开源”推断数据一定不离开设备，仍应读取实际网络请求和部署配置。
与成熟剪辑软件比较时不要只看功能表
| 维度 | 实际要验证的内容 |
|---|---|
| 稳定性 | 长时间编辑、撤销、崩溃恢复 |
| 格式支持 | 实际导入与导出编码 |
| 性能 | 预览卡顿、代理媒体、渲染时间 |
| 字幕 | 导入、编辑、样式和导出 |
| 自动化 | API、Headless、批量任务成熟度 |
| 生态 | 插件、模板、教程和维护速度 |
OpenCut 的未来路线很吸引人，但迁移决策应建立在当前可验证能力上。
排错速查
| 问题 | 优先检查 |
|---|---|
proto 找不到 |
安装是否完成、终端是否重开、PATH |
moon run 失败 |
.prototools 是否安装成功、仓库分支是否匹配 |
| 5173 无法访问 | Web 任务日志和端口占用 |
| 页面能开但操作报错 | API 服务、8787 请求和环境变量 |
| 桌面端失败 | apps/desktop/README.md 与系统依赖 |
| 导出结果异常 | 素材编码、渲染日志和输出参数 |
常见问题
OpenCut 可以完全替代 CapCut 吗？
目前不能简单下结论。基础剪辑场景可以尝试，但模板、特效、字幕、素材生态和跨设备工作流仍需逐项比较。
为什么仓库能启动但不能正常导出？
先确认使用的是 Classic 还是重写版，并查看对应分支和文档。主仓库的开发服务启动成功，只说明前后端能运行，不代表所有编辑功能已经完成。
可以用 Docker 一键部署新版吗？
是否存在可用镜像和 Compose 配置应以当前仓库文档为准。开发服务涉及浏览器、API 和桌面端，不应把第三方未经维护的镜像当作官方稳定部署方式。
OpenCut 的 MCP 现在就能用于批量剪辑吗？
README 把 MCP 列为重写方向之一。真正接入前要确认当前代码和 Release 已提供可用 Server、工具列表和权限说明，不能只依据规划文字配置生产任务。
如何跟踪重写进度
OpenCut 主仓库变化快，判断某个功能是否可用时，按这个顺序查证：
- README 当前状态说明；
- Releases 中是否有对应版本；
- 代码中是否存在实际实现；
- Issue 是否标记限制或已知故障；
- 新版演示站能否完成相同操作；
- 本地检出版本与文档提交是否一致。
不要只看截图、路线图或第三方视频。尤其是 MCP、Headless 和插件 API，只有出现稳定接口、权限说明和可重复示例后，才适合围绕它开发生产自动化。
开发版升级与回退
升级前先记录当前 Git 提交和 .prototools 解析出的工具版本。若本地有改动，先建立分支并提交，不要直接拉取后让依赖升级与业务修改混在一起。
推荐步骤：
|
|
随后分别启动 Web、API 和桌面任务，重新跑导入、时间轴、导出和恢复测试。若新版无法使用，可以回到记录的提交进行对比，但不要用破坏性 Git 命令丢弃未保存素材或代码。
素材与隐私检查
测试开发版时使用可公开的短素材，避免客户视频、人脸、未发布产品和带定位信息的原片。打开浏览器网络面板确认上传请求和第三方域名；桌面端还要检查缓存、临时文件和崩溃日志是否包含素材路径。
如果未来启用 MCP 或脚本功能，应把编辑器项目、素材目录和导出目录分别授权，不要让 Agent 默认读取整个用户主目录。
总结
OpenCut 值得关注，但最重要的信息是“当前正在重写”。普通用户应把 Classic 当作现阶段入口，开发者则可以用 proto 和 moon 研究新版。等编辑器 API、插件和 Headless 渲染稳定后，它才更适合进入自动化生产流程。