呢啲資料唔足以證明整個行業有一個統一失敗率，但就反映出一個反覆出現嘅模式：助手可以愈講愈似人，日常執行卻未必同樣進步。

點解講得自然，反而令控制變複雜？

舊式語音助手功能有限，但由語音到動作嘅路徑相對簡單。系統辨認到一個指令之後，可以將佢對應到預先定義、經過驗證嘅操作，例如：

setBrightness(device = kitchen, level = 50)

代價係用戶要講得比較「規矩」，要跟較窄嘅指令格式。但好處係系統少啲可能嘅解讀，執行裝置操作嘅方法亦較一致。

以大型語言模型（LLM）為核心嘅助手，就要同時處理更多工作：

1. 推斷用戶真正想做乜；
2. 理解「呢度」、「嗰啲」或者「啲燈」所指嘅對象；
3. 找出正確房間、裝置同功能；
4. 揀啱工具或者 API；
5. 填入有效參數；
6. 考慮裝置目前嘅實際狀態；以及
7. 準確講清楚操作係計劃中、已送出，定係真係成功完成。

任何一個環節出錯，都可能令結果唔啱。助手可能揀錯裝置、搞錯房間、使用裝置唔支援嘅功能、送出無效參數、依賴過時狀態資料，甚至未確認燈光有冇改變，就直接話自己做成功。

有關 LLM 控制智能家居嘅研究，將不確定性、推理延遲及成本、同個人化不足，列為可靠控制裝置嘅主要障礙。研究亦指出，當要求清晰而且有結構時，系統通常表現較好；一旦要靠助手自行補足大段語境，表現就容易轉差。

「理解」同「執行」其實係兩種能力

Amazon 同 Google 所宣傳嘅能力，的確有實際用途。Alexa+ 其中一個設計方向，就係由用戶描述想做嘅事，再配對到相關裝置及功能；Google 則強調 Gemini 可以處理多部分指令、例外情況，以及用戶講到一半改口。

呢啲能力適合用喺：

• 用戶形容想要嘅氣氛，再由助手提出一個燈光場景；
• 唔使喺複雜 App 入面逐頁設定，就咁用語音建立 routine；
• 解釋某個自動化流程會做啲乜；以及
• 將含糊要求整理成一個結構化方案。

但「理解要求」唔等於「準確執行要求」。

「食飯時想間房舒服溫馨啲」可以交畀系統自行判斷；但「將廚房燈調到 50%」就有一個固定結果。前者受惠於靈活嘅語言模型，後者就需要一條狹窄、可驗證嘅控制路徑。

所以，助手有時可以令人驚訝咁處理一大串複雜句子，卻喺一句簡單嘅開燈指令上失手。語言複雜，唔代表實際執行複雜；相反，一個多裝置要求可能只係因為模型啱啱揀中正確工具同參數，而短指令就可能喺辨認裝置或檢查功能時出問題。

慢幾秒，都足以令人覺得唔可靠

可靠性唔只係「最後有冇做啱」。智能家居指令亦要喺合理而且相對穩定嘅時間內回應。一盞燈隔咗好耐先著，或者要用戶重複幾次先有反應，就算最後狀態正確，體驗都會令人覺得失靈。

《The Verge》一篇 Alexa+ 評測指，部分回應最長要等 15 秒；雖然基本燈光及恆溫器操作喺某些情況下會快啲。 另一批關於 Gemini for Home 嘅報道，亦提到更新正集中改善日常指令嘅回應速度及縮短回覆，反映延遲仍然係工程團隊要持續處理嘅問題。

雲端處理、模型選擇、搜尋裝置，以及呼叫工具，全部都可能增加等待時間。結果就係：系統理論上更強，實際上卻未必更可預測。

早期用戶，係咪變相做緊測試員？

軟件持續更新已經十分普遍。對低風險嘅聊天功能而言，邊推出、邊收集數據、邊改善，未必唔合理。但智能家居控制唔同：出錯會直接影響實體裝置同屋企原本運作緊嘅日常流程。

如果更新之後燈光、鬧鐘或者自動化行為改變，用戶感受到嘅唔係聊天機械人介面入面一個錯誤，而係屋企真實環境突然唔按預期運作。

一連串「推出後出現投訴，之後再靠更新修正」嘅情況，唔足以證明廠商刻意推出未完成產品；但就顯示消費者確實喺系統仍然調校緊嘅階段遇到問題。自動化被跳過、routine 失效、回應前後不一，加上持續出現嘅用戶投訴，令「先推出、收集資料、再改善」套模式用喺日常家居控制上，代價顯得特別高。

