把 LLM 當備援不當核心：旅行社自動化的克制用法

發表於 2026-07-10 分類於 AI

這一年幫朋友的旅行社業務做了一系列自動化工具，最後發現整套系統裡最重要的設計決策，是「哪裡不要用 LLM」。

前言

朋友在旅行社當業務，日常充滿重複性工作：出團前要一封一封組 LINE 行前通知、客人進線要回覆、報名後要追訂金與合約。我陸續幫忙做了幾個工具：LINE 行前通知產生器、客戶 CRM、客服 LINE bot、還有一堆跑在 n8n 上的自動化流程。

這類需求丟給 2026 年的工程師，直覺反應大概是「全部接 LLM 就好了啊」。但實際落地後我的結論相反：LLM 只放在「可失敗、可降級」的位置，確定性的規則與流程才是主幹。整理出四個實際用到的模式。

模式一：結構化資料優先，LLM 只補缺

行前通知產生器的邏輯是：輸入一個行程代碼 → 向上游系統取回結構化資料（集合時間、航班、領隊、氣候、時差…）→ 按模板組出 LINE 訊息。

LLM（Gemini）只有一個角色：當來源資料缺了時差或氣候欄位時，才被呼叫來補這兩格。而且補位是有保險絲的：

async function getTimezoneGemini(dest, apiKey) {
  if (!apiKey) return '';           // 沒金鑰 → 直接回空字串，不打 API
  try {
    const res = await fetch(url, {
      // ...
      signal: AbortSignal.timeout(3000),  // 3 秒 timeout
    });
    return data.candidates?.[0]?.content?.parts?.[0]?.text?.trim() || '';
  } catch {
    return '';                      // 失敗 → 空字串，主流程照走
  }
}

多數團的資料是齊的，所以 Gemini 多數時候根本不會被呼叫；就算被呼叫且失敗，也只是訊息少一格，業務自己補一句就好。另外「使用者調整欄位後重新組裝文案」的端點是純函式組裝，絕不碰外部 API 也絕不碰 LLM——已經確認過的資料，沒有理由再讓模型有機會改寫它。

模式二：Regex 先行，LLM 補位

另一個場景是把自由文字轉成結構化單據：業務丟一段隨手打的客戶需求，系統要能建出對應的資料。

原則是有明確格式的欄位一律先用 regex 解，解不出來的長尾才交給模型，還缺就回頭問使用者。電話號碼、人數這種東西，regex 一毛錢不花、零延遲、永不幻覺；LLM 只處理「規則寫不完」的部分。

一個小細節：不同入口用各自獨立的 API Key，避免互搶額度——把 LLM 當成一種會塞車的外部資源來管理，而不是無限供應的魔法。

模式三：意圖分類交給輕量模型，流程控制留給狀態機

客服 LINE bot 是最容易寫成「全部丟給 LLM 自由發揮」的地方。我的做法剛好相反：模型在這裡只負責把客人的訊息歸到幾個預先定義好的意圖類別，產出是一個枚舉值，不是自由文字。真正決定「現在走到哪一步、該問什麼、還缺哪些欄位」的，是一台確定性的狀態機，全部由程式碼控制。

這樣切的好處是失敗面積很小：模型答錯頂多是分錯類、走錯一條分支，而不會憑空承諾客人一個不存在的行程或價格。

模式四：真人審核後才推播

這是全系統最硬的一條紅線：排程與監控類的自動流程，一律不得直接對客人 LINE 推播。各種到期與狀態提醒偵測到條件成立時，做的事情是——先發一張卡片到業務的內部通訊軟體，附上客戶頁連結和「預計要發的 LINE 文案」，業務看過按下送出，訊息才會真的出去。

CRM 的手動推播也有 preview dry-run 模式：先組好文案回傳給前端讓業務確認，這一步不 push、不寫資料庫。

自動化省掉的是「組文案、盯條件」的時間，「要不要發、發什麼」的決定權永遠留在人身上。對面是付了幾萬塊團費的真實客人，這條線不能省。

冪等與防重複：自動化的隱形地基

跟 LLM 無關但同樣重要的一課：只要流程會被自動觸發，就要假設它一定會被重複觸發。系統裡實際用到的手段：

去重視窗：建立單據前，先查一段時間內有沒有內容相同的單，命中就短路回傳既有的那筆——serverless 有 timeout，回應丟失後使用者重按一次是常態
一次性旗標：「已通知」這類事件用一個 timestamp 欄位當 gate，寫過就不再觸發
冷卻時間：提醒類通知設冷卻期；事件驅動的 webhook 入口另設節流閘，cron 排程退居兜底

沒有這層地基，上面接再聰明的模型都只是讓錯誤發生得更快。

結語

回頭看整套系統，LLM 出現的三個位置——補缺欄位、解析長尾文字、意圖分類——共同點是：輸出可以驗證或可以捨棄，失敗時有明確的降級路徑。而金流、推播、狀態流轉這些「錯了會痛」的地方，全部是確定性程式加上真人把關。

把 LLM 當備援不當核心，聽起來很不炫，但這套東西讓一個非工程背景的業務每天安心用到現在。你的專案把 LLM 放在哪一層？歡迎留言交流。

參考資料：