客訴自動化大腦：讓 AI 在半夜替你讀客訴

這篇在講什麼

餐飲集團最怕的不是客訴，是客訴躺在 Excel 裡沒人看。每天幾十筆顧客留言散在各店回報表裡，等老闆想起來要看，已經是幾週後的事，而且是幾百筆資料攤在眼前，根本看不完。

這篇講我怎麼把「看客訴」這件事完全自動化：從 Excel 進資料夾、AI 讀懂每條客訴、到每天早上自動推一份 LINE 戰報給經理群組。

管線長這樣

[地端客訴 xlsx] ──檔案一進來──▶ [自動轉檔 + 寫入資料庫]
                                        │
                                        ▼
                    [AI 語意分析：讀懂每條客訴的標籤、實體、門店]
                                        │
                                        ▼
              [Streamlit 看板 + 每天 8:10 LINE Flex 戰報推播]

最關鍵的一環是中間那段 AI 語意分析。

為什麼要 AI 來讀客訴

客訴的原始文字長這樣：「肉有腥味」、「出餐遺漏」、「服務生忙到不理人」。

真正有用的不是分類（負評/正評），而是抓到具體的痛點——「雙拼牛發霉」比「餐點品質」有用一百倍。所以 AI 的任務是：讀每一條留言，抽出標籤、實體（哪道菜）、人名、門店，把「這家店最近是不是出餐老是漏」這種趨勢揪出來。

還有一件微妙的事：寬泛詞彙要過濾。「態度」這種詞沒意義——每家店客訴都會提態度，但「服務生忙到不理人」才是行動線索。filter prompt 就是在做這件事。

踩過的一個雷：資料庫被鎖死，前台空白

系統上線後，最常出事的不是 AI，是資料庫鎖定。客訴寫入頻率高，多個進程同時開系統時，DuckDB 會被鎖住，前台直接空白。

處理方式是三層：

啟動前精準清進程——每次啟動先把佔用資料庫的舊進程清掉，單一實例防禦；
WAL 模式——SQLite 開 WAL，寫入和讀取不再互卡；
本地緩衝——寫入失敗時先暫存在記憶體，網頁重整時自動合併，前台使用者完全無感。

教訓：DB 鎖是併發問題，不是邏輯問題。先查誰佔著，不要為了繞鎖去改資料邏輯——那只會把問題變成隱形 bug。

效能：從 5 分鐘到 80 秒

系統每天要處理一份幾萬列的營業報表，完整重建原本要 5 分鐘。後來發現：大部分時間沒有新菜色，根本不需要全部重算。

解法是一個偵測：比較 count.xlsx 有沒有變。沒變 → 跳過重建，0.2 秒啟動；有變 → 只重建一張表（Fast Path），縮到 80 秒內。判斷「什麼時候不必做」，往往比優化「怎麼做得快」更有效。

LINE 戰報：兩顆容易踩的雷

80KB 上限——Flex 卡片打包超過 80KB 會被 LINE 拒收，需要動態打包演算法分頁。
push 額度會爆——LINE 免費方案每月 200 則，全員廣播一次就沒了。客訴戰報推給經理群組剛好，但這個教訓讓我後來的專案（Learning Hub）全部改用「圖文選單切換」這種不計 push 額度的方式。

紀律：這套系統教會我的事

這是我的第一個大型專案，也是「雙環境紀律」的起源：

正式區（生產）與測試區（開發）分開，所有開發都在測試區；
同步正式區前：備份 → 授權 → 驗證；
同一修復連敗 3 次 → 停下來重新審視假設，不要硬剛。

這套紀律後來複製到我所有專案——包括我下一篇要講的：多代理 AI 工作流是怎麼分工的。