事件總覽：Anthropic 旗下的 AI 服務 Claude 在這個月（3月）遭遇了一連串的服務中斷與異常，從單次的回應延遲到長達數小時的全面當機，這些事件不僅衝擊了廣大使用者，更引發業界對 AI 基礎設施穩定性與企業營運風險的深切關注。
📅 3月2日：大規模服務中斷，需求高峰下的系統考驗
話說回來，這個月的當機事件可說是以 3月2日 的大規模服務中斷拉開序幕。當天 UTC 時間上午 11:49，數以萬計的 Claude 用戶並非看到熟悉的對話框，而是「Claude will return soon. Claude is currently experiencing a temporary service disruption.」這行字。Anthropic 隨後透過 WhatsApp 聲明，將此次服務下線歸因於過去一週遭遇的「史上最高需求」（unprecedented demand）。不過，從事故日誌來看，整個過程並不穩定：登入路徑在 UTC 15:47 剛恢復穩定，Opus 4.6 又在 UTC 17:09 爆出新問題，緊接著 Claude Haiku 4.5 也於 UTC 17:56 隨之崩潰。有趣的是，在網頁介面崩潰期間，Claude 底層的 API 服務多數時候保持穩定，這顯示了兩種不同認證路徑的架構差異，讓直接透過 API Key 呼叫服務的企業用戶大多未受影響，但仰賴網頁版的用戶卻是完全失去入口。
📅 3月17日至22日：密集故障，系統性警報響起
在此之後，服務中斷並未畫下句點。根據 StatusGator 的監控紀錄，光是 3月17日至22日 短短六天內，就記錄到七次事故，這已遠非「偶發故障」所能解釋。舉例來說，3月17日當機長達 3 小時 56 分鐘，並伴隨 5 小時 54 分鐘的警告；隔天 3月18日更出現長達 9 小時 3 分鐘的嚴重當機；而 3月19日，Opus 4.6 甚至連續兩次錯誤率飆升。到了 3月21日，分鐘反應持續延遲了 132 小時。最近的一次，即 3月22日，Claude 再次出現異常，被標記為「回應延遲完成」，持續約 2 小時。這些密集的異常，無疑是對 AI 產業基礎設施發出的系統性警報，挑戰著其穩定性與可靠度。
企業用戶的沉重代價：從營收流失到信任危機
這些頻繁的當機事件，對於深度依賴 Claude 服務的企業來說，代價是顯而易見的。某 AI 新創公司創辦人在當機後推文直言：「我們整個產品都依賴 Claude。那幾個小時我們收入流失，也失去客戶的信任。」這句話並非個案，而是數千條網路控訴中最具代表性的一條。根據 Downdetector 的數據，3月2日當機高峰時約有兩千名用戶回報故障，紐約時間早上 6:40 達到顛峰。試想，當 AI 客服系統集體下線，人工客服不得不緊急接管；程式碼審查、文件產生、Debug 等核心工作流程全部停擺；資料分析和決策支援系統也失去回應，這對企業的營運打擊有多大？更諷刺的是，許多公司甚至在 AI 停止運作之前，根本不清楚自己對 AI 的依賴程度有多深。
AI 供應商的「單點故障」風險與多模型策略的重要性
這些事件深刻揭示了現代科技的關鍵漏洞：單點故障（Single Point of Failure）。當 Anthropic 努力解決問題時，當機的滾動性質證明了一件事：對於重視正常運行時間的企業來說，「等它自己好」根本不是一個可行的解決方案。AI 服務不只牽涉技術選型，也隱含政策風險。一道政策命令，一個供應商就可能從採購名單上消失，將所有 AI 雞蛋放在同一個籃子裡，風險不只來自技術層面。對於那些將 Claude 深度嵌入工作流程的企業而言，當機時要立即切換到競爭對手並不容易，因為適配層、授權差異和行為差異都會產生摩擦。因此，多模型策略在紙上看起來很美，但如果從未真正測試過故障轉移邏輯，那這份備案就形同虛設。
至今影響與未來展望
Claude 在三月經歷的頻繁服務中斷，無疑為 AI 產業敲響了警鐘，迫使企業重新審視其 AI 供應鏈的韌性與可靠性。Anthropic 在這系列事件中，資訊揭露相對透明，例如 3月2日當機後 17 分鐘內即發布公告，3月17日更主動說明「目前只有免費用戶受影響」，這點值得肯定，至少比業界平均水準要好。然而，這些事件也讓企業意識到，將核心業務過度綁定單一 AI 供應商所帶來的巨大風險。未來，企業在導入 AI 服務時，必須更深入地評估供應商的基礎設施穩定性、備援機制，並積極規劃多模型或多供應商策略，以確保在面對不可預期的服務中斷時，仍能維持營運的連續性與客戶的信任。