现在到底该用哪个版本
搜 OpenCut 的人十有八九会在第一屏就懵一次：GitHub 上跳出来一个 8 万多星的仓库，点进去 README 第一句告诉你「这个正在从头重写」，让你去用另一个只有两百来星的仓库；而那个两百来星的仓库顶上挂着灰色的 archived 标签，写着「已归档，不再维护」。星数差了几百倍，指向却是反的。
这篇不打算给你列一张功能对比表，因为在当前这个状态下，功能表会骗人。我们换个问法：你是谁、你要干什么，决定了你该看哪个仓库。
状态声明（先看这一段再往下读）
本文涉及旧版行为的部分，描述的是 OpenCut 旧版（classic）的行为。该代码库已归档、不再维护，
opencut.app线上目前仍运行该版本；重写版正在开发中，功能与操作可能变化。本文涉及新版的部分，描述的是 OpenCut 重写版仓库当前的代码结构与官方 README 声明的路线图。该版本尚未发布，Editor API、插件体系、MCP server、无头模式等均为官方声明的计划，我们没有见到可用实现。
核对日 2026-08-09。我们没有编译或运行过任何版本的 OpenCut。
先把两个仓库分清楚
每次提到 OpenCut，都必须说清是哪一个，否则后面全是误会。以 2026-08-09 的 GitHub API 快照为准：
| 主仓（重写版） | classic（旧版） | |
|---|---|---|
| 仓库全名 | OpenCut-app/OpenCut | OpenCut-app/opencut-classic |
| 仓库描述 | The open-source CapCut alternative | Original OpenCut codebase |
| star | 81917 | 213 |
| fork | 8102 | — |
| open issues | 366 | 0 |
| 最后推送 | 2026-08-05 | 2026-05-17 |
| archived | false | true（已归档） |
| license | MIT | MIT |
| 主页 | opencut.app | — |
star 数只是这一天的快照，它不能推出任何关于质量、稳定性或适用性的结论——尤其在这里，星都堆在那个「还在重写」的仓库上。真正有决策价值的是最后两行：一个 archived 为 true，一个把 opencut.app 挂在主页字段上。
主仓 README 的 Status 段落原话是：
OpenCut is being rewritten from the ground up.（OpenCut 正在被从头重写。）
紧接着它自己交代了去处：旧版本仍在 opencut-app/opencut-classic，那才是今天该用的那个；opencut.app 跑的仍然是 classic 版本；重写版会先住在 new.opencut.app，直到它准备好接管。
classic README 的第一句同样直白：这是最初的 OpenCut 代码库，已归档，不再维护。
两边说的是同一件事，只是一个从「未来」的角度说，一个从「过去」的角度说。没有第三个仓库，也没有一个「稳定版分支」在中间。
五种处境，五条路
处境一：我只想在浏览器里剪一段视频
看 classic 这条线。依据是主仓 README 自己写的那句「opencut.app 跑的仍然是 classic 版本」。你打开的那个线上编辑器，对应的源码就是那个已归档的仓库。
需要接受的前提有两条：第一，你用的这套东西背后的代码库不再接受新提交与新 issue；第二，官方没有给出任何迁移时间表，README 只说重写版「直到它准备好」才接管。所以别按「下个月就换新版」来安排你的工作流。
至于用起来手感如何、导出快不快、画质怎么样——我们没用过，不编。 这些你自己试十分钟比看任何评测都准。
处境二：我要在本地跑一份，自己改自己用
还是 classic。它的 README 给了完整的本地运行链路，前置是 Bun 与 Docker/Docker Compose（Docker 是可选但推荐的，用来跑本地数据库与 Redis；只做前端可以跳过）：
# 1. fork 并 clone 仓库
# 2. 复制环境变量文件
cp apps/web/.env.example apps/web/.env.local # Unix/Linux/Mac
Copy-Item apps/web/.env.example apps/web/.env.local # Windows PowerShell
# 3. 起数据库与 Redis
docker compose up -d db redis serverless-redis-http
# 4. 装依赖并起开发服务
bun install
bun dev:web
应用起在 http://localhost:3000。README 说 .env.example 的默认值与 Docker Compose 配置对应，开箱即用。桌面端（apps/desktop/，用 GPUI 构建，README 标注 in progress）是 opt-in 的，只做 web 就完全跳过。
「已归档」在这条路上意味着什么，得说清楚，不吓唬也不粉饰：归档的含义是仓库不再接受提交与 issue，代码本身仍是 MIT 许可，你仍然可以 fork 出来自己维护。我们没有任何关于它的安全信息，所以既不会说「归档了就别用了」，也不会说「放心用」——这是你自己的风险判断，跟你把它部署在哪、给谁用有关。
处境三：我想读源码，学一个视频编辑器是怎么搭的
两边都值得读，但读到的是不同的东西。
classic 里有已经成形的子系统与配套文档：rust/ 目录是平台无关的核心（README 描述为 GPU 合成器、特效、蒙版、WASM 绑定），rust/crates/ 下有 bridge、compositor、effects、gpu、masks、time 六个 crate，另有 rust/wasm/ 发布为 npm 包 opencut-wasm；docs/ 下有 Actions、关键帧、特效与 GPU 渲染器等几份架构文档。想看「一个功能从快捷键到 GPU pass 是怎么串起来的」，这边有料。
重写版主仓目前是另一幅图景，这是我们实读目录得出的：apps/web/src/ 整个 web app 共 98 个文件，其中 components/ui/ 下 40 多个是 shadcn 风格的基础 UI 组件（accordion、button、dialog、command 之类），属于通用组件库而不是编辑器功能；apps/desktop/src/ 是 Rust + gpui，只有 main.rs、shell.rs、theme.rs、7 个 components/ 与 4 个 panels/（browser.rs、inspector.rs、preview.rs、timeline.rs）；apps/api/ 是一个 Cloudflare Worker，就四个文件。
最能说明当前阶段的是根 Cargo.toml：workspace 的 members 里只有 apps/desktop 一个成员，crates/* 那一行是被注释掉的。也就是说 README 承诺的「Rust 核心」，在主仓里还没有对应的 crate。这是事实陈述，我们不评价进度快慢，也不预测发布时间。
处境四：我想给它提 PR
先看这句，否则你会白写代码。主仓 README 原文：
We’re not set up to take outside contributions yet while the architecture is being designed. （架构还在设计中，我们还没准备好接受外部贡献。）
想跟进的人可以加 Discord（discord.gg/zmR9N35cjK）或开 issue。而 classic 那边已归档，同样不再接受提交与 issue。
结论就是这么朴素：当下没有一个可以正常提 PR 的入口。 你要么先去 issue 与 Discord 里蹲着，要么 fork 一份 classic 自己维护——那是 MIT 许可给你的自由，但也意味着后续维护成本归你。
处境五：我在等 Editor API、插件、MCP server、无头批渲染
这一节是全篇最要紧的。主仓 README 在「即将到来」下面列了这些：一个 Editor API；一等公民的第三方插件（由插件优先的架构实现）；桌面、移动、浏览器共用一套代码库（Rust 核心）；一个 MCP server（面向 AI agent）；无头模式（自动化、批量渲染）；编辑器里直接内置的脚本标签页。
这些全部是官方声明的计划，不是现有能力。 我们没有见到任何一条的可用实现。所以：
- 别因为「它有 MCP server」把它排进你的 agent 工具链——它没有；
- 别因为「它支持无头批渲染」写进你的自动化方案评估——它不支持；
- 别因为「它有插件体系」去规划你要写的插件——插件体系还没有落地。
如果你的需求取决于这几条里的任意一条，那么当下正确的动作不是选型，是等待，或者去看别的方案。把计划当能力用，是这类「重写中」项目最常见的踩坑方式。
一张表收束决策
| 你的处境 | 该看哪个 | 依据 | 我们答不了的 |
|---|---|---|---|
| 在线剪辑 | classic（经 opencut.app） | 主仓 README：opencut.app 仍跑 classic | 好不好用、导出效果 |
| 本地跑并自己改 | classic 仓库 | README 给了完整本地运行步骤，端口 3000 | 归档代码的安全状况 |
| 读源码学架构 | 两个都读，目的不同 | classic 有六个 crate 与四份架构文档；主仓 crates/* 仍被注释 | 哪套设计更优 |
| 提 PR 参与 | 暂时都不行 | 主仓明说尚不接受外部贡献；classic 已归档 | 什么时候开放 |
| 要 Editor API / 插件 / MCP | 现在都别指望 | 以上各条均为 README 声明的计划，非现有能力 | 何时发布，README 无时间表 |
有几件事我们明确不比
- 不比性能、画质、导出速度、播放流畅度。 我们没有编译或运行过任何一个版本，官方也没有给出可比的数据。这一点没依据，就不比。
- 不比哪套技术栈更好。 两边确实不同：classic 是 Next.js 一套，重写版 web 端换成了 TanStack Router / TanStack Start + Vite，本地端口从 3000 变成 5173，另有
moon run api:dev起在 8787；重写版还用 proto + moon 把工具链版本钉死在.prototools里（moon 2.3.3、bun 1.3.11、rust 1.97.0），Rust workspace 版本 0.1.0、edition 2024、gpui 0.2.2。这些都是 package.json 与配置文件里的客观差异，但官方没有说明换栈的理由，我们也不评价孰优孰劣。 - 不比它和商业产品的高下。 classic README 给的三条「Why」（Privacy、Free features、Simple）是项目方的自述立场，我们如实转述，不当成自己的结论，也不对任何商业产品的收费策略做评判。顺带一提，两个 README 都写了赞助关系（classic 感谢 Vercel 与 fal.ai，主仓 Sponsors 段列出 fal.ai），如实提及，不做褒贬。
最后一句实话
主仓的 changelog/ 目录里有 0.1.0、0.2.0、0.3.0 三份文件，日期在 2026-02 到 2026-04 之间，条目相当详细。看到它很容易顺手得出「新版已经迭代三个版本了」的结论——别这么推。 README 没有说明这些 changelog 归属于哪一个代码库的发布历史，我们不做推断，你在选型时也别拿它当新版可用性的证据。
把话收回到最开始那个矛盾上：星数在新仓，可用的东西在旧仓。这不是矛盾，只是一个项目正处在「旧的还在跑、新的还没成」的中间态。认清自己站在哪个处境上，比看任何一张对比表都管用。
延伸阅读
本文依据 OpenCut 官方仓库（github.com/OpenCut-app/OpenCut 与已归档的 github.com/OpenCut-app/opencut-classic）的 README、docs/ 架构文档、package.json、Cargo.toml 与 changelog/ 整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有编译或运行过任何版本的 OpenCut。
本文描述的是 OpenCut 旧版（classic）的行为。该代码库已归档、不再维护，
opencut.app线上目前仍运行该版本；重写版正在开发中，功能与操作可能变化。
本文描述的是 OpenCut 重写版仓库当前的代码结构与官方 README 声明的路线图。该版本尚未发布，Editor API、插件体系、MCP server、无头模式等均为官方声明的计划，我们没有见到可用实现。
许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。