考慮到目前市場上Alexa、Google Assistant、DuerOS、AliGenie等語音智慧平臺都有各自的優缺點，本文講述的語音互動設計將是通用、抽象型的，以及不會針對任意一款語音智慧平臺進行設計。enjoy~

對話是人與人之間交換資訊的普遍方式。人可以在交流時透過判別對方的語氣、眼神和表情判斷對方表達的情感，以及根據自身的語言、文化、經驗和能力理解對方所發出的資訊，但對於只有0（false）和1（true）的計算機來講，理解人的對話是一件非常困難的事情，因為計算機不具備以上能力，所以目前的語音互動主要由人來設計。

有人覺得語音互動設計就是設計怎麼問怎麼答，看似很簡單也很無聊，但其實語音互動設計涉及系統學、語言學和心理學，因此它比GUI的互動設計複雜很多。

要做好一個好的語音互動設計，需要知道：

第一，自己的產品主要服務物件是誰？單人還是多人使用？

第二，要對你即將使用的語音智慧平臺非常瞭解；

第三是考慮清楚你設計的產品使用在哪，純語音音箱還是帶螢幕的語音裝置？

瞭解完以上三點你才能更好地去設計一款語音產品。

考慮到目前市場上Alexa、Google Assistant、DuerOS、AliGenie等語音智慧平臺都有各自的優缺點，以下講述的語音互動設計將是通用、抽象型的，以及不會針對任意一款語音智慧平臺進行設計。

語音互動相關術語

在設計語言互動之前，我們先了解一下與語音互動相關的術語：

技能（Skill）

技能可以簡單理解為一個應用。當用戶說“Alexa，我要看新聞”或者說“Alexa，我要在京東上買東西”時，使用者將分別開啟新聞技能和京東購物兩項技能，而“新聞”和“京東”兩個詞都屬於觸發該技能的關鍵詞，也就是開啟該應用的入口，後面使用者說的話都會優先匹配該項技能裡面的意圖。由於使用者呼喊觸發詞會加深使用者對該品牌的記憶，因此觸發詞具有很高的商業價值。

“Alexa”是喚醒語音裝置的喚醒詞，相當於手機的解鎖頁面，同時也是便捷回到首頁的home鍵。目前的語音裝置需要被喚醒才能執行相關操作，例如“Alexa，現在幾點？”、“Alexa，幫我設定一個鬧鐘”。這樣設計的好處是省電以及保護使用者隱私，避免裝置長時間錄音。

意圖（Intent）

意圖可以簡單理解為某個應用的功能或者流程，主要滿足使用者的請求或目的。意圖是多句表達形式的集合，例如“我要看電影”和“我想看2001年劉德華拍攝的動作電影”都可以屬於同一個影片播放的意圖。意圖要隸屬於某項技能，例如“京東，我要買巧克力”這個案例，“我要買巧克力”這個意圖是屬於京東這個技能的。當用戶說“Alexa，我要買巧克力”，如果系統不知道這項意圖屬於哪個技能時，系統是無法理解並且執行的。

但是，有些意圖不一定依賴於技能，例如“Alexa，今天深圳天氣怎麼樣”這種意圖就可以忽略技能而直接執行，因為它們預設屬於系統技能。當語音裝置上存在第三方天氣技能時，如果使用者直接喊“Alexa，今天深圳天氣怎麼樣”，系統還是會直接執行預設的意圖。我們做語音互動更多是在設計意圖，也就是設計意圖要怎麼理解以及執行相關操作。

詞典（Dictionary）

詞典可以理解為某個領域內詞彙的集合，是使用者與技能互動過程中的一個重要概念。例如“北京”、“廣州”、“深圳”都屬於“中國城市”這項詞典，同時屬於“地點”這項範圍更大的詞典；“下雨”、“颱風”、“天晴”都屬於“天氣”這項詞典。有些詞語會存在於不同詞典中，不同詞典的呼叫也會影響意圖的識別。例如“劉德華”、“張學友”、“陳奕迅”都屬於“男歌星”這項詞典，同時他們也屬於“電影男演員”這項詞典。

