六个停服日期：给一人公司的供应商体检表

从 2026 年 8 月 5 日到 9 月 3 日，公开可查的硬期限有六个。其中提前量最短的那一个，从官方公告到备份截止只有 12 天，而逾期的后果不是「服务不能用了」，是数据被删掉。

一人公司最容易被低估的成本，不是每月那几百块订阅费。订阅费是明账，每个月都会在账单上提醒你一次。真正贵的是另一样：某个供应商在你不知道的时候定了一个日期，日期一到，你手上那条链路直接断，而你要用一整个周末去重建它。这笔钱不出现在任何账单上，它出现在你那一周没接的单子里。

站内此前有一篇讲过「把供应商风险写进 AI 计划」的框架，那篇给的是判断方法。本篇不重复框架，只做一件事：把 2026 年 8 月这一个月里公开的六个日期摆出来，说清每一个不动手会发生什么，再给一张十分钟能做完的表。所有日期的采集日是 2026 年 8 月 18 日。

一、六个日期，连同它们各自的提前量

先看这张表。注意最右边那一列——公告日到生效日之间隔了多久，这一列比日期本身更有用。

据 Anthropic 官方模型退役页，Opus 4.1 于 2026 年 8 月 5 日退役后，API 请求一律报错，官方推荐迁到 `claude-opus-4-8` 或 Claude Opus 5。据 Google Gemini API 官方弃用页，Imagen 4 全系已于 2026 年 8 月 17 日退役。据 Kimi 官方模型页，页面原文写着「Kimi K3 发布后，`kimi-k2.5` 和 `moonshot-v1` 系列模型已停止向新注册用户开放（全平台正式下线时间为 8 月 31 日）」，`moonshot-v1` 系列包含 8k / 32k / 128k 三档和三个 vision-preview。据 OpenAI 帮助中心的迁移说明，ChatGPT Atlas 于 2026 年 8 月 9 日停服，书签不会自动迁移、Cookie 无法导出，需在停服前手动导出 HTML。据凤凰科技 2026 年 8 月 10 日转载的零一万物公司公告，该平台自公告日起停止新用户注册与充值，2026 年 9 月 3 日 24:00 停止模型体验与 API 调用，退款申请截止 2026 年 12 月 3 日 24:00。

据 Manus 官方 2026 年 8 月 11 日的用户通知，备份窗口截至 2026 年 8 月 23 日 SGT 07:59，删除自 8 月 23 日 SGT 08:00 起执行至 8 月 24 日，2026 年 8 月 25 日 SGT 08:00 起可用官方工具恢复已备份的数据。官方原文用的是 "certain users"，也就是「部分用户」，不是全体——所以第一步是确认自己在不在受影响范围里，而不是直接开始备份。

先指出一个普遍的错误。多数人处理这类消息的方式是：看到了，心里记一下，等真出问题再说。这个做法在两个月提前量的条目上勉强能过，因为你大概率会在两个月里的某一次报错时想起来；它在 12 天提前量的条目上必然失效，因为 12 天之内你根本不会碰那个产品。提前量越短的条目，越不能靠记忆处理。

二、按「不动手的后果」分三类，不要按厂商分

把六条按供应商排，得到的是一张没用的表——你会按熟悉程度去看它，最熟的排最前，而最熟的那个恰恰是你最不会忘的。我的建议是按后果分三类。

第一类：不动手就丢东西。这一个月里只有一条，就是 Manus 那条。它的特征是「过期不补」——8 月 23 日 SGT 08:00 之后删除开始执行，删完就没有了，恢复工具只能恢复你自己备份过的那份。ChatGPT Atlas 那条有一半属于这一类：官方明确写了 Cookie 无法导出、书签不会自动迁移，要在停服前手动导出 HTML；停服日 2026 年 8 月 9 日已经过去，没导的那部分补不回来。

第二类：不动手就挂掉，但东西还在。Opus 4.1 退役、Kimi 那两个系列 8 月 31 日下线、零一万物 9 月 3 日停 API——这三条的共同点是，你的数据没事，断的是调用。表现形式通常是某个凌晨的定时任务开始报错，或者某个客户在使用中途收到一个不知所云的错误页。修法是改模型名或换供应商，工作量取决于你把那个模型名写在了几个地方。

第三类：不动手也不会立刻死，但会慢慢变贵或变难用。Imagen 4 全系退役属于这一类：官方给了替代型号，你的图还在，只是原来那个型号调不出来了。零一万物那条的退款环节也属于这一类——API 在 9 月 3 日停，但退款申请一直开到 2026 年 12 月 3 日 24:00，不处理不会立刻损失，拖到期就损失了。

分完类之后，顺序就自己出来了：先做第一类，再做第二类，第三类排进月底的固定动作里。这个顺序不需要判断力，只需要照做。

