我们构建了一个 AI 视频聚合平台 — 这是没人告诉你的难点

去年我们开始构建一个看起来很简单的东西：AI 视频生成的统一界面。

一个提示词，多个模型，选择最好的结果。

六个月后，我可以告诉你：概念很简单，执行起来完全不是那么回事。

这是我们构建 Reelive.ai 时学到的东西 — 那些没人警告过我们的技术挑战。

理想与现实

理论上，AI 视频聚合很直接：

1. 用户提交提示词
2. 发送给 OpenAI Sora、Google Veo、Kling、Wan
3. 返回视频
4. 扣除积分

实际上，每一步都有边缘情况，会让你怀疑自己的职业选择。

成为会员

挑战 #1：每个 API 说的都是不同的语言

你可能以为 AI 视频 API 会有一些标准化。你错了。

这是我们要处理的：

Sora 立即返回任务 ID，然后你轮询等待完成。进度更新很零散。有时从 10% 直接跳到 100%，毫无预警。

Veo 使用完全不同的认证流程。响应负载嵌套三层深。错误码……很有创意。

Kling 有根据时间变化的速率限制（我们猜的）。文档存在，但同时是中文和机器翻译的英文。

Wan 有时返回的视频 URL 15 分钟过期，有时 24 小时。我们从没搞清楚规律。

我们的解决方案？一个标准化层，把每个提供商的怪癖翻译成一致的内部格式：

interface NormalizedTask {
  id: string;
  provider: 'sora' | 'veo' | 'kling' | 'wan';
  status: 'pending' | 'processing' | 'completed' | 'failed';
  progress: number; // 0-100，即使提供商不支持
  videoUrl?: string;
  expiresAt?: Date;
  error?: NormalizedError;
}

简单？是的。实现过程？47 个 if-else 分支，还在增加。

挑战 #2：什么时候扣积分？

这听起来很简单，其实不是。

考虑这些失败模式：

• 用户提交提示词 → 生成开始 → 提供商崩溃 → 要扣费吗？
• 用户提交提示词 → 生成完成 → 视频 URL 在下载前过期 → 退款？
• 用户提交提示词 → 生成「完成」→ 视频是 3 秒黑屏 → 怎么办？

我们经历了四种不同的积分扣除策略才确定现在的方案：

策略 1：预先扣费 问题：用户为失败的生成付费。客服工单爆炸。

策略 2：完成后扣费 问题：恶意用户疯狂生成，只「接受」好的结果。

策略 3：创建任务时扣费，失败时退款 问题：退款时机很棘手。有些提供商 5 分钟失败，有些 5 小时。

策略 4（当前）：预留积分，然后扣除 我们现在在任务开始时预留积分，但只有在验证输出有效后才最终扣除。如果任务失败或产出垃圾，预留会被释放。

这需要建立一个带过期处理的 creditTransaction 表：

CREATE TABLE credit_transaction (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  amount INTEGER NOT NULL,
  type VARCHAR(20) NOT NULL, -- 'deduct', 'reserve', 'release', 'refund'
  expires_at TIMESTAMP,
  finalized_at TIMESTAMP,
  task_id UUID REFERENCES generate_task(id)
);

finalized_at 列是后来加的，因为我们发现预留的积分会泄漏到虚空中。

挑战 #3：Serverless 世界中的长时间任务

AI 视频生成需要 30 秒到 5 分钟，有时更长。

我们运行在 Vercel 和 Cloudflare Workers 上。函数超时：最多 30 秒。

显而易见的解决方案是轮询。但轮询有自己的问题：

• 多久轮询一次？太频繁 = 被限速。太慢 = 用户体验差。
• 如果客户端断开连接呢？任务还在提供商那边运行。
• 如果你的服务器在轮询中重启呢？

我们的架构：

1. 任务发起：Serverless 函数向提供商发送请求，保存任务到数据库，立即返回
2. 状态跟踪：单独的 Serverless 函数按计划轮询提供商 API（Vercel Cron）
3. 客户端更新：前端通过轮询获取实时状态（我们试过 WebSocket，但 Cloudflare Workers 让它变得很痛苦）
4. 完成处理：另一个 Serverless 函数处理完成的任务，下载视频，上传到我们的 S3，更新积分

这比单体应用复杂。但在没人使用时可以缩放到零，这对自举创业很重要。

缺点：调试分布式系统是地狱。我们有任务卡在「processing」状态好几天，因为一个 cron 作业静默失败了。