當用戶說“我要看劉德華電影”的時候，系統更多是匹配到電影男演員的“劉德華”；如果使用者說“我想聽劉德華的歌”，系統更多是匹配到男歌星詞典裡的“劉德華”。如果使用者說出“開啟劉德華”模稜兩可的話術時，那麼這句話究竟是匹配影片意圖還是歌曲意圖呢？這時候就需要人為設計相關的策略來匹配意圖。

詞槽（Slot）

詞槽可以理解為一句話中所包含的引數是什麼，而槽位是指這句話裡有多少個引數，它們直接決定系統能否匹配到正確的意圖。舉個例子，“今天深圳天氣怎麼樣”這項天氣意圖可以拆分成“今天”、“深圳”、“天氣”、“怎麼樣”四個詞語，那麼天氣意圖就包含了“時間”、“地點”、“觸發關鍵詞”、“無義詞”四個詞槽。

詞槽和詞典是有強關係的，同時詞槽和槽位跟語言的語法也是強相關的。例如“聲音大一點”這句話裡就包括了主語、謂語和狀語，如果缺乏主語，那麼語音智慧平臺是不知道哪個東西該“大一點”。

在設計前，我們要先了解清楚語音智慧平臺是否支援詞槽狀態選擇（可選、必選）、是否具備泛化能力以及槽位是否支援萬用字元。

詞槽和槽位是設計意圖中最重要的環節，它們能直接影響你未來的工作量。

泛化（Generalize）

一個語音智慧平臺的泛化能力能直接影響系統能否聽懂使用者在說什麼以及設計師的工作量大小，同時也能反映出該平臺的人工智慧水平到底怎麼樣。究竟什麼是泛化？泛化是指同一個意圖有不同表達方式，例如“聲音幫我大一點”、“聲音大一點”、“聲音再大一點點”都屬於調節音量的意圖，但是表達的差異可能會直接導致槽位的設計失效，從而無法識別出這句話究竟是什麼意思。

目前所有語音智慧平臺的泛化能力相當較弱，需要設計師源源不斷地將不同的表達方式寫入系統裡。詞槽和槽位的設計也會影響泛化能力，如果設計不當，設計人員的工作可能會翻好幾倍。

萬用字元（Wildcard Character）

萬用字元主要用來進行模糊搜尋和匹配。當用戶查詢文字時不知道真正的字元或者懶得輸入完整名字時，常常使用萬用字元來代替字元。萬用字元在意圖設計中非常有用，尤其是資料缺乏導致某些詞典資料不全的時候，它能直接簡化製作詞典的工作量。例如“XXX”為一個萬用字元，當我為“影片播放”這項意圖增加“我想看XXX電影”這項表達後，無論XXX是什麼，只要系統命中“看”和“電影”兩個關鍵詞，系統都能開啟影片應用搜索XXX的電影。

但是，萬用字元對語音互動來說其實是一把雙刃劍。

假設我們設計了一個“開啟XXX”的意圖，當用戶說“開啟電燈”其實是要開啟物聯網中的電燈裝置，而“開啟哈利波特”是要觀看哈利波特的系列電影或者小說。當我們設計一個“我要看XXX”和“我要看XXX電影”兩個意圖時，很明顯前者包含了後者。萬用字元用得越多會影響詞槽和槽位的設計，導致系統識別意圖時不知道如何對眾多符合的意圖進行排序，所以萬用字元一定要合理使用。

自動語音識別技術（ASR，Automatic Speech Recognition）

將語音直接轉換成文字，有些時候由於語句裡某些詞可能聽不清楚或者出現二異性會導致文字出錯。

語音智慧平臺如何聽懂使用者說的話

語音互動主要分為兩部分，第一部分是“聽懂”，第二部分才是與人進行互動。如果連使用者說的是什麼都聽不懂，那麼就不用考慮後面的流程了。這就好比如開啟的所有網頁連結全是404一樣，使用者使用你的產品會經常感受到挫敗感。因此能否“聽懂”使用者說的話是最能體現語音產品人工智慧能力的前提。

決定你的產品是否能聽懂使用者說的大部分內容，主要由語音智慧平臺決定，我們在做產品設計前需要先了解清楚語音智慧平臺的以下七個方面：

1.

