用 3 个工程师撑起 10 万次月度媒体投递，Featured 把整个基建全搬到了

把 374 个站点从 AWS Elastic Beanstalk 迁移到 Vercel 到底省了多少事

在搬家之前，他们用的是 AWS Elastic Beanstalk。最离谱的坑在于，他们需要同时上线 374 个 Sanity 站点，在 EB 上这意味着每个站点都要手动启动、迁移、然后再手动销毁。对于一个只有 3 个人的工程团队来说，这种重复劳动简直是灾难。

迁移到 Vercel 后，这些操作变成了单点部署（Single-click deploy）。最直接的体感变化是，之前得一个集群一个集群地滚动更新，现在三家品牌的所有站点可以在一个平台上统一发布。如果你现在还在用 EB 或者自建 K8s 跑这种小规模但多实例的站点，建议直接看 Vercel 的部署流，真的没必要在基础设施上浪费时间。

怎么用一个接口管理 17 个 AI 模型

Featured 内部同时路由 17 个不同的模型，如果每个模型都写一套 API 适配、处理不同的 Rate Limit，代码库会变得极其臃肿。他们用了 AI SDK 和 AI Gateway 做了抽象层。

这里有个实操细节：调用模型变成了基于 Schema 的标准化函数。这意味着他们想换模型供应商时，不需要重写代码，直接改配置就行。对于我们这种需要快速测试新模型（比如从 GPT-4o 换到 Claude 3.5）的团队来说，这种架构非常关键，能把测试周期从「写代码-部署-验证」缩短到「改配置-验证」。

用 Workflow SDK 替代自建的任务调度系统

很多 AI 应用最头疼的是长耗时任务（Long-running jobs），比如全天候监控媒体动态、筛选机会，这些没法在简单的 Request-Response 周期里完成。

Featured 之前是自建了一套编排基础设施来跑这些任务，但现在全部移到了 Workflow SDK。这解决了两个核心痛点：

• 摆脱请求超时： 复杂的 AI 筛选链路耗时很长，Workflow SDK 允许任务在后台异步运行。
• 降低运维成本： 3 个工程师没时间去修调度系统的 Bug，用 SDK 托管后，他们只需要关注「筛选逻辑」而不是「队列是否挂了」。

目前这套方案支撑他们每月发送超过 10 万次媒体 Pitch，而且一年发送了超过 1 亿封 HARO 邮件。

成本与风险判断

虽然 Vercel 极大地提升了开发效率，但这种「全家桶」方案也有风险：

• 供应商锁定： 一旦深度绑定 AI Gateway 和 Workflow SDK，未来想迁回自建环境成本极高。
• 费用阶梯： Vercel 的带宽和函数执行费用在规模扩大后可能比 AWS 原生服务贵，但对于 3 人小团队来说，用金钱换取研发时间（Time-to-Market）是绝对划算的。

如果你团队规模在 5 人以下，且核心竞争力在产品逻辑而非基建，完全可以参考这个路径：Vercel 部署 + AI SDK 统一模型层 + Workflow SDK 处理异步任务。