Notion 全線抽起 Anthropic 模型——暴露 AI 基建嘅脆弱現實

2026 年 6 月 7 號星期日凌晨，一班用開 Notion AI 功能嘅用戶發現有啲唔對路：模型選擇器裡面嘅 Anthropic Claude 模型一夜之間全部消失晒。原因係 Anthropic 旗下最強嘅模型 Claude Opus 4.7 同 4.8，突然間出現大量錯誤同失敗請求。表面上睇，呢次只係一個持續幾個鐘嘅小插曲，但實際上，佢係全球頂尖 AI 供應商近期風雨飄搖嘅最新警號。

本文會同你詳細拆解究竟發生咗咩事、Notion 同 Anthropic 點樣應對，同埋最重要嘅一點——對於任何將關鍵工作流程押注喺第三方 AI 模型上面嘅團隊嚟講，呢一連串 Claude 事故背後嘅啟示係咩。

6 月 7 號事件：時間軸逐格睇

星期日凌晨，Notion 嘅官方狀態帳號發出警示，話 Anthropic 嘅 Opus 4.7 同 4.8 模型「出現效能下降，導致選擇呢啲模型嘅 Notion AI 用戶有較高失敗率。」作為回應，Notion 嘅工程團隊決定抽起晒所有 Anthropic 模型，唔畀佢哋喺 AI 生產力工具度出現，並自動將嗰啲 AI 請求跳轉到其他備用供應商嗰度 。

根據 Anthropic 喺自己狀態頁面記錄嘅調查時間軸，件事好快就搵到源頭。佢哋喺 UTC 時間凌晨 3 點 31 分開始調查，3 點 41 分就搵到問題，去到凌晨 4 點 28 分已經大致解決咗個效能下降事故。之後，Opus 4.7 喺下晝 2 點 35 分又出現多一次嘅個別報錯事件，最終喺 3 點 41 分解決 。

Notion 嘅產品主管 Max Schoening 確認，喺服務中斷大約 12 個鐘頭之後，Anthropic 模型嘅存取權限已經恢復。佢形容呢次只係一次標準嘅暫時性服務中斷，仲話呢類事故「乜平台都會發生，Notion 自己會，GitHub 會，AWS 會，你屋企隻 OpenClaw 都會」。

Anthropic 發言人就將問題歸咎於「一個短暫嘅基礎設施問題」，令到多個 Claude 模型喺短時間內出現大量錯誤，仲確認問題已經解決晒 。

Notion 應對策略：教科書級嘅多模型故障轉移

Notion 冇對外詳細講明究竟邊幾間 AI 供應商做咗「後備軍」接收咗啲跳轉流量，但佢哋嘅行動就非常清晰：一偵測到 Anthropic 嘅 Opus 模型開始回傳啲降級嘅結果，系統就自動喺用戶界面嗰度收起晒所有 Anthropic 模型，然後將啲請求掟去第二度處理 。

呢個就係一個活生生嘅「多模型故障轉移（Multi-Model Failover）」架構實例。Notion 冇選擇乾等 Anthropic 修復，然後任由用戶睇住啲失敗訊息乾焦急。相反，佢哋將 AI 模型層當成一件可以隨時更換嘅零件——就好似一個雲端架構師處理一個跪低咗嘅數據庫，或者一個冇晒反應嘅 CDN 一樣。

Claude 嘅「暴風月」：更大規模嘅死機規律

單獨睇 6 月 7 號呢單嘢，的確係小事一樁。但將佢放返喺成個六月嘅背景，就會發現佢只係一堆動搖緊平台信心嘅 Claude 事故入面，最新嘅一塊碎片。

6 月 2 號 – 全球大死機（約 6 小時）

最嚴重嘅一次死機發生喺 6 月 2 號。當日 Claude.ai、API、Claude Console 同 Claude Code 全部都受到嚴重影響。Opus 4.6 同其他模型嘅錯誤率大幅上升，Downdetector 上面嘅用戶回報喺美國東岸時間凌晨 2 點 10 分（即係格林威治時間朝早 7 點 10 分）左右開始飆升。成個服務中斷持續咗差唔多六個鐘頭先至全面恢復 。

6 月 5 號 – 星期五死機兼數據洩漏調查（約 3 小時）

