工程案例|把 AI 對話接進既有健康服務

已交付的對話子系統,如何整合知識檢索、LINE、管理後台與既有健康計算服務;區分個人責任、協作範圍與仍在開發的平台。

對話子系統已交付 · 整體平台持續開發

這個合作專案要把既有健康服務接入對話介面,讓使用者透過 LINE 或應用程式逐步提供資料,並由系統串接知識與既有計算服務。

案例採匿名呈現;封面為臨時佔位圖,非客戶介面或真實健康資料。

問題:對話只是入口,後面還有完整的服務流程

能回答一句問題,不代表能完成一次服務。對話需要收集資料、引用知識、呼叫既有服務,也需要讓管理者維護文件與檢查對話。

我的責任與協作邊界

我負責對話服務與系統整合,包含 LINE 接入、知識檢索及管理功能。健康計算由既有的獨立服務提供;我串接它,不把該服務的計算邏輯或健康專業內容列為個人研發成果。

系統如何運作

  1. 使用者透過 LINE 或 API 進入同一套對話服務。
  2. 對話流程逐步收集必要資料,依問題使用知識庫檢索。
  3. 需要計算或報告時,呼叫既有健康計算服務。
  4. 管理者透過後台維護文件、設定接入管道與測試對話。

工程決策:把語言互動與業務計算分開

語言模型處理互動,業務服務處理既有計算。這個分工讓資料如何進入計算服務、結果如何回到使用者,都有明確的串接邊界,而不是交由模型自由生成所有結果。

同樣地,LINE 是接入管道,不是整套服務本身;保留 API 接入,讓後續應用可以使用同一套對話能力。

實際交付了什麼?

2026 年 4 月的正式交付文件列有對話子系統原始碼、部署資源、Web 管理後台、LINE 接入與 API 文件。文件也記載系統已部署到指定環境。

這代表對話子系統有明確交付範圍,不代表整體平台已全面完成。目前專案紀錄仍列為開發中,對話模組持續優化;商城、其他平台功能及選配項目不列入本篇已交付成果。

案例能說明什麼,不能說明什麼?

它呈現的是 AI 與既有軟體流程整合的工程經驗,不是醫療效果、診斷能力或模型準確率的證明。未公開客戶名稱、管理介面位址、使用者資料或內部文件。

如果你也有相似需求

可以從目前的服務流程、既有 API、需要人工處理的步驟,以及希望先驗證的一個使用情境開始。先界定整合範圍,再討論實作方式。

討論 AI 對話與流程整合 → 更多工程案例

分享出去

發佈留言

Connect with

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *