从 0.1.0 到 0.3.0：官方 changelog 记了些什么

2026-08-09

先把状态说清楚，不然下面每一句都会被误读。

本文描述的是 OpenCut 重写版仓库当前的代码结构与官方 README 声明的路线图。该版本尚未发布，Editor API、插件体系、MCP server、无头模式等均为官方声明的计划，我们没有见到可用实现。核对日 2026-08-09。

OpenCut 现在有两个仓库，状态完全不一样：OpenCut-app/OpenCut 是正在从头重写的主仓；OpenCut-app/opencut-classic 是旧版，已归档、不再维护，而 opencut.app 线上跑的仍然是它。这篇要拆的三份 changelog 文件，位于重写主仓的 changelog/ 目录下——注意，「文件在哪个仓库」和「这些条目属于哪个代码库的发布历史」是两回事，这正是本文第二节要花最多篇幅讲的地方。

三份文件，一张表

changelog/ 下是三份带 frontmatter 元数据的 md，把元数据抽出来并排放，是这样：

版本	日期	标题	条目数	new / improved / fixed
0.1.0	2026-02-23	Editor foundation	14	8 / 5 / 1
0.2.0	2026-03-01	Motion & effects	19	4 / 4 / 11
0.3.0	2026-04-15	Masks, animation & more	52	15 / 13 / 16

各版的 summary 官方也写了一句：0.1.0 是属性面板大改、1000+ 字体、混合模式、新取色器、预览区直接操作；0.2.0 是关键帧动画、带逐片段模糊的新特效系统、ripple 编辑模式；0.3.0 是蒙版、曲线图形编辑器、音量与速度控制、预览缩放、画布背景、贴纸。

这张表本身就是全文的原始数据，后面几节都是在解释怎么读它。

先解决归属问题，再谈功能

大多数人读 changelog 的姿势是：搜一个关键词，看到「已修复」就松口气，看到「新增」就默认自己现在能用上。放在 OpenCut 上，这个姿势会直接出事。

我们手上能确认的事实只有这些：这三份文件位于重写主仓的 changelog/ 目录；日期是 2026-02-23 到 2026-04-15；其中描述的那些功能——关键帧、蒙版、特效系统——在 classic 代码库里有一一对应的实现痕迹，比如 docs/keyframes.md、docs/effects-renderer.md、rust/crates/masks。

能确认的到此为止。README 没有说这三份记录是哪个代码库的发布历史，我们也不打算替它说。所以本文一律只讲「重写主仓的 changelog/ 记录了这三个版本及其条目」，不写「重写版已经支持蒙版」，也不写「classic 的 0.3.0 更新了什么」——这两种写法都是在补一个官方没给的前提。

**这是你读这篇、以及读任何一个正在重构中的项目的 changelog 时，第一条该拿走的判断依据：先确认这份记录描述的是哪一份可运行的代码，再决定要不要把它当依据。**判断办法也很朴素：不要停在 changelog 上，去对应仓库里找那个功能的实现文件或文档是否存在。像上面提到的 docs/keyframes.md、rust/crates/masks 这类路径，才是「某处确实有过这段代码」的证据；changelog 只是一段叙述。

顺带一个能对照但不能推论的时间线：classic 仓库最后推送是 2026-05-17，随后归档；重写主仓创建于 2025-06-22，最后推送 2026-08-05。这些日期可以并排看，但它们不足以判定 changelog 的归属，我们不做推断。

new / improved / fixed 的分布怎么读

三档分类是 changelog 自己带的元数据，比条目正文更适合快速判断，因为它不受措辞影响。

把三个版本的分布竖着看：0.1.0 是 8 新 / 5 改 / 1 修，0.2.0 是 4 新 / 4 改 / 11 修，0.3.0 是 15 新 / 13 改 / 16 修。

读法（这是读任何项目 changelog 的通用经验，不是对 OpenCut 的进度判断）：新增条目远多于修复条目的版本，通常意味着这一版在铺面，你搜「我这个问题修了没」多半搜不到；修复条目占大头的版本，往往紧跟在一次大范围新功能之后，说明上一版铺下去的东西开始被人用出问题了——这种版本反过来是查旧问题的好去处。三类都不少的版本，条目正文的信息密度最高，也最值得逐条看。

具体到你自己的用法：如果你的诉求是「找某个报错有没有被处理」，优先翻 fixed 条目多的那一版；如果诉求是「看这个项目往哪个方向走」，看 new 条目和版本标题就够了，不必逐条读。

还有一个必须如实说出来的细节：0.3.0 那一行里，三类相加是 15 + 13 + 16 = 44，而条目数字段写的是 52，差 8 条。前两版是对得上的（8 + 5 + 1 = 14，4 + 4 + 11 = 19）。差额那 8 条落在这三类之外，具体属于什么类别，我们手上的记录没有写，不做推断。提这一句不是挑刺，而是想说：元数据也要自己核一遍，别默认它自洽。真要以某一类的条目数量做判断，先把加法算一遍，一分钟的事。