當前使用的語音智慧平臺NLU（Natural Language Understanding，自然語言理解）能力如何，尤其是否具備較好的泛化能力。NLU是每個語音智慧平臺的核心。

2. 瞭解系統的意圖匹配規則是完全匹配還是模糊匹配？

以聲音調整作為例子。假設聲音調整這個意圖由“操作物件”、“調整”和“狀態”三個詞槽決定，“聲音提高一點”這句話裡的“聲音”、“提高”和“一點”分別對應“操作物件”、“調整”和“狀態”三個詞槽。如果這時候使用者說“請幫我聲音提高一點”，這時候因為增加了“請幫我”三個字導致意圖匹配不了，那麼該系統的意圖匹配規則是完全匹配，如果能匹配成功說明意圖匹配規則支援模糊匹配。

只支援詞槽完全匹配的語音智慧平臺幾乎沒有任何泛化能力，這時候設計師需要考慮透過構建詞典、詞槽和槽位的方式實現意圖泛化，這非常考驗設計師的語言理解水平、邏輯能力以及對整體詞典、詞槽、槽位的全域性設計能力，我們可以認為這項任務極其艱鉅。

如果語音智慧平臺支援詞槽模糊匹配，說明系統採用了識別關鍵詞的做法，以剛剛的“請幫我聲音提高一點”作為例子，系統能識別出“聲音提高一點”分別屬於“操作物件”、“調整”和“狀態”三個詞槽，然後匹配對應的意圖，而其他文字“請幫我”或者“請幫幫我吧”將會被忽略。模糊匹配能力對意圖的泛化能力有明顯的提升，能極大減少設計師的工作量，

因為我們儘可能選擇具備模糊匹配能力的語音智慧平臺

。

3. 當前使用的語音智慧平臺對語言的支援程度如何。

每種語言都有自己的語法和特點，這導致了目前的NLU不能很好地支援各種語言，例如Alexa、Google Assistant和Siri都在深耕英語英文的識別和理解，但對漢語中文的理解會相對差很多，而國內的DuerOS、AliGenie等語音智慧平臺則相反。

4.

有些詞典我們很難透過手動的方式收集完整，例如具有時效性的名人詞典還有熱詞詞典。如果收集不完整最終結果就是系統很有可能不知道你說的語句是什麼意思。這時候我們需要官方提供的系統詞典，它能直接幫助我們減輕大量的工作。系統詞典一般是對一些通用領域的詞彙進行整理的詞典，例如城市詞典、計量單位詞典、數字詞典、名人詞典還有音樂詞典等等。

因此我們需要了解當前使用的語音智慧平臺的系統詞典數量是否夠多，每個詞典擁有的詞彙量是否齊全。

5. 瞭解清楚語音智慧平臺是否支援客戶端和服務端自定義引數的傳輸，這一項非常重要，尤其是對帶螢幕的語音裝置來說。

我們做設計最注重的是使用者在哪個場景下做了什麼，簡單點就是5W1H，What（什麼事情）、Where（什麼地點）、When（什麼時候）、Who（使用者是誰）、Why（原因）和How（如何），這些都可以理解為場景化的多個引數。

據我瞭解，有些語音智慧平臺在將語音轉換為文字時是不支傳輸傳自定義引數的，這可能會導致你在設計時只能考慮多輪對話中的上下文，無法結合使用者的地理位置、時間等引數進行設計。

為什麼說自定義引數對帶屏語音裝置非常重要？因為使用者有可能說完一句話就直接操作螢幕，然後繼續語音對話，如果語音裝置不知道使用者在螢幕上進行什麼樣的操作，可以認為語音智慧平臺是不知道使用者整個使用流程是怎麼樣的。

在不同場景下，使用者說的話都可能會有不同的意圖，例如使用者在愛奇藝裡說“周杰倫”，是想看與周杰倫相關的影片；如果在QQ音樂裡說“周杰倫”，使用者是想聽周杰倫唱的歌曲。因此，Where除了是使用者在哪座城市，還有就是使用者目前在哪個應用裡。

6.

