对话里发起、时间线里收尾：跨工具的项目得能带走｜洹拓科技
一、链路拆进两个工具，麻烦全落在中间那份项目
一家视频剪辑工具宣布，把自家的视频生成与编辑能力以插件形式接入一个通用对话产品。按公布的流程，用户在对话产品里描述创意，由插件生成视频初稿，再把项目带到该剪辑工具的网页编辑器里继续调整、分享与发布；官方演示视频标明，公开测试计划覆盖移动端、桌面端与网页端三处；官方给的口径是一句话——对话负责发起制作，精细编辑回到时间线完成。发布公告本身用的是“即将推出”的表述，所以下面写的都是这条链路一旦跑通要面对的工程问题，不是对某个已上线功能的评测，也不涉及任何具体接口与字段命名。
“对话发起、时间线收尾”听起来只是分工，工程上它做了一件很硬的事：把原本在一个应用里完成的创作，拆到两个工具之间，中间用一份可以传递的对象接上。这份对象我们统称“项目”。它装了什么、谁有权改、回到另一端会不会被覆盖、坏了怎么退回去——这四问决定了这条链路到底是“把项目带走”，还是“只带走一层壳”。
站内《创作工作台的对象模型与血缘四问》问的是单一工具内部的对象与血缘；本篇问的是另一种情形：对象要从发起端走到精修端，中间跨一次工具边界。同一份内容在两处之间移动时，丢东西的位置不在编辑功能里，而在那次交接面上。评估一条跨工具链路，不该从功能清单开始，该从“交接面有几道、每道丢什么”开始。
二、项目对象分三层，逐层只问三句话
我们把项目拆成三层，每层只问三句：对话侧能不能读、能不能改、改动回到编辑器还在不在。
- 素材清单与来源。这一层列出用了哪些片段、各自来自哪里。对话侧读得到清单不算难；难在“改”——对话里追加一句换掉背景音乐，改动落到清单上，回到编辑器时新素材的来源凭证还在不在。
- 时间线与效果参数。这一层是精修真正要动的地方。参数被改是常态，问题是另一端认不认这份改动，还是会按自己的理解重算一遍。
- 导出与发布设置。这一层决定作品出去时长什么样、发到哪、以谁的身份发。
三层的危险点各不相同：素材层的危险在来源凭证掉队；时间线层的危险在不认识的参数被静默丢弃；导出层的危险在这一层本该只有最高一档权限能碰，却常被当成普通设置一起带走。把项目压成“一个能分享的成品文件”来交接，三层就会塌成一层，回到编辑器能看却改不动——这是跨工具链路里最常见的失败形态，也是最容易被当成“功能正常”放过去的形态。
三、能力边界按可调用动作列，不按宣传语列
插件形态的能力，宣传语会说“能生成、能编辑、能发布”，但这三件事不在同一档。工程上应该按可调用的动作集合列成三档，而不是按形容词列。
| 能力档位 | 允许的动作 | 不允许的动作 | 出错后能不能收回 |
|---|---|---|---|
| 只读 | 能看清单与参数 | 改任何一层 | 无所谓，没有写入 |
| 可写 | 改素材清单与时间线 | 对外发布 | 能，靠快照退回去 |
| 可发布 | 触发导出与对外发布 | 不随可写自动获得 | 不能，只能靠前置约束 |
关键一句：可发布不能从可写里顺带拿到。对话侧每下一次指令就动一次项目，如果每次动作的尽头连着“对外”，就等于把发布权接到了每一次对话上。三档之间的分别不是功能多少，而是出错之后可不可逆：只读档不会出错，可写档出错可以退回，可发布档一旦动作就没有“退回”这回事。这也决定了授权粒度——可写按会话授，可发布必须单独确认，两者不能共用一个开关。
四、三端一致性要出一张对照表
官方公布的公测计划覆盖移动端、桌面端与网页端三处。一份项目在三个地方还原，差异不会靠“我们都用同一种项目格式”这句话消失，只能靠一张对照表逐格填出来。要重点盯三类形态：
- 某一端不渲染的效果。它不报错，只是按“没有这个效果”画出来，用户在那一端看不出异常，到另一端才发现少了东西。
- 参数被默认值吃掉。某一端读不到某项参数时，是明确报错，还是悄悄填一个默认值；后者会让回到另一端时呈现为“看起来改了，其实没了”。
- 导出之后回到编辑器还能不能改。导出是一次成型动作，成型之后那份项目处于什么状态，三端必须一致。
站内《AI 视频工具链四层与镜头元数据》写工具链分层与元数据规范，本篇不重复那套，只写这张表怎么填：每一格填“这一端读出来是什么”，而不是填“这一端支不支持”。填“支持与否”只会得到一堆二元结论，填“读出来是什么”才会暴露默认值吃掉参数这类问题。它也和《同一个搜索能力开成三种接口：API、MCP 与 Skill 的分工在哪》无关——那篇讲同一种能力的三种入口如何分工，本篇讲同一份数据在三个渲染端上的还原差异；至于《个人 AI 会话与自定义能力的导出保真度四档》，那篇评的是会话与自定义能力导出时的保真档位，本篇评的是项目对象跨工具搬运时的丢失位置。四篇的落点各不相同，别混着引。
五、素材权属三条线：能导出不等于有授权
项目里的素材按来源分三条线，各自的凭证与二次使用边界不一样：
- 平台生成素材。由对话侧发起生成，凭证要记“哪一次生成、按什么参数生成”，二次使用的边界由生成服务方的条款来定，这一条不是剪辑工具能替它承诺的。
- 用户上传素材。授权链在用户那一侧，项目要带的是用户上传时声明的来源，而不是工具替他补一个“已授权”的标记。
- 内置模板素材。模板自带使用范围，跨出模板场景还能不能用，要有可查的出处。
三条线共用一条判据：能导出只是技术动作跑通，不等于对这份素材有对外使用的授权。如果项目对象里只带“素材可用”这样一个是非值，而不带来源凭证，走到发布那一步就没人能回答授权问题——那时想补都补不回来，因为原始来源信息在第一次交接时已经掉了。导出与发布那一层同理：发到哪里、以谁的名义发，也要跟来源凭证一起走，不能等到点发布时才现凑。
六、版本、回退与三条实测题
对话驱动有一个特性：每下一次指令就动一次时间线。动得越频繁，越需要留最小快照集，而不是每次都全量存一份。要写死的有三点——留哪几份、留多久、什么时候触发保留。我们的建议是把触发条件挂在对外动作上：一次改动将要触发导出或发布时强制留一份快照，其余改动按间隔或按次数留。这样快照量和对外的不可逆动作对上，而不是和每一次对话对上，存储代价可控，回退点也刚好落在需要它的地方。回退时，最小快照集要能退回到“发起生成之前”那个状态，否则退回去拿到的还是一份被改坏的时间线。
最后三条实测题，给客户验收用，不看功能列表，只看这三问能不能答上：
- 同一条目改三次，中间那一次改动还能不能追回来——测版本链是不是被覆盖成了一格。
- 在对话侧发起之后、没有落到编辑器的中间态去哪了——测“带走”是不是只在落进编辑器之后才成立。
- 发布之后回到编辑器还能不能改——测可发布档与可写档之间那道闸到底存不存在。
| 交接面 | 最容易丢的东西 | 怎么测 |
|---|---|---|
| 对话侧写入项目 | 改动的来源与生效顺序 | 同一条目连改三次，再回编辑器核对 |
| 项目传到网页编辑器 | 某一端不渲染的效果与参数 | 三端各打开同一份项目逐项对照 |
| 编辑器导出到发布 | 素材的来源凭证 | 发布前追一次授权链能否走通 |
| 发布后回到编辑器 | 可改状态与回退点 | 发布后试着改一处并尝试回退 |
洹拓把这类跨工具链路当成交付里的一份交接说明来写：发起端交出什么、精修端接住什么、中间那份项目由谁负责保证完整。链路能不能带走一份项目，最后不取决于两个工具各自有多强，而取决于中间那次交接被定义得多清楚——层分得越粗，丢的东西越难被发现。