我是如何用 Rust 搭了一个视频生成平台的

在上一篇里提到，这个周末我把视频生成真正做成了一条可复用的流程。 但很快我就发现一件事：

如果流程足够稳定，它就不该只是“我自己用的脚本”。

于是，我索性往前多走了一步—— 用 Rust 把这条流程，直接做成了一个视频生成平台。

为什么不是“工具”，而是“平台”

一开始，我只是想提高自己的效率。

但在不断拆解流程的过程中，我发现视频生成本质上具备几个特征：

• 多步骤、强依赖顺序
• 每一步都可能失败、重试
• 对性能和稳定性要求很高
• 非常适合“任务化 / 管道化”

这已经不是一个简单的「调 API 的脚本」了，而是：

一个典型的后端任务系统。

既然如此，与其堆工具，不如直接按平台来设计。

为什么选 Rust

选 Rust，其实不是情怀，而是非常现实的考虑。

视频生成是“重 IO + 重 CPU”的混合场景

• 文案生成、TTS、素材拉取 → IO 密集
• 视频合成、渲染、转码 → CPU 密集

Rust + Tokio 非常适合这种场景：

• 高并发
• 低开销
• 对资源控制极强

我需要一个“不会越跑越慢”的系统

视频生成往往是：

• 批量任务
• 长时间运行
• 后期容易堆积

Rust 的优势在于：

• 内存可控
• 不容易出现“跑一晚上就炸”的情况
• 非常适合长期服务

平台一定会“越写越复杂”

一旦变成平台，就会出现：

• 任务状态管理
• 失败重试
• 限流、队列、并发控制
• 不同生成策略的扩展

Rust 的类型系统在这里反而是加分项： 👉 复杂度被提前暴露，而不是线上爆炸。

整体架构是怎么设计的

从一开始，我就没把它当成“视频工具”，而是一个任务编排系统。

整体可以拆成 4 层：

API 层：只负责“接需求”

• 创建视频生成任务
• 查询任务状态
• 拉取最终结果

这一层极薄，不做任何业务逻辑。

任务编排层（核心）

这是整个平台的中枢，负责：

• 拆解一个视频生成任务
• 把任务拆成多个 step
• 控制依赖关系
• 管理状态流转（Pending / Running / Failed / Done）

👉 本质是一个 DAG + 状态机。

执行层：每一步都是插件

比如：

• 文案生成
• TTS
• 画面生成
• 视频合成

每一步都抽象成统一接口：

• 输入是什么
• 输出是什么
• 是否可重试
• 是否可并行

这样后面：

• 换模型
• 换生成策略
• 加新能力 都不用动核心流程。

资源与限流层

这是很多人一开始不会重视，但非常关键的一层：

• 控制并发数
• 控制 CPU / IO 使用
• 控制第三方 API 速率
• 防止一波任务把机器打死

这层我基本是“先设计，再实现”，而不是事后补救。

平台化带来的变化

把它做成平台后，有几个非常明显的变化：

✅ 从“写一次”到“反复跑”

• 同一套流程可以跑不同内容
• 不再为单个视频写定制逻辑

✅ 从“人驱动”到“任务驱动”

• 不需要盯着
• 出错有状态、有日志、有重试

✅ 从“玩具”到“可扩展系统”

• 可以接 Web
• 可以给别人用
• 可以继续加能力，而不推翻重来

一些真实感受

这次让我最有成就感的，不是“生成了多少视频”，而是：

我终于把一件创作型的事情，用工程手段彻底驯服了。

AI 负责不确定性， Rust 负责确定性， 而我，只需要决定“值不值得做”。

这大概是我目前最喜欢的工作状态。