0.1.0 的条目长什么样

官方 changelog 在 0.1.0 里记的，大多是编辑器的地基件。挑几条原文要点：

属性面板从零重建，数值输入支持数学表达式，也支持点击拖拽 scrub，不再只能打字；面板结构从一列平铺的基础文字样式，重组为 transform / blending / typography / spacing / background 几个分区，文字元素这一版才有了位置、缩放、旋转；新取色器带吸管、不透明度与多种颜色格式；书签支持备注、颜色标签与可选时长；可以在预览面板里直接移动、缩放、旋转元素；混合模式（Multiply、Screen、Overlay 等）加入，官方原文特别注明当时仅文字元素可用；支持从剪贴板直接粘贴图片、视频、音频；按住 Shift 可以临时关掉吸附；字体从 7 种扩到 1000 多种，且加载更快。

上面那个加粗的地方，是本节真正想讲的东西。「混合模式当时仅文字元素可用」这半句，是原文自带的限定语。读 changelog 抄结论时，限定语必须连着抄——把它删掉，「支持混合模式」就变成了一句在多数场景下不成立的话。这类限定语在 changelog 里通常以「目前」「仅」「for X only」的形式出现，很容易在转述时掉队，而它恰恰是那条记录里信息量最大的部分。

0.2.0：条目少，但修复占了大头

0.2.0 只隔了六天（2026-02-23 到 2026-03-01），summary 给的是关键帧动画、带逐片段模糊的新特效系统、ripple 编辑模式，19 条里 11 条归在 fixed。

按上一节的读法，这一版对「找旧问题」的人比对「看新功能」的人更有价值。需要提醒的是，我们没有这 11 条 fixed 的逐条原文，所以本文不列清单，也不猜它们修的是什么——真要查，去重写主仓的 changelog/ 里翻这份文件本身，比看任何二手转述都准。

0.3.0：条目最多，也最容易被误引

0.3.0 是三份里体量最大的，52 条。官方 changelog 里记的部分要点：

新增了品牌页与可下载的品牌资源；播放性能的条目，官方自述是 dramatically better，并且写明了旧行为——播放时编辑器会慢到爬、播放中操作元素时音频会卡顿，两者都已修复；缩放从一个数值拆成独立的宽高控制；系统字体（Arial、Helvetica、Times New Roman 等）开始与 Google Fonts 一同出现在字体选择器里；时间轴那一组改动比较密集——轨道间距加大、轨道行在含选中元素时高亮、轨道下方空白处点击可以移动播放头、垂直滚动在整个面板都生效；按住 Shift 或 Ctrl 框选时，改为追加到已有选区，而不是替换；Firefox 上带音频的 MP4 导出曾经失败，这一版记为已修复。

这一节有两个陷阱，说清楚：

第一，自述不是测评结论。「播放性能 dramatically better」是项目方在自己的 changelog 里写的话，不是我们的结论——我们没有编译或运行过任何版本的 OpenCut，没有任何性能数据。本文只能把这句话作为官方记载转述出来，你在引用时也该保留这个出处。

第二，fixed 条目的真正用途，是反向读旧行为。「Firefox 上带音频的 MP4 导出曾经失败」「播放中操作元素时音频会卡顿」——这两条对你的价值，不在于「所以现在好了」，而在于它们点名了这个项目在哪些组合上出过问题：特定浏览器 + 特定容器格式 + 带音轨。如果你手上要处理的正是这个组合，那这就是一条明确的风险提示，值得先做小样本验证再上量。至于「现在是不是真的好了」，changelog 说了不算，你自己的环境说了算。

把 changelog 当依据之前，先过这四问

这份记录描述的是哪一份代码？ OpenCut 这个例子里，答案是「官方没明说」。没明说就别替它补。
限定语抄全了吗？ 「当时仅文字元素可用」这半句，决定了那条记录是能用还是不能用。
元数据自洽吗？ 0.3.0 三类相加 44、条目数写 52，差额我们没有依据解释。加法一分钟就能算完。
自述和验证分清了吗？ dramatically better 是项目方的话；能不能在你的环境里成立，只有你自己能验。

最后重复一次开头那件事：opencut.app 线上跑的是已归档、不再维护的 classic；重写主仓仍在从头重写，README 列的 Editor API、第三方插件、跨三端一套代码、MCP server、无头模式、编辑器内置脚本标签页，全部是官方声明的计划，我们没有见到可用实现。别把 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 重写版仓库当前的代码结构与官方 README 声明的路线图。该版本尚未发布，Editor API、插件体系、MCP server、无头模式等均为官方声明的计划，我们没有见到可用实现。