我已經使用 Chat AI 將近三年了。無論是解決生活中的疑難雜症，還是面對工作上的大小挑戰，AI已成為我日常中不可或缺的工具。有時候，我甚至會開啟對話模式，讓我的兒子試著和 AI 互動。
身為一名開發者，長時間與這樣的工具接觸，自然會開始思考得更深入。從一個單純的「使用者」，逐漸轉變成一個充滿好奇心的「探索者」。我常常想著：「這麼方便的工具，如果要做一個專屬於我的助理，能針對特定情境給出專業的回應，該如何實作呢？」
最近，公司剛好有一個案子，目標是開發「個人健康專屬 AI Chat」。這算是我第一次真正接觸如何從零開始打造一個專屬 AI 助理，從傳統的意圖驅動設計到直接串接 API 的方式，我都稍微摸索了一遍。也因此決定花點時間深入理解這塊領域。雖然近期工作壓力很大，但我仍希望督促自己完成這次比賽。
目前常見的 AI Chat 設計大致可以分成幾種：
意圖驅動＋流程設計（狀態機）：
先定義意圖／路由、槽位（slot）、表單（form）、流程節點與條件，像是在畫一張 State Machine。路徑明確、可驗證，也能做 A/B 測試。Google 的 Dialogflow CX 就是典型範例，透過「Flow / Route / Intent / Condition」來分支。
LLM 優先（直接串模型）：
利用提示詞讓模型決策，並透過函式呼叫來查資料、下指令或串 API。整個流程不是事先寫死，而是由模型「規劃 → 呼叫工具 → 回填 → 生成」來完成。像 LangChain 的 Agents/Chains 就能看出「固定串接」與「自我規劃」的差別。
混合式（LLM＋RAG＋工具＋守門機制＋必要時回到流程）：
可預期、需要合規的部分交給流程控制；遇到開放式問答或需要外部資料時，交由 LLM Agent + RAG + 函式呼叫來處理；最後再將結果回填到同一條會話中。
依我自己的經驗，前兩種都有嘗試過。意圖＋流程設計在人力成本上相當高；而直接串接 LLM 則能最快「先動起來」。所以我會建議先採取 LLM 優先＋最小護欄 的策略起跑，等流量與問句分佈穩定後，再將高頻場景沉澱到流程或狀態機裡。稍微以幾個面向整理簡易表格如下
| 特性 | 意圖驅動＋流程設計 (狀態機) | LLM 優先 (直接串模型) | 混合式 (流程＋LLM) |
|---|---|---|---|
| 核心比喻 | 照劇本演的演員 | 即興演出的天才 | 掌握全局的導演 |
| 彈性 | 低（路徑寫死，難以應對意外） | 極高（能理解模糊、開放式指令） | 高（在規則內保有彈性） |
| 可預測性 | 高（結果穩定、可控、易測試） | 低（可能產生幻覺或非預期行為） | 中高（關鍵流程可控） |
| 治理複雜度 | 中低（規則清晰，但需維護標註與流程更新） | 中～高（PoC 較低，但商用需強化監控與法遵） | 高（需整合兩套系統，且團隊能力要求高） |
| 優點 | 穩定可靠、法遵友好、易除錯 | 開發速度快、能處理複雜情境 | 兼具穩定與彈性、使用者體驗佳 |
| 缺點 | 開發維護成本高、體驗機械化 | 結果難預測、除錯困難、安全風險 | 整合與治理成本最高、團隊需具跨域能力 |
| 適用場景 | 高合規流程（金融、醫療）、預約/訂單查詢 | 內容創作、知識問答、探索式對話、快速原型 | 智慧客服、知識輔助、需兼顧體驗與法遵的應用 |
這次鐵人賽，我不打算太嚴肅，會用輕鬆的心情來分享我對這個議題的思考與實作嘗試，過程也會帶一些輕鬆的小實作。如果你已經用AI一段時間，
iThome鐵人賽
看影片追技術
看更多
