為什麼一天的人工智慧花費超過一個月的伺服器？
非工程師用Claude Code快速構建了一個AI功能，但由於資料庫列缺失導致確定性失敗，自動重試機制使同一任務重複21次，單日AI成本超過整月伺服器費用。本文分析了重試風暴的原因並總結了教訓。
一位財務總監用Claude Code兩天內構建了一個AI功能，而作為工程師的我接手後，在梳理後端程式碼時發現了一筆驚人的成本：單日AI呼叫費用竟然超過整個伺服器群一個月的開銷。
故事始於一張LLM API費用圖表。大多數日子成本極低，唯有一天像富士山一樣高聳，貢獻了當月近一半的賬單。起初我以為是開發者當天反覆測試功能所致，但深入檢查應用日誌後發現真相完全不同：同一批任務，被機器自動執行了21次。
問題的核心在於任務流程：它依次呼叫多個LLM，然後儲存結果到資料庫。然而，資料庫的某個列尚未新增，儲存步驟因此丟擲“列不存在”錯誤，返回500。諷刺的是，所有LLM呼叫都成功了（200狀態碼），意味著每次呼叫都產生了賬單。相當於吃完大餐付了錢，卻在出門時摔倒失憶，回到座位上重新吃一遍，重複21次。
這種“重試風暴”並非源於臨時網路故障，而是兩個陷阱的組合：第一，部署順序錯誤——先部署了依賴新列的程式碼，後執行資料庫遷移；第二，任務佇列將500錯誤視為可重試的失敗，自動重新執行。由於任務不具備冪等性（不跳過已處理的工作），每次重試都重新開始，導致完整成本反覆產生。
財務總監得知真相後也很震驚：“呼叫成功了，付了錢，然後結果被扔掉？”對於非工程師來說，這確實難以理解。但這件事暴露了更深層的問題：重試不是萬能的善意。確定性失敗（如模式不匹配、4xx類錯誤）不會因重試而解決，必須立刻中止並設定重試上限。帶有高不確定性成本的任務（如LLM呼叫）必須從一開始就實現冪等性。部署順序應遵循“先模式後程式碼”，避免臨時性錯誤。此外，如果沒有成本監控（如獨立金鑰、預算告警），這類問題只能在收到賬單後才發現。
“氛圍編碼”確實降低了非工程師構建生產系統的門檻，但理解系統如何出錯、如何增加成本仍是另一項技能。兩天可以構建功能，但防止“優雅重試”演變成“丟棄成功結果並重復計費”需要更多時間。重試不總是善意——這次經歷就是最昂貴的教訓。