无限画布加上多轨时间线，创作工作台真正难的是对象模型
一、界面可以有两个，对象只能有一套
据公开报道，某厂商在一场 AI 创作发布会上推出一站式创作工作台，由无限画布和多轨道编辑器组成；用户可以从一句话、参考视频或文档开始整理思路、生成脚本，并调用生成能力，同时推出智能创作助手与移动端助手，并上线新的会员订阅方案。来源给到的就只是这条产品组合描述，功能细节、参数与价格都没有公布，本篇也不谈订阅档位划不划算——它真正值得拆的是另一件事：把两个界面拼在一起容易，让两边共用同一批对象很难。
画布和时间线是两种根本不同的组织方式。画布按空间组织，靠位置、叠放和分组表达关系，它的天然单位是“这块地方有什么”。时间线按时长组织，靠轨道、入点出点和相对偏移表达关系，它的天然单位是“这段时间里发生什么”。一旦同一批素材和生成结果要在两种拓扑里都出现，系统必须先回答一个定义性问题：什么算一份内容。
这个问题不答，两边会各自演化出两套数据：画布把素材存成自己的节点载荷，时间线把同一份素材存成另一个轨道项，各带一份参数副本。表面看用户在同一工作台里操作，实际改一边不影响另一边，导出时取哪一份变成随机事件。这类事故在集成式工具里非常常见，而且极难事后修——两套 schema 一旦各自长出功能，合并就等价于重写。
二、三种入口各自要记住什么
一句话、一段参考素材、一份已有文档，这三种入口对系统的要求不一样，不是“输入框长一点”的区别。
- 一句话进来时，要记的不只是提示词全文，还有参数集、被调用的模型与其版本标识、生成时间，以及这段文本里哪些是用户写的、哪些是模型补的。否则日后无法解释“这个画面是谁的决定”。
- 参考素材进来时，要记来源与上传方式、授权状态（谁的、可做什么）、它自己是否被裁剪或从别处派生而来、以及能否被再次用于生成。素材的授权属性必须能表达“可用于生成”与“仅可在本工程内播放”的区别，否则一次生成就把授权范围悄悄扩大了。
- 已有文档进来时，要记结构（章节层级）、被引用的具体段落位置、文档版本与读取时间。只存“引用了某文档”等于没存，因为文档会变，而且脚本里真正用到的只是某几段。
入口混用时最容易丢的一件事是派生关系：这段结果由哪个输入、哪一版参数、哪一次生成而来。派生关系要落成有向边（源对象、目标对象、转换动作、参数快照、时间戳），而不是挂在结果上的一个备注字段。字段可以改，备注可以删，边是结构。
围绕一份生成物，有四个身份问题必须能回答，缺一个它就会在流程里变成不可解释的资产：
- 它被改过几版？每版是就地覆盖还是另存，改动人是谁。
- 它被引用了几处？分别在画布节点还是时间线片段上。
- 源素材被删或换版后，它还能不能被解释——即血缘链是否完整。
- 它进入过哪些导出物，导出物是否仍可追到它。
三、无限画布的状态：先分清文档状态与视图状态
画布最容易做错的是把视图状态写进文档。可用的判定原则只有一句：影响他人所见结果的是文档状态，只影响自己怎么看的是视图状态。
| 状态项 | 归属 | 定错的后果 |
|---|---|---|
| 卡片位置与尺寸 | 文档 | 记成视图则协同里各人看到不同排布，导出结构漂移 |
| 分组与层级遮挡 | 文档 | 记成视图则导出时组关系丢失，无法还原 |
| 连线与引用指向 | 文档 | 记成视图则血缘断裂，派生关系查不到 |
| 缩放级别与视口中心 | 视图 | 记成文档则每次平移都写数据，冲突率暴涨 |
| 选择集与临时高亮 | 视图 | 记成文档则互相干扰操作，无法并发 |
| 面板折叠、筛选条件 | 视图 | 记成文档则个人偏好污染协作内容 |
缩放级别这一项看着无害，实际是协同冲突的主要来源：一旦进入文档，用户的每一次滚动平移都变成一次写操作，冲突概率与流量同步放大，导出的画布尺寸也会被最后一个人看到的状态污染。反过来，分组如果被做成纯视图（只为方便整理而不进文档），导出时组结构就没了，用户“我按组分了层”的劳动直接蒸发。
写入粒度要落在对象级而不是页面级。整张画布存成一个二进制块，协同就只能靠锁，代价是两个人不能同时编辑。对象级写入带来的要求很具体：每次操作携带版本号、位置类高频更新要节流合并（拖拽结束时提交终值，过程值只在本地广播）、删除写成墓碑而不是物理移除——否则另一个人正在引用的对象无声消失，时间线那边收到的是一段空白而不是一个错误。
四、多轨时间线的语义：轨道存的是引用
时间线这一侧的关键约定是：轨道项不持有素材，只持有对素材某版本的引用，外加一组自己的属性——入点、出点、变速比、音量与关键帧。这一条定下来，“时长重算”才有确定规则：素材本体时长是属性，轨道项的有效时长由入出点与变速比推导，拼接顺序变了要重算下游偏移，字幕与配音轨的偏移跟着主轨走。
跨轨依赖要显式建模，不能靠“看起来对齐了”。画中画轨与主轨的相对位置、字幕轨与配音轨的时间偏移、音乐轨与整段时长的贴合关系，这三类都是依赖边。主轨因为一次替换改变了长度，下游谁该跟着移动、谁该保持不动，必须是规则而不是用户的记忆。
素材被替换是最常见也最危险的操作，要按属性变化类型给出明确处置：分辨率变化可能只影响缩放，帧率变化会牵动全部时长推导，时长变化会让所有依赖偏移的轨错位，音轨存在与否决定口型与字幕是否需要重做。因此替换动作要产出一份失效清单，把受影响片段按三档标注：可自动重算、需人工确认、必须报错。最坏的实现是静默通过——时间线上看不出问题，导出后才发现后半段全偏。
五、两边共用水库时必须回答的四个问题
素材库成为唯一事实源之后，有四个问题躲不过去，每一个都不能靠默认值糊过去。
第一，一份素材被删除时，正在使用它的工程怎么办。可用做法是引用计数加软删除：删除动作先把对象置为“已下架”，新版本不再可被引用，已存在的引用继续解析；物理回收留到保留期之后，并且回收要能追溯到是谁在哪个时点触发的。
第二，素材更新版本是就地覆盖还是新建一份。这决定了引用语义：就地覆盖意味着所有引用自动跟随当前版，改动会传播到别人正在做的工程里；固定版本意味着每个引用钉在某版上，改对了要逐个同步，改错了倒不会扩散。推荐默认固定版本、显式选择跟随，并在使用处显示“该引用落后于当前版本”的标记，把差异暴露出来而不是藏起来。
第三，跨工程引用怎么判权限。要用素材、要修改素材、要在自己的工程里长期依赖它，是三种不同权限，混成一个“可读”就会出事故。判定时机也要定：导入时判一次会被授权变更绕过，运行时每次解析引用都判更稳，代价是要有一层可缓存的授权查询。
第四，导出之后血缘还要不要保留。画布和剪片都是过程，导出物才是交付。导出那一刻要留下一条记录：用了哪个工程版本、哪些对象版本、导出参数、导出人。没有这条记录，后续被问“这个画面是依据哪份素材做的”就无法回答——这恰恰是素材权属争议里最容易丢的证据。
六、确认点、计费事件与最小权限
“从一句话到成片”这条链不能一路自动跑到底。至少要把脚本、分镜、配音、成片四个人工确认点显式设计出来，其中两个以上必须能停在“待审”状态：状态字段区分机器生成与已确认，确认要留操作者与时点，批量任务在确认点前自动暂停而不是继续往下灌。没有这个设计，批量生成的内容质量没法在流程里被拦住，返工全部堆到导出的成品之后，成本完全不同。
订阅档位这件事本篇不评价格，只说它的工程含义：功能边界最终要落成用量事件。按次消耗的能力、按席位的能力、按导出分辨率分档的能力，三类对应三张不同的事件表——一次生成算一条事件、一个成员算一条、一个分辨率算一条，这些都要在业务流里打得出来，能按对象和时间聚合。落不出事件的边界，上线后一定以“功能可用但账单不对”的形态暴露出来。
协同权限的最小可行三档也值得单独定：对素材只读、对时间线可编辑、对导出可执行。比“管理员与成员”两档更贴近真实分工，因为它按动作而不是按身份切；素材只读意味着能用不能改，时间线可编辑意味着能排布不能替换素材本体，导出可执行意味着能出片但不能改对象版本。三档之外还需要一条跨工程引用的默认拒绝策略，否则权限表会在共用水库下被逐步架空。
移动端助手带来的是并发场景，不是新界面：移动上改一段脚本，桌面这边时间线的字幕是否重算、离线改动回到线上时冲突按哪边优先、部分同步状态下引用解析失败要显示成什么。这三条都属于对象模型问题，界面层解决不了。
我们把这些整理成产品评审里的固定一问：先画对象模型和血缘，再画界面。顺序反过来，画布与时间线一定会各自长出半个数据模型，等到要协同、要导出、要算账时返工。洹拓给客户做过几次编辑类系统的接入改造，返工点几乎都落在这两处——状态归属没分清，或者血缘字段少一列。