從 Claude 切到 Codex 要多久？真正卡住你的不是帳號，是那份沒寫完的交接

前言

以 UTC 計，7 月 29 日晚間 Claude 出現一次跨全模型的服務事件；隔天 7 月 30 日又來一次橫跨多個模型的錯誤率升高，接著 Opus 4.8 再單獨降級一次。三起。（換算台北時間，這三起其實都落在 7 月 30 日，第一起在清晨。）

這種時候網路上會出現兩種文章：一種是重播當機新聞，一種是列表比較哪一家比較穩、勸你換家。這篇兩種都不是。

廠商可靠度當然值得追究，選供應商的時候該看事故揭露、該看服務水準承諾。但那件事推動起來慢，而且多數使用者影響不了。相對地，「它掛掉的時候我能不能換一家繼續做事」，其中的準備工作有一部分你今天就能開始；至於真的切不切得過去，還是得先驗過帳號、權限與工具鏈。

所以這篇處理後面那個問題，不是因為前面那個不重要，是因為後面那個你動得了。而這個問題有一個很具體的版本：如果現在 Claude 不能用，我改用 Codex 把手上這件事做完，要花多久？ 底下會把決定這個數字的三件事拆開：憑證與環境、記憶與脈絡、工具。第一件通常最好解，第三件決定你的天花板；對我這組工具而言，最吃時間的是中間那件。

不過在談備援之前，得先把一個很多人以為自己知道的東西弄清楚：你查到的那些可用性數字，多半不能直接用。

你查到的當機次數，取決於誰在數

寫這篇之前，我看到一個流傳的說法：某第三方監測服務顯示，Claude 自 2026 年 1 月以來已經當機 155 次。

這個數字夠具體，具體到讓人想直接引用。所以我去抓了官方狀態頁的原始資料，把 status.claude.com 歷史頁面上 2026 年 1 月到 7 月 30 日的每一則事件抓下來逐月計數，結果是 326 次。

超過流傳數字的兩倍。

而且我自己去開那個第三方頁面的時候，它顯示的是 158 次而不是 155。兩個數字我都只是當下看到，無法凍結重現，也無從確認它為什麼會變。所以底下的說明一律以可重算的官方歷史頁 326 起為準。

兩個數字為什麼差一倍？我沒辦法從公開資訊確認。這兩個來源都沒有完整交代自己怎麼計數，所以無論往哪個方向推測，都只是把一個聽起來合理的解釋補上去。我不打算這樣做。

能確定的只有兩件事。第一，同一個服務、同一段期間，兩個公開來源給出的次數可以差一倍以上。第二，其中一個還會隨時變動。

這件事的實際影響是：當你想比較「A 家和 B 家誰比較穩」的時候，你多半是在比較兩家的計數方式與揭露政策，不是比較他們的穩定度。

我原本打算做一張三家並列的可用性比較表，做不出來。原因很具體：

• Claude 的官方狀態頁提供 15 個月的逐事件紀錄，可以完整計數。
• OpenAI 的狀態頁，我這次抓到的五份都只涵蓋 2026 年 5 月到 7 月；更早的資料我沒有取得，所以只能在這個窗口比較。
• Google Cloud 的事件資料來源在我抓取的當下總共只有 4 筆紀錄，其中與 Gemini 相關的只有 1 筆（2026 年 2 月 27 日，Vertex Gemini API，等級標為低）。這份回應沒有交代保留期間或收錄規則，所以我只能說：光憑它無法當成完整歷史使用，不能拿來跟前兩家並列。

把這三個數字並排放進同一張表，會得到一個看起來很有說服力、但完全誤導的結論。所以這裡只做一件在方法上站得住的比較：在 2026 年 5 月到 7 月這個雙方都有資料的區間，各自以官方狀態頁公布的事件計數，Claude 是 142 次，OpenAI 是 96 次（OpenAI 那五份頁面內容重複，已按年月去重）。這個比較的前提是「兩家都以自己選擇公布的事件為準」，它衡量的仍然不是絕對可靠度。

