Vercel 扛不住的 AI 任务，被 Cloudflare Workers 秒解了

一个真实踩坑故事：AI 批量生成 1200 篇文章，把 Vercel 直接跑超时。作者没升级套餐，而是换了思路，把核心函数迁到 Cloudflare Workers。结果不只是跑通了，还顺手打开了 Serverless + AI 应用的新姿势。

不是模型不行，是 Serverless 先倒下了

这条视频最有杀伤力的地方，不是 Cloudflare Workers 有多快，而是一个很多 AI 开发者都会遇到、却常常归因错的失败场景。

作者 Michael 在做一个叫 SEO Heist 的项目：用户丢进一个竞品的 sitemap，系统自动抓出上千个博客标题，然后用 AI 批量生成新文章。本质上，这是一个很典型的生成式 AI 应用：长任务、批量处理、对响应时间不敏感，但对“能不能跑完”极其敏感。

问题来了：在本地一切正常，上线到 Vercel（Hobby 方案）后，函数直接 timeout。不是偶尔，是必现。更扎心的是，这不是“加点优化就能解决”的问题，而是 Serverless 平台对单次执行时长的硬限制。

Michael 在视频里说了一句很实在的话：即使上 Pro，可能也扛不住。这句话背后，其实点出了一个被低估的现实——很多 AI 应用，天然就不适合放在以“短请求”为核心假设的 Serverless 环境里，至少不是以默认方式。

Cloudflare Workers 的真正价值：不是快，是“不急着杀你”

转机出现在他开始研究 Cloudflare Workers。

很多人第一次听 Workers，会下意识把它当成“另一个 Serverless”，但 Michael 的使用场景说明了一件事：Workers 的价值不在于跑 Hello World，而在于它对长时间、I/O 密集任务的容忍度。

视频里他直接演示了完整流程：登录 Cloudflare → Workers → Create Worker → Quick Edit。几行示例代码，部署，发送请求，返回响应。这部分看起来很基础，但真正的重点在后面——他把 Next.js 里那个“罪魁祸首”的函数，整个搬进了 Worker。

这个函数干了什么？
- 接收一个标题数组（上千条）
- 判断请求类型（JSON / text）
- 循环标题
- 构造 prompt
- 调用 Mistral AI
- 解析返回结果
- 收集生成的博客内容
- 捕获异常并继续执行

放在 Vercel，这是一个标准的“等死型函数”。放进 Worker 之后，它变成了一个可以老老实实把活干完的后台工人。没有夸张优化，没有复杂架构，只是换了一个更符合任务本质的执行环境。

Wrangler + Worker：把 AI 长任务从前端项目里“拆”出来

视频中另一个容易被忽略、但对专业开发者很重要的点，是他的开发方式。

Michael 没有把 Worker 当成“网页里的一段配置”，而是用 Wrangler CLI，把它当成一个独立服务来管理：
- 本地初始化 Worker 项目
- 用 Git 做版本控制
- wrangler publish 一行命令部署

这其实是一个非常清晰的架构信号：

Next.js 负责交互、Dashboard、用户体验；Cloudflare Worker 专注跑耗时、不可预测的 AI 任务。

两者通过 HTTP 通信，而不是强行塞在一个全栈框架里。

这点对 AI 应用尤其关键。因为随着调用模型次数增加，你迟早会遇到：
- 某一次生成特别慢
- 某一个 prompt 触发异常输出
- 某个 API 波动

把这些不稳定性隔离在 Worker 层，前端只等结果或状态更新，系统整体的“心理安全感”会高很多。

这不是 SEO Heist 的故事，而是 AI 应用架构的分水岭

视频最后，Michael 展示了一个简单的 Dashboard：生成文章、管理额度、查看结果。他自己也说，还在摸索怎么把数据交付给用户。

但对行业来说，重要的不是这个产品会不会火，而是这个模式已经非常清晰：

生成式 AI 正在把大量应用，从“请求-响应”模式，推向“任务-结果”模式。

而在这种模式下：
- 你不需要极速响应
- 你需要稳定执行
- 你需要便宜地失败、重试、继续跑

Cloudflare Workers 在这里的角色，很像一个被低估的“AI 执行层”。它不和模型竞争，也不和前端框架抢戏，但它决定了一件事：你的 AI 应用，到底能不能在真实流量下活下来。

总结

这条视频最值得 AI 从业者记住的一点是：很多看起来是“模型、prompt、算力”的问题，最后其实是架构问题。如果你的 AI 功能一上线就超时、卡死、只能在本地跑，那不一定是你代码写得差，而是你把长任务，放进了不该承受它的地方。

一个可执行的 takeaway：下一次你设计 AI 功能时，先问自己一句——这是“秒回的接口”，还是“慢慢跑的任务”？如果是后者，把它从 Next.js / Vercel 里拆出来，放进像 Cloudflare Workers 这样的执行层，可能比换模型、调 prompt 更有效。

未来一年，谁能优雅地处理这些“又慢又重”的 AI 任务，谁就能真正把生成式 AI 变成产品，而不只是 Demo。

关键词： Cloudflare Workers， Next.js， 生成式AI， Serverless 架构， Mistral AI

事实核查备注： 需要核查：1）视频发布时间 2024-02-21 是否准确；2）作者/频道名 Ras Mic；3）Vercel Hobby / Pro 对函数执行时长的限制为背景信息，文中未给出具体秒数；4）Mistral AI 被用于生成博客内容；5）SEO Heist 为作者个人项目名称