AI服務中斷同一天打中 OpenAI、Claude、Grok：中小企業的單一依賴警訊｜AIRUN
OpenAI、Claude、Grok 在同一個早上近乎同時中斷。把營運綁在單一 AI 供應商上，本身就是風險。
這篇發稿於 9 月 5 日。依我們擷取來源當下的顯示，事故約發生在一天前。Hacker News 上 ChatGPT 與 Claude 的中斷討論串標題都已標註「已解決」；Grok 那則標題沒有這個標示。正因為前兩家很快就標成已解決，這件事很容易被當成一場虛驚。我們的看法相反：這是第一次有具體案例證明，全球用量最大的三家 AI 可以在同一個早上一起不可用。對已經把客服、報價、寫作流程交給 AI 的台灣中小企業，這比任何一次功能更新都值得花二十分鐘讀完。
以下所有事實只取自 Hacker News 當天的討論串與三家官方狀態頁。來源沒講的，我們寫「官方未公布」，不補腦。
這次三家同日中斷到底發生了什麼事？
三家用量最大的 AI 服務在同一個早上先後中斷。Hacker News 上一則標題為「為什麼 OpenAI、Claude、Grok 同時掛掉」的討論串衝到 393 分、688 則留言。一位自稱在 OpenAI 擔任該次事件指揮官的工程師在討論串留言表示，原因是內部路由錯誤；OpenAI 官方未正式公告，Anthropic 與 xAI 的正式原因官方也未公布。
先交代時間的依據。我們擷取的 Hacker News 討論串頁面只顯示相對時間：主題發文為「1 天前」，該名自稱 OpenAI 工程師的留言為「13 小時前」，該留言稱事故發生於「昨天」。因此只能說事故發生在來源擷取前約一天，本文不把它換算成公曆日期。確切的事故起迄時間戳，本文不替它們代填，讀者得自己去三家狀態頁的事故紀錄查。
當天的事故分別記錄在三家的官方狀態頁：status.openai.com、status.claude.com、status.x.ai。Hacker News 上也各自有獨立討論串：ChatGPT 中斷（已解決）有 315 則留言、Claude 中斷（已解決）有 146 則、Grok 中斷有 142 則。Grok 那則標題沒有「已解決」字樣，是否已恢復請以官方狀態頁為準。
時間順序來自一位留言者的整理，並非官方時間軸：Claude 與 Grok 的中斷分別發生在早上 6 點 23 分與 6 點 30 分左右，但留言者沒有指明哪個時間對應哪一家，何者先何者後官方也未標明；OpenAI 則是 7 點 43 分。留言者未標明時區，我們也不替他補。可以確定的只有一件事：三家在大約一個半小時內先後倒下。
白話解釋一下「路由錯誤」：路由是資料中心裡負責決定「這個請求該送到哪台機器」的那一層。那層出錯，你的請求要不送不到、要不送錯地方，畫面上看到的就是轉圈圈或錯誤訊息。
三家同時掛，是巧合還是共同上游出了問題？
目前唯一有具名帳號出面的說法，來自一位自稱 OpenAI 工程師的 Hacker News 留言：自家基礎設施的路由錯誤。至於是否與其他家有關，這位留言者表示 OpenAI 不評論其他供應商的中斷。這則留言未經獨立查核，OpenAI 官方也未正式公告。Claude 與 Grok 相隔約七分鐘中斷，社群最被接受的推測是兩者共用 xAI 在 Memphis 的算力，但兩家官方都沒有證實。
一位帳號為 OfficialTurkey 的使用者在討論串中自稱是 OpenAI 的基礎設施工程師，並擔任這次事件的「事件指揮官」。他的說法有三點：一，原因是 OpenAI 內部的路由錯誤，影響部分產品；二，與同期發表的 Astra 無關（Astra 是 OpenAI 當時剛推出的新品，來源沒有進一步描述它的內容，我們也不補）；三，OpenAI 不評論其他供應商的中斷。這三點都只是該帳號的自述，本文無法核實他的身分，要確認得看 OpenAI 官方狀態頁的事故紀錄。
「事件指揮官」（Incident Commander）值得多解釋一句。這是資安與維運圈的標準角色，指事故期間負責統籌工作流、拍板決策的那個人，事故結束頭銜就卸下。PagerDuty 的事故應變文件有完整定義。它借用自消防與災難救援的指揮體系，重點在多個單位同時處理一件事時，所有人都知道聽誰的。
關於 Claude 與 Grok 的關聯，留言者 wnmurphy 的推論是這樣：兩家中斷時間只差七分鐘，xAI 提到 Memphis 機房有狀況，而 Anthropic 被認為在該處租用 Colossus 1 的算力，所以兩家可能倒在同一個底層上。OpenAI 晚了一個多小時才出事，更像是獨立事件撞在同一天。這個推論邏輯通順，但截至發稿，Anthropic 與 xAI 都沒有公開確認。
討論串裡也有人猜三家共用某個「不該被知道存在」的上游，甚至扯到情報機構。這些說法沒有任何證據，我們不採用，也建議你不要拿它當決策依據。
對老闆來說，原因其實可以放一邊。已經發生的事實是：三家在同一個早上、一個半小時內都不可用過一次。這件事本身，就是你要處理的風險。
「只綁一家 AI」對中小企業算什麼等級的風險？
跟「只有一家供應商供貨」「只有一位老師傅會修機器」是同一等級的風險。差別在於 AI 斷線沒有預警、你打不進客服、也沒有人賠你損失。
台灣中小企業目前常見的 AI 綁法，大致落在四種流程：客服訊息的初稿或自動回覆、報價與業務信件、行銷文案與社群貼文、工程師的程式碼助手。這四種流程各自綁一家 AI，而且多數公司四種都綁同一家。
平常你不會感覺到這是依賴，因為 AI 服務不會像停電一樣讓你立刻察覺。它比較像全公司的助理同一天請假：事情還是有人做，只是每件事都慢三倍、品質掉一截，而且沒人事先告訴你今天會這樣。
這次事件的另一層意義在「多元化」這個詞被打了折扣。你以為用 Claude 和用 Grok 是兩家不同公司，社群推測顯示它們可能在同一座機房裡。品牌分散，底層未必分散。這一點在下面談備援時會直接影響你的選擇。
這對台灣中小企業意味著什麼？
意味著你該問的問題換了。從「哪家 AI 比較強」，換成「斷線那一刻，我公司哪些流程會跟著停」。這個問題現在就要有答案，而且答案要寫下來、要有人負責。
我們的判斷有四條，每條都可以直接執行。
第一，先盤點依賴，再談備援。花三十分鐘列出公司裡所有「有 AI 參與」的流程，標記每一條停一小時、停一天各會發生什麼事。客戶等不到報價、客服訊息堆積、社群排程開天窗，各自的代價不同，備援的優先順序就照代價排。
第二，多供應商不等於多保險。既然 Claude 與 Grok 這次可能倒在同一個底層，你選第二家 AI 時，要問的是「它跟第一家有沒有共用機房或算力」。官方不說，你就當它可能共用，備援方案裡至少要有一項完全不靠雲端 AI 的選項。
第三，人工接手的 SOP（標準作業流程，白話說就是「出事時誰做什麼」的步驟清單）比技術切換值錢。多數台灣中小企業沒有工程師寫 API（程式介面，讓公司系統直接呼叫 AI 的接口）做自動切換，也不需要。最實際的備援是一張紙：AI 斷線時，客服由誰接、用哪份範本、報價用哪一版模板、誰負責通知客戶會晚回。這張紙寫完並演練過一次，你的抗風險能力已經贏過八成同業。
第四，把「AI 斷線一小時」當成季度演練。消防演練沒人覺得多餘，AI 斷線演練也一樣。每季挑一個下午，全公司關掉 AI 工具一小時，看哪裡卡住。卡住的地方就是下一季要補的備援。
這四件事不用花錢，只花時間。現在就做，不留「視情況考慮」的餘地。
多供應商切換、離線草稿、人工接手，哪一套備援適合我？
多數中小企業應該同時做「人工接手 SOP」加「離線範本庫」，有工程師的公司再加一層 API 多供應商切換。自架模型只適合資安要求高、用量大的少數公司。
下表把常見的五種備援方案放在同一把尺上比較：
| 備援方案 | 適合對象 | 建置成本 | 斷線時能撐什麼 | 主要弱點 |
|---|---|---|---|---|
| API 層多供應商自動切換（由系統程式自動改呼叫第二家） | 有工程師、流程已走 API | 中 | 系統自動改走第二家，使用者無感 | 底層算力可能共用；提示詞要在第二家重測 |
| 第二家帳號手動切換 | 沒工程師、用網頁版 | 低 | 人手動換視窗繼續做 | 對話脈絡帶不過去；沒演練就沒人記得用 |
| 離線範本與草稿庫 | 客服、報價、常用文案 | 低 | 用預存範本先回覆，維持基本服務 | 需定期更新，否則內容過時 |
| 人工接手 SOP（標準作業流程） | 所有公司 | 低，但要寫、要演練 | 人接手，客戶不被晾著 | 沒演練等於沒有；人力尖峰時吃緊 |
| 本地或自架模型 | 資安要求高、用量大 | 高 | 完全不依賴外部服務 | 品質落差、硬體與維護成本、需專人 |
我們建議的順序是：先寫人工接手 SOP，再建離線範本庫，最後才評估技術切換。理由很直接：前兩項一週內能完成、不花錢、不依賴任何供應商，而且這次事件證明「品牌分散」的技術切換未必真的分散了風險。
如果明天 AI 全部斷線，我的公司該照什麼順序動？
先確認範圍，再切人工，最後才想供應商切換。順序反過來，你會花半小時在猜原因，客戶那邊已經開始等。
- 確認是對方掛還是自己掛。 開三家狀態頁：status.openai.com、status.claude.com、status.x.ai。有標示事故就往下走，沒有就先查自家網路與帳號額度。
- 啟動人工接手。 客服改由人回覆，用範本庫的預存回覆；報價用上一版模板手動填；社群貼文若有排程，改用前一週備妥的備稿。
- 主動通知會受影響的客戶。 一句話就好：今天回覆會比平常慢，預計何時恢復。客戶等得起延遲，等不起沒消息。
- 事後補記。 這次哪些流程停了、停多久、有沒有訂單或客訴因此發生。這份紀錄就是下一次備援的優先清單。
- 平時每季演練一次。 全公司關掉 AI 一小時，把卡住的地方寫進 SOP。
這次的中斷，ChatGPT 與 Claude 的討論串在我們擷取來源時已標為已解決；Grok 的來源沒有這個標示。恢復得快，很容易讓人覺得「反正很快就好了」。這個念頭要丟掉。三家同一天倒已經發生過一次，下一次不會事先通知你，也不會挑你不忙的時候。備援是老闆的決定，工程只是執行。決定現在就能下，不用等下一次。
想知道自己公司的 AI 依賴集中到什麼程度，AIRUN 的對抗式創業體檢會把「AI 斷線那一刻你會停在哪裡」當成第一刀：https://mingnow.airun.tw。
常見問題
這次 AI服務中斷，官方公布的原因是什麼？
目前只有 OpenAI 有具名說法。一位自稱在 OpenAI 擔任該次事件指揮官的工程師在 Hacker News 表示，原因是自家基礎設施內的路由錯誤，影響部分產品，與同期發表的新品 Astra 無關。Anthropic（Claude）與 xAI（Grok）的正式事故原因，截至發稿為止官方未公布，只能看狀態頁。
Claude 和 Grok 同一時間掛掉，是因為共用機房嗎？
這是 Hacker News 上最多人接受的推測，還沒有官方證實。留言者整理出 Claude 與 Grok 相隔約七分鐘先後中斷，並指出 xAI 曾提到 Memphis 機房有狀況，而 Anthropic 被認為在那裡租用算力。兩家公司都沒有公開確認這個關聯，請把它當成待驗證的推論，而非事實。
我只用 ChatGPT 網頁版，沒有接 API，也需要備援嗎？
需要，而且你的備援比工程團隊的更簡單。API（程式介面，讓公司系統直接呼叫 AI 的接口）是工程師才會碰的東西；網頁版使用者最實際的備援是三樣東西：第二家 AI 的帳號、一份常用提示詞與回覆範本的本機檔案、一張寫清楚「AI 斷線時誰接手做什麼」的紙本 SOP（標準作業流程）。這三樣加起來不用寫程式，一個下午就能備齊。
多買一家 AI 訂閱，就算有備援了嗎？
只算一半。這次事件顯示不同品牌的 AI 可能共用底層算力或機房，帳號分開不代表底層分開。真正的備援要同時做到兩件事：第二家 AI 的提示詞與範本事先測過可用，以及斷線時有人知道要切換、怎麼切換。沒有演練過的第二帳號，斷線那天多半沒人記得去用。
怎麼知道是 AI 廠商掛掉，還是我公司自己的網路有問題？
先開三家的官方狀態頁：status.openai.com、status.claude.com、status.x.ai。狀態頁有標示事故就是對方的問題，直接啟動人工接手。狀態頁一切正常，才回頭查自己的網路、帳號額度或瀏覽器。把這三個網址存進公司共用書籤，斷線時省下十分鐘的互相猜測。
AIRUN 對抗式創業體檢 AgentFlow Solutions（双云行銷試運行）