一个已归档的仓库还能用吗：把话说清楚

2026-08-09

有人在群里丢了一句：「OpenCut 那个仓库不是归档了吗，还能用？」下面立刻分成两派，一派说归档等于死了别碰，一派说线上不是还在跑吗有什么问题。两边都对了一半，也都少说了关键的一半。

这篇不打算给一个「能用/不能用」的单选答案。归档是仓库的状态，不是软件的状态，更不是你的处境。下面先把状态摆平，再按处境分岔。

本文描述的是 OpenCut 旧版（classic）的行为。该代码库已归档、不再维护，opencut.app 线上目前仍运行该版本；重写版正在开发中，功能与操作可能变化。

先把两个仓库分开

争论之所以打不完，多半是因为两拨人说的不是同一个仓库。OpenCut 现在确实有两个，状态完全不同。以下是 2026-08-09 当天的 GitHub 元数据快照：

	主仓（重写版）	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

先说一句免得误会：star 数只是当天的一个计数，它不能推出质量、稳定性或者适不适合你，我在下文里也不会拿它做任何论证。

真正要看的是最后两行。classic 的 archived 是 true，open issues 归零；主仓的 archived 是 false，最后推送在几天前。

两个仓库的 README 各自说了什么，也必须原样带出来。主仓 README 的 Status 段第一句是「OpenCut is being rewritten from the ground up.」——正在被从头重写；紧接着它自己写明，旧版本仍在 opencut-app/opencut-classic，那才是今天该用的那个，而且 opencut.app 跑的仍然是 classic 版本，重写版会先住在 new.opencut.app，直到它准备好接管。classic 的 README 第一句同样直白：「This is the original OpenCut codebase. It’s archived and no longer maintained.」

所以「归档了还能用吗」这个问题，官方自己已经给了半个答案：他们把线上服务和「今天该用哪个」都指向了 classic。剩下的半个答案，得看你要拿它干什么。

「归档」到底意味着什么

先把这个词的边界划清楚，避免两边都过度发挥。

可以说的：仓库归档意味着不再接受提交与 issue；classic 的 open issues 是 0，最后推送停在 2026-05-17；代码是 MIT 许可，仍然可以 fork 出来自行维护；官方 README 明写线上 opencut.app 仍在运行该版本。

不能由「归档」这两个字推出来的：

不能推出「所以它不安全、有漏洞」。 我们手里没有任何关于它的安全信息，说这话是编的。
不能推出「官方某月某日就会迁移」。 README 只说「直到它准备好」，没有给任何时间表。
不能推出「重写版会更快更好」。 同样没有依据。重写版 README 列的那些「即将到来」的东西——Editor API、一等公民的第三方插件、桌面移动浏览器共用一套代码库、面向 AI agent 的 MCP server、无头模式、编辑器里内置的脚本标签页——是官方声明的计划，不是现有能力，我们没有见到可用实现。把计划当能力，是这轮讨论里最常见的一次跑偏。

