「20 分鐘前還在用的」：一句 529 錯誤訊息，是怎麼被設計出來的

先從一個畫面看起。V2EX 的程式員節點上，有人發了一則短短的提問：「Claude 服務是掛了嗎？20 分鐘前還在用的」。沒有截圖，沒有冗長的故障描述，只有一句時間錨點。樓主貼出的訊息原文是：「API Error: 529 Overloaded. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.」

這則貼文在十幾個小時內被看了五百多次，沒有人回覆。一個服務掛了，使用者的第一反應竟然是去問一個論壇，而不是去看官方狀態頁。這個行為本身就值得從介面設計的角度拆開來看：當一個 AI 服務中斷時，使用者實際接觸到的那些文字、數字、網址，是被誰、按什麼邏輯設計出來的。

529 這個數字，先被選定了

HTTP 狀態碼裡，5xx 開頭代表伺服器端的問題。常見的 500 是泛用的內部錯誤，503 是服務不可用，529 則相對少見，在主流規範裡它並非標準碼，而是被 Anthropic 用來表示「overloaded」，服務過載。這個選擇本身就有設計意圖：如果用 503，使用者會理解為「伺服器掛了」；用 529，搭配 Overloaded 這個詞，傳達的是「服務還活著，只是太忙了」。

措辭的下一句更值得注意：「This is a server-side issue, usually temporary」。這兩句話做了兩件事：先把責任劃清楚（問題在伺服器端，你的程式碼沒有寫錯），再給出時間預期（通常是暫時的）。對開發者來說，這是錯誤訊息設計裡最核心的兩個資訊：誰的責任，以及要等多久。很多產品的錯誤訊息只做到第一件事，把使用者丟在「那我現在該怎麼辦」的懸空狀態。

然後是那句「try again in a moment」。它沒有給出具體秒數，也沒有附上重試按鈕，只是一個口語化的時間承諾。相較之下，一些服務會在 429（請求過多）的回應裡附上 Retry-After 標頭，明確告訴客戶端要等幾秒。529 沒有這個機制，於是「一會兒」變成了一個需要使用者自行詮釋的模糊區間。樓主那句「20 分鐘前還在用的」，某種程度上就是在用自己的時間經驗，去填補這個模糊區間：二十分鐘前是好的，現在壞了，這算不算「usually temporary」？

狀態頁網址，被放在訊息的最尾端

整則錯誤訊息的最後一句是：「If it persists, check https://status.claude.com」。把狀態頁網址放在最後、且加上「如果持續發生」的條件句，這個排序本身就是一種介面取捨。

它的邏輯是：絕大多數 529 會在幾次重試內消失，使用者不需要離開當下的工作流程；只有持續失敗的人，才值得被引導到狀態頁。這對輕度中斷是合理的設計，但對重度中斷就會出現裂縫：當整個服務大面積過載時，每個收到 529 的使用者都會「持續失敗」，於是所有人都在同一時間被導向同一個網址。狀態頁在這個瞬間承擔的，是整個產品信任的出口。

而 V2EX 這則貼文的存在，說明了另一個現實：多數使用者並沒有記住 status.claude.com 這個網址。狀態頁作為一個獨立域名，本質上是為「已經知道要去哪裡找答案的人」設計的。不知道的人，會走向搜尋引擎、走向社羣、走向同溫層裡的其他使用者。發問者用「20 分鐘前還在用的」這個句式，其實是在向社羣發出一個對時請求：有沒有人的時間線跟我對得上？這種求助模式在各大開發者社羣反覆出現，它反映的是錯誤訊息與人之間，還缺一層主動的、可見的溝通介面。

這種「訊息本身能不能被信賴」的課題，在數位產品裡反覆出現。先前我們觀察過Anthropic 為 Claude 文本加上又迅速被拆掉的水印，同一家公司的另一個設計決策，同樣碰上「設計意圖與使用者行動之間的落差」。水印在五小時內被破解，狀態頁在幾百次瀏覽裡沒有被記得，兩件事指向同一個問題：設計者預設的使用路徑，和使用者實際走的路徑，中間隔著一段需要被設計卻常常沒被設計的距離。

一個沒有回覆的討論串，說明了什麼

這則貼文最後的狀態是：522 次瀏覽，零則回覆。這個數字組合值得多看一眼。

522 次瀏覽代表有五百多個人曾經搜尋或滑到這個問題，他們很可能也在經歷同樣的 529。零回覆則可能有幾種解釋：問題太短暫，等不到有人回覆就自己恢復了；或者每個點進來的人都只是想確認「是不是大家都掛了」，看到沒人說掛，便默默離開。這是一種很當代的求助行為：提問者要的往往不是答案，而是確認自己位於一條共享的故障時間線上。

對比另一種極端：當大型服務中斷時，GitHub、Cloudflare 這類公司的狀態頁會即時更新元件列表、事故時間軸、更新頻率承諾，甚至有專門的工程師寫事後報告。狀態頁在那裡是一個被當作產品來經營的介面。而對多數 AI 服務的使用者來說，狀態頁還是一個「出事才會第一次造訪」的地方，它的資訊架構、更新節奏、歷史紀錄的可讀性，決定了使用者在焦慮的三十秒裡能得到多少確定性。

529 的「usually temporary」在統計上大概是真的，但在使用者的主觀時間裡，等待沒有長短，只有「還能不能用」。一句口語化的安撫，換成論壇上「是不是掛了」的提問，這中間的落差，就是介面還沒有走完的最後一哩。

收在一個具體的觀點上

回到那一則錯誤訊息。它其實寫得不算差：責任歸屬清楚、語氣平和、提供了下一步的出口。問題在於它的出口是線性的，先重試、再持續、才去狀態頁，而使用者的焦慮是非線性的，二十分鐘前還在用的東西，現在不能用，這個斷裂感不會按照訊息裡排好的順序發生。

一個服務的可靠性，最終是由它最糟的那幾分鐘定義的。在那幾分鐘裡，使用者握住的只有一行文字和一個網址。這行文字被寫得多誠實、這個網址被記得多牢固，決定了「掛了」這件事從技術事件變成情緒事件的距離。Claude 的 529 訊息把前者做得不錯，後者則交給了運氣，以及像 V2EX 這樣，一羣互不相識的人用「我這邊也掛了」互相校時的地方。