OpenRouter 3次崩潰實錄：3層防火墻救了我

2024年3月，我的翻譯功能在2小時內收到847條錯誤通知。不是翻譯質量崩了——是三個反引號把整件事搞砸了。

模型突然開始"貼心"地用 Markdown 代碼塊包裹 JSON 響應。```json 開頭，``` 結尾。前端 parse 直接報錯，用戶看到大片空白。那天我學到第一課：生產(chǎn)環(huán)境跑大語言模型（LLM），最先崩的永遠是格式，不是內容。

這是 Lovai 的實戰(zhàn)記錄——一個 AI 食譜分享平臺的日英互譯系統(tǒng)。用戶生成內容結構復雜：標題、摘要、多段正文。三次事故，三層防御，按時間線展開。

第一層：response_format 是底線，不是保險

最初我沒開 JSON Mode。系統(tǒng)提示里寫"請返回 JSON"，response_format 留空。這招撐了六周，直到模型靜默更新行為。

OpenRouter 的模型頁會標注 structured outputs 兼容性。json_object 和 json_schema 不是全模型支持，但支持的必須開。把 LLM 輸出直接丟進 JSON.parse() 而不加 response_format，等于生產(chǎn)環(huán)境裸奔。

純提示詞指令的問題在于靜默失效——模型更新時、服務高負載時，行為漂移不會有任何預警。我加的 response_format: { type: 'json_object' } 是第一道鎖，強制約束輸出格式。

第二層：response-healing 自動修復，但有盲區(qū)

JSON Mode 上線后，第二次事故來了。模型沒包代碼塊，但 max_tokens 截斷了響應，JSON 結構殘缺。

OpenRouter 有個插件叫 response-healing，開啟后自動修復常見格式錯誤。配置很簡單：plugins 數(shù)組里加 { id: 'response-healing' }，和 json_object 并行工作。

但它有兩個硬約束：非流式響應 only，且修不了截斷問題。token 上限砍掉的結構，神仙也補不回來。我把 max_tokens 從 2048 調到 4096，同時保留 healing 插件——它修小毛病，我防大坑。

第三層：應用層解析器，最后的偏執(zhí)

即使前兩道鎖都開，我仍在應用層保留了防御性解析器。保險邏輯很簡單：遇到部分或畸形數(shù)據(jù)，拒絕而非嘗試修復。

這個設計來自第三次教訓。某次 OpenRouter 的 API 文檔更新，response-healing 的修復規(guī)則微調，導致一批響應被錯誤地二次處理。我的解析器捕獲了異常格式，直接觸發(fā)降級流程——返回原文并標記待人工審核，而不是把臟數(shù)據(jù)喂給下游。

三層防御的本質是不信任：不信任模型行為穩(wěn)定，不信任中間層修復完美，不信任自己的早期假設。

retry 與 fallback：崩了怎么辦

JSON 之外，還有兩個工程問題值得提。retry 策略我做成指數(shù)退避，3 次失敗后切換備用模型。OpenRouter 的多模型路由是優(yōu)勢，但切換時要重新校驗新模型的 structured outputs 兼容性。

language detection 是另一個坑。用戶偶爾用混合語言發(fā)帖，模型對"這段主要是日語還是英語"的判斷會搖擺。我的解法是在提示里加明確指令，同時保留置信度閾值——檢測置信度低于 0.85 時，跳過翻譯直接展示原文。

整個系統(tǒng)的核心指標不是翻譯準確率，是端到端可用率。格式錯誤導致的 feature down，比翻譯生硬嚴重十倍。

現(xiàn)在我的監(jiān)控看板上有三個告警：JSON parse 失敗率、response-healing 觸發(fā)率、人工審核隊列深度。第三個數(shù)字最近從每周 120 條降到了 15 條——不是模型變乖了，是三層防火墻把臟數(shù)據(jù)攔在了用戶看不見的地方。

你生產(chǎn)環(huán)境的 LLM 輸出，現(xiàn)在有幾層保險？