---
凌晨两点半，手机被报警短信震醒：某模型 API 大面积超时。打开自家产品一看，好家伙，生成页面直接白屏转圈——前端把 AI 返回当成了渲染前提，模型一抖，整个产品跟着陪葬。
这是我去年被坑惨了的一次踩坑。用户不管你后端调的是哪家模型，他们只记得“这产品用不了”。
降级路径：AI 失败后用户实际拿到的那个结果，必须在写第一行代码之前想清楚。
很多人接 AI 的思路是“先跑通再说”，异常处理里随手写个 catch 然后弹个“服务繁忙”。这不叫容错，这叫把锅甩给用户。
正确的问法是反过来的：假如这个 AI 能力明天彻底下线，我的产品还剩多少价值？剩下的那部分，才是你产品的真实底盘。
答案如果是“啥也不剩”，那硬伤不在 AI，在你的产品定义。
我们做课件工具时接过 TTS，给生成的生字卡配朗读。上线第一周语音接口就开始抽风，返回空音频。
当时的处理：合成失败就直接跳过语音模块，课件照常生成、照常下载，页面上语音按钮变灰加一行“语音服务暂时不可用”。
结果呢？零投诉。老师要的是可打印的生字卡，语音是加分项不是及格线。增强能力降级：锦上添花的功能挂了，就把花撤了，锦还在。
另一个场景是 LLM 改稿：用户上传草稿，模型帮忙润色。模型抽风时流式响应卡在半截，用户盯着屏幕喂鱼。
兜底方案是确定性回退：改稿超过硬超时（我们定 25 秒），放弃 AI 改写，走本地规则引擎做一轮基础排版和纠错，产出一份“虽然没有灵魂但能用”的版本。
有 AI 是 90 分，没 AI 是 70 分，超时卡死是 0 分。你选哪个？
多语言站点的机器翻译挂了怎么办？保留原文，加个角标提示“翻译暂不可用”。
听起来很朴素对吧？但我见过太多产品把翻译调用写在渲染主链路里，接口一挂整站 500。最小可用交付：宁可给用户英文原文，也别给一个报错页。
说人话就是：菜凉了可以上，盘子碎了客人就走了。
渐进增强：先用确定性能力保证 60 分可用，AI 在这之上把体验拉到 90 分。
落到执行层面就一条军规：任何一个功能，先做无 AI 版本并跑通，再叠 AI。顺序反了，你就不是在做产品，是在给模型厂商打工顺便接盘他们的稳定性。
为什么顺序不能反？因为无 AI 版本会逼你想清楚核心价值到底是什么。
AI 加持的功能上线那天就该有降级预案，而不是等第一次翻车后连夜补。
这四条都不难写，难的是上线压力下你还记不记得写。模型厂商的 SLA 哪怕是 99.9%，摊到你的日活头上也够你喝一壶。
传统工程里失败是 exception，AI 产品里失败是常态流量。
设计评审时我会强制问每个 AI 调用点一句话：“这条链路的 Plan B 是什么？”答不上来的，打回重做。
这套思路也贯穿了本站工具的设计：核心能力尽量走确定性路径，能不上传就不上传，能不依赖外部服务就不依赖。比如密码生成器，纯本地随机算法，零 AI、零后端调用，任何模型 API 抖动都影响不到它——因为它压根不调。躺赚的可靠性，都是设计出来的。
Q1：降级体验和正常体验差异很大，用户会不会觉得产品很烂？
会，但远好于白屏。用户的容忍度排序是：正常 > 功能缩水 > 转圈 > 报错，降级本质是把第四名换成第二名。
Q2：为降级路径维护一套无 AI 逻辑，成本是不是太高了？
不高，因为这套逻辑往往就是你的 v1 版本，本来就该有。真正贵的是没有它——每次模型抖动都是一次公关事故。
Q3：模型越来越稳了，降级设计是不是可以省了？
省了它，你就把产品可用性和别人的 SLA 绑死了。模型商自己也会改版、限流、涨价，别赌运气。
相关推荐
评论列表 （0条）
