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