还有一条不在 8 月、但值得一起排进日历：据 Make.com 官方帮助中心，该平台的 cycles per run 设置将于 2026 年 10 月 1 日下线，用了多 cycle 的场景必须在此之前改造；同一来源还记录了 2026 年 8 月 10 日起部分 OpenAI GPT 模型弃用、2026 年 8 月 7 日起部分 Anthropic Claude 模型临时停用，两条都给了替换指引。把它放进来是因为它示范了第二类里最麻烦的一种：断的不是模型，是平台的一个功能设置，改模型名解决不了。

三、十分钟做一张体检表，以及三条约束

这张表不需要工具，一个文档、一张纸、或者日历里的六条提醒都行。四步：

• 1列出「停了你这个月就交不了活」的那些。 注意约束条件：不是列你注册过的所有账号，是列「停了会影响交付」的。你注册过的账号数量一定远多于这个数，但真正压在交付链路上的是少数。上限：这张表不许超过十条。超过十条，说明你要先做的不是体检表，是砍工具。
• 2给每一条找到它的官方公告入口，把链接抄进表里。 找法是固定的：官方文档站搜 deprecations、changelog、release notes、announcements 这几个词；帮助中心搜「下线」「停服」「迁移」。找不到公告页的产品，在表里单独标一下——一个连弃用公告页都没有的供应商，本身就是一条风险记录。
• 3给每一条填两个格：最坏情况丢什么，以及重建要多久。 「丢什么」只有三个选项：丢数据 / 丢调用 / 丢一个功能。「重建要多久」写你自己的估计，单位是小时，不用精确。这两个格是这张表唯一有判断成分的地方，其余全是抄。
• 4把有明确日期的条目设成日历提醒，提醒日期定在生效日往前推七天。 不要定在当天。第一类那种 12 天提前量的条目，往前推七天正好落在你还来得及处理的位置。

第 2 步是四步里最花时间的，第一次做大概占掉七八分钟；但它只用做一次，之后每个月只是往里加行。做完之后跑满两周再回头看一次——两周里你会发现自己漏了一两个天天在用却没想起来的东西，那时候补进去比第一次凭空想全要准。

三条约束，逐条说清为什么：

约束一，表里只放有官方页面可查的日期，不放传闻。媒体报道某家「可能要停」的消息，不进这张表。理由很实际：传闻进表之后，你会为它做准备，而准备是有成本的，一次白做就再也没人维护这张表了。

约束二，不为「万一」做双供应商。给每条链路都配一个备份供应商，听起来稳妥，实际是把维护成本翻倍——两套提示词、两套失败处理、两份账单。一个人扛不住。只对第一类（会丢数据的）做真备份，第二类接受「挂了再改」。

约束三，第 3 步里「重建要多久」超过八小时的条目，要单独标出来。超过八小时意味着它不是一个可以「挂了再改」的东西，你得在它挂之前就有替代方案。我给的上限是两个：超过两个，说明你的交付太依赖外部服务，该改的是结构，不是这张表。

四、代价：什么时候不该迁，以及这张表帮不了你什么

先说这张表的成本。第一次做十分钟，之后每月维护大概五分钟，加上第一类条目的实际备份时间。这个成本很低，低到我不建议你为它做任何优化——不要为这件事去搭自动化，不要写脚本去抓各家的弃用页。抓取会失效，失效之后你会以为「没消息就是没事」，那比没有这张表更危险。

再说什么时候不该迁。看到一个下线公告就立刻迁走，是另一种浪费。三种情况下我的建议是不迁：

第一，官方给了同族替代型号，且改动只是一个字符串。Opus 4.1 迁到 Opus 4.8 或 Opus 5、Imagen 4 迁到 `gemini-3.1-flash-image`，这类改动的正确做法是改完跑一遍你自己的验证用例，确认输出没塌，就结束了。不要借这个机会顺手换个供应商——你会同时改变两个变量，出问题时分不清是哪一个。

第二，那条链路本来就要重做。如果某个功能你早就想推倒重来，供应商下线只是给了你一个日期。这时候不要做迁移，直接做重做，把迁移的工时并进重做里。分两次做，你会付两遍验证成本。

第三，用量小到人工替代更便宜。一条一个月只跑二十次的链路，供应商停了，你花四个小时迁移，不如接受这四个月自己手工做二十次，同时观察这个功能到底还需不需要存在。很多功能是在这种时候被发现其实没人用的。

最后说这张表帮不了你什么。它只覆盖「官方公开宣布过日期」的那一类风险，而一人公司遇到的中断，相当一部分没有日期：一次没有预告的接口变更、一次限流策略调整、一次账号因为风控被暂停。这些不在任何弃用页上，也不可能提前记进日历。对付那一类只有一个办法，和这张表无关：把每条交付链路的关键产出物落到自己能拿到的地方。图片、文案、客户数据、对话记录，定期导出一份到你自己的盘上。这件事没有日期，所以要靠固定动作，不靠提醒。

关于供应商风险的判断框架，站内已有一篇专门写过，本篇只补日历这一层。