醫數行銷 MedaLink
市面上的 AI 客服只做到自動回訊息。這一套還要算出醫師、診間、儀器同時空得出來的時段，還要接手提醒、改約、術後衛教與半年回診召回。兩個人做完，AI 那一半從對話引擎到雲端部署都是我。
- 功能模組
- 7 類 59 項（訊息中心 · 回覆引擎 · 知識庫 · 預約排程 · 資源階段 · CRM · 報表）
- 系統規模
- 173 條 API 路由 · 71 個資料庫 migration · 64,687 行
- 回歸測試
- 63 個對話情境的 eval case，含離線 replay 與線上比對
- 團隊規模
- 2 人，需求到上線
- 上線狀態
- 生產中，每天在診所裡跑
在解什麼問題
我原本以為診所要的是一個回訊息比較快的機器人。後來發現不是——櫃檯一個人接得到的時間，是一個月 720 小時裡的 176 小時；剩下的 544 小時訊息還在進，但沒有人在。廣告費買來的每一則私訊，回得慢就是浪費掉。
而只做「自動回訊息」解不了真正難的那一段：答完問題之後要把人帶進時段，那個時段必須是醫師、助理、診間、儀器同時空得出來的；約完之後還有提醒、改約、取消退位、術後衛教、半年召回。只做前半段的系統，等於把工作從「回訊息」搬到「處理系統丟出來的爛約」。
架構決策
01
療程拆成階段，每個階段各自宣告要佔用哪些資源；四類資源全部空得出來才算可約。
- 沒選的
- 用單一「時長」欄位排時段，像一般的預約系統那樣
- 為什麼
- 一個隱形矯正評估是四個階段共 55 分鐘：X 光要助理、醫師檢查要醫師與診間、3D 口掃要助理與診間與口掃機、術式說明要諮詢師。用單一時長排，系統會排出一個「醫師有空但口掃機被佔用」的時段，然後櫃檯得打電話去改。算不出來的時段，寧可不出現在選項裡。
- 代價
- 排程引擎的複雜度整個上一階，而且每家客戶都得先把資源與階段設定完才能開通。
02
醫療影像、傷口這類敏感照片一律不進模型判讀，強制轉真人。
- 沒選的
- 用視覺模型辨識，至少給一個初步回覆
- 代價
- 圖片辨識的覆蓋率少一塊；匯款截圖、地址、文件仍然判讀。
03
禁答清單擋在生成之前 ——療效保證、比較性用語、術後症狀判斷，AI 一律停手並標記需關注。
- 沒選的
- 讓模型自己判斷該不該回答
- 為什麼
- 醫療廣告的法規責任在醫療機構本身，不在工具。把「不能講的話」寫成建立診所時依科別預設的關鍵字清單，是可稽核的機制；靠模型自律不是。
- 代價
- 清單要依科別維護，導入時得逐家補齊。
04
推銷與灌水訊息在進入 AI 之前就擋掉，不佔用量。
- 沒選的
- 全部交給 AI 判斷，反正它會回「這不是我能處理的」
- 為什麼
- 客戶付的是每則訊息的 AI 平台費。讓貸款廣告燒客戶的預算，這筆帳在成本試算那頁會直接露餡。
- 代價
- 守門規則本身要維護，誤擋真客戶的風險要靠「連續打擾自動暫停」補。
05
每則訊息做模型分流，但用純決定性訊號決定，不額外呼叫一次 LLM 來決定要用哪個 LLM。
- 沒選的
- 讓一個小模型先讀訊息、判斷難度，再決定要不要升級
- 為什麼
- 分流本身如果要花一次 API 呼叫，就等於每則訊息都多一次延遲與一筆費用 ——而分流的全部目的就是省那筆錢。改用關鍵字加對話階段：命中七類高風險情境 （預約流程、猶豫、術後、客訴、比價追問、未成年、團體人數）就升級，短招呼一律走便宜模型。判斷在毫秒內完成，成本是零。
- 代價
- 關鍵字表要人維護，而且會漏。漏掉的代價是那一回合掉規則，所以升級條件寧可寬鬆 ——誤升級只是貴一點，該升沒升是品牌傷害。
06
模型漂移成簡體時才轉正體，而且保留一份「不要改」的白名單。
- 沒選的
- 所有輸出無條件跑一次簡轉繁
- 為什麼
- 無條件轉換會把本來就正確的正體回覆改壞 ——轉換表對某些詞的「修正」在台灣用語裡是錯的。所以先偵測到簡體才轉，並保護一批會被誤修正的詞。
- 代價
- 偵測本身有偽陰性，混雜簡繁的句子可能漏掉。
07
買斷制，系統與資料都是客戶的，後台可直接匯出 CSV。
- 沒選的
- 訂閱制
08
「我想改…」用決定性關鍵字查表回答，不讓模型去猜使用者想改哪一格。
- 沒選的
- 把使用者的自然語言丟給 LLM，讓它推測該去哪一頁、直接幫他改
- 為什麼
- 整批設定問題的形狀都是同一個：設定寫在看得起來合理、但沒有作用點的地方，失效時零訊號。原本已經有兩道反應式的網（打字時的 lint、存檔後的對帳），但兩道都是「你寫錯了才告訴你」。缺的是前導式那一半 ——使用者從零開始想 「我要讓 AI 先問部位」時，沒有入口告訴他該去哪，他只會打開最熟悉的那個大文字框，再錯一次。所以做成一份單一真相的對照表：每一格真的管什麼、最常被誤放進來的是什麼、使用者會怎麼描述這件事。三個地方（提示落點、設定對帳、後台查找）都引用同一份。分三份寫的話，三個地方遲早各自漂移，同一個問題會拿到三種答案。
- 代價
- 關鍵字要人維護，而且只回答表上有的。換來的是零幻覺 ——一個猜錯位置的答案比沒有答案更糟，因為使用者會照著去改，然後更確信自己改對了。
09
設定衝突的一鍵修正只做機械可逆的那幾種，其餘只報告不給按鈕。
- 沒選的
- 對所有偵測到的衝突都提供修正按鈕
- 為什麼
- 「兩個價格哪個對」「兩個施作間隔哪個對」是客戶才知道的事，系統猜不出來。寧可少一個按鈕，不要一個會改壞資料的按鈕。另外套用前一律重跑一次偵測、比對條目簽章才動手 ——不信任瀏覽器送來的結果。少了這一步，這支端點就是一個「照使用者說的改任何欄位」的萬用寫入 API。
- 代價
- 偵測到的問題裡只有一部分能一鍵解決，其餘還是要人去判斷。報告與修正之間那段人的空閒時間，只被縮短，沒有被消除。
資料怎麼流
- 01
收件
LINE / FB / IG / 官網四個通路的私訊進同一個收件匣。
守門先擋推銷與灌水，不佔 AI 用量。
- 02
回覆
依客戶自己佈建的劇本、知識庫與禁答清單生成回覆；語氣學該客戶自己的對話紀錄。
命中禁答清單就停手，標記需關注並通知櫃檯。
- 03
收斂
問題答清楚之後用二選一問句把人帶進時段；必問欄位由客戶自訂。
- 04
排程
療程拆階段，比對醫師、助理、空間與設備的實際空檔，算得出來的才進選項。
- 05
建檔
寫入 CRM，狀態進入七段流程的第一段。
- 06
跟進
前一天提醒、改約與取消退位、候補遞補、術後衛教、半年回診召回；每個節點可單獨關閉。
- 07
回報
營運儀表板 + 每日固定時間推一張戰報到 LINE 群組。
技術
- React 18
- Vite 6
- GSAP
- Recharts
- Cloudflare Pages Functions
- jose
- LLM Multi-Agent
- 自建模型分流
- 自建輸出淨化層
- Cloudflare D1
- Cloudflare R2
- Cloudflare Pages
- Cloudflare Workers Cron
- Browser Rendering
- Wrangler