Case 01 · 1.Talk AI Agent
Designing an AI assistant clinics could trust, control, and safely use in daily patient communication
讓診所敢把第一線對話交給 AI
我設計了 1.Talk AI Agent 的產品體驗與 AI 行為系統,讓診所能安全承接大量病患訊息,同時在高風險情境保留真人控制權。產品從 2025 年 5 月的測試功能成長為公司主力產品;截至 2026/01,已有約 44 家診所開通,高用量診所近 7 天 AI 回覆準確率達 87.7%–94.1%。
成果
- 從 2025 年 5 月的測試功能,成長為公司主力產品,服務台灣與日本診所
- 截至 2026/01,約 44 家診所開通,且逐月加速(11 月 3 家 → 12 月 11 家 → 1 月 10 家)
- 高用量診所近 7 天 AI 回覆準確率 87.7%–94.1%
- 成功案例診所導入前:櫃檯每日需花 2–3 小時處理訊息,同時應對 500+ 對話。用戶導入後:AI 過濾 80% 以上重複性訊息,平均每日承接 80+ 則訊息、協助 35+ 位患者、節省 120+ 分鐘
- Role
- 唯一產品設計師,負責使用者研究、AI 行為規則設計、產品介面設計,以及 AI 測試管理系統的結構與流程設計
- Team
- PM ×1、QA ×1、前端 ×1、後端 ×2、設計師 ×1(我)
- Timeline
- 2025/05 – 進行中(數據截至 2026/01)
- 方法一句
- 把 AI chatbot 從自動回覆工具,設計成可控、可接手、可測試的診所工作流系統

1ContextLINE 已經是診所的半自動入口
在做 1.Talk AI Agent 之前,我們訪談了一間已使用舊版線上預約的診所。診所已透過 LINE(台灣與日本常用的通訊軟體)Rich Menu 提供預約入口,體感約一半病患會從 LINE 開始預約。
但線上入口不代表流程已經自動化。很多病患會先在 LINE 詢問、確認狀況,再請櫃檯協助安排。對診所來說,LINE 已經是半自動入口:前段像自助,最後一步仍仰賴真人。
這也讓我看到一個重要問題:LINE 裡的訊息不是同一種難度。有些是高頻、標準化問題,例如門診時間、地址、預約方式;有些則需要真人判斷,例如自費療程排診、床位安排、健保規則、客訴或 VIP 客戶對話。
這讓我意識到,LINE 不是單純的客服入口,而是一個混合了查詢、預約、判斷與風險處理的工作入口。

2InsightAI 的價值不在回答更多,而在判斷每一種對話該怎麼處理
從訪談和後續 AI Agent 需求討論裡,我們發現診所真正擔心的不是 AI 會不會聊天,而是它能不能判斷每一種對話該怎麼處理。
門診時間、地址、預約方式這類高頻問題,可以由 AI 先承接;但自費療程排診、床位安排、健保規則、投訴或 VIP 客戶對話,就不能讓 AI 自由發揮。
也因此,診所要的不是一個 FAQ bot,而是一個能穩定分類、正確回覆、控制風險,並在不確定時交回真人的系統。
這個 insight 讓設計問題變得很清楚:AI 不能只會回答,它必須知道什麼時候該回、該停、該引導,或該請真人接手。

3Design challenge讓 AI 可以被信任地進入真人工作流
要讓診所願意把第一線對話交給 AI,我需要解決三個設計挑戰:
- 資訊不能錯:門診時間、醫師姓名、費用與療程資訊不能編造,也不能模糊帶過。
- 能力不能假裝有:AI 不能承諾它做不到的事,例如「我會轉達」「會安排專人回覆」「會保證處理」。
- 診所要能拿回控制權:不同診所有不同工作模式,有人想全天開,有人只想下診後開,也有人只想讓 AI 處理初診或預約問題。
4Strategy把信任拆成一套產品系統
因為問題不是單一畫面或單一功能,我把解法拆成四個部分:
- 定義 AI 邊界:先說清楚 AI 能說什麼、不能說什麼。
- 建立人機交接:讓診所能暫停 AI、切回真人、處理高風險對話。
- 建立測試閉環:把 AI 每次可能不同的回答,變成可以重測、追蹤、修正的案例。
- 轉譯使用價值:把 Prompt、視覺身份與成果數據,轉成診所和病患看得懂的語言。
這四件事串起來,才讓 AI 從「會回答」變成「可以被診所放心使用」。

