我们是怎么规模化运行 AI emoji 生成的:路由、限额与失败处理

Forgemoji 的系统一面:我们如何让生成响应足够快、跨供应商做回落,以及管线里某段出错时怎么干净地恢复。

Lois Chen·Emoji 文化研究员 + 平台指南撰稿人·2026年6月21日

大多数人以为 AI emoji 生成器就是一个提示框加一个模型调用。实际上,产品只有在大量不性感的系统一起转起来时,才显得可靠:限流、供应商回落、队列时序、错误整形、可观测性。产品视觉上可以很 playful,但搭建起来得像一个严肃的生产服务。这才是值得写下来的版本。

用户对产品的预期

当有人点 Generate 时,他们预期是三种结果之一:一张能用的图、一条清晰的重试路径、或者一句对失败原因的朴素解释。他们不想知道用了哪个供应商,除非出事了。他们也不想操心队列、重试、或者重试的重试。他们要的是产品即使后端是分布式的,也显得即时且可预测。

这种预期决定了栈里的每一个设计选择。一个快但不可靠的模型,不如一个略慢但稳定的模型。一个花哨的动画,不如一个清晰的状态标签。一个隐藏的回落,胜过一次响亮的失败。在规模化下,产品信任来自响应的稳定性,而不是后端的复杂度。

跨供应商路由

生成器刻意做成了供应商无关的。我们不把产品钉死在单一模型上,因为每个供应商都有不同的延迟模式、配额行为和宕机窗口。请求先进路由层,挑出主供应商,然后当首选慢或挂了时回落。用户看到的是一个 generate 按钮;内部,服务每次都在做一个小型路由决策。

路由决策	目标	为什么重要
主供应商	用当前可用的最快模型	保住顺风路的快
回落供应商	主供应商慢或被限流时恢复	防止硬失败
超时策略	在 UI 感觉卡住之前停等	保持系统响应性
重试策略	避免重复劳动	省成本,避免混淆

实操教训是:模型选择只是故事的一半。路由逻辑才是供应商拓扑变化时还能让体验不塌的部分。在消费级应用里,一条扛造的回落路径,通常比一个稍微好一点的提示词更值。

为什么我们激进度限流

限流不只是为了控成本。它保护队列,防止滥用流量挤占正常用户,也给前端一个稳定的预期,知道生成多久能成。用户视角的限额很简单:一个免费档、一个清晰的每日上限、一个一眼就能看明白的清零节奏。

从系统视角看,限流也降低了失败链式传播。供应商已经在挣扎时,一波重试只会让故障显得更糟。硬上限和按 IP 限额是钝刀,但它们可靠。对一个有消费受众的公开产品,可靠胜过花哨。

我们怎么给失败整形

一次失败的生成也应该像一个产品响应,而不是一坨堆栈跟踪。我们把供应商错误归一成一小组面向用户的状态:pending、generating、可重试失败、永久失败、成功。技术细节留在日志和告警里。界面保持小。这个分隔压低了支持负担,因为失败话术是一致的,即使底层原因在变。

管线有多个步骤时,这件事更重要。生成可能成功,但背景去除失败。静态导出可能成功,但动画编码失败。如果这些被当成一坨大失败,用户完全不知道下一步怎么办。如果每一步是独立的,UI 就能在对的瞬间给出对的重试按钮。

可观测性是产品的一部分

我们打的日志刚好够回答那些重要的问题:用了哪个供应商、哪一步挂了、每一步花了多久、以及用户最终是不是拿到了能用的结果。重点不是收一条巨大的遥测水管。重点是把下一次调试做得很便宜。如果一个供应商开始超时,我们要快点知道,还要知道回落路径是不是救下了那个请求。

好的可观测性也会改进编辑性内容。当你真的理解生产中的瓶颈,你就能写出更好的技术文章,改进入门流程,以及诚实地向用户解释系统。这种诚实是 E-E-A-T 的一部分:这个站点读起来像一个真产品,由真懂它在哪里会坏的人搭建。

我们把哪些留在浏览器里

浏览器拿到的是最擅长在边缘做的事:收输入、显示进度、渲染结果、以及保留历史。它不需要知道供应商拓扑。也不需要知道队列实现。它只需要知道当前请求是 pending、generating、done 还是 failed。这种窄契约让 UI 轻量、让代码更容易理解。

我们也让浏览器负责用户意图。切换模式、选 emoji、或重试的控件应该始终感觉即时。如果页面每次小交互都得等网络来回,产品就开始像一个远程过程调用 demo,而不是一个创意工具。

为什么我们选 App Router

站点大部分是内容,但生成器本身行为像一个 app。App Router 让我们能用一种干净的方式,让静态内容页保持静态,同时让交互面保持响应。这个分裂对性能和对可爬取性都重要。对搜索引擎来说站点像一个内容出版物,对真实用户来说像一个工具,两边都不别扭。

这也让部署故事更干净。静态页可以预渲染。动态面只有在需要时才选择额外的工作。结果是一个看起来比实际更大的站点,却不需要复杂的运维设置。

现实中先坏的是哪些

•供应商延迟尖刺,先于完全宕机
•模型成功后,背景去除反而成了瓶颈
•响应慢时,用户会重复提交同一个想法
•移动浏览器对重度加载态的惩罚大于桌面浏览器
•系统承压时,动画导出是第一个被砍的功能

知道这些故障模式很有用,因为它告诉我们该把工程时间花在哪。很少是花哨功能需要更多代码。往往是无聊的路径需要更好的超时、更干净的日志、或稍微更清楚的重试按钮。

上线前我们的清单

1.顺风路的延迟能保持在产品预算内吗?
2.回落供应商能不改变用户流程救下请求吗?
3.某一步失败时,UI 能用一句话解释下一步该做什么吗?
4.我们能不看原始堆栈跟踪就观察到失败吗?
5.输出在我们用户真正关心的平台上还工作吗?

如果其中任何一个答案是"不",这个功能就没完。听起来很严,但它能让产品躲过 AI 应用最常见的故障模式:demo 惊艳,生产脆弱。

想看产品的故事,先从生成器开始,然后看结果在不同导出模式下的表现。

试试生成器 →

常见问题

一旦人们意识到这个产品背后是一条真的路由和失败处理层,而不是单次模型调用,他们就开始问这些问题。

为什么不用单一供应商、把事情做简单?

因为简单在那个单一供应商第一次限流或变慢时就消失了。回落给代码加了复杂度,但给用户体验减了复杂度。用户拿到的是稳定的结果路径,而不是一次宕机。

为什么不直接让浏览器在失败时重试?

因为浏览器重试不擅长隐藏供应商的不稳定,也容易不小心重复。重试应该发生在有失败上下文的地方，那是 server 或 worker 层,不是用户点的那个按钮。

最重要的指标是什么?

最重要的指标不是原始生成数。是无需要用户介入、最终变成可复用且平台安全素材的请求占比。那才是这个产品真正的成功率。

你们最紧密监控的是什么?

供应商超时、回落频率、背景去除失败、重试与成功导出之比。这四个数字比一千个通用 PV 更能告诉我们产品健康度。

最后备注

最好的 AI 产品不只是聪明。它们宽容。把用户不需要的复杂度藏起来,在出问题时只暴露刚够用的信息。这就是 Forgemoji 背后的运维哲学,也是让这个 app 让人觉得可靠而不是实验性的那部分。