昨天，我先確認了 CareCall AI 想解決的核心問題：照護人員需要花費大量時間逐一關懷高齡者，但長者的回答可能口語、含糊、缺漏，甚至完全沒有回應，使真正需要人工介入的個案不容易被快速找出。
今天，我進一步整理三個彼此相連的問題：CareCall AI 的主要使用者是誰、高齡者應該透過什麼方式與系統互動，以及整套關懷流程實際上應該如何運作。

誰才是 CareCall AI 的主要使用者？

因為這個專案與高齡照護有關，一開始很容易認為高齡者就是主要使用者。但把整個流程拆開後，我發現不同角色需要完成的任務並不相同。
長者主要負責回答關懷問題，例如今天是否按時服藥、是否完成量測、有沒有不舒服，以及是否需要協助。他們不應該被要求登入複雜系統、查看大量資訊，或理解不同的後台狀態。
真正需要查看紀錄、判斷狀況並安排後續處理的人，通常是照護人員、個案管理師或居家照護工作者。他們需要快速知道哪些個案已經完成關懷、哪些人尚未回應、哪些回答缺少資訊，以及哪些個案需要再次聯絡。
因此，我將照護人員設定為 CareCall AI 第一版 Web App 的主要使用者，而長者則是語音或文字關懷的互動對象。
家屬未來可能希望接收摘要或通知，機構主管也可能需要查看整體統計與工作量。不過，如果第一版同時製作家屬端、主管端、多層權限與通知功能，產品範圍會快速膨脹。因此，這些角色暫時不會擁有完整介面。

為什麼選擇語音，而不是再做一個 App？

確定角色分工之後，下一個問題是：長者應該用什麼方式回答？
我比較了 App、LINE Bot、網頁表單和語音／電話四種入口。

App 看起來功能最完整，但對部分高齡者來說，登入帳號、找到功能、查看通知、閱讀文字和填寫表單，本身就可能形成使用門檻。即使 App 的功能設計得很好，只要長者沒有主動打開，整個關懷流程仍然無法開始。
LINE Bot 雖然比獨立 App 更熟悉，但仍需要智慧型手機，也需要使用者查看訊息與輸入回答。網頁表單最容易製作，卻同樣依賴閱讀、打字與主動開啟連結。
相較之下，語音更接近日常溝通方式。長者可以直接說出自己的狀況，不必先整理成正式文字，也不需要理解複雜介面。語音未來也有機會延伸成電話形式，降低對智慧型手機與 App 操作的依賴。
不過，第一版如果直接開發真實電話外撥，還會涉及電話服務、費用、號碼管理、隱私、法規與通訊串接。這些內容可能會讓我把大量時間投入電話技術，反而沒有先驗證 CareCall AI 最重要的關懷流程。
因此，我決定第一版先採用「網頁語音輸入＋文字備援」。使用者可以在網頁中說出回答，由系統轉成文字，再確認或修改內容。若麥克風、瀏覽器或語音辨識失敗，也能直接切換成文字輸入，避免整個流程被中斷。

CareCall AI 實際怎麼運作？

確定角色與入口之後，我開始把 CareCall AI 整理成一條可以操作的流程。
目前的核心流程是：

照護人員查看今日關懷總覽
→ 選擇個案與關懷腳本
→ 長者透過語音或文字回答
→ 系統將語音轉成文字
→ 使用者確認或修改逐字稿
→ 保存原始回答與確認後內容
→ AI 將回答整理成固定欄位
→ 規則引擎分配處理狀態
→ 照護人員查看摘要、原因與下一步
→ 必要時加入人工待辦並保存紀錄
這條流程大致可以分成三個階段。

第一階段：收集回答

第一版會同時保留語音與文字輸入。語音是主要體驗，文字則是備援方法，確保麥克風或辨識功能失敗時，流程仍然可以完成。

第二階段：整理資訊

長者的回答可能非常口語，例如：

「藥有吃啦，血壓還沒量，剛剛站起來有一點暈。」
系統需要先保留原始回答與逐字稿，再由 AI 將內容整理成一致的欄位，例如：

• 是否服藥：是
• 是否完成量測：否
• 不適狀況：站立時頭暈
• 缺漏資訊：持續時間、目前是否仍不舒服
• 建議下一步：人工確認
  AI 在這裡負責的是資訊整理，而不是醫療診斷。它不能直接判斷長者罹患什麼疾病，也不能取代照護人員做出醫療決策。

第三階段：安排工作流程

系統會根據回答是否完整、是否出現需要追問的內容，以及是否完全沒有回應，分配不同的工作流程狀態。
目前規劃的狀態包括：

• 已完成
• 待提醒
• 待人工確認
• 優先處理
  這些狀態代表照護工作的處理順序，不等同於醫療上的病情嚴重程度。最後的確認與處理仍然需要由照護人員完成。

用三種情境檢查流程

為了確認這條流程不是只在紙上看起來合理，我先用三種情境進行檢查。
第一種是正常關懷。長者表示已服藥、已完成量測，也沒有不舒服。系統整理後標記為「已完成」，保存紀錄即可。
第二種是需要人工確認。長者表示有服藥，但尚未量測，而且站起來有點頭暈。系統整理出不適內容與缺漏資訊，並將個案加入「待人工確認」，提醒照護人員再次聯絡。
第三種是未回應。若長者沒有完成回答，系統不能假設對方一定安全，也不能直接判定發生危險，而是先標記為「待提醒」。如果之後仍持續未回應，再進入人工處理清單。

今天確定的設計原則

經過今天的整理，我確定了幾項重要原則：

長者端的操作越少越好，照護端的資訊則必須一眼就能看懂。
CareCall AI 選擇語音，不是因為語音比較新，而是希望降低閱讀、打字與主動開啟 App 的門檻。
AI 負責整理資訊，不負責醫療診斷；系統狀態代表工作流程優先度，不代表病情嚴重程度。
因此，CareCall AI 第一版的定位是：長者透過語音或文字回答關懷問題，系統將回答整理成固定欄位與處理狀態，照護人員再透過 Web App 後台查看結果、處理人工待辦並保存紀錄。
今天最大的進展，是讓 CareCall AI 不再只是一個「語音加 AI」的模糊功能，而是形成一條從回答收集、資訊整理、狀態分配，到人工接手與紀錄保存的完整照護流程。這條流程也會成為後續 Demo、Figma 原型與程式實作的共同基礎。