6 万 Star 的视频编辑器，作者决定推倒重写

大家好，我是若风。

2025 年 6 月，一个叫 OpenCut 的开源视频编辑器在 GitHub 上出现，定位很简单，做 CapCut 的开源替代品。一年过去，63,000 个 Star,6,774 个 Fork。

然后作者做了一个很多人不会做的决定，推倒重写。

README 开头第一句话就写了，OpenCut is being rewritten from the ground up。正在从零开始重写。你现在去 opencut.app 用到的还是旧版本，新版本在 new.opencut.app 上开发，等它 ready 了才会接管主域名。

这件事本身就值得聊。一个 6 万 Star 的项目，为什么不等版本迭代，而是直接推倒重来？

一句话定位

OpenCut 是一个面向 Web、桌面、移动端的开源视频编辑器，MIT 协议，目标是成为 CapCut 的开源替代品。旧版用 TypeScript + Next.js，新版正在用 Rust 内核重写。

旧版本跑得好好的，为什么要重写

看旧版的 issue 列表就能感受到压力。332 个 open issues 里，排在前面的是这些。

• #460 Implement core video export functionality using WebCodecs
• #794 support browsers without WebCodecs via FFmpeg + HTML5 fallbacks
• #503 Native HTML5 Video Thumbnails with Smart Aspect Ratio Detection
• #582 add video effects system and interactive element manipulation

翻译过来就是，视频导出还没实现好，浏览器兼容性是硬伤，缩略图渲染靠 HTML5 憋着，特效系统想加但架构不允许。

这些不是 bug，是架构性债务。一个基于 Next.js + DOM 操作的视频编辑器，天花板就在那里。浏览器的 DOM 不是为实时视频处理设计的，你用 React 管理状态、用 CSS 做视觉、用 Canvas 做渲染，每一步都在跟性能搏斗。

坦白讲，这个天花板不是 OpenCut 独有的。所有基于 Web 技术的视频编辑器都面临同样的问题。CapCut 的桌面版是原生 C++ 写的，Final Cut Pro 是 Metal/DirectX 级别的原生应用。你要在浏览器里做视频编辑，就得接受 WebCodecs 不普及、WebGL 性能有限、DOM 重排不可控这些约束。

OpenCut 的作者显然不愿意接受这个天花板。

新版本在做什么

README 把新版本的路线图列得很清楚。我来拆几个关键决策。

Rust 核心引擎。 看 Cargo.toml 的 workspace 配置，新版有一个 apps/desktop 成员，用的是 Rust 2024 edition。更有意思的是 workspace 依赖里有 gpui = "0.2.2"。

GPUI 是什么？它是 Zed 编辑器的 GPU 加速 UI 框架。Zed 团队把它单独抽出来作为 crate 发布，OpenCut 直接拿来用了。GPUI 的核心卖点是，它跳过了浏览器的 DOM/CSS 渲染管线，直接在 GPU 上绘制 UI，帧率稳定，内存占用低。Zed 编辑器能跑到 120fps 的输入响应速度，GPUI 是关键。

一个视频编辑器用 GPUI 做桌面端，这个选择非常聪明。视频编辑器的 UI 需要处理时间轴、预览窗口、特效面板，每一帧的延迟用户都能感知到。GPUI 的 GPU 直接渲染比 Electron 的 Chromium 渲染快一个量级。

一套代码三端跑。 monorepo 用 moon + proto 管理，看 .prototools 的配置。

moon = "2.3.3"
bun  = "1.3.11"
rust = "1.97.0"

moon 是 moonrepo 的构建工具，类似 Turbo 但更精确。proto 锁定工具链版本，保证每个开发者和 CI 环境用的是同一个 Rust、Bun、moon 版本。三端架构是 apps/web(浏览器版) + apps/desktop(Rust + GPUI 桌面版) + apps/api(Cloudflare Workers 后端)。

插件优先架构。 README 明确写了新版的卖点之一是「first-class third party plugins, made possible by a plugin-first architecture」。这意味着核心功能会被拆成可组合的插件，第三方开发者可以扩展编辑器的能力。

