AI音视频创作平台构建的一些心得体会（一）

构建 AI 创作平台的一些实践体会

最近参与了类似 PexelDance https://www.pexeldance.com 这类 AI 图音视频无限画布创作平台的搭建工作，过程中对系统架构、前后端协作和安全防护有了不少切身体会，简单分享几点。

一、系统架构：别把所有模型“焊死”在一起

我们非常兴奋地把自研模型和外部API调用 Sora2 或 Runway 的 API 有机结合，但很快发现一个问题：不同模型的输入输出格式五花八门，今天换一个模型，明天整个流程就得重写。后来我们决定做一层“适配中间件”，把每个 AI 能力（比如文生图、语音克隆、视频生成）封装成独立服务，统一接口标准。这样一来，不管是自研模型还是第三方 API，只要符合规范就能插进来用。

整个系统按功能拆成十几个微服务，剧本生成、角色设计、视频合成各司其职。用户点一下“生成短视频”，后台就自动走一条任务流水线：先写脚本，再画分镜，接着出角色图，然后跑视频，最后配乐加对口型。中间哪一步失败了，也能单独重试，不用从头来过。

为了扛住高并发，我们用了消息队列做异步调度，配合 Kubernetes 动态扩缩容。尤其在渲染 8K 视频时，GPU 资源很紧张，通过优先级队列和缓存机制，才勉强保证大多数用户能在一分钟内拿到结果。

二、关于前后端分离与底层技术架构的一些思考

1. 前后端怎么分？各干各的，但得对上频道
   前端专注用户体验：

我们用 React + TypeScript 构建主界面，配合 Zustand 管理状态，避免 Redux 的样板代码。所有创作操作（比如拖拽分镜、切换角色风格、试听配音）都在浏览器内完成，尽量减少不必要的请求。对于视频预览这类重资源，采用懒加载 + 分段缓存策略，避免页面卡死。
后端专注能力输出：

所有功能通过清晰的 RESTful API 暴露，比如 POST /api/v1/video/generate 接收生成参数，返回任务 ID。前端不再关心“视频是怎么生成的”，只负责提交任务、轮询状态、展示结果。这种解耦让前后端团队可以并行开发，接口文档用 Swagger 维护，联调效率高了不少。
2. 后端选择微服务：不是为了时髦，而是被业务逼的
一开始我们尝试用单体应用扛所有功能——剧本生成、图像渲染、语音合成全塞在一个服务里。结果上线两周就撑不住了：

图像生成占满 GPU，把语音任务饿死了；
改个分镜逻辑，得全量发布，风险高；
监控日志混在一起，排查问题像大海捞针。
于是果断拆成微服务。每个核心能力独立成服务，比如：

script-service：负责 AI 写剧本、结构校验；
character-service：管理角色设计、多角度一致性生成；
video-gen-service：对接 Sora2、Veo3.1 等多个视频模型，做统一调度；
audio-service：处理语音克隆、配乐生成、对口型同步。
这些服务之间通过内部 API 或消息队列通信，彼此无强依赖。某个服务升级或故障，不会导致整个平台瘫痪。比如 Runway 的 API 临时不可用，系统可以自动降级到 Kling 或本地备用模型，用户甚至感知不到异常。

部署上跑在 Kubernetes 集群里，GPU 节点专门打标签，只调度视频/图像类服务；CPU 节点跑轻量服务。配合 Prometheus + Grafana 做监控，哪个服务响应慢、错误率高，一目了然。

3. Redis：从“可有可无”变成“离了它真不行”
   最初 Redis 只用来缓存热门模板，后来慢慢成了系统的“中枢神经”。

任务状态中转站：

用户提交一个视频生成任务，后端立刻写一条记录到 Redis：task:{id} → {status: “queued”, progress: 0}。前端通过 WebSocket 或轮询读这个 key，实时更新进度条。比起查数据库，延迟从几十毫秒降到 1 毫秒以内。
防重复 & 防刷：

有些用户会反复点击“生成”，我们用 SET user:{uid}:last_gen EX 10 NX 实现 10 秒内防重。对于 API 调用，用滑动窗口 + Redis 计数做限流，超出免费额度就拒绝，保护后端不被薅秃。
临时草稿兜底：

用户没登录时编辑的内容，先存 Redis（带 24 小时过期），登录后再迁移到数据库。这样既省了数据库写压力，又不让新用户因为“必须注册”而流失。
现在 Redis 不仅是缓存，更是协调前后端、服务间状态的“共享内存”。