用户在前端输入提示词、上传图片，几分钟后拿到一段视频——AI视频生成的界面看起来就是这么简单。但后端完全不是一回事。

如果你正在开发一个调用AI视频API的产品，需要处理长时任务、失败重试、服务商回调、文件存储、用户可见的状态更新，以及发布前的内容审核。这篇文章介绍一套实用的架构方案。

打开网易新闻 查看精彩图片

文中以SeeVido为例，说明产品如何调用外部AI视频服务。同样的模式适用于任何支持文生视频或图生视频的服务商。

核心问题：视频生成不是普通请求

大多数Web请求都很短：用户点击按钮，服务器处理，快速返回响应。AI视频生成完全不同——它可能耗时很久，中途失败，产出需要人工审核，或者在用户已经离开页面后才返回回调。把它当成同步请求处理，通常会导致体验糟糕、系统难以调试。

正确的做法是将视频生成建模为"任务"（job）。一个任务包含：所有者、输入类型（文生视频或图生视频）、提示词或源素材、服务商请求ID、当前状态、事件历史、一个或多个输出产物、审核决定。这让产品能可靠回答最常见的客服问题："我的视频怎么了？"

推荐架构

一套最小可用的生产级系统可以这样设计：

前端提交提示词或源图片 → API服务器在数据库创建任务记录 → Worker从队列取任务 → Worker向AI视频服务商发送请求 → 服务商返回请求ID → 服务商向Webhook发送状态更新 → 完成的文件复制到对象存储 → 审核后台批准或拒绝输出 → 用户在应用中看到最终状态。

关键决策是分离：API请求只负责创建任务，不等待视频生成完成。

任务状态设计

状态模型建议保持简单明确：

queued（排队中）→ submitted（已提交）→ processing（处理中）→ completed（已完成）→ approved（已批准）/ rejected（已拒绝）/ failed（失败）

可能还需要：canceled（已取消）、expired（已过期）、retrying（重试中）。避免使用模糊的单一状态如"done"——视频技术上已完成，但可能还未获批发布。

数据库表结构

起步时不需要复杂的事件溯源系统。通常一张当前状态表加一张事件表就够了。

video_generation_jobs表包含：ID、公开ID、用户ID、工作流类型、服务商名称、服务商请求ID、当前状态、源素材ID、提示词哈希、创建时间、更新时间、完成时间。

video_generation_events表记录任务生命周期中的每个状态变更。

这套设计的价值在于可观测性。当用户追问视频去向时，你能精确还原完整链路：何时提交、何时开始处理、服务商返回了什么、文件存到哪里、审核结果如何。没有黑箱，只有清晰的审计轨迹。