OpenCut：7 万 Star 的开源版剪映，为什么要把整个项目推倒重写

从「网页版剪映替代品」到 Rust 内核 + 插件 + MCP——拆解一个 71k Star 开源视频编辑器的技术架构与重写决策

CapCut（剪映国际版）开始把基础功能一道道搬进付费墙之后，一个叫 OpenCut 的项目在 GitHub 上悄悄涨到了 7.1 万 Star。

它的自我定位极其直白：The open-source CapCut alternative（开源版 CapCut）。

更有意思的是这个项目当下的状态：维护团队没有在经典版本上加功能，而是 把它整个推倒重写。新仓库的 README 第一行就写明——「OpenCut is being rewritten from the ground up」。

一个已经拿到 7 万 Star、能用的产品，为什么要重写？重写版的技术栈和架构选型又透露了哪些设计意图？这篇文章把两代代码库都拆开来看。

一、为什么是 OpenCut：三个直击痛点的理由

经典版 OpenCut 的 README 用三句话讲清了它存在的理由，每句都对应一个真实痛点：

• Privacy（隐私）：你的视频始终留在本地设备上，不上传云端。剪映这类云端编辑器最被诟病的，就是素材和工程文件的去向不可控。

• Free features（免费功能）：剪映越来越多基础功能被收进付费墙。OpenCut 选 MIT 协议，核心能力全部免费。

• Simple（简单）：人们需要好用的编辑器，剪映已经证明了「简单」本身就有市场。OpenCut 想复刻这条路径，但保持开源。

这三点合起来，解释了它为什么能在短时间内冲到 7 万 Star——它踩中的是 创作者工具「收费化 + 云端化」趋势下被挤压的中间层用户：想要剪映的易用，又不想交订阅费、不想把素材交出去。

项目的赞助商列表也透露了它的走向：fal.ai（生成式图像/视频/音频模型）赫然在列。OpenCut 不只想做传统剪辑，还想接住 AI 生成内容这波。

二、经典版架构：Next.js + Bun + Rust/WASM 混合栈

经典版（opencut-classic）是今天 opencut.app 真正运行的版本，也是「现在该去用的版本」。它的项目结构很值得拆：

apps/web/ Next.js 网页应用

apps/desktop/ GPUI 原生桌面应用（开发中）

rust/ 平台无关的核心：GPU 合成器、特效、蒙版、WASM 绑定

docs/ 架构与子系统文档

几个关键设计决策：

1. 渲染内核用 Rust 写，编译成 WASM 给网页用。

rust/ 目录是整个项目的性能地基——GPU compositor（合成器）、effects（特效）、masks（蒙版）这些吃性能的部分都在 Rust 里实现，再通过 wasm-pack 编译成 WASM，供 apps/web 调用。业务逻辑也在从 TypeScript 往 Rust 迁。

这套 Rust + WASM 的组合，让网页版能拿到接近原生的渲染性能，是「网页版剪映」能成立的技术前提。

2. 桌面端用 GPUI，不是 Electron。

经典版 apps/desktop 选了 GPUI（Zed 编辑器同款 UI 框架）而不是 Electron。代价是开发难度更高、生态更小，换来的是更小的体积、更低的内存、更直接的 GPU 渲染。

3. Bun 作为运行时和包管理器。

整个经典版用 Bun 做 install 和 dev server，配合 Docker 跑本地数据库和 Redis。Docker 可选——只做前端开发可以完全跳过。

4. 自托管友好。

docker compose up -d 就能把整套（含生产构建）跑起来，应用在 localhost:3100。这对一个开源工具很重要：私有部署、离线使用、二次开发都留了路。

一句话总结经典版：网页优先（Next.js），性能内核 Rust + WASM，桌面端押注 GPUI，Bun 统一工具链。 这套架构能跑、能用，但维护团队显然觉得它不够好——否则不会重写。

三、重写版架构：一个 Rust 工作区，三个 App

重写版（OpenCut-app/OpenCut）的仓库结构换了思路，从一个 monorepo 进化成一个 Rust workspace + 多端 App 的格局：

apps/web/ TanStack Start + React 19 + Vite 网页端

apps/api/ Elysia + Cloudflare Workers API

apps/desktop/ GPUI 桌面端（极早期，目前只开一个窗口）

Cargo.toml Rust workspace（目前成员只有 desktop，预留 crates/）

几个值得注意的选型变化：

1. 网页端从 Next.js 换成 TanStack Start + React 19。

经典版用 Next.js，重写版改用 TanStack Start（@tanstack/react-start），配合 React 19、Vite 8、Tailwind 4。UI 组件基于 shadcn + Radix + Base UI。这个选择把网页端从 Next.js 的 SSR/Server Actions 体系里解放出来，更贴近纯客户端富应用的形态——视频编辑器本来就是重客户端逻辑。

2. API 用 Elysia 跑在 Cloudflare Workers 上。

apps/api/src/index.ts 目前只有一个脚手架：Elysia 框架 + Cloudflare Adapter，暴露 /、/health、/echo 三个接口。bun run deploy 直接 wrangler deploy 到 Cloudflare。这意味着 OpenCut 的服务端要走边缘计算路线——轻量、按需、全球分发。

3. 工具链用 moonrepo + proto 统一锁版本。

重写版引入了 moon（monorepo 任务编排）和 proto（工具版本管理）。.prototools 把整个工作区的工具版本钉死：

moon = "2.3.3"

bun = "1.3.11"

rust = "1.97.0"