隔咗三日，到 6 月 5 號，Anthropic 嘅 Claude 平台又一次「死咗」。狀態頁面記錄顯示，由 UTC 時間下晝 3 點 08 分到傍晚 6 點 28 分，「多個 Claude 模型出現大量錯誤」，其中 Opus 4.7 同 4.8 係最遲先恢復嘅。呢次事件仲有單更「大鑊」嘅後續：有用戶報告話，服務恢復之後，佢哋竟然收到一啲好似屬於其他人嘅對話紀錄。咁樣就迫使 Anthropic 要正式開 file 調查，睇下有冇潛在嘅數據洩漏風險 。

6 月 6 號 – Opus 4.8 效能下降（約 50 分鐘）

6 月 6 號又有一單短啲嘅事故，影響到 claude.ai、Console 同 API。Opus 4.8 嘅服務降級咗大約五十分鐘，之後先有修復措施推出並受到監察 。

更早嘅質素問題：五月同四月

呢一堆事故唔係無端端爆出嚟嘅。Opus 4.7 喺 5 月 22 號同 25 號已經記錄咗有報錯嘅時間窗口。由開發者提交嘅回報顯示，Opus 4.7 喺 4 月 16 號發布大約一個禮拜之後，就出現咗品質回退（Quality Regression）——呢個情況同 Opus 4.6 喺 3 月嗰陣嘅「發病」模式一模一樣 。

喺 2026 年 4 月，Anthropic 都公開承認咗 Claude Code、Claude Agent SDK 同 Claude Cowork 喺 3 月 4 號至 4 月 20 號期間出現品質下降。佢哋將原因歸咎於三個唔同嘅因素，喺出咗事後檢討報告之後，仲重置咗用戶嘅使用限制 。

呢種模式對下游整合商有咩啟示？

對於嗰啲依賴 Claude 作為核心組件嘅公司嚟講，6 月 7 號 Notion 嘅事件帶嚟咗一個直截了當嘅教訓：第三方 AI 模型嘅依賴，已經演變成一種基建風險，係一定要用工程手段去抗衡嘅。

依賴單一模型係何其脆弱

一個直接調用單一 Anthropic 模型嘅生產系統，係需要配備三種唔同嘅能力：一個應付瞬時 5xx 或者 529 錯誤嘅重試策略（Retry Strategy）；一個喺服務中斷時可以吸收衝擊嘅後備模型（Fallback Model）；仲有一個應對長期品質回退或者模型退役嘅遷移計劃（Migration Plan）。淨係靠以上任何一種策略都係唔夠穩陣嘅 。

故障轉移架構成為必需品

Notion 自動停用所有 Anthropic 模型，同埋無縫咁跳轉去其他供應商嘅做法，正正係更多下游整合商需要跟住採用嘅模式。如果你冇呢種多模型故障轉移架構，就算只係短短五十分鐘嘅效能下降，都可能令到客服機械人、數據管道同開發者工具全面「跪低」，造成災難級嘅客戶體驗 。

在線時間（Uptime）數字唔係全部真相

Anthropic 自己嘅 90 日在線數據顯示，claude.ai 有 98.8% 在線率，而 Claude API 有 99.15% 。就咁睇落呢啲數字好似幾合理，但你唔好忘記，好多公司而家已經將呢個平台當成第一層（Tier-1）嘅基建咁看待。2026 年 6 月初呢一堆密集式事故——一次六個鐘嘅全球死機、一次引發數據洩漏調查嘅三粒鐘死機，再加多幾次小型中斷——都係強烈暗示緊一件事：AI 依賴嘅韌性門檻，必須要設定得比傳統 SaaS 服務更高先得。

結語

Notion 喺 6 月 7 號全線抽起 Anthropic 模型，係一次針對暫時性基建問題嘅例行操作。但係，喺大約六個星期之內出現咗六次比較明顯嘅 Claude 死機事件，呢個動作就變成咗一個好清晰嘅信號：將生成式 AI 當成一個刺激嘅新實驗品嗰段「蜜月期」，已經正式結束。

對於任何喺 Claude 或者其他第三方 AI 模型上面「起樓」嘅團隊嚟講，可靠性工程已經唔再係一個選擇題。重試邏輯、後備供應商，同埋一條經得起測試嘅模型遷移路徑，將會係你喺地基開始搖晃嗰陣，保住你件產品唔好「爛尾」嘅最基本入場籌碼。