我的多领域创作软件架构：稳定核心与可替换入口

我希望自己的创作软件能逐步容纳视频、音频和视觉工作。它可以从一个很小的工具开始，但以后加时间线、换界面、接 AI 时，不应该每次都重新定义“修改一个工程”是什么意思。

这套架构的出发点，是把稳定的身份与编辑规则放在中心，把入口和具体设施留在外侧。按钮、快捷键、脚本与 AI 都是调用者；谁能修改什么、怎样保存、失败后怎样重试，则有明确的权威边界。

一个操作，多个入口从一个操作出发，理解多个入口如何共享能力。

如果“调整图层透明度”分别藏在按钮、快捷键和 AI 工具里，三个入口迟早会有三种校验、三套撤销和三种保存结果。我的选择是先定义操作，再做入口：识别目标，验证类型与引用，检查权限和工程版本，准备变更，最后提交。

界面可以从 React 换成原生，也可以增加 CLI。入口负责输入与反馈，应用规则负责什么算成功。这样的分工使 AI 接入成为另一种调用方式，而不是允许模型绕过界面去改底层文件。

编辑提交与制作执行走两条路径

查看大图 ↗

UI、脚本和 AI 通过应用 API 工作。编辑由权威提交边界保存；制作另外读取固定快照，经领域编译后交给执行器。这张图讲设计关系，实现范围在文末单独说明。

一次耐久编辑先读取权威状态，由纯领域规则 prepare，再在同一短事务里保存语义操作、投影与 revision。提交完成之后才返回 ACK。“界面派发了请求”和“工程已经保存”是两个不同事实。

超时意味着结果未知。重试需要识别原来的 operation ID 与 payload：已经提交的同一操作返回原结果，相同 ID 换了内容则拒绝。这个顺序关系决定了断线后是否会重复修改工程。

导出、分析和生成另走任务路径：捕获明确 revision 的固定快照，交给领域编译器和执行器。用户继续编辑，不改变正在导出的输入。产物如果需要写回工程，也要经过新的内容命令。

长脚本可以查询、等待分析、构造计划，再请求短事务提交；不能跨 await 持有写事务。SQLite 提供底层原子性，业务幂等、语义日志和 ACK 顺序仍需要应用自己负责。

从一段命令看稳定语义

下面是契约形状的 TypeScript 示意，不是原型的现有公开接口。它把对象地址、版本与操作身份放在请求里，不传一个“面板组件的内部状态”。真正执行时，权限来自可信宿主，不由这段请求自报。

type ParameterAddress = {
  documentId: string;
  instanceId: string;
  definitionId: string;
};

type SetNumber = {
  kind: "parameter.set-number";
  target: ParameterAddress;
  value: number;
};

type EditBatch = {
  operationId: string;       // 同一次重试复用身份
  baseRevision: number;     // 提案绑定读取时的版本
  commands: readonly SetNumber[];
};

参数不只有 0.5，还要说明它的类型、单位、范围、默认值、是否可动画以及如何插值。Inspector、API 和 AI 共用这份说明书；复杂引用、色彩或实时规则仍由权威校验完成。metadata 可以减少重复描述，但不能替代领域判断。

AssetId 也不等于文件路径。移动文件不应改变逻辑身份，替换内容则需要更新 digest 与派生缓存。文件、操作与 API 分开版本化；旧程序遇到未来格式时，不能静默覆盖自己不理解的数据。

调用关系之外，再约束源码依赖

查看大图 ↗

源码依赖从界面、存储与执行适配指向应用契约和纯规则，再指向工程模型与参数定义。运行时由 Host 装配实际实现；纯核心不需要知道某个按钮、数据库或设备如何工作。

“Host 调用存储，存储调用规则”说的是运行行为。源码的约束则是纯模型与规则不认识 UI、数据库、设备或 Host。外部实现依赖稳定语义，稳定语义不反向导入具体设施。两张图各自回答一个问题，不用一张混合分层图包办所有关系。

Host 负责装配、路径、进程和设备资源。应用 API 描述有界契约与授权检查，不因为叫 API 就自动成为网络服务。模块的存在应由真实调用者证明，不能先为 GPU、音频和云创建一排没有使用路径的空模块。

共享最小语义，保留专业结构

把所有媒介塞进带有 transform、duration、pixels、audio 的超级对象，会把无关领域绑在一起。我更愿意共享 ID、参数地址、资产引用、时间换算和编辑事务：时间线保留片段与时间映射，合成保留层级与依赖，音频保留采样、声道和实时预算。统一工程不要求统一一个求值器。

表达式与自动化也应分开。表达式面对有界快照、时间、seed 和输出类型；自动化通过授权接口请求修改。实时音频不能跑 VM、JSON 或等待普通锁。独立 worker 虽然有进程边界，仍要验证强杀、退出和资源回收，不能仅凭“多进程”三个字宣称隔离完成。

让 AI 调用能力，也让 AI 读懂边界

AI 可以读授权摘要，提出绑定版本的修改，提交 batch 或启动 job。每一步都有范围与预算。provider 名称和插件 manifest 是声明，不是可信身份；是否允许执行，由宿主确认。公开 API、界面贡献 API 与持久格式也应各自演进。

对我而言，Skill 则保存另一层能力：这套架构为什么这样划分，下一次设计时先看哪些证据，怎样挑一条真实闭环来验证。文章解释思路，Skill 指导判断，API 执行操作；三者互相补充。

已有原型给出的证据与反例

这套思路已经在我的 Cue 原型中做过有限验证。这里保留项目名称，是为了让来源可以回查；上面的设计图并不是对这个原型所有现有功能的描述。

本地记录中的两个反例值得保留：结构编辑和全文查询仍有全量处理，局部参数变快不代表所有操作都已增量化；Host 被系统强杀后，worker 可能继续存活，正常 EOF 回收也不能证明解决了强杀后的资源约束。它们让我知道下一步要验证什么。

实现判断来自截至 2026-10-08 的本地记录、依赖与相关源码，本次文章工作没有重跑原型完整压力套件。历史报告只支持当时版本。真实媒体的导入、编辑、保存重开与输出，仍是后续需要打通的制作闭环。

把设计哲学带到下一次开发

随文的创作软件架构决策 Skill 从原始规范和评审整理而来：先读产品约束与真实实现，再找状态所有者，分别画调用与依赖，区分 query / preview / batch / job，最后挑一条可验证的路径。它允许不同技术栈，也要求记录代价和重审条件。

原始 v0.1 规范原样保留作为作者证据；随文 Skill 是吸收评审后的整理版。AI 按任务读取涉及的参考资料即可，不需要每次把长规范全部塞进上下文。

我希望这套架构能随着真实创作逐步长大。它先保护已经成立的身份、命令与提交规则，然后让新入口和新领域有地方接入；是否值得继续抽象，最终由下一条能跑通的工作路径回答。