11月7日下午，DeepSeek的API又出问题了。官方状态页把这次故障记在15:11到15:56，45分钟。有用户说，13点左右就调不通了。距离10月15日那次4小时52分钟的宕机，还不到一个月。DeepSeek状态页知乎
上次的赠金到账截图曾刷屏，所以这次一崩，很多人第一反应是：上次补了，这次要不要申请？
答案是：没有“申请”这个动作。
目前能查到的成文补偿，是10月15日傍晚发的《服务恢复及补偿通知》。通知写得很具体：故障时间8:11至13:04，按账号7日内（10.8-10.14）的消耗金额，以赠金形式全额返还，赠金自动到账，API计费扣款先从赠金账户扣除。注意“自动到账”四个字。没有申请表，没有客服审核，也没有“符合条件者请于某日前提交材料”。平台算好账，直接发到账户里。所以当时社交平台上全是“晒到账”，不是“申请攻略”。返的也不是现金，而是只能在平台里继续抵扣的赠金。微博
11月3日那次，官方状态页记了16:58到18:48，1小时50分钟，影响对话、V4 Pro和V4.1 Flash；11月7日这次，记录更短，45分钟，影响范围还多了搜索服务。两次都只有状态页上的故障记录。截至11月7日发稿，没有新的补偿通知。官方也没有公布触发补偿的门槛：多长的故障、多大的影响面才补，通知和协议里都没写。DeepSeek状态页
11月7日这条记录本身，也值得看一眼。第一条更新就是“已实施修复，正在监控结果”，没有“正在排查”。这条记录把起点直接落在“已实施修复”上。故障从什么时候开始，用户和平台各有一套时间。补偿按什么算、算多久，前提是有一个双方都认的故障窗口；现在这个窗口是平台自己写的。DeepSeek状态页
再往前一步，协议里也没有给“申请补偿”留位置。
《DeepSeek开放平台服务协议》7.4条写得很直白：不保证本服务在操作上不会中断、没有错误、不受干扰、持续稳定或不存在任何故障。这句话的意思是，服务可用性不是合同承诺，而是努力目标。DeepSeek开放平台
7.3条则把上限写死了：违约金、赔偿、补偿及其他费用，合计不超过过去十二个月实际消耗的服务费总额。这条把最坏情况下的赔付总额也框住了。DeepSeek
连退款也不是为宕机准备的。6.3条只允许退“剩余全部未消费的充值金额”，已经消耗掉的金额，协议写明不予退回。换句话说，API用户和平台之间不是“你保证99.9%，达不到就赔”的SLA关系；至少公开协议里没有这条。从协议文本看，宕机本身不自动产生一笔可以主张的补偿。DeepSeek开放平台
那现在能做什么？
如果你只是想问这次有没有补偿，协议里留的入口是产品界面的“联系我们”和邮箱api-service@deepseek.com。它接受投诉和反馈，但没有一条写着“故障补偿申请”。发信之前，别把10月15日当成惯例——那是一次单独的通知，不是一份长期政策。
如果你已经不想用了，能退的是账户里没消费完的余额，按“账单-退款管理”走；已经烧掉的token钱，协议写明不退。
如果你是靠它跑业务，真正能降低损失的还是那几件老事：备用模型、超时和重试、幂等、队列、监控状态页的RSS。10月15日那笔赠金，对用量大的团队是一笔实打实的抵扣；但它补的是token账单，不是你停掉的半天业务。宕机时最贵的，往往不是那笔token账单。
所以，API用户能申请补偿吗？现在不能。能决定补不补的，不是用户的申请，是平台下一次愿不愿意再发一份通知。在协议里，稳定是“尽力”，补偿是“例外”；把例外当预期，下一次宕机还是会措手不及。