當前使用的語音智慧平臺是否支援意圖的自定義排序。其實，意圖匹配並不是只匹配到一條意圖，它很有可能匹配到多個意圖，只是每個意圖都有不同的匹配機率，最後系統只會召回機率最大的意圖。在第五點已提到，在不同場景下使用者說的語句可能會有不同的意圖，所以意圖應該根據當前場景進行匹配，而不只是根據詞槽來識別。

因此語音智慧平臺支援意圖的自定義排序非常重要，它能根據特定引數匹配某些低機率的意圖，實現場景化的理解。當然，只有在第五點可實現的情況下，意圖自定義排序才有意義。

7. 當前使用的語音智慧平臺是否支援聲紋識別。

一臺語音裝置很有可能被多個人使用，而聲紋識別可以區分當前正在使用裝置的使用者到底是誰，有助於針對不同使用者給出個性化的回答。

設計“能聽懂使用者說什麼”的智慧語音產品

當我們對整個語音智慧平臺有較深入的理解後，我們開始設計一套“能聽懂使用者說什麼”的智慧語音產品。為了讓大家對語音互動設計有深入淺出的理解，以下內容將是為帶屏裝置設計一款智慧語音系統，使用的語音智慧平臺不具備泛化能力，但是它可以自定義引數傳輸和意圖自定義排序。以下內容分為系統全域性設計和意圖設計。

全域性設計主要分為以下步驟：

1. 對產品賦予一個固定的人物形象

如果跟我們對話的“人”性格和風格經常變化，那麼我們可能會覺得這“人”可能有點問題，所以我們要對產品賦予一個固定的人物形象。

首先，我們需要明確我們的使用者群體是誰？再根據我們使用者群體的畫像設計一個虛擬角色，並對這個角色進行畫像描述，包括性別、年齡、性格、愛好等等，還有采用哪種音色，如果還要在螢幕上顯示虛擬角色，那麼我們要考慮設計整套虛擬角色的形象和動作。

完整的案例我們可以參考微軟小冰，微軟把小冰定義成一位話嘮的17歲高中女生，並且為小冰賦予了年輕女性的音色以及一整套少女形象。

2. 考慮我們的產品目的是什麼

這將會為使用者提供哪些技能（應用），這些技能的目的是什麼？使用者為什麼要使用它？使用者透過技能能做什麼和不能做什麼？使用者可以用哪些方式呼叫該技能？還有我們的產品將會深耕哪個垂直領域，智慧家居控制？音樂？影片？體育？資訊查詢？閒聊？

由於有些意圖是通用而且使用者經常用到的，例如“開啟XXX”這個意圖，“開啟電燈”屬於智慧家居控制意圖，而“開啟QQ音樂”屬於裝置內控制意圖，“開啟哈利波特”有可能屬於電子書或者影片意圖，所以每個領域都會有意圖重疊，因此我們要對自己提供的技能進行先後排序，哪些是最重要的，哪些是次要的。在這裡我建議把資訊查詢和閒聊最好放在排序的最後面，理由請看第三點。

3. 建立合適的兜底策略

兜底方案是指語音完全匹配不上意圖時提供的最後解決方案，可以這樣認為：

當智慧語音平臺技術不成熟，自己設計的語音技能較少，整個產品基本聽不懂人在說什麼的時候，兜底策略是整套語音互動設計中最重要的設計。

兜底方案主要有以下三種：

（1）以多種形式告知使用者系統暫時無法理解使用者的意思

例如“抱歉，目前還不能理解你的意思”、“我還在學習該技能中”等等。這種做法參考了人類交流過程中多變的表達方式，使整個對話不會那麼無聊生硬。

這種兜底策略成本是最低的，並且需要結合虛擬角色一起考慮。如果這種兜底方案出現的頻率過高，使用者很有可能覺得你的產品什麼都不懂，很不智慧。

（2）將聽不懂的語句傳給第三方搜尋功能

基本上很多問題都能在搜尋網站上找到答案，只是答案過多導致使用者的操作成本有點高。

為了有個更好的體驗，我建議產品提供百科、影片、音樂等多種搜尋入口。

以“我想看哈利波特的影片”這句話為例子，我們可以透過正則表示式的技術手段技能挖掘出“影片”一詞，同時將“我想看”、“的”詞語過濾掉，最後獲取“哈利波特”一詞，直接放到影片搜尋裡，有效降低使用者的操作步驟。

