🔴 這裡⛔ 沒有「AI 回覆率」：merge.ts 會把客人短時間內的多則訊息合併成一次回覆
⇒ 訊息數相除量到的是客人怎麼打字，不是 AI 有沒有出事。用「客人數」口徑看。
⚠️ 已知偏差：真人接手中的客人會被算成「沒被 AI 回到」 ⇒ 要和轉真人件數一起看。
目前狀態：—
—
🔴 按下之後畫面顯示的是重新 select 回來的值，⛔ 不是送出去的值。 回讀值與預期不符會顯示紅字，⛔ 不會假裝成功。
🔴 R-5（覆蓋率）刻意不設——Howl 2026-09-26 決定不設門檻，⛔ 不是漏做。
⚠️ 已知偽紅燈，⛔ 沒有加抑制邏輯：R-2 在清晨「有人傳、AI 還沒回完」那一瞬間會閃； R-6 在網路抖一下或 session 剛過期時會閃。閃一下的成本遠低於漏掉真事故。
這盞燈只反映「本後台」讀不到設定。
AI 那側（line-webhook）是否也讀失敗，本頁看不到——要查 Edge Function log。
怎麼查
Supabase Dashboard → Edge Functions → line-webhook → Logs，搜尋字串：讀 ai_enabled 失敗
命中的那幾行會帶 lastKnown=、年齡ms=、採用= 三個值——採用= 就是那一刻 AI 實際用的開關狀態。
CLI 等價：supabase functions logs line-webhook（見 docs/PHASE0_設定步驟.md 疑難排解段）。
🔴 上面那個搜尋字串必須與 line-webhook/settings.ts 裡 console.error 的第一個參數逐字一致。
改了程式那句話卻沒改這裡（或反過來），照著查就會「查不到」——而查不到長得像「沒發生過」。
載入中…
窗：台灣時間 — 月 1 日 00:00 起
—
呼叫次數 — / calls 合計 —
—
模型：—
token：—
權威數字在 console.anthropic.com 的 Usage 頁；本頁只是早期警示。
🔴 這個數字為什麼一定偏低：
generate() throw 時（額度用罄、429、服務中斷）不會寫 llm_usage。
⚠️ 所以爆掉那天這張卡反而會變平，看起來很省——⛔ 不可拿成本卡判斷有沒有爆，那是 R-4 的工作。claude.ts 重試 throw 時沿用首次結果，第二次呼叫已計費但 usage 取不到；2026-09-29 現查在 claude.ts:219–224）。claude-sonnet-4-6 ＋ 1 小時快取 TTL；換模型或改 TTL 必須同一次改 app_settings 的四個 llm_price_* key，否則本卡會安靜地算錯。