而且「越來越不穩」這個感覺，資料上不太成立

既然抓了 15 個月的資料，順便看一下趨勢。

Claude 官方狀態頁的月度事件數，2025 年 5 月到 12 月是每月平均 30.8 次；2026 年 1 月到 7 月是每月平均 46.6 次（7 月的資料截至 7 月 30 日）。成長超過五成，看起來確實惡化了。

但事件次數只是一半。我另外算了每個月「至少有一起事件處於未解決狀態」的時間總長，也就是把重疊的事件區間合併之後（不合併會嚴重灌水，2 月的事件時間相加是 281.9 小時，但 2 月總共才 672 小時），結果是：2025 年那段期間佔 15.7%，2026 年 1 到 7 月佔 17.1%。

事件次數多了五成，但在這份狀態頁紀錄裡，「至少有一起事件未解決」的時間只多了 1.4 個百分點。 要強調的是這個數字不等於服務不可用時間：多數事件的等級是 minor，而且往往只影響單一模型。就這份紀錄本身來看，變化的主要是形狀：事件變得更碎、更頻繁，單次持續時間變短。

月份分布也值得看一眼。截至 7 月 30 日，7 月有 54 起，是 2026 年的次高——最高的是 2 月的 58 起。而以「該月有多少比例的時間存在未解決事件」來看，7 月是 18.1%，2 月的 37.3% 和 3 月的 31.1% 都明顯更高。

至於 7 月底那幾起為什麼讓人感覺特別嚴重，狀態頁的資料回答不了，因為它沒有使用者所在地或使用時段的資訊。這裡只能說：以事件數與時間聯集來看，7 月不是 2026 年最壞的月份。

（順帶一提，如果你把 status.anthropic.com 加進書籤，現在它會轉址到 status.claude.com。）

講這些不是要幫誰說話。是因為備援策略應該建立在「事件會反覆發生、每次通常持續一小時上下」這個現實上，而不是建立在「某一家快撐不住了、趕快換」這個判斷上。後者會讓你做出錯的準備。

兩種「不能用」，處置完全不同

在講怎麼備援之前，要先分清楚你遇到的是哪一種不可用。它們長得很像，處置卻相反。

第一種是廠商事件。 特徵是狀態頁會亮，而且你完全無法預測。要注意影響範圍不一定是全面的，很多事件只波及部分模型或部分功能，所以「別人能用、我不能用」也可能仍是廠商事件。

第二種是你自己的額度用完。 別人都好好的，只有你被擋。有些訂閱制的 AI 工具設有滾動的用量上限，密集工作幾天就可能在週間某天撞牆。

第二種對我來說比第一種好安排，因為在用量與重置時間看得到的前提下，它是可預測的。但這個前提會隨產品和方案而異，有些方案你根本看不到自己還剩多少。我自己的實際情況就是這樣：Claude Code 的週用量在週一下午撞牆過，撞牆之後當週可能整段停擺，所以真正促使我把備援建起來的不是當機，是額度。

這兩種是我自己遇到最多的兩類，但不是全部：帳號、付款、權限、地區網路、用戶端設定都可能讓你用不了。只是前兩種最常見，也最值得先準備。

備援不是「再辦一個帳號」

多開一個帳號是備援裡最便宜、也最沒有用的部分。

真正決定你切不切得過去的，是切換摩擦：主力停擺的那一刻，你要花多少時間、補多少東西，備援才能接著把事情做完。摩擦如果夠高，備援在名義上存在、在實際上等於沒有——你最後還是會等主力恢復。

摩擦有三層，由淺到深。

第一層：憑證與環境

這層最容易解，也最常被高估。