這種兜底策略能簡單有效地解決大部分常用的查詢說法，但用在指令意圖上會非常怪，例如“開啟客廳的燈”結果跳去了百度進行搜尋，這時候會讓使用者覺得你的產品非常傻；還有，如果在設計整個兜底策略時沒有全域性考慮清楚，很有可能導致截取出來的的關鍵詞有問題，導致使用者覺得很難理解。

（3）將聽不懂的語句傳給第三方閒聊機器人

有些積累較深的第三方閒聊機器人說不定能理解使用者問的是什麼，而且提供多輪對話的閒聊機器人可以使整個產品看起來“人性化”一點。

由於閒聊機器人本身就有自己的角色定位，所以這種兜底策略一定要結合虛擬角色並行考慮。而且第三方閒聊機器人需要第三方API支援，是三個兜底策略中成本最高的，但效果也有可能是最好的。

由於是聽不懂才需要兜底策略，所以以上三種兜底方案是

互斥的

。為了讓整個產品有更好的體驗，我們不能完全依賴最後的兜底策略，還是需要設計更多技能和意圖匹配更多的使用者需求。人與機器的對話可以概括為

傳送指令、資訊查詢和閒聊

三種形式，以上三種兜底方案在實際應用時都會有所優缺點，設計師可以根據實際需求選擇最合適產品的兜底策略。

4. 檢視語音智慧平臺是否提供了與技能相關的垂直領域官方詞典

檢視語音智慧平臺是否提供了與技能相關的垂直領域官方詞典，如果沒有就需要考慮手動建立自己的詞典。

手動建立的詞典質量決定了你的意圖識別準確率

，因此建立詞典時需要注意以下幾點：

（1）詞彙的覆蓋面決定了詞典質量，所以詞彙量是越多越好。

（2）該詞典是否需要考慮動態更新，例如名人、影片、音樂等詞典都應該支援動態更新。

（3）該詞彙是否有同義詞，例如醫院、學校等詞彙都應該考慮其他的常用叫法。

（4）如果想精益求精，還需要考慮詞彙是否是多音字，還有是否有常見的錯誤叫法。有時ASR（Automatic Speech Recognition，自動語音識別）會將語音識別錯誤，因此還需要考慮是否需要手動糾正錯誤。

5. 在場景的幫助下，我們可以更好地理解使用者的意圖

由於我們的大部分裝置都是使用開源的安卓系統，而且語音應用和其他應用都相互獨立，資訊幾乎不能傳輸，所以我們可以透過安卓官方的API獲取棧頂應用資訊瞭解使用者當前處於哪個應用。如果使用者當前使用的應用是由我們設計開發的，我們就可以將使用者的一系列操作流程以及相關引數傳輸給伺服器進行分析，這樣有助於我們更好地判斷使用者的想法是什麼，並前置最相關的意圖。

6. 撰寫指令碼

指令碼就像電影或戲劇裡一樣，它是確定對話如何互動的好方法。可以使用指令碼來幫助確認你可能沒考慮到的情況。撰寫指令碼需要考慮以下幾點：

（1）保持互動簡短，避免重複的短語。

（2）寫出人們是如何交談的，而不是如何閱讀和寫作的。

（3）當用戶需要提供資訊給出相應的指示。

（4）不要假設使用者知道該做什麼。

（5）問問題時一次只問一個資訊。

（6）讓使用者做選擇時，一次提供不超過三個選擇。

（7）學會使用話輪轉換（Turn-taking）。話輪轉換是一個不是特別明顯但是很重要的談話工具，它涉及了對話中我們習以為常的微妙訊號。 人們利用這些訊號保持對話的往復過程。缺少有效的輪迴，可能會出現談話的雙方同時說話、或者對話內容不同步並且難以被理解的情況。

（8）對話中的所有元素應該可以繫結一起成為簡單的一句話，這些元素將是我們意圖設計中最重要的引數，因此我們要留意對話中的線索。

7. 最後我們要將指令碼轉化為決策樹

