昨天，我替 CareCall AI 封存了第一個不會歸零的文字／規則版 MVP。今天準備往語音功能前進，但我沒有立刻開始寫麥克風程式，而是先回答一個更根本的問題：如果語音沒有成功，使用者是否仍能完成關懷？對高齡關懷原型來說，語音的價值是降低閱讀與打字負擔，而不是把原本可運作的文字流程變成新的單點故障。

我把語音入口限定在「文字／語音關懷」頁，而且一次只處理一題。長者或 Demo 展示者按下開始後，瀏覽器取得這一題的語音並轉成文字。逐字稿不會立刻送進分類規則，而是先放進題目下方的文字框。使用者可以檢查辨識結果、修改錯字或補充內容，最後按下「確認這題回答」，文字才會保存成原始回答。這樣可以避免辨識錯誤直接改變個案狀態，也讓語音與既有資料格式保持一致。

正常流程之外，我特別整理了五種失敗情況。瀏覽器不支援語音時，語音按鈕停用，但文字框仍可使用；麥克風權限被拒絕時，系統告訴使用者可以檢查權限或直接打字；沉默、逾時或沒有辨識結果時，空白不能被誤認成否定回答；辨識服務錯誤時，畫面清楚說明這次內容尚未保存；使用者主動取消時，也不會把取消當成未回應，更不會清除其他已確認題目。

今天最重要的設計決定，是讓文字輸入從一開始就存在，而不是等語音失敗後才臨時出現。使用者可以完全不啟用麥克風，也可以在失敗後直接回到同一題繼續輸入。切換方式不會讓前面已完成的回答消失，未確認的逐字稿也不會偷偷進入分類。語音只是可替換的輸入模組，真正穩定的底座仍是 Day 18 封存的文字資料、有限規則與人工接手流程。

這個版本也清楚限制資料範圍：Day 20 預計使用瀏覽器語音轉文字，不串真實電話，不保存音檔，也不宣稱所有瀏覽器都支援。所有測試只能使用虛構內容，語音結果不提供醫療診斷，工作狀態仍只代表處理順序。

設計語音功能時，最吸引人的畫面通常是按下按鈕後成功出現逐字稿。但真正決定產品能不能被信任的，是權限被拒絕、裝置不支援、使用者沒有說話或辨識服務失敗時，流程是否還走得下去。今天沒有新增一個看得見的功能，卻先替明天的實作定義了不能犧牲的安全條件：語音可以失敗，關懷不能因此停止。