較安全嘅做法，應該係保留一條可靠嘅確定性控制路徑，先處理固定嘅日常指令，再喺外圍加入生成式 AI 功能。用戶可以享受自然對話，但唔應該失去家居自動化最基本嘅承諾：講出一個已知指令之後，指定裝置就應該即時轉到指定狀態。

最實際出路：混合式架構

解決方法唔係完全將 LLM 踢出智能家居，而係喺最容易造成實際損害嘅位置，限制佢嘅角色。

一個較穩健嘅系統可以先用 LLM 理解語言同制定計劃，再將結果交畀控制層處理，當中包括：

• 以 schema 驗證裝置選擇及參數；
• 為鎖、鬧鐘等敏感操作設定清晰權限；
• 執行前後檢查裝置目前狀態；
• 設置重試機制及清楚嘅錯誤處理；以及
• 分清楚「計劃執行」同「已經完成」，只喺確認後先向用戶報告成功。

一項名為「compiled AI」嘅研究方向，提出由 LLM 喺編譯階段產生可執行嘅程式產物，之後由工作流程系統以確定方式處理分支、工具選擇、重試同錯誤，而唔係每次運行都重新呼叫 LLM。

套原則放入智能家居，即係由模型幫手表達意圖，但唔應該每次都由模型單獨決定會發生咩實體動作。指令愈接近一筆固定嘅裝置交易，執行路徑就愈應該受到限制、方便測試同驗證。

講得叻，唔代表做得穩

Alexa+ 同 Gemini for Home 反映出生成式 AI 一個更廣泛嘅限制：更識講嘢，唔代表更識操作。

評論員測試、用戶回報同科技媒體報道，都指出呢啲助手可以理解更豐富嘅語境、組合更進取嘅要求，卻仍然會喺燈光、調光、鬧鐘同 routine 呢啲基本工作上失手。

未來較可靠嘅智能家居助手，可能唔係純粹由生成式 AI 或傳統自動化其中一方勝出，而係兩者分工：AI 負責令設定同對話更靈活；確定性軟件就負責令最後一個動作準確、夠快，而且可以驗證。

只要呢條界線仲未設計好，一個更識傾偈嘅助手，就有可能聽落更加聰明，實際上卻連屋企最基本嘅工作都做得冇咁穩陣。

呢啲資料唔足以證明整個行業有一個統一失敗率，但就反映出一個反覆出現嘅模式：助手可以愈講愈似人，日常執行卻未必同樣進步。

點解講得自然，反而令控制變複雜？

舊式語音助手功能有限，但由語音到動作嘅路徑相對簡單。系統辨認到一個指令之後，可以將佢對應到預先定義、經過驗證嘅操作，例如：

setBrightness(device = kitchen, level = 50)

代價係用戶要講得比較「規矩」，要跟較窄嘅指令格式。但好處係系統少啲可能嘅解讀，執行裝置操作嘅方法亦較一致。

以大型語言模型（LLM）為核心嘅助手，就要同時處理更多工作：

1. 推斷用戶真正想做乜；
2. 理解「呢度」、「嗰啲」或者「啲燈」所指嘅對象；
3. 找出正確房間、裝置同功能；
4. 揀啱工具或者 API；
5. 填入有效參數；
6. 考慮裝置目前嘅實際狀態；以及
7. 準確講清楚操作係計劃中、已送出，定係真係成功完成。

任何一個環節出錯，都可能令結果唔啱。助手可能揀錯裝置、搞錯房間、使用裝置唔支援嘅功能、送出無效參數、依賴過時狀態資料，甚至未確認燈光有冇改變，就直接話自己做成功。

有關 LLM 控制智能家居嘅研究，將不確定性、推理延遲及成本、同個人化不足，列為可靠控制裝置嘅主要障礙。研究亦指出，當要求清晰而且有結構時，系統通常表現較好；一旦要靠助手自行補足大段語境，表現就容易轉差。

「理解」同「執行」其實係兩種能力

Amazon 同 Google 所宣傳嘅能力，的確有實際用途。Alexa+ 其中一個設計方向，就係由用戶描述想做嘅事，再配對到相關裝置及功能；Google 則強調 Gemini 可以處理多部分指令、例外情況，以及用戶講到一半改口。

呢啲能力適合用喺：

• 用戶形容想要嘅氣氛，再由助手提出一個燈光場景；
• 唔使喺複雜 App 入面逐頁設定，就咁用語音建立 routine；
• 解釋某個自動化流程會做啲乜；以及
• 將含糊要求整理成一個結構化方案。

但「理解要求」唔等於「準確執行要求」。

