這些案例無法證明整個產業有一個統一的失敗率,但足以呈現反覆出現的模式:助理的對話能力進步了,日常執行卻仍然不穩定。
早期的語音助理功能有限,但控制流程相對受約束。系統辨識出指令後,通常會對應到已知意圖,再執行預先驗證的操作,例如:
setBrightness(device = kitchen, level = 50)這種做法要求使用者採用較固定的說法,換來的則是較少的解讀空間,以及從語音到裝置動作更可重複的路徑。
採用大型語言模型(LLM)的助理,必須處理更寬廣的任務。它可能要依序完成:
任何一個環節出錯,都可能導致錯誤結果。助理可能選錯裝置、誤解房間指涉、使用裝置不支援的功能、送出無效參數、依賴過時的狀態資訊,甚至在沒有確認裝置變化前就宣稱操作成功。
Amazon 與 Google 所宣傳的功能確實有實用價值。Alexa+ 的設計,是將使用者用口語描述的需求對應到相關裝置與功能;Google 則強調多段指令、例外條件,以及使用者在一句話中途修改要求的能力。
這些能力適合用來:
但理解需求,和實際執行需求,是兩件不同的事。「讓客廳有適合晚餐的溫馨氣氛」可以交給系統自行判斷;「把廚房燈設定為 50%」則有明確且固定的結果。前者需要靈活的模型,後者更需要狹窄、可驗證的控制路徑。
這也解釋了為什麼助理可能把一個複雜句子說得頭頭是道,卻連簡單的開燈指令都做不到。語言複雜,不等於執行複雜;多裝置指令可能只是剛好選對工具與參數,短指令則可能在辨識裝置或確認能力時出錯。
可靠性不只關乎最後有沒有做對,也包括反應時間是否合理。燈光如果隔了很久才亮,或要使用者重複說幾次才有反應,即使最終狀態正確,體驗仍會讓人覺得系統不可靠。
The Verge 對 Alexa+ 的評測發現,部分回答最長需要 15 秒;不過在某些情況下,開燈和調整恆溫器等基本操作可以更快完成。Android Authority 對 Gemini for Home 的報導也提到,相關更新著重於提升回應速度,並縮短日常指令的回答,顯示延遲仍是持續處理中的工程問題。
雲端處理、模型選擇、裝置搜尋與工具呼叫,都可能增加等待時間。結果是:系統理論上更有能力,使用者在當下卻更難預期它何時、以及是否會完成工作。
軟體持續部署已是常態;對風險較低的聊天功能而言,邊推出邊改善或許合理。但智慧家庭控制會影響實體裝置與使用者已建立的生活習慣。當更新導致燈光、鬧鐘或自動化行為改變,使用者面對的是家中真實環境,而不是聊天機器人介面裡的一次錯誤回答。
一再出現「推出後收到抱怨,再發布修正與可靠性更新」的循環,並不能證明業者是刻意把未完成的產品交給消費者。但它確實顯示,使用者正在系統尚未調校完成時承受問題。自動化被跳過、例程失效、回應前後不一致,以及持續出現的使用者抱怨,讓「推出、蒐集資料、再改善」的模式,在日常家庭控制上顯得代價特別高。
較安全的做法,是保留一條可靠的確定性路徑,處理固定的日常指令;生成式 AI 則在這條路徑周邊提供更自然的互動。使用者可以享受口語操作的便利,同時保有家庭自動化最基本的承諾:當我下達已知指令,指定裝置就應該立刻進入指定狀態。
實際可行的方向,不是把 LLM 完全排除在智慧家庭之外,而是在錯誤代價最高的環節限制它的角色。
一套更穩健的系統可以讓 LLM 負責理解語言與規劃,再把結果交給控制層,並由控制層提供:
套用到智慧家庭,原則就是讓模型協助表達意圖,但不要讓它每次都成為決定實體動作的唯一權威。指令越接近固定的裝置交易,執行路徑就越應該受到限制、驗證並方便測試。
Alexa+ 與 Gemini for Home 反映了生成式 AI 的一個更大教訓:更會聊天,不會自動等於更會操作。評論員、使用者與科技媒體的報導顯示,這些助理能理解更豐富的上下文,也能組合更複雜的要求,但在燈光、調光器、鬧鐘與例程等基本工作上仍會失手。
未來真正耐用的智慧家庭助理,很可能必須結合兩種方法:生成式 AI 負責讓設定與對話更靈活;確定性軟體則負責讓最後的裝置動作準確、快速且可驗證。在這道界線被妥善設計之前,更會聊天的助理,可能只是讓人覺得它更聰明,卻在家中最基本、最重要的工作上表現得不如預期。