AI應用的日誌設計：什麼值得記，什麼必須入庫

console.log在生產環境不是日誌——而是可觀測性缺口

在AI應用的開發初期，console.log幾乎是所有人的第一選擇——快速、直觀、無需額外配置。這個習慣在本地調試環境完全可行，但一旦進入生產，它代表的是一個系統性的可觀測性缺口。

console.log 不是生產日誌

在Vercel、AWS Lambda等Serverless環境中，console.log的輸出存在於進程的標準輸出，通常只保留24至72小時，且無法進行結構化查詢與跨時段聚合。當以下情況發生時，你需要的是數據庫記錄：

• 用戶報告某次對話回答出錯，但你無法還原當時的輸入與輸出
• 費用賬單本月異常飆升，但無法定位到哪個功能或哪個用戶群體
• API在特定時段反覆超時，但不知道發生頻率與時間規律

必須入庫的最低字段

時區標準化是常被忽略的細節

若部分字段以UTC存儲、部分以本地時間存儲，跨時段的查詢結果將出現難以察覺的偏差，例如「昨日高峰時段」的統計範圍因時區混亂而錯誤。建議在數據庫層面統一使用+8時區存儲所有時間戳，避免報表計算出錯。

有意義的告警依賴結構化日誌

有了字段清晰的日誌記錄，才能建立有意義的告警規則：

• 單一用戶24小時累計費用超過閾值 → 告警至管理員
• 過去5分鐘429錯誤比例超過設定閾值 → 觸發速率限制告警
• P95響應時間持續超過N秒 → 效能降級告警

這些規則的條件值應存儲為具名常量，而非散落在業務邏輯中的硬編碼數字，否則閾值調整時必須逐一搜索修改。

常見的記錄遺漏

失敗請求往往比成功請求更值得分析，卻是最常被遺漏的記錄對象。另一個常見問題是費用字段在調用時未即時計算，而是依賴事後從API賬單反推——這導致實時費用控制能力缺失，超支往往只有在月底收到賬單時才被發現。

更多AI生產可觀測性的問題，可參閱AI應用的靜默失敗：每個錯誤都必須留下記錄。

小結

AI應用的日誌是運營可觀測性的基礎設施，其設計應在第一版API調用結構確定時同步完成。事後補加字段的成本遠高於設計之初做對。Token費用、模型行為與錯誤模式的可觀測性，直接決定了當問題出現時你能否作出有效診斷，而不是只能盲目猜測。