OpenRouter崩了3次后，我堆了3層防火墻

去年Q3，Lovai的翻譯功能掛了47分鐘。不是模型翻得爛，是三個反引號把整件事搞砸了。

用戶刷著日料帖子，突然滿屏空白。監控報警炸鍋，根因定位花了11分鐘——模型"貼心"地給JSON包了一層Markdown代碼圍欄。```json開頭，```結尾。JSON.parse()當場窒息，整個翻譯鏈路陪葬。

這事發生在OpenRouter上。我用它跑日英雙向翻譯，處理用戶生成的菜譜標題、摘要和多段正文。生產環境跑了大半年，第一次真正理解什么叫"結構化輸出"的脆弱性。

本文按故障發生順序，還原我堆的三層防御。JSON格式問題是主戰場，重試降級和語言檢測順帶提，但工程時間大頭全花在讓JSON不崩上。

第一層：response_format是底線，不是可選項

最初實現根本沒開JSON Mode。系統提示寫得很隨意："請返回JSON格式"。沒加response_format參數，純靠模型自覺。

這事在輕負載時跑得挺順。直到某天模型靜默更新，或者OpenRouter流量洪峰觸發了某種行為漂移——沒人知道具體是哪邊變的——響應突然開始帶代碼圍欄。

實際返回長這樣：

```json
{"__title": "Built Translation with OpenRouter"}
```

前端拿到這串東西，JSON.parse()直接拋異常。用戶看到空白塊，以為是翻譯失敗，其實是解析失敗。質量差還能忍，功能下線忍不了。

修復第一步：強制加response_format: { type: 'json_object' }。這行代碼約束模型輸出合法JSON，去掉Markdown包裝。OpenRouter文檔里寫得明白，但不是所有模型都支持，得去模型詳情頁查兼容性矩陣。

關鍵認知：生產環境跑LLM輸出進JSON.parse()，不開json_object或json_schema等于裸奔。提示詞指令會在模型更新或服務負載變化時無聲斷裂，你甚至收不到告警。

第二層：response-healing是補丁，不是萬能藥

開了JSON Mode之后，我以為高枕無憂。兩周后又崩了一次，這次是被max_tokens截斷的半截JSON。

OpenRouter有個叫response-healing的插件，自動修復格式問題。接入方式很直白：

plugins: [{ id: 'response-healing' }]

它和json_object/json_schema疊加使用，能處理不少邊緣情況。但文檔里埋了兩個限制：只支持非流式響應，且修不了token上限導致的截斷。

第二次故障就是踩了第二個坑。用戶發了一篇超長菜譜，正文拆成6個block，模型翻完第4個就撞墻了。返回的JSON缺了右大括號和后半截數組，response-healing搖頭說修不了。

這個插件是保險絲，不是發電機。它能兜住格式漂移，兜不住資源硬限制。我后來給長內容加了分段策略，但那是另一個話題。

第三層：應用層解析器是最后一張底牌

即便疊了JSON Mode和response-healing，我還是在應用層留了防御性解析器。代碼不復雜，但邏輯很硬：

遇到不完整或畸形數據，直接拒絕，不進業務邏輯。不嘗試"智能修復"，不猜用戶意圖，不返回半成品。失敗就觸發降級流程，走備用模型或標記人工復核。

這個設計來自第三次驚嚇。某次OpenRouter的API響應頭里Content-Type是對的，但body里混進了調試日志的HTML片段。概率極低，但一旦發生，沒有這層過濾就會污染數據庫。

三層防御的優先級很明確：協議層約束（response_format）→ 服務層修復（response-healing）→ 應用層熔斷（自定義解析器）。越往上成本越低，越往下兜底能力越強。

整個系統現在跑在日英雙向翻譯上，日均處理1.2萬條用戶內容。JSON解析失敗率從早期的3.7%壓到0.02%，剩下的全是模型不支持結構化輸出的邊緣機型，正在逐步下線。

最后留個細節：response-healing的修復日志默認不開，得在OpenRouter dashboard里手動啟用審計。我第一次排查故障時，花了20分鐘才發現這個開關?，F在它是我檢查列表的第二項，排在"確認模型支持JSON Mode"之后。

你的生產環境里，LLM輸出進解析器之前，有幾層過濾？