決策樹跟我們理解的資訊架構非常相似，也是整個技能、意圖、對話流程設計的關鍵。這時候我們可以透過決策樹發現我們整個技能設計是否有邏輯不嚴密的地方，從而最佳化我們整個產設計。

以上是全域性設計的相關內容，以下開始講述意圖設計。

意圖設計主要包括以下內容：

1. 在前面提到，意圖識別是由詞槽（引數）和槽位（引數數量）決定的

當一個意圖的槽位越多，它的能力還有複用程度就越高；但是槽位越多也會導致整個意圖變得更復雜，出錯的機率就會越高，所以意圖設計並不是槽位越多就越好，最終還是要根據實際情況而決定。當我們設計詞槽和槽位時，請結合當前語言的語法和詞性一起考慮，例如每一句話需要考慮主謂賓結構，還有各種的名詞、動詞、副詞、量詞和形容詞。

2. 當語音智慧平臺泛化能力較弱時，我們可以考慮手動提升整體的泛化能力

主要的做法是將常用的表達方式抽離出來成為獨立的詞典，然後每個意圖都匹配該詞典。

3. 如果設計的是系統產品，我們應該考慮全域性意圖的設計

例如像帶屏智慧音箱、投影儀都是有實體按鍵的，我們可以考慮透過語音命令的方式模擬按鍵操作從而達到全域性操作，例如“上一條”、“下一個”、“開啟xxx”這些語音命令在很多應用內都能用到。

以下透過簡單的案例學習一下整個意圖是怎麼設計的，我們先從“開啟關閉裝置”意圖入手：

（1）首先我們設計“執行詞典”和“裝置詞典”

，詞典如下：

（2）設計“執行裝置”的詞槽為“執行”+“裝置”。

無論使用者說“開燈”或者“開啟光管”時都能順利匹配到“Turn_on”+“Light”；而使用者說“關掉彩電”或者“關電視”都能順利匹配到“Turn_off”+“Television”，從而執行不同的命令。

（3）為了增加泛化能力，我們需要設計一個“語氣詞典”

，詞典如下：

（4）增加意圖槽位

這時候把“執行”和“裝置”兩個槽位設定為必選槽位，意思是這句話這兩個詞槽缺一不可，如果缺少其中之一需要多輪對話詢問，或者系統直接無法識別。

接著增加兩個可選槽位，同時為“語氣”，可選槽位的意思是這句話可以不需要這個詞都能順利識別。這時候使用者說“請開燈”、“能不能幫我開燈”都能順利匹配到“Please”+“Turn_on”+“Light”以及“Please”+“Turn_on”+“Light”+“Suffix”，由於“Please”和“Suffix”都屬於“語氣”可選詞槽的內容，所以兩句話最後識別都是“Turn_on”+“Light”。

透過引數相乘的方式，我們可以將整個“開啟關閉裝置”意圖分別執行4種命令，並泛化數十種常用表達出來。

剛剛也提到，對輪對話的目的是為了補全意圖中全部必選詞槽的內容。當用戶家裡存在數盞燈時，系統應該將剛才的常用表達升級為“Please”+“Turn_on”+“Which”+“Light”+“Suffix”。當用戶說“開啟燈”的時候，系統應該詢問“您需要開啟的哪一盞燈”，再根據使用者的反饋結果執行相關命令。

以上的案例只是整個意圖設計中的一小部分，還有很多細節需要根據實際情況進行設計。完成整個全域性設計和意圖設計後，我們應該邀請使用者進行實踐與測試，這時候們很有可能發現使用者會用我們沒想到的話術進行語音互動，我們要儘可能地完善意圖以及對話設計，避免產品上線後出現問題。

最後，關於建立使用者故事、撰寫指令碼和對話流程設計，請閱讀Google的《Actions on Google Design》和Amazon的《Amazon Alexa Voice Design Guide》兩份文件以及相關的語音智慧平臺的官方使用文件，裡面會更詳細地介紹相關細節。

最後的最後，衷心感謝騰訊MXD團隊翻譯的《Actions on Google Design》以及餘小璐和王帆翻譯的《Amazon Alexa Voice Design Guide》兩份中文文件。

全棧開發者，專注於互動設計和人工智慧設計。。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自Pixabay，基於CC0協議