大家好！歡迎來到這次的 30 天鐵人賽系列~

在生成式 AI 爆發的時代，大語言模型（LLM）的語意理解與推論能力突飛猛進。許多人日常會用 ChatGPT 查資料或寫信，但在嚴謹且高度專業的醫療健康領域，直接拿未經調校的 LLM 來回答醫學問題，往往會面臨兩大核心瓶頸：

1. AI 幻覺：模型可能自信地給出看似合理卻完全錯誤的醫學建議。
2. 缺乏即時醫療資訊：模型無法即時取得醫院的掛號診表、就診進度或個人生理數值。

這 30 天的挑戰，我們將透過目前業界熱門的低代碼（Low-code）工具與國際醫療標準，從零搭建一個兼顧衛教問答、就醫引導與流程自動化的「智慧醫療 Agent」。

為什麼傳統醫療系統需要 AI Agent？

傳統醫療院所的資訊系統（HIS、線上掛號入口網）普遍存在幾個使用痛點：

• 資訊分散且操作繁瑣：民眾身體不適時常不知道該看哪一科，在醫院網站層層點選仍找不到合適診別。
• 衛教內容生硬難讀：衛教資訊多為長篇單張或 PDF，民眾難以快速擷取與自身症狀相關的重點。
• 系統封閉且整合不易：各院區格式不一，缺乏標準化介面，讓外部服務串接門檻極高。

AI Agent 的核心價值：
具備「感知」、「推論」與「執行工具」的能力。它能聽懂民眾口語化的描述（例如：「我頭痛好幾天，眼睛周圍脹脹的」），自動推薦就醫科別，並進一步調用後端 API 查詢即時空位，甚至完成自動化通知。

本系列核心技術拼圖

要完成一個具備實用價值的醫療 Agent，單靠寫 Prompt 是不夠的。本系列將使用四大技術支柱：

• Dify（AI 應用開發平台）：負責系統的大腦。提供視覺化 Prompt 編排、RAG 知識庫管理與 Tool 調用機制。
• n8n（流程自動化引擎）：負責系統的「神經與四肢」。透過節點串接 Webhook、資料轉換與第三方 API，扮演黏著各系統的膠水。
• HL7 FHIR（醫療資訊交換標準）：國際通行的次世代醫療資料標準，透過標準 RESTful API 傳輸，確保資料格式不各唱各的調。
• Docker & ngrok（開發環境與通道）：提供容器化部署環境，並透過內網穿透快速與外部 Webhook 或通訊軟體對接。

30 天架構運作流程

整個系統的資料流如下：

1. 使用者端：民眾透過 Line Bot 提出問題或口語化症狀描述。
2. 推論層（Dify Agent）：接收訊息後，先檢索本地醫療知識庫（RAG），並判斷是否需要呼叫外部工具。
3. 自動化整合層（n8n Workflow）：當 Agent 觸發「查詢診表」或「記錄數據」工具，n8n 負責接收參數並進行邏輯處理。
4. 標準資料層（FHIR API）：n8n 與 FHIR Server 互動，讀取或寫入符合標準的醫療資源物件（如 Patient、Observation）。

30 天實作節奏規劃

本系列以手把手實作為主，章節規劃如下：

階段一：開發環境與通訊標準（Day 1 ~ Day 5）

• 建置 Docker 開發環境（Dify / n8n）
• 認識 HL7 FHIR 標準與 Postman 測試

階段二：n8n 自動化流程打底（Day 6 ~ Day 9）

• Webhook 觸發、JSON 資料解析與 API 串接實戰
• 異常處理（Error Handling）與日誌機制

階段三：Dify 醫療 Agent 與 RAG 實作（Day 10 ~ Day 16）

• 醫療 Prompt Engineering 與防幻覺設計
• 醫療衛教知識庫建置（Chunking / Embedding）
• Dify 自訂工具（Custom Tools）串接 n8n

階段四：情境落地與通訊軟體串接（Day 17 ~ Day 22）

• 智慧掛號科別推薦 Agent 實作
• 串接 Line Bot 打造視覺化對話卡片

階段五：資安、維運與總結（Day 23 ~ Day 30）

• Prompt 注入防禦與醫療隱私資料脫敏
• 輕量雲端部署與架構覆盤總結

明天 【Day 2】，我們將直接進入實作環節，使用 docker-compose.yml 在本地端一次跑起 Dify 與 n8n 的開發環境~