「食飯時想間房舒服溫馨啲」可以交畀系統自行判斷；但「將廚房燈調到 50%」就有一個固定結果。前者受惠於靈活嘅語言模型，後者就需要一條狹窄、可驗證嘅控制路徑。

所以，助手有時可以令人驚訝咁處理一大串複雜句子，卻喺一句簡單嘅開燈指令上失手。語言複雜，唔代表實際執行複雜；相反，一個多裝置要求可能只係因為模型啱啱揀中正確工具同參數，而短指令就可能喺辨認裝置或檢查功能時出問題。

慢幾秒，都足以令人覺得唔可靠

可靠性唔只係「最後有冇做啱」。智能家居指令亦要喺合理而且相對穩定嘅時間內回應。一盞燈隔咗好耐先著，或者要用戶重複幾次先有反應，就算最後狀態正確，體驗都會令人覺得失靈。

《The Verge》一篇 Alexa+ 評測指，部分回應最長要等 15 秒；雖然基本燈光及恆溫器操作喺某些情況下會快啲。 另一批關於 Gemini for Home 嘅報道，亦提到更新正集中改善日常指令嘅回應速度及縮短回覆，反映延遲仍然係工程團隊要持續處理嘅問題。

雲端處理、模型選擇、搜尋裝置，以及呼叫工具，全部都可能增加等待時間。結果就係：系統理論上更強，實際上卻未必更可預測。

早期用戶，係咪變相做緊測試員？

軟件持續更新已經十分普遍。對低風險嘅聊天功能而言，邊推出、邊收集數據、邊改善，未必唔合理。但智能家居控制唔同：出錯會直接影響實體裝置同屋企原本運作緊嘅日常流程。

如果更新之後燈光、鬧鐘或者自動化行為改變，用戶感受到嘅唔係聊天機械人介面入面一個錯誤，而係屋企真實環境突然唔按預期運作。

一連串「推出後出現投訴，之後再靠更新修正」嘅情況，唔足以證明廠商刻意推出未完成產品；但就顯示消費者確實喺系統仍然調校緊嘅階段遇到問題。自動化被跳過、routine 失效、回應前後不一，加上持續出現嘅用戶投訴，令「先推出、收集資料、再改善」套模式用喺日常家居控制上，代價顯得特別高。

較安全嘅做法，應該係保留一條可靠嘅確定性控制路徑，先處理固定嘅日常指令，再喺外圍加入生成式 AI 功能。用戶可以享受自然對話，但唔應該失去家居自動化最基本嘅承諾：講出一個已知指令之後，指定裝置就應該即時轉到指定狀態。

最實際出路：混合式架構

解決方法唔係完全將 LLM 踢出智能家居，而係喺最容易造成實際損害嘅位置，限制佢嘅角色。

一個較穩健嘅系統可以先用 LLM 理解語言同制定計劃，再將結果交畀控制層處理，當中包括：

• 以 schema 驗證裝置選擇及參數；
• 為鎖、鬧鐘等敏感操作設定清晰權限；
• 執行前後檢查裝置目前狀態；
• 設置重試機制及清楚嘅錯誤處理；以及
• 分清楚「計劃執行」同「已經完成」，只喺確認後先向用戶報告成功。

一項名為「compiled AI」嘅研究方向，提出由 LLM 喺編譯階段產生可執行嘅程式產物，之後由工作流程系統以確定方式處理分支、工具選擇、重試同錯誤，而唔係每次運行都重新呼叫 LLM。

套原則放入智能家居，即係由模型幫手表達意圖，但唔應該每次都由模型單獨決定會發生咩實體動作。指令愈接近一筆固定嘅裝置交易，執行路徑就愈應該受到限制、方便測試同驗證。

講得叻，唔代表做得穩

Alexa+ 同 Gemini for Home 反映出生成式 AI 一個更廣泛嘅限制：更識講嘢，唔代表更識操作。

評論員測試、用戶回報同科技媒體報道，都指出呢啲助手可以理解更豐富嘅語境、組合更進取嘅要求，卻仍然會喺燈光、調光、鬧鐘同 routine 呢啲基本工作上失手。

未來較可靠嘅智能家居助手，可能唔係純粹由生成式 AI 或傳統自動化其中一方勝出，而係兩者分工：AI 負責令設定同對話更靈活；確定性軟件就負責令最後一個動作準確、夠快，而且可以驗證。

只要呢條界線仲未設計好，一個更識傾偈嘅助手，就有可能聽落更加聰明，實際上卻連屋企最基本嘅工作都做得冇咁穩陣。