proto use 一条命令，任何开发者和 CI 机器拿到的环境完全一致。.moon/workspace.yml 自动发现 apps/* 下的所有项目，并预留了 crates/* 给未来的共享 Rust crate。

开发命令也统一收敛到 moon：

moon run web:dev # localhost:5173

moon run api:dev # localhost:8787

moon run desktop:dev # cargo run

4. 一个细节：bunfig.toml 里设了 minimumReleaseAge = 604800。

也就是依赖发布满 7 天（604800 秒）才允许安装。这是个防「投毒/抢装」的供应链安全措施——新发布的包哪怕进了 registry，7 天内也不会被自动拉进项目。对一个 7 万 Star、必然会被盯上的开源项目来说，这种自觉很难得。

四、重写的真正意图：六个新架构关键词

读懂重写版，关键不在「换了什么框架」，而在 README 里列出的那组 新架构关键词。这才是推倒重写的真正理由：

• Editor API：把编辑器能力开放成 API，而不只是 GUI。

• First-class third-party plugins：插件从一开始就是一等公民，靠 plugin-first architecture（插件优先架构）实现——系统先为插件设计，再在上面长功能。

• 三端一套代码（Rust core）：桌面、移动、浏览器共享同一个 Rust 内核。这是 GPUI 桌面端 + WASM 网页端那条路的延伸，把内核下沉到 Rust，三端只做外壳。

• MCP server（for AI agents）：内置 MCP（Model Context Protocol）服务，让 AI Agent 能直接驱动编辑器。

• Headless mode：无头模式，支持自动化和批量渲染。

• Scripting tab：编辑器里直接开一个脚本标签页。

把这六条连起来看，重写版 OpenCut 的野心就清晰了：它想做的已经超越「更好的网页版剪映」，而是一个 可编程、可自动化、可被 AI 驱动的视频渲染平台。

MCP server + Headless mode + Scripting tab + Editor API 这四个加在一起，等于把视频编辑从「人拖时间线」变成了 「任何程序都能调用的能力」——Agent 可以批量生成视频、CI 可以自动渲染、插件可以接管任意环节。这正是fal.ai 这类生成式模型赞助商所需要的基础设施：AI 生成素材 → OpenCut 组装渲染 → 自动产出成片。

而 plugin-first 架构是这一切的地基：没有它，Editor API 和第三方插件都只能做成脆弱的补丁。经典版显然做不到这点，所以才必须重写。

五、理性看：重写版现在能用到什么程度？

需要泼一盆冷水。重写版目前处于 极早期：

• 桌面端 README 自己标注「Very early. Right now this is just a window that opens」（非常早期，现在只是能开个窗口）。main.rs 里确实只有用 GPUI 画了一个写着 "OpenCut" 和 "desktop shell scaffold" 的窗口。

• 网页端 routes/index.tsx 还是 hello world!。

• API 只有三个测试接口。

• Rust workspace 成员目前只有 apps/desktop 一个，crates/ 还没落地。

• README 明确写：「We're not set up to take outside contributions yet while the architecture is being designed」（架构设计阶段，暂不接受外部贡献）。

换句话说，重写版现在是个 架构宣言 + 脚手架，离能用还远。今天真正想用 OpenCut 的人，该去经典版（opencut-app/opencut-classic）和 opencut.app。

六、对工程师的几点启发

抛开「又一个开源爆款」的叙事，OpenCut 的演进路径对做工具型产品的工程师有几个实在的启发：

1. 性能内核下沉到 Rust + WASM，是当下富 Web 应用的稳妥选择。 视频编辑这类吃性能的场景，把合成/特效/蒙版写进 Rust 再编译 WASM，比纯 JS 死磕性能更可持续，还能复用到桌面端。

2. 接受「重写」是一种正常演进，而不是失败。 经典版拿到了 7 万 Star，团队依然选择推倒重来——因为 plugin-first、MCP、headless 这些新需求在旧架构上是补不进去的。与其在烂地基上盖楼，不如重打地基。代价是漫长的双轨期（classic 还在服役，new 在 new.opencut.app）。

3. 供应链安全要写进工程默认配置。 minimumReleaseAge = 604800 这种一行配置的自觉，比事后救火值钱得多。

4. 工具链锁版本用 proto + moon，比 README 里写「请安装 node 18」靠谱。 任何机器 proto use 一下，环境就一致，CI 和本地不再有「在我电脑上能跑」。

5. 「AI 驱动的工具」正在从口号变成架构。 MCP server + headless + scripting 这套组合，正在成为新一代创作者工具的标配设计。OpenCut 不是唯一这么想的，但它把这套设计写进了一个 7 万 Star 项目的重写蓝图里，值得跟踪。

结语

OpenCut 的故事其实是 2026 年开源工具演进的一个缩影：先靠「免费 + 隐私 + 易用」打下半壁江山，再靠「可编程 + AI 驱动」押注下一程。

经典版证明了开源能做出好用的剪映替代品；重写版则赌的是——未来的视频编辑器，应该是一个能被 Agent 调用、能被脚本驱动、能被插件扩展的渲染平台。

它能不能跑通，还要看 Rust 内核和 plugin-first 架构落地的速度。但方向，已经很清楚了。

项目地址：https://github.com/OpenCut-app/OpenCut 经典版（今天能用的）：https://github.com/opencut-app/opencut-classic 在线试用：https://opencut.app

本文基于 OpenCut 开源仓库（MIT 协议）的公开代码与文档整理，Star 数与仓库元数据截至 2026 年 7 月。