5Solution 1先定義 AI 能說什麼、不能說什麼
第一層信任,是先管住 AI。
我主筆了 AI 初版行為規格書(Global Prompt),核心原則只有一句:寧可少說,不可說錯。
這個原則落在幾個具體規則裡:
- 不編造:電話、網址、醫師姓名、營業時間,查得到才說,查不到就明說查不到
- 資訊零容錯:醫師姓名、門診時間、療程資訊不能猜,也不能用相近資訊代替
- 不假承諾:不能說「我會幫您轉接」「會安排專人回覆」,因為系統當時沒有主動通報診所端的能力
- 高風險情境要收斂:重大投訴、醫療爭議、情緒強烈的對話,優先道歉、提供診所電話,必要時導向真人或外部協助

案例 A:門診時間零容錯
訪談中,診所提到門診表其實已經放在 LINE 選單裡,但病患仍反覆詢問特定醫師的門診時間。對櫃檯來說,這是重複問題;對 AI 來說,卻是不能答錯的高風險資訊。
所以我把這個痛點寫進 AI 行為規格:醫師姓名必須與資料庫逐字一致、查不到就明說查不到、不得編造門診資訊。後續在測試資料庫裡,「診療時間查詢」也成為每間診所都要驗證的測試項目。
一個第一線的重複問題,變成一條 AI 規則,再變成可重複驗證的測試案例。這條追溯鏈就是這個產品的做事方法。
案例 B:高風險投訴不能假承諾
另一次測試中,AI 面對一位遭遇騷擾的病患時,回覆「會將情況轉達給診所」。語氣看起來貼心,但問題是:系統其實沒有這個功能。
這類回覆不是語氣問題,而是能力邊界問題。第一版我先在 Global Prompt 裡收斂 AI 的說法:不承諾轉達、不建立內部通報假象;面對重大投訴時,先承接情緒、道歉,並提供診所電話。
這次判斷也讓我更確定:不是所有問題都該用更好的話術解決;有些問題需要被推進成產品機制。
6Solution 2控制權不是一個開關,而是一組工作流選擇
AI 上線後,診所每天都會遇到需要人工判斷的對話。只讓診所完成設定還不夠;他們還需要在任何時候都能暫停 AI、切回真人處理。

因此,我沒有把控制權設計成單一開關,而是拆成三層:
- 全域開關:必要時一鍵停止所有自動回覆。
- 單一聊天室開關:針對特定對話關閉 AI,覆蓋全域設定,且記憶先前狀態。
- 真人接手訊號:當 AI 判斷需要真人協助時,聊天室會顯示「真人招手」的 emoji 動態,讓櫃檯知道這段對話需要接手。
真人接手必須直接出現在櫃檯的工作現場,而不是另開一個系統,因為櫃檯沒有時間切畫面。
上線後的真實使用也印證了這層設計:有診所日常營業就開著 AI,讓櫃檯在人工與 AI 之間切換;也有診所選擇「下診才開啟」,讓 AI 承接休假時段的訊息,隔天再由櫃檯接續處理。後續訪談也出現更細的需求,例如希望 AI 只回覆初診或預約相關病患,避免影響 VIP 客戶體驗。
這些回饋讓我們更確定:AI 的控制權不該只有開或關,而要能對應診所真實的分時段、分情境工作流。訪談中診所也明確說,自費療程因為床位和醫師現場判斷,必須人工排診。所以我們沒有追求「全自動」:human-in-the-loop 是設計,不是妥協。