这是对 CapCut 生态封闭的正面回应。CapCut 的模板和特效都是平台内置的，用户没法自己写。OpenCut 如果真的做到插件优先，它就不只是一个编辑器，是一个视频编辑平台。

MCP server。 这个很超前去，新版本计划内置一个 MCP server，让 AI Agent 能直接操控编辑器。想象一下，你用自然语言描述「把第 15 秒到第 30 秒的片段加一个淡入淡出」，AI Agent 通过 MCP 协议调用编辑器的 API 完成操作。

这不是空想，MCP(模型上下文协议)在 2025 年下半年已经成为 AI Agent 和工具交互的标准协议。OpenCut 把它纳入路线图，说明作者对 AI 辅助创作这件事很认真。

Headless 模式。 无头模式，用于自动化和批量渲染。这个功能对内容工厂和批量生产场景意义重大。你写一个脚本，OpenCut 在后台批量渲染 100 个视频，每个用不同模板，全程不需要人坐在屏幕前。

还没准备好

这里要说句实话。OpenCut 的新版本现在还不能用。

README 的 Contributing 部分写得很直白，「We’re not set up to take outside contributions yet while the architecture is being designed」。架构还在设计阶段，不接受外部贡献。这意味着你现在能看到的代码是个进行中的工程，不是成品。

Release 节奏也说明了这一点。

• v0.1.0 (2026-02-23)
• v0.2.0 (2026-03-02)
• v0.3.0 (2026-04-15)

从 v0.1 到 v0.3，三个月三个版本，之后就没有新 release 了。这不是一个迭代稳定的成熟项目，是一个正在从零搭建的新项目。你今天 clone 下来的代码，可能下个月结构就全变了。

而且旧版的 opencut-classic 仓库只有 111 个 Star，和主仓库的 63,000 形成巨大反差。这说明绝大多数人关注的是「OpenCut 这个概念」，而不是任何一个具体版本的代码。

fal.ai 的赞助值得注意

OpenCut 的赞助商列表里只有一家，fal.ai。这是一家做生成式 AI 模型平台的公司，提供图片、视频、音频的生成模型 API。

这个赞助关系透露了一个信号。视频编辑器的未来大概率不只是剪切拼接，还包含 AI 生成能力。你拍了一段素材，编辑器帮你用 AI 生成背景音乐、生成转场特效、甚至生成补帧画面。fal.ai 提供模型，OpenCut 提供编辑界面，两者结合可能是一个很有想象力的产品方向。

但这也意味着，OpenCut 未来的完整体验可能依赖 fal.ai 的付费 API。开源不等于免费，这点在 AI 时代越来越明显。

这个项目教你判断什么

我觉得 OpenCut 最值得思考的不是它的技术选型，而是一个产品决策,什么时候该推倒重来。

6 万 Star 的项目选择重写，这个决定不容易做。很多人会想着在旧版本上修修补补，加功能、修 bug，但 OpenCut 的作者看到了一个根本性问题，基于 DOM 的 Web 视频编辑器架构有天花板，再怎么优化也跑不过原生应用。

与其在一个有天花板的方向上投入更多精力，不如趁势能还在的时候切换赛道。旧版 6 万 Star 给了新版足够的关注度和社区基础，如果再等一年，竞品追上来，可能就没有这个窗口了。

这个判断适用于很多场景。你做的项目是否在一个有结构性限制的方向上？如果是，什么时候止损重建比继续优化更划算？

OpenCut 给了一个参考答案，当你的核心架构限制了你实现核心功能（比如视频导出）时，重写的 ROI 比补丁高。

如果你只是想找个 CapCut 替代品用，现在 OpenCut 旧版还能凑合。如果你对视频编辑器的架构设计感兴趣，值得关注它的新版，Rust + GPUI + 插件 + MCP 的组合在开源世界里几乎没有第二家在做。但别拿它做生产工具，至少等 v1.0。