備援工具要能動，得摸得到你的檔案、你的金鑰、你的部署權限。如果兩個工具跑在同一台電腦上，這層會省掉一大半：它們看得到同一份工作目錄，通常也讀得到同一份 SSH 金鑰與雲端設定。

我自己的組合就是這種關係：Claude Code 和 Codex 跑在同一台 Mac 上，看同一份程式碼、用同一組憑證（兩者的功能差異我在〈Claude Code vs Codex：兩個終端機 AI 助手，你該選哪一個？〉寫過，這篇只談換手）。所以「跑腳本、推 git、部署」這類事情換手幾乎沒有成本。

但別把「同一台機器」當成自動通過。同機器省掉的是檔案與環境同步，不等於備援工具自動拿到同一組帳號、金鑰與部署權限，這些仍然要逐項實測。而如果備援在另一台機器上，還要再加上未提交的分支要先推、憑證要另配、環境差異要處理。

第二層：記憶與脈絡

這層是真正的分水嶺，而且最常被忽略。

備援工具接手時，它不知道你在做什麼。不知道這個專案的部署管線長什麼樣、上次改到哪、哪裡有雷。你會發現它開始從零摸索，去翻你三個月前就解決過的問題，或是用一個你早就否決過的方法。

我踩過這個坑的具體形狀是：明明相關資訊寫過，但備援工具搆不到那份筆記，於是它跑去從零探索雲端設定。問題不在它笨，在交接資訊放在它讀不到的地方。

所以這層的解法有兩個動作：

一是讓兩邊讀同一份筆記。 不要各寫各的：兩份平行筆記可能會漂移，而漂移之後你不會知道哪一份才是對的。做法是讓備援工具的設定檔指向同一份主筆記，而不是複製一份給它。

二是每段重要進度收尾就寫進去，不要等「之後再整理」。 這點聽起來像老生常談，但它的理由很具體：下一刻你就可能撞額度牆換工具了。 「之後再整理」的那個「之後」，很可能已經在備援上場之後。

而且交接筆記要寫的是接手者需要的東西，不是給人看的漂亮摘要：檔案路徑、部署管線怎麼跑、最後一個 commit、還沒做完的事、以及哪裡有雷。

第三層：工具

這層決定了你的備援天花板在哪，而且有一條很硬的界線。

現在的 AI 工具能做事，多半是因為外掛了一堆連接器，用來讀你的網站數據、查廣告後台、抓資料庫。備援工具有沒有同一套，決定了它能接多少活。

就我實際搬過的這一組工具而言，可攜性分成兩類（這是我這組的結果，不是連接器的通則）：

跑在你自己機器上的連接器，我這幾支都順利複製過去了。 它們本質上就是一行啟動指令加幾個環境變數，把設定抄到備援工具的設定檔就好。我這邊的網站分析、搜尋成效、廣告數據都屬於這類。要注意它們仍可能各自依賴帳密或作業系統權限，不是抄了就一定會動。

綁在原廠帳號上、走原廠登入的連接器，我這邊沒能直接搬過去。 這類連接器的定義不在你的機器上，本機找不到可複製的東西。備援工具要用同樣的功能，得逐項確認能不能重新授權，不行就另外找對應的本機版本自己架、或接受這塊缺席。

這條界線很值得先弄清楚，因為它會直接改變你對備援的期待：有些能力不是「設定一下就有」，是「需要另外做一份」。

分級：哪些活真的能無痛切

把三層摩擦套到實際工作上，會得到一個相當不平均的分布。以下是我在同一台機器、共用工作目錄、權限都已驗證過的前提下得到的分級。你的結果會不同，而且能不能接手還取決於腳本完不完整、有沒有未提交的東西、誰負責驗收。請把它當成分層的方式，不是分層的答案。

換手成本最低的，是「讀筆記、跑本機腳本」這類機械性工作。 排程發文、資料抓取、部署、推送程式碼，這些的判斷多半已經寫在腳本裡了。前提是腳本完整、沒有未提交的東西、驗收責任也講清楚；這幾件都成立時，對我來說可以接近無痛地切換。

