11 月 7 日下午，一位网友在微博上写：“代码刚写到一半、方案刚有思路，它直接给我崩了一天断好几次”。 当天下午，DeepSeek 网页和 API 再次部分中断，对话服务、V4 Pro 和 V4.1 Flash API 都在受影响名单里；状态页随后显示，故障于 15:11 触发，目前已完成修复，并进入持续监控阶段。微博微博
更尴尬的是，有人打开自己的“备用”workBuddy，发现它接的也是 DeepSeek，一样没反应。 你以为准备了两个入口，其实共用一个上游。微博
往前数，10 月 15 日、11 月 3 日、11 月 7 日，不到一个月三次公开中断；其中 10 月 15 日那次持续接近 5 个小时。 那一次，有人总结得更直接——DeepSeek 宕机 5 小时，连带上下游 AI 工具集体瘫痪。第一财经机器之心小红书
所以真正要回答的不是“怎么又崩了”，而是“下次崩五个小时，我还能不能干活”。
把依赖拆开，日常至少有三层可以留后手。
第一层，上游要独立。普通用户最省事的做法，是换一个支持多模型的客户端，把同一段提示词分别存进两家不同厂商的模型；开发者的版本更彻底：主备两条通道，加自动熔断，主节点波动或报 429 时，网关切到备用池，业务层几乎无感。 还有一个更便宜的习惯：把模型名做成配置项，换模型只改一个字符串，别把模型写死在代码和流程里。接了同一个 API 的应用不算备选，workBuddy 是现成的例子。知乎
第二层，上下文要能带走。真正让人抓狂的，还是开头那句话：思路刚有，服务没了。把提示词、素材、阶段成果放在本地文档里，长任务分段保存，聊天记录定期导出。这样切换模型时，你损失的是几分钟，不是一下午。
第三层，离线要能降级。本地部署是唯一不看云端脸色的方案，但门槛要说清楚：把 552B 的 DeepSeek 塞进两台小型工作站，自然语言单流跑到 74.9 tok/s、代码近 110 tok/s。 对大多数人，更现实的是备一个能跑的小参数开源模型，先保证“能继续干活”。看到“12GB 显卡跑满血”的教程，先确认权重真的在本地，而不是 API 加一个桌面壳。知乎
还有两件事，最好别算进备选方案。一是补偿。10 月 15 日那次，DeepSeek 按事故前 7 天的 API 消费全额返赠金，但返的是只能继续调 API 的赠金，提不了现，网页和 App 用户也没有对应的“时间补偿”。 二是“逢崩必更”的节奏。11 月 3 日 DeepSeek 中断，同一天 Harness 更新了 v0.2.2-alpha.3。 但发新版是产品节奏，不是服务承诺，它救不了你当天的 deadline。小红书智东西
DeepSeek 在补偿通知里提到，要“梳理并剥离单点依赖”。 这句话其实也适合用户：别急着换掉 DeepSeek，先把你工作流里那个“只能靠它”的单点拆掉。它仍然是便宜、好用的主入口；只是主入口，不该是唯一入口。小红书
