下一步

我們完成了一個簡單的對話引擎，不過，距離完整的語音助理，還有很多的工作要做。

與 GUI 的整合

接下來自然是要將這個對話引擎，實際應用在一個完整的 Flutter 應用當中，我們可以考慮把我們的語音引擎放在一個 Provider 或是 BLoC 中，放在 Widget Tree 比較上層的位置，讓整個 App 的其他部分可以開始或是結束對話，以及透過監聽語音助理的狀態變化，更新 GUI。

在實務上，我們除了在 GUI 上反應語音助理的狀態，也常常會有複雜的 GUI/VUI 混合的互動流程，比方說，在點餐系統中，當使用者講了「我想點餐」，我們除了用 VUI 反問使用者「您想點些什麼」，進入第二輪對話之外，也可能用一個 System Call，在畫面中跳出一份菜單，除了可以用語音回答之外，也可以用點擊的方式選擇，我們或許也可以設計像「前一個」、「下一個」、「前一頁」、「下一頁」等命令，而這些命令，也都會讓 GUI 因此改動。

在做 GUI/VUI 混合的產品設計時，除了 VUI flow 本身的 Activity Diagram 之外，也需要設計 GUI 的 Wire Frame 或是 Mockup，兩者互相搭配。至於 GUI 開發，則與大多的 Flutter 應用開發過程無異，在這裡不贅述。

更多不同的實作

我們現在使用一些 Flutter 本身提供的 ASR 與 TTS 套件，加上 Gemini API 提供 NLU/NLG 功能，不過，我們不見得想使用這些套件或服務。由於在這個架構中， ASR、TTS、NLU 與 NLG，都是 interface，因此，只要按照這些 interface 實作，都可以替換掉原本的套件。

喚醒（Wake-up）

我們在這裡並沒有提供喚醒功能。在喚醒系統的時候，會需要一套喚醒詞（Wake-up Word），常見的喚醒時就是「Hey Siri」、「OK Google」、「Alexa」等，語音助理平常處於一種等待狀態，雖然在錄音，但是並不做複雜的識別，只偵測在路到的聲音當中是否符合上述這些喚醒詞，如果有，才進入 ASR 識別狀態，開始嘗試識別完整的文字。雖然在很多應用中，並不需要用這種方式啟動語音助理，但或許您會有這種需求。

在 Flutter 提供的套件中，其實並沒有特別是合開發喚醒功能的套件。喚醒功能的要求是省電，而且避免連接網路，降低使用者的設備的耗電以及網路費用，但是像 iOS/Android 系統所提供的系統語音識別，背後通常都連接到特定的網路服務上，而且每一次識別都有時間上限，不適合長時間處於閒置狀態，而且每天每個 app 可以開啟識別的次數也有限制，大約一天 2000 次左右（這個次數可能隨時會有變化）。

因此，如果您的 app 有使用喚醒詞的需求，大概還是要倚賴有喚醒技術的供應商。