顺带一个能佐证「还在路上」的实读事实：重写主仓根目录的 Cargo.toml 里，workspace 成员只有 apps/desktop 一个，crates/* 那一行还被注释着。README 说的「Rust 核心」，在这个仓库里目前还没有对应的 crate。这只是陈述当前代码状态，不做进度评价，也不预测发布时间。

按处境分岔：五种人，五个答案

一、你只想有个能剪的在线工具

这种情况其实最简单：官方 README 说 opencut.app 跑的就是 classic，而归档不影响一个已经部署好的服务继续运行。仓库归档管的是代码仓库的收改口，不是线上进程的开关。

需要你自己接受的代价是：没有维护承诺。上游不会再合入修复，出了问题也没有 issue 区可提。这跟「一定会出问题」是两回事，别自己吓自己，也别把「现在能用」当成「以后一直能用」。

二、你想在自己机器上跑一份

classic 的 README 给了完整步骤，前置是 Bun 和 Docker（Docker 是可选但推荐的，用来跑本地数据库和 Redis；只做前端可以跳过），装完依赖起开发服务，应用在 http://localhost:3000。这条路今天依然走得通——归档冻的是仓库，不是你本地那份 clone。

这里要提醒的是别把两个仓库的跑法混起来：classic 用 Bun，应用起在 3000；重写版是另一套工具链，moon run web:dev 起在 5173、moon run api:dev 起在 8787。命令和端口都不通用，照着重写版 README 的命令去 classic 目录里敲，只会白折腾一轮。

真正的取舍在后面：你 fork 之后，维护责任就完全落到你自己身上了。依赖升级、浏览器行为变化、自己改出来的 bug，上游都不会再管。MIT 许可让 fork 自行维护这条路是开着的，但许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。

三、你想读代码、学架构

归档对这类需求几乎没有影响，甚至是好事——代码不再变，你读的和文档写的对得上。

classic 仓库的 docs/ 下有几份子系统文档，讲 actions 触发层、关键帧的数据模型与注册表、特效与 GPU 渲染器的分工。里面有些设计经验是可以直接搬走的，比如它文档里那条：快捷键持久化在 localStorage 里，新的默认值只对全新安装生效，所以带 defaultShortcuts 的改动必须同时写 keybindings 迁移。「改默认值」和「让老用户拿到新默认值」是两件事——这条经验跟视频剪辑没关系，跟任何带用户配置的产品都有关系。

学习价值不会因为仓库被归档而蒸发。要注意的只有一点：你读到的是 classic 的结构，重写版换了一整套栈，别把在这边学到的目录结构套到那边去讲。

四、你想提 PR、想参与

这是最需要提前说清楚的一种，否则白忙一场。

classic 已归档，归档仓库不再接受提交与 issue。而重写主仓的 README 自己写着：「We’re not set up to take outside contributions yet while the architecture is being designed.」——架构还在设计中，还没准备好接受外部贡献。

也就是说，当下这两个仓库，没有一个是提 PR 的地方。想跟进的人，官方给的路子是加 Discord（discord.gg/zmR9N35cjK）或者开 issue。先去看一眼当前的收口状态，再决定要不要动手写代码，比写完发现无处提交要省事得多。

五、你在给团队做生产选型

到这一层，问题就不是「能不能用」，而是「你能不能承担它的状态」。三个判断点：

第一，你能不能接受一个没有上游维护的依赖。 如果能（比如场景固定、锁死版本、出事有人自己修），归档不是拦路虎；如果你的流程要求「有厂商或社区在持续修」，那 classic 现在给不了这个。

第二，别把重写版排进计划表。 README 只说「直到它准备好」，没有时间表；上面那几条「即将到来」的东西——Editor API、第三方插件、MCP server、无头模式——也都还只是官方声明的计划，尚未发布。选型表里写「等重写版出来就有插件了」是拿计划当交付。

第三，先确认你要的能力在不在 classic 里。 这一步我帮不了你——我们没有编译或运行过任何版本的 OpenCut，界面长什么样、导出什么效果、快不快，一个字都不该由我来写。要验，只能你自己按上面第二种处境跑一份，或者在官方站点上试。

顺带一提，classic README 给的三条「Why」——Privacy（视频留在你自己设备上）、Free features、Simple——是项目方自己的主张，我原样转述，不作为我们的结论；里面涉及商业产品收费策略的部分，我不做评判。

一张自查表

你的处境	归档是不是拦路虎	你要自己确认的事
在线随手用	基本不是	接受「无维护承诺」
本地跑一份	不是	fork 后维护责任归你
读代码学架构	不是	别把 classic 结构套到重写版上
提 PR 参与	是	两个仓库当前都不收外部贡献
生产选型	看你的流程	别把重写版的计划排进时间表

最后：哪些问题这篇不回答

我把边界写在明处，省得被当成结论引用：这篇没有回答 classic 安不安全、有没有已知漏洞、性能如何、导出质量如何、重写版什么时候发布、重写值不值得。这些要么我们没有信息，要么根本没有公开依据。

能确定的只有三件事：classic 的仓库已归档、不再维护；官方 README 说线上 opencut.app 仍在运行它，并把它称作「今天该用的那个」；重写版还在开发，README 列的能力是计划。剩下的，按你自己的处境接着往下判断。

延伸阅读

本文依据 OpenCut 官方仓库（github.com/OpenCut-app/OpenCut 与已归档的 github.com/OpenCut-app/opencut-classic）的 README、docs/ 架构文档、package.json、Cargo.toml 与 changelog/ 整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有编译或运行过任何版本的 OpenCut。