只能降級使用的，是依賴特定工具鏈的工作。 影音處理、圖像生成、需要特定連接器的數據查詢。備援工具的工具面通常比較薄，不保證有等價物。這類活可以接，但你要接受產出品質或流程長度不一樣。

基本上切不過去的，是風格與品味類的工作。 兩個模型寫出來的東西語感不同，這不是設定問題。如果你的產出有既定的文字風格，換手之後多半要重寫一輪。

四個會讓備援在關鍵時刻失效的陷阱

備援失效通常不是因為備援本身壞掉。以下四個是我實際遇過或事後才想到的。

交接資訊過期。 這是最常見的一種，前面說過了，不重複。判準很簡單：如果你現在被迫換手，備援讀得到的最新進度是哪一天的？如果答案超過一週，你的備援其實還沒建好。

你的備援本來是你的查核者。 這個陷阱比較隱蔽。如果你平常用第二個模型交叉檢查第一個模型的產出（這是很好的習慣），那麼當第一個模型掛掉、第二個模型變成主力的時候，你就同時失去了查核機制。產出還在，但沒有人在檢查它了。這種時候要嘛降低對產出的信任度、要嘛另外找第三方來驗，不能假裝沒事。

筆記回寫是單向的。 我這邊的備援工具讀得到共用筆記，但不會把自己做的事寫回去。所以它接手期間的進度不會自動留下紀錄，用越久漂移越大。這不是致命問題，但你要知道有這件事，並在切回主力時人工補齊。

備援從來沒被真的用過。 沒演練過的備援跟沒有備援的差別，只在你心裡比較安心。而且演練的重點不是「它會不會回答」，是「它接得到脈絡嗎」。讓它從你的筆記出發，把一件真實的小事做完，你會很快發現缺什麼。

一份務實的建置順序

如果你現在要開始建，我建議照這個順序，理由是每一步都能單獨帶來價值，不必全部做完才有用。

第一步，先確認你的兩種不可用長什麼樣。 你的主力工具有沒有用量上限？上限什麼時候重置？官方狀態頁在哪、你有沒有訂閱通知？光是知道「我的問題通常是額度不是當機」，就會讓你把力氣花在對的地方。

第二步，把備援放在同一台機器上。 這一步直接消掉第一層摩擦的大部分。

第三步，讓兩邊讀同一份筆記。 指向同一份，不要複製。這是三步裡投報率最高的。

第四步，挑一條「這週有硬期限」的工作，把它練到能換手。 注意這裡的重點：不要試圖把備援練成全能。 正確的做法是只讓有時間壓力的那條線做到可換手，其他工作容忍延後或降級。想把備援練到跟主力一樣強，成本會高到你根本不會完成，最後變成什麼都沒準備。

第五步，盤一次你的連接器。 哪些是本機的（可以複製）、哪些是綁帳號的（搬不過去）。搬不過去的那些，決定你要另外架、還是接受缺席。

第六步，真的演練一次。 挑一天主力還活著的時候，硬用備援做完一件事。

什麼時候不該建備援

備援有維護成本：設定會過期、筆記要同步、連接器會壞。所以它不是每個人都該做的事。

如果你用 AI 工具是偶爾問問題、沒有交付期限，那服務掛掉的時候休息一下就好，建備援是浪費時間。如果你的工作可以延後一天而沒有任何後果，同理。

備援值得建，是在**「這件事今天一定要交」與「你不能控制服務何時恢復」同時成立**的時候。這兩個條件缺一個，你其實都可以再等等。

給非工程師的一句話

換一家不難，難的是把你正在做的事整包帶過去；所以備援的重點從來不是多辦幾個帳號，而是讓你的工作筆記隨時新鮮到別人接得上——你要準備的不是第二個工具，是一份好的交接。