目录
生成式 AI 如今已深深嵌入日常工作——写作、编码、调研、摘要。越是方便，下面这个问题就越沉重："如果明天，那个 AI 突然不能用了，怎么办？" 这并非杞人忧天。2026 年 6 月，一款顶级模型在发布仅仅三天后就对所有用户停用了。
本文将梳理什么是AI 依赖风险、AI"消失"的几种形态（六种类型），并面向个人和生产系统两类场景，给出无论它何时停摆都能从容应对的具体准备方法。全文写得即使没有任何前置知识也能读懂，后半部分会一直深入到面向开发者的冗余设计。
不要把全部身家押在单一 AI 上
— 按"它一定会停"来设计，停了也不会受伤
全部押在一个模型上
这是一个"单点故障"：一旦它被停用、退役、涨价或变更，你的工作就跟着一起停摆。
靠设计防护，而非靠预测
别去猜"它什么时候会停"。要让它在停的那一刻能够"自动切换过去"。
备选方案、冗余、自己留底
备好一个替补模型，把数据和提示词留在自己手里，并事先准备好切换方案。
1. 什么是 AI 依赖风险？——"太方便"的另一面
AI 依赖风险，指的是你的工作或生活过度依赖某个特定的 AI 服务或模型，以至于当它变得不可用、发生变化或变贵时，你会遭受重创的状态。真正可怕的，与其说是"AI 会出错"，不如说是"昨天还能用的 AI，今天却不在手边了"这种突然的断裂。
基于云端的生成式 AI 很方便，但它的开关却握在你掌控之外。有媒体一针见血地指出："你的 AI 厂商，如今就是一个单点故障（single point of failure）。" 那些你以为会像水电一样随时都在的东西，可能因为监管、商业决策或一次故障而一夜之间停掉——这就是 AI 时代全新的依赖风险。
💡 要点：依赖本身并不是问题。问题在于"没有替代品"的依赖。哪怕只准备一个备选方案，就能把风险从"致命"降级为"不便"。
2. 真实发生过：Fable 5 与 Mythos 5 一夜之间消失
2026 年 6 月 12 日，Anthropic对所有用户停用了其顶级模型Claude Fable 5 与 Mythos 5 的访问权限。这是对美国政府出口管制指令的回应，而这两款模型在 6 月 9 日才刚刚发布——距离上线仅仅三天就全面停摆。App、API、云端，每条通道无一幸免，无论免费还是付费，陷入了"哪个入口都进不去"的局面。
截至本文撰写时（2026 年 6 月下旬），两款模型仍处于停用状态。Anthropic 的一位高管曾在 6 月中旬表示会在"未来几天内"恢复，但官方状态页上至今仍未显示恢复，重启时间仍不明朗。完整的事件经过整理在我们的 Fable 5 / Mythos 5 停用事件一文 中。
🚨 这件事的教训：它停摆，并不是因为"质量不行"。而是出于与性能毫无关系的理由——监管——最高性能的模型在一夜之间消失了。换句话说，无论一个 AI 有多强，停用风险都无法降到零。
Fable 5 只是冰山一角。事实上，2026 年也是各家厂商接连让旧模型退役（retire）的一年。停用与废止并不是"特殊事件"，它们正在变成只要你还在用 AI 就要长期相伴的常态风险。
3. 依赖风险的 6 种类型
"AI 变得不可用"这一句话里，背后的发生方式其实千差万别。在思考防护之前，不妨先把麻烦会以什么形态出现分成六类来理清。
① 突然停用
监管、国家安全或法律纠纷导致服务毫无预警地中止。Fable 5 就是典型——也是最难来得及应对的一种。
② 模型废止（退役 / deprecation）
随着用户迁移到新模型，旧模型按计划被逐步停掉。虽有提前通知，但期限一到就一定会停——还在继续指定它就会出问题。
③ 涨价 / 计费体系变更
资费调整、免费额度缩水、套餐停售。服务还活着，但账算不过来了，于是用不起。
④ 质量变化 / 静默改动
同一个模型名下，行为却变了 / 安全限制收紧了。"昨天还好用的提示词，今天却不灵了。" 麻烦之处在于很容易被忽略。
⑤ 故障 / 速率限制 / 封号
服务器故障、用量上限、账号被封。即便只是暂时性的，在那一刻它也确实停了。
⑥ 厂商锁定（vendor lock-in）
把系统深度绑定到某一家的专有功能和格式上，结果无法迁移到别家——在 ①～⑤ 发生时，亲手堵死了自己的退路。
①～⑤ 是"从外部砸下来"的风险；⑥ 则是你"自己一手造成"的风险。前者无法完全防住，但仅仅避开 ⑥，就能在关键时刻大幅减轻损失。
4. 先量一量"自己的依赖度"
准备的第一步不是去采购，而是盘点家底。专家们一致认为，起点是"冷静地把自己的 AI 依赖链条理清楚"。把下面三件事写出来，你就有了一份属于自己的依赖地图。
你依赖的是什么
哪个服务、哪个模型，用在了哪项工作上。把一切都列出来——App、API 和各种内置功能。
一旦它停了会怎样
把"没它就转不动"的工作和"没它也能凑合"的工作分开。按重要度 × 替换难度来排优先级。
没了它你打算怎么办
为每项依赖事先定好一只"另一只手"：换一个模型、改回手工，或者暂时停下。
这里的关键在于把"需要顶级性能的工作"和"差不多就够用的工作"分开。大多数日常工作不用旗舰模型也能跑得很顺。把旗舰模型只留给真正需要的少数场景，那么一旦它出问题，波及范围就会更小。
5. 个人用户如何准备（5 个步骤）
即便是不搭建系统的普通用户，从今天起也能着手准备。说到底，就是"别把一切都甩给 AI"的习惯。
把成果保存在自己这一侧
别把重要的输出和聊天记录一直丢在服务里——在本地或自己的文档中留一份副本。服务一旦停摆，连同里面的历史记录也可能一起无法访问。
把好用的提示词当成资产留存
把效果好的提示词积攒下来。它们大多几乎可以原封不动地搬到另一个 AI 上。把财富积累在"自己手里"，而不是"AI 里面"。
保留"没有 AI 也能做"的能力
把最终判断、核实事实、辨别文章好坏的能力留在自己身上。不把一切都交给 AI，正是它停摆时你最大的保险。
机密别全交出去，也要分散
别把核心业务信息全部灌进同一家厂商。遵守输入时的注意事项，在即便它停了、即便发生泄露也不至于把你拖垮的范围内使用 AI。
6. 生产系统的准备（用设计做冗余）
如果你已经把 AI 嵌入了服务或 App，那么准备就从"习惯"上升到了"设计"。关键是不要硬绑定到某个特定模型。下面这些做法按效果从大到小排列。
(1) 插入一个抽象层（LLM 网关）
不要从 App 里直接调用各家的 API，而是在中间加上一个统一入口（网关）。这样一来，切换模型就只是改个配置而已。主流的选择有：
LiteLLM
自托管型，适合把"零厂商锁定"放在首位的人。你可以精细地配置回退链、重试和超时，并掌握数据主权。运维则要自己扛。
OpenRouter
用一个 API 密钥即可访问众多模型和提供方。无需自己管理基础设施，而且传入一个模型数组就能依次回退，非常简单。适合做原型和评估。
一个在代码侧抽象各提供方的库。不改 App 代码就能替换模型。与 Web / App 开发非常契合。
✅ 迁移比你想象的更轻松：许多主流网关都提供"兼容 OpenAI 的 API"，因此很多时候你要改的只是基础 URL 和 API 密钥。现有代码基本可以照常运行。趁现在先垫上这一层，是性价比最高的保险。
(2) 搭一条回退链（但一定要测试）
定义一条会自动切换的链条："第一选择失败就走第二，第二也失败就走第三"。大多数网关都允许你按模型名分别设置回退目标、重试和超时。
⚠️ 陷阱：回退一定要"在用到它之前就测过"。一套你以为配好了、实际却从不触发——或者悄无声息地失败的方案，比没有回退还糟（你连出了故障都察觉不到）。在风平浪静时，故意把主模型停掉，确认它能否正确切换。
(3) 分层——让 AI 成为"可拆卸的零件"
把你的系统按两层来思考。诀窍在于，把那些绝不能交给 AI 替代的部分，与 AI 保持独立。
起草、摘要、建议
AI 停了，你也只是失去了这一块。要设计成：生产力会下降，但工作仍能继续。
数据、台账、核心系统
把它们放在自己掌控之下，不依赖外部 AI。即使 AI 消失了，你的核心数据与处理流程依然存活。
(4) 用本地 LLM 作为最后一道防线
哪怕整个云端都瘫痪，也能在自己硬件上运行的本地 LLM留上一个，对网络故障、API 停用和监管都同样管用。它也许性能不是最顶尖的，但能给你一条掌握在自己手里的底线："至少到这里为止，我们永远不会陷入无 AI 可用的境地。"它还很适合机密数据不能离开内部的场景。
(5) 写一页恢复手册（playbook）
真出了事的时候，临时抱佛脚地从头查起会拖慢恢复速度。哪怕只留一页纸——"主模型宕机 → 用这条命令切到替代方案 → 用这个模板通知相关方"——也能把恢复时间（MTTR）从"几天"缩短到"几小时"。每年实地做一次切换演练，到了关键时刻它就一定能跑起来。
7. 选择厂商的检查清单
其实，光是选哪个服务这一步，依赖风险就会大不相同。除了性能和价格，还要看"它停起来诚不诚实"。各家的废止政策是有差别的。
⏳ 废止的提前通知期
在废止一款公开模型之前，会给多少缓冲时间。Anthropic 声明至少 60 天；OpenAI 对正式发布的模型至少提前 6 个月。但预览版模型可能只有 2 周左右——因此依赖预览版需要格外小心。
🔔 变更的透明度
它是否以用户看得见的方式公告规格变更和限制。"悄悄降低质量"对于被依赖方来说是很危险的。要看它的公告、迁移指南和状态页是否完善。
🗄️ 退役后的善后
它对退役的模型是否还有照顾。例如 Anthropic 就表示会长期保存模型权重，并通过申请的方式让部分退役模型仍可使用。这样的态度能为迁移带来一份安心。
📌 注意：通知期和政策每家厂商都会修订。采用之前，务必在官方的"模型废止（deprecation）"页面确认最新数值。本文中的数字是 2026 年 6 月时的参考。
总结
对 AI 依赖风险的准备，可以浓缩成三句话。
- 知道它是真实的：正如 Fable 5 所展示的，即便是最高性能的 AI，也可能因监管、商业或故障而一夜之间停摆。停用与废止是一种常态风险。
- 靠设计防护，而非靠预测：你猜不准"它什么时候会停"。正确做法是让它在停的时候能"自动切换 / 不会受伤"。一个替代品、一层抽象层、一页恢复手册。
- 把资产留在自己这边：把数据、提示词和判断力存在"自己手里"，而不是"AI 里面"。仅仅避开 ⑥ 厂商锁定，就能为自己留下一条退路。
AI 是一件强大的工具——但工具有时会从你手中消失。把系统设计成它消失时核心工作也不会停摆，这正是让你能够安心、深入地用足 AI 的根基。
FAQ
Q. 那到底用哪个 AI 最安全？
A. "只选一个"这个想法本身就是风险。安全的不是某个特定服务，而是随时都能切换到另一个 AI 的状态。日常固定用一个，同时保持至少有一个随手能用的替代品——这才是现实中最优的做法。
Q. 我只是当兴趣随便用用，也需要做准备吗？
A. 轻轻准备一下就够了。只要做两件事——"把重要的输出保存到本地"和"把好用的提示词记在备忘里"——就几乎能防住服务停摆时的所有损失。完整的冗余是用于工作场景时才需要讨论的话题。
Q. "废止（deprecation）"和"停用"是两回事吗？
A. 废止是为迁移到新模型而进行的有计划的收尾，通常会提前数周到数月通知。而像 Fable 5 那样的停用，则可能毫无预警地突然发生。前者用迁移来应对，后者用冗余来防备——这样区分开就清晰多了。
Q. 同时支持多个 AI，难道不会增加成本和精力吗？
A. 只要插入一层抽象层（LLM 网关），支持成本就会大幅下降。很多网关都兼容 OpenAI，所以切换大致就是改一下端点和密钥。你并不需要时刻同时跑两家厂商——只要保持"随时能切换"的就绪状态，平时的精力几乎不会增加。
Q. 有了本地 LLM，还需要云端 AI 吗？
A. 它们各司其职。本地 LLM 在性能上往往比不上顶级的云端模型，但它作为"绝不宕机的最后一道防线"自有其价值。平时用云端，紧急时用本地——这种两层配置才是现实可行的方案。
