// 01
问题背景
如实说明：OpenCut 是 opencut-app 社区的开源项目（上游仓库主作者为 Maze Winther 等），本人并非主导开发者。本地仓库是 Bin-team 组织下的 fork，git 历史中无本人提交记录，此条目标注的是开源生态参与与学习，而非个人开发成果。
跟踪它的动机很直接：BinCutAgent 的渲染管线需要一个成熟的「时间轴编辑器」参照系——OpenCut 正在进行的重写（Rust 核心、插件优先架构、Editor API、面向 AI Agent 的 MCP Server、Headless 批量渲染）恰好覆盖了「编辑器如何对程序暴露能力」这个关键问题，其 MCP server 方向与 BinCutAgent 的 services/mcp/opencut 适配器直接相关。
// 02
系统架构
应用层
monorepo 内的多形态应用
核心层
重写中的 Rust 编辑器内核
程序化接口层
面向自动化与 AI 的开放能力
// 03
关键技术决策
每一条都包含「为什么这样选」与「代价是什么」——这是我理解这个项目的方式。
为什么研究「重写版」而非稳定的 classic 版
opencut-classic 是当前生产可用版本，但重写版的方向（Rust 核心 + Editor API + MCP + Headless）才回答了 BinCutAgent 关心的问题：编辑器能力如何被程序、而非人类调用。研读重写进程的设计与代码组织，比 fork 一个成熟但封闭的旧架构更有杠杆。
以 fork 跟踪而非另起炉灶自研编辑器
自研时间轴编辑器是年级别工程，且不是 BinCutAgent 的差异化所在（差异化在 AI 流水线与渲染编排）。跟踪上游重写、预留 MCP 适配接口，等其 Editor API 稳定后接入，是更务实的路径。代价是路线受制于上游节奏——重写期间上游明确暂不接收外部 PR，因此当前阶段以研读为主。
// 04
我的职责与产出
RESPONSIBILITIES
- 跟踪 OpenCut 重写进程（Rust 核心 / 插件架构 / Editor API 演进）
- 研读其 monorepo 工程化组织（Turborepo / biome / wrangler 部署）
- 在 BinCutAgent 中预留 services/mcp/opencut 适配器接口
- 维护 Bin-team 组织下的 fork 与上游同步
OUTCOMES
- 厘清「编辑器对 AI 暴露能力」的三种形态：Editor API / MCP Server / Headless 渲染
- 为 BinCutAgent 的 MCP 工具链提供可对接的生态选项
- 积累插件优先架构与时间轴引擎设计的研读笔记
// 05
踩坑与复盘
坦诚讲，这个条目展示的不是「我写了什么」，而是「我如何判断一个不自己写的项目值不值得跟」。结论是：重写期的架构讨论往往比稳定期的代码信息量更大。风险同样明确——上游重写周期长、API 未冻结，BinCutAgent 侧的适配层必须保持「可拔掉」的松耦合。
// 06
技术栈
- TypeScript
- Rust
- Turborepo
- Bun
- Cloudflare Workers