AXMORF Studio

从一个视频需求开始

制作一条视频，要把主题、叙事、场景、旁白、字幕、声音和封面组织成同一个作品。Agent 可以参与这些工作，但要让各部分在时间、画面和文件交付上真正对齐，仍然需要一个明确的生产过程。

AXMORF Studio 围绕这个过程建立了用户自有的本地工作区。用户把创作需求交给正在使用的 coding Agent；Agent 根据项目规则组织内容、编写视觉场景并执行生产。项目源码、素材、配置、中间产物和最终文件都保存在工作区中，可以检查，也可以继续修改。

把创作拆成有明确输入与结果的任务

一个故事对应一个 Remotion Composition，内容段落对应具体场景。场景、整体视觉和封面各自承担清楚的职责，旁白与字幕由统一的时间结构组织，避免多个创作任务重复控制同一层内容。

生产开始前，系统先检查输入是否完整、哪些产物可以复用、哪些任务需要重新执行，以及有哪些阻塞。需要调用媒体服务的准备步骤有单独入口。随后，Agent 在分配的任务范围内完成创作，固定程序负责校验、组装和渲染。

实际流程是：创作需求 → 项目定义 → 生产检查 → 媒体准备 → 场景与封面创作 → 校验与渲染 → 本地交付。

让声音成为时间安排的依据

旁白的真实时长会影响字幕、场景切换和视觉节奏。AXMORF 以生成后音频的实际采样数计算时间，再映射到视频帧；经校验的音频被固定下来，后续生产使用同一份声音与时间信息。

这样，场景与字幕能够围绕实际旁白展开。旁白、背景音乐和音效也有各自的职责：旁白承担叙述，背景音乐覆盖规定的内容区间，场景音效作为独立声音参与作品。

把已经完成的工作保留下来

创作通常需要反复调整。AXMORF 根据任务输入和产物内容识别可复用结果；输入没有变化且文件仍通过校验的部分，可以继续使用。修改一个场景时，重新生产的范围沿实际依赖传播，其他仍然有效的场景、封面或旁白能够保留。

修改已有作品时，新版本先在隔离的候选区域中完成。只有候选结果通过检查，才替换当前项目与交付；候选制作失败时，上一份作品仍然可用。这个安排让试错有了明确边界，也降低了修改中途损坏现有成果的风险。

完成意味着四个可检查的文件

一次交付包含 video.mp4、横向的 cover-4x3.png、纵向的 cover-3x4.png 和 publish.json。发布清单保存用于发布的文案与交付信息，实际上传由用户另行完成。

交付检查覆盖文件集合、校验和、媒体格式、尺寸、帧率与帧数，以及媒体能否完整解码。工作区还提供本地 Web 控制中心和 Remotion Studio，分别用于查看配置、诊断、进度、当前交付和画面预览。

这个项目的工程重点

AXMORF 将开放的创作判断放在 Agent 一侧，把输入规则、任务边界、结果校验和交付替换交给程序。Agent 可以决定一段内容怎样表达，系统则负责检查它是否产出了可接入作品的结果。

这种分工使失败发生的位置更容易辨认：环境准备、素材服务、某个场景、渲染或最终交付，都有各自的状态与检查。有效结果也能在后续执行中继续使用，让创作过程具备可追踪、可修改的基础。

当前阶段与适用范围

项目处于公开测试阶段，已有 npm 工作区发行与 Codex、Hermes 的真实制作记录。它需要可用的 Node.js、渲染浏览器及配置的媒体服务；工作区保存在本地，所选外部服务仍可能涉及网络调用和费用。

自动检查可以确认文件与部分制作约束，画面美感、叙事效果和完整听审仍需要人工判断。项目目前不承担平台账号、视频上传或云端生产调度。不同宿主和执行模式的证据范围，以对应版本的验收记录为准。