7Solution 3把 AI 行為變成可重測的 QA 系統
有了邊界與控制權,下一個問題是:我們怎麼知道 AI 真的照規則運作?
傳統 QA 測「按下按鈕會不會壞」;AI 產品的測試是「它在這個情境會不會說出不該說的話」,而且每次回答都可能不同。
我設計了一套測試管理系統的結構與流程,與 QA 協作運營,把分散在對話、截圖、文件裡的測試回饋收斂成結構化資料庫。系統記錄測試情境、預期與實際結果、失敗原因、優先級、負責人與重測狀態,讓團隊能追蹤每個案例從 Failed 到 Pass 的修正過程。
測試分類包含身份認同、服務範圍、語氣風格、回覆規則、情境判斷、工具使用、邊界情況與安全性。實際攔下的問題包括:多輪對話中 AI 助理身份漂移(P1)、資料庫衝突時輸出系統符號、回覆風格三種語氣的呈現不符預期,以及 RAG 回覆資料正確性需要獨立驗證。
測試不再是一次性的驗收,而是這個非確定性產品持續校正的機制。
8Adoption把 Prompt、視覺與成果轉成診所看得懂的語言
當 AI 的邊界、控制權和測試機制都建立後,下一個問題是:診所和病患要如何建立使用信心?我的做法不是讓使用者理解 AI 技術,而是把它轉譯成他們看得懂、用得上的語言。
首先是 Prompt 設定的轉譯。早期測試發現,診所會混淆「知識庫」和「提示詞」:前者決定 AI 有什麼資料可以答,後者決定它怎麼答、何時轉真人。這不是使用者的錯,而是概念本身就太工程。因此我把 prompt engineering 拆成診所熟悉的設定:助理名稱與歡迎詞定義身份,回覆風格讓語氣可被選擇,AI 提示詞補充診所希望 AI 遵守的規則,而「更新知識庫」則獨立處理資料更新。對診所來說,這不是在設定 prompt,而是在教一位新櫃檯:它叫什麼、怎麼說話、知道哪些事、遇到不確定時該怎麼停下來。
其次是 視覺身份的轉譯。初期我們討論過是否要讓 AI 助理直接使用各診所的 logo,但我選擇先讓病患辨識「這是一位 AI 助理」,而不是把它完全包裝成診所本人。因為產品初期仍在校正,清楚的 AI 身份能降低誤解,也讓病患對偶發的不完整回覆有更高容錯。
在角色形象上,我們一開始延續公司吉祥物「熊」的概念,把它當成 AI 助理的分身;後來和行銷團隊討論後,決定讓 AI Agent 有更獨立的產品意象。後續由另一位設計師接手角色視覺,我協助判斷與收斂:將設計中的 spark 閃光點轉化成眼鏡反光,既保留 AI 的智慧感,也暗示「博學、多聞、能協助判斷」的角色特質。當熊的意象被進一步簡化,整體角色也從可愛吉祥物,變成更精準的產品代表。
此外,診所也已經可以自行替換角色圖像,讓 AI 助理在保有清楚身份的前提下,仍能銜接各診所自己的品牌視覺。


最後是 成果數據的轉譯。Extension 打開的第一眼不是設定細節,而是 AI 已經帶來的價值:它自動回覆了多少訊息、協助了多少位患者,以及大約節省了多少人工回覆時間。
我刻意不用「訊息量」作為唯一主指標,因為診所真正關心的不是 AI 有多活躍,而是它是否真的減少櫃檯負擔。因此我把 AI 的活動翻譯成診所熟悉的營運語言:
- 協助了幾位患者
- 回覆了幾則訊息
- 節省了多少人工回覆時間
這讓「要不要繼續開著 AI」從一個感覺問題,變成一個能用營運效益判斷的決定。

9Outcome從測試功能到主力產品
1.Talk AI Agent 從 2025 年 5 月的測試功能,成長為公司主力產品。
- 診所開通
- 44 家
- 到 2026 年 1 月,已有約 44 家診所開通,且逐月加速。
- AI 回覆準確率
- 87.7%–94.1%
- 高用量診所近 7 天 AI 回覆準確率達 87.7%–94.1%。
- 每日節省人工回覆時間
- 120+ 分鐘
- 成功案例診所導入後,AI 過濾 80% 以上重複性訊息,平均每日承接 80+ 則訊息、協助 35+ 位患者,並節省 120+ 分鐘人工回覆時間。
更重要的是,這個產品讓團隊建立了一套可以持續擴充的 AI 導入方法:先定義行為邊界,再讓診所保有控制權,最後用測試和數據持續校正。 這套方法後續也成為日本診所導入時的基礎,讓團隊能用同一套行為規格、測試情境與風險邊界,對齊不同醫療市場的使用需求。
10Reflection從回答問題,到協助完成任務
這個專案讓我重新理解 AI 產品的設計範圍。AI Agent 的設計不只在 UI,也在規則、測試、失敗處理和人機交接這些「看不見的產品介面」裡。
1. AI 的設計也包含「它不該做什麼」
真正影響信任的,不只是 AI 回得多自然,而是它能不能在不確定時停下來,不編造、不假承諾。
2. 醫療場景裡,邊界比自動化更重要
有些對話可以標準化,有些必須保留真人判斷。好的 AI 設計不是追求全自動,而是讓 AI 和真人能安全交接。
3. 下一步是從回答走向協助完成
未來 AI 可以先收集資訊、判斷條件,再交由櫃檯確認,或完成低風險任務,逐步成為診所工作流裡可靠的協作者。