挑战 #4：视频存储经济学

AI 生成的视频很大。10 秒 1080p 视频是 20-50MB。

用户生成很多视频。其中很多是垃圾（参见：我们上篇文章讲的随机性问题）。

永久存储一切很贵。删太狠会惹恼用户。

我们当前的策略：

• 视频在生成后存储 7 天
• 用户可以「保存」视频延长到 30 天
• 付费用户获得永久存储（有合理使用限制）

但这里有个没人告诉你的事：视频转码是隐藏成本。

提供商返回不同格式的视频。Sora 给你 H.264 的 MP4。Veo 有时返回 WebM。Kling 有自己的编码偏好。

为了在各种浏览器上一致播放，我们转码所有视频。这是 CPU 时间。Serverless 平台上的 CPU 时间很贵。

我们最终把转码卸载到便宜 VPS 上的专用 worker。不优雅，但比在 Lambda 上做便宜 10 倍。

挑战 #5：提供商宕机和降级

AI 提供商经常宕机。

过去 6 个月：

• Sora 有 3 次重大宕机（以小时计，不是分钟）
• Veo 有过静默降级，视频会生成但是损坏的
• Kling 的 API 整个周末返回 500 错误
• Wan 有段时间每个视频都包含他们几个月前已经移除的水印

当你是单一提供商的包装器时，宕机就是你的宕机。

当你是聚合器时，你有选择：

async function generateWithFallback(prompt: string, preferredProvider: Provider) {
  const providers = [preferredProvider, ...getFallbackProviders(preferredProvider)];

  for (const provider of providers) {
    try {
      const health = await checkProviderHealth(provider);
      if (!health.available) continue;

      return await generateVideo(provider, prompt);
    } catch (error) {
      logger.warn(`Provider ${provider} failed, trying next`, { error });
      continue;
    }
  }

  throw new AllProvidersFailedError();
}

理论上听起来很棒。实际上：

• 不同提供商有不同优势。从 Sora 回退到 Kling 可能给出完全不同的结果。
• 当用户选择一个模型却得到另一个的输出时会困惑。
• 积分成本因提供商而异。你收原价还是回退价？

我们最终让回退成为可选的，并在 UI 中非常明确。自动魔法带来的问题比解决的多。

挑战 #6：提示词翻译问题

这是我们没预料到的：在一个模型上效果很好的提示词在另一个上可能完全失败。

「Cinematic drone shot over mountains, golden hour lighting, 8K」

• Sora：完美理解
• Veo：字面理解「8K」，试图生成疯狂的分辨率
• Kling：忽略「drone shot」，给你静态相机
• Wan：灯光处理得很好，相机运动很奇怪

我们尝试过自动提示词适配 — 重写提示词以匹配每个提供商的优势。

没用。转换太不可预测，用户感觉失去了控制。

我们当前的方法：文档。大量的文档。我们向用户展示每个模型擅长什么，让他们决定。

没那么神奇。更透明。更少的客服工单。

如果重来我们会怎么做

如果重新开始：

1. 先构建标准化层。我们是渐进式拼凑的，现在是意大利面代码。

2. 更早投资可观测性。我们在第 4 个月才添加适当的日志和追踪。应该是第 1 天。

3. 不要和平台对着干。我们花了几周试图让 WebSocket 在 Cloudflare 上工作。轮询就够了。

4. 构建回退逻辑前先和用户聊。我们假设他们想要自动故障转移。他们不想。

5. 为提供商变化做计划。API 会变。速率限制会变。定价会变。为灵活性而构建。

AI 视频聚合的现状

六个月后，这是我诚实的评估：

技术很难但可解决。真正的挑战是信任。

用户把钱给你来访问他们理论上可以直接访问的 AI。为什么用聚合器？

• 便利（一个账号 vs 五个）
• 成本（批量积分定价）
• 对比（轻松 A/B 测试模型）
• 可靠性（我们处理宕机，你不用）

但如果你的平台有 bug、很慢或不公平地吃积分，这一切都会崩塌。

我们花在边缘情况和错误处理上的时间比功能开发还多。这对于一个建立在信任上的平台来说，可能是正确的权衡。

自己试试

如果你在构建类似的东西，希望这篇文章能帮你少踩坑。

如果你只想生成 AI 视频而不处理这些，这就是我们构建 Reelive.ai 的原因。