OpenCut
爱情是一个不可缺少的、但它只能是推动我们前进的加速器，而不是工作、学习的绊脚石。——张志新
https://github.com/OpenCut-app/OpenCut
OpenCut：一把还在重铸中的开源视频剪辑刀
开源世界里，很多项目一出场就急着证明自己“已经能做很多事”。OpenCut 给人的感觉却不太一样。它没有把自己包装成一件已经打磨到无可挑剔的成品，反而很坦率地把自己的状态摆在台面上：它正在从头重写。
而正是这种坦率，让这个项目显得格外有意思。
根据仓库 description，OpenCut 被定义为 “The open-source CapCut alternative”。README 则把它进一步介绍为：一个面向 web、desktop 和 mobile 的免费开源视频编辑器。 但它并没有停留在一句替代口号上，而是很明确地告诉你：现在看到的这个仓库，处在一场“从地基开始重新搭建”的过程里。
项目地址：https://github.com/OpenCut-app/OpenCut
它不是在修修补补，而是在重写自己
README 的 Status 一节非常直接：
OpenCut is being rewritten from the ground up.
这句话一出来，整个项目的阅读视角就变了。
你不会再把它当成一个“已经成熟、现在只是在补功能”的仓库，而会意识到：OpenCut 当前真正重要的，不是列出一大串现成能力，而是说明它接下来想成为什么。
README 紧接着列出了这次重写之后“即将到来”的方向：
- 一个 Editor API
- 一等公民级别的第三方插件支持
- 基于单一代码库同时覆盖 desktop、mobile 和 browser
- MCP server
- Headless mode
- 直接集成在编辑器里的 scripting tab
这份清单很能说明 OpenCut 的野心。
它不是只想做一个能剪视频的应用，而是想把视频编辑器本身变成一个更开放、更可扩展、更适合自动化和智能化协作的平台。
“插件优先”这个信号，很值得多看一眼
在即将到来的能力里，README 特别提到：
- First-class third party plugins
- made possible by a plugin-first architecture
这不是普通的“未来也许支持插件”。
它强调的是 plugin-first architecture，也就是插件不是后来补上的附加结构，而是从架构层面被放进了中心位置。
这种设计方向意味着，OpenCut 想象中的编辑器，不只是一个封闭的时间线工具箱。它更像是一个可以被扩展、被组合、被外部能力接入的创作平台。
而当一个视频编辑器从一开始就把第三方插件当成一等公民，它的气质通常会发生变化：
它不再只是“给用户用”的软件，也开始成为“给生态接入”的基础层。
一个代码库跑三端，这件事在 README 里写得很清楚
README 提到，OpenCut 希望实现：
- Desktop, mobile, and browser from one codebase
- Rust core
这里有两个非常关键的信息。
第一，它明确追求 单一代码库覆盖桌面、移动端和浏览器。
这说明 OpenCut 不是把不同平台当成彼此独立的产品线，而是希望在一个统一基础上展开。
第二，它点出了 Rust core。
这意味着这个跨平台目标，并不是停留在“愿景层面的统一”，而是准备通过 Rust 核心来承接不同平台的共同能力。
这种组合非常有意思：
上层是多端统一，下层是 Rust 核心。它给人的感觉像是在试图搭一台真正跨场景的编辑引擎，而不只是把几个前端壳子拼在一起。
它甚至已经把 AI 代理的位置预留好了
在“What’s coming”列表里，有一项非常醒目：
- MCP server (for AI agents)
这句信息量不小。
它意味着 OpenCut 在重新设计架构时，已经把 AI agent 的接入当成未来组成部分之一。不是事后想起“也许可以加点 AI”，而是在重构期就提前给它留出了位置。
如果把这件事和前面的 Editor API、plugin-first architecture、headless mode、scripting tab 放在一起看，就会发现一条很有意思的线：
OpenCut 未来想呈现的，可能不只是一个“图形界面视频编辑器”，而是一个可以被 API、插件、脚本、自动化流程以及 AI 代理共同调用和扩展的系统。
README 没有用很多夸张词汇去描述这件事，但这些关键词本身已经很能说明方向。
Headless mode 和 scripting tab，让它的未来不止是“手动剪辑”
在即将到来的能力中，README 还列出了：
- Headless mode (automation, batch rendering)
- A scripting tab directly in the editor
这两项放在视频编辑器里，味道很不一样。
Headless mode 说明 OpenCut 不只考虑人在图形界面里点击操作，也考虑自动化与批量渲染这样的场景。
而 scripting tab 则说明它不仅要做“有脚本能力”，还打算把脚本入口直接安放在编辑器内部。
这两点组合起来，会让 OpenCut 的未来形态更像一个创作引擎平台，而不只是一个传统意义上的“剪辑软件”。
你可以想象到一种工作方式：界面操作、插件扩展、脚本控制、批量处理，甚至 AI 代理协作，都围绕同一个核心展开。
README 没有展开这些能力的具体实现，但它已经把路线牌插得很明显了。
很诚实的一点是：它没有假装“现在就已经准备好了”
OpenCut 最讨人喜欢的一点，可能正是它不装。
README 明确说：
- 现在这套仓库正在重写
- 今天真正应该使用的，是前一个版本
- 站点当前也仍然指向经典版本
也就是说，项目没有把“正在重建中的未来版本”和“此刻可立即依赖的版本”混为一谈。
它反而很明确地区分了两者：未来在这里，今天可用的在经典版那里。
这种表达很少见，也很可贵。
因为很多项目面对重构期时，常常容易陷入一种尴尬状态：既想展示新方向，又不愿承认当前还没准备好。而 OpenCut 的 README 没有回避这种阶段性现实，它把“现在”和“接下来”分得很清楚。
开发方式也很直给，没有绕圈子
README 的 Development 部分很简洁，但足够清楚。
它先要求安装 proto：
1 | bash <(curl -fsSL https://moonrepo.dev/install/proto.sh) |
然后在仓库根目录执行：
1 | proto use |
README 说明，这个命令会安装 .prototools 中固定下来的工具。
接着是开发命令：
1 | moon run web:dev # localhost:5173 |
这一组命令给人的感觉很清爽。
没有过多铺垫，也没有把开发流程写成一篇漫长教程，而是直接把主要入口摆出来。你一眼就能看出，这个仓库至少在结构上已经区分了 web、api 和 desktop 这几个方向。
Desktop 部分虽然非常早期，但也写得很坦率
仓库里的 apps/desktop/README.md 提供了一个很有意思的补充视角。
它一开头就写：
- Built with GPUI
- Very early. Right now this is just a window that opens.
这句话几乎有点可爱。
它没有试图把桌面端描述得很宏伟，而是干脆告诉你：目前非常早，眼下只是一个能打开的窗口。
这种诚实，会让人对项目状态的判断更准确，也更容易建立信任。
Desktop 的运行方式
README 给出的桌面端命令如下：
1 | moon run desktop:dev # cargo run |
同时说明：
- Rust 被固定在仓库根目录的
.prototools中 - 第一次构建会从源码编译 GPUI，因此会比较久
- 根目录
Cargo.lock已提交
这些信息不多，但足够让人理解当前桌面端开发路径的大致轮廓。
Desktop 的平台要求
apps/desktop/README.md 还列出了平台要求：
- macOS：需要 Xcode command line tools，使用 Metal renderer
- Windows：无需额外依赖，使用 Win32 + DirectWrite
- Linux：通过 Vulkan 渲染，通过 Wayland 或 X11 创建窗口，并依赖一组系统包
这部分信息虽然是开发层面的，但它也隐约反映出 OpenCut 在桌面方向上的技术选择：它不是简单包一层网页，而是在认真建设一条桌面图形栈路径。
它的“现在”很克制，但“方向”很张扬
OpenCut 的 README 很短，但并不空。
它没有拿出一长串已经完成的剪辑功能去堆砌卖点，也没有试图编造当前能做到的复杂能力。相反，它把主要精力放在说明：
- 它现在处于什么阶段
- 它正在往哪里去
- 它想用什么架构去抵达那个方向
这种写法很特别。因为它更像一张蓝图说明书，而不是成品目录。
从 README 能清楚看到，OpenCut 想要的未来至少包括：
- 可扩展的编辑器 API
- 真正一等公民的插件体系
- 用 Rust 核心统一 browser、desktop、mobile
- 面向 AI agent 的 MCP server
- 无头模式与批量渲染能力
- 直接内建在编辑器里的脚本环境
这不是普通“功能加法”，而更像是一套编辑器能力模型的重新定义。
“开源 CapCut 替代品”这句话，在这里更像一个入口，而不是全部
仓库 description 中那句 The open-source CapCut alternative，确实很容易抓住眼球。
但如果只停留在这句话上，其实会低估 OpenCut 当前 README 展示出来的真正重点。
因为 README 更强调的，不是“我们像谁”，而是“我们正在重新搭什么”。
相比一个单纯的替代品定位，它现在更像是在重做一套面向未来的视频编辑基础设施：更开放、更跨平台、更插件化，也更适合自动化和 AI 协作。
也正因如此，这个项目目前最吸引人的地方，不一定是它已经完成了什么，而是它很明确地告诉你：它准备把视频编辑器做成一个怎样的系统。
关于贡献这件事，它也说得很明确
README 的 Contributing 一节没有给出开放式热情邀请，反而非常直接地说明：
- 目前架构还在设计中
- 还没有准备好接收外部贡献
- 如果想关注进展、提问或参与交流，可以加入 Discord
这依然是那种熟悉的 OpenCut 式坦率。
它没有为了看起来热闹而假装“随时欢迎大规模贡献”，而是承认自己仍处于架构探索阶段。这会让外部开发者更容易理解项目当前的节奏，也减少不必要的预期落差。
README 里还提到了支持者，但语气依旧克制
Sponsors 一节写到：
- OpenCut 获得相信开源创作者工具的公司支持
- 列出了
fal.ai
这里并没有大段渲染，也没有把赞助信息写成宣传海报。它只是安静地说明：这个项目背后确实有支持它继续往前走的力量。
从仓库信息看，它的技术身份也很清楚
根据仓库 metadata：
- 仓库名为
OpenCut-app/OpenCut - 默认分支是
main - 主要语言是 TypeScript
- License 为 MIT
- 仓库 description 是 The open-source CapCut alternative
而 README 又补充了 Rust core 与桌面端 Rust 路线、GPUI 桌面实现方向等信息。
这让 OpenCut 呈现出一种很有层次的技术形象：表面上它是一个 TypeScript 主导的多端项目仓库，但在更核心的跨平台路线里，Rust 被放在一个非常关键的位置。
如果把 OpenCut 拟人化，它像一个正在重画骨架的创作者工具
它不像那种已经穿戴整齐、随时准备上台表演的软件，更像一个正待在工作台前、把旧零件拆开、重新焊接骨架的工匠。它不急着夸自己已经多强，而是先把框架重新搭稳，把未来要接入的插件、脚本、自动化和 AI 协作入口一一预留出来。
所以你看它时，会觉得它此刻还年轻，甚至还很早；但也会很清楚，它不是在随便长大，而是在朝一个相当明确的方向生长。
结语
OpenCut 目前最重要的事实，并不是“它已经是一款成熟的视频编辑器”，而是：它正在从零重写，并试图把视频编辑器这件事做成一个更开放、更统一、更可扩展的系统。 README 里写出的 Editor API、plugin-first architecture、Rust core、多端统一、MCP server、headless mode 和 scripting tab，已经勾勒出这场重构的主线。
它现在还很早，桌面端 README 甚至坦白说“目前只是一个会打开的窗口”。但也正因为这种不遮掩的早期状态，OpenCut 反而显得很真实。它没有急着把自己说成一把已经锋利无比的剪刀，而是在认真重铸刀身。
而对于一个开源创作者工具来说，有时候最值得期待的，恰恰就是这种仍在火里、但轮廓已经越来越清晰的时刻。