如何最簡單的搭建一個語音交互的原型？

01-08

比如，通過對手機下達語音指令，手機的APP可執行某個動作。
如何搭建這樣的演示原型？

謝邀。

這個問題太複雜了，我沒有做過這類交互，給不了你答案。至少我覺得至少可以先自己理一下人和手機之間的交互場景，還不著急如何「搭建」。

如果是演示原型的話，可以直接通過：訊飛的體驗區來給客戶體驗：訊飛開放平台

最簡單的是畫出流程線框圖，就可以把設計說明清楚，需要描述的界面有：

1.輸入前 2.輸入（語音輸入的入口，輸入的內容，輸入過程中的反饋） 3.輸入後（app執行動作）

如果按照題主的問題需要搭建可演示的原型，實現語音交互一般來說要應用到以下語音技術：

1.語音識別

自動語音識別技術(Auto Speech Recognize，簡稱ASR)所要解決的問題是讓計算機能夠「聽懂」人類的語音，將語音中包含的文字信息「提取」出來。ASR技術在「能聽會說」的智能計算機系統中扮演著重要角色，相當於給計算機系統安裝上「耳朵」，使其具備「能聽」的功能，進而實現信息時代利用「語音」這一最自然、最便捷的手段進行人機通信和交互。

2.語音合成

又稱文語轉換（Text to Speech）技術，它涉及聲學、語言學、數字信號處理、計算機科學等多個學科技術，是中文信息處理領域的一項前沿技術，解決的主要問題就是如何將文字信息轉化為可聽的聲音信息，也即讓機器像人一樣開口說話。我們所說的「讓機器像人一樣開口說話」與傳統的聲音回放設備（系統）有著本質的區別。傳統的聲音回放設備（系統），如磁帶錄音機，是通過預先錄製聲音然後回放來實現「讓機器說話」的。這種方式無論是在內容、存儲、傳輸或者方便性、及時性等方面都存在很大的限制。而通過計算機語音合成則可以在任何時候將任意文本轉換成具有高自然度的語音，從而真正實現讓機器「像人一樣開口說話」。

3.智能語義

語義，顧名思義，就是指語言描述的事物所代表的含義，以及這些含義之間的關係。人類的語言是由符號構成的體系，語義實際上也就是對符號的解釋。

我們的日常生活是由一個個場景構成的，同樣的語言，在不同的場景中所代表的含義可能截然不同，因此，語義具有領域性特徵，沒有領域特徵的語義是不存在的。智能語義，就是使用計算機去理解語言在特定領域所代表語義。

4.語音聽寫

語音聽寫是基於自然語言處理技術，將自然語言轉換為文本輸出。自然語言處理技術所涵蓋的研究內容非常廣泛，從研究成果的表現形式來說，基本可以分為基礎研究和應用研究兩大類：

基礎研究：主要指對自然語言內在規律的研究，從研究深度和難度上大致可劃分為詞典編撰、分詞斷句、詞性分析、語言模型、語法分析、語義分析、語用分析等等。

應用研究：主要指基於基礎研究的成果，面向不同的應用，研發相關的自然語言處理技術，大的方向至少包括：拼音輸入法、信息檢索、信息抽取、自動摘要、機器翻譯、語音合成、語音識別、文本匹配、文本分類、對話系統等。

自然語言處理技術中最核心的自然語言理解技術，從進展和目前所取得的成果來說，都與人們的普遍預期有較大差距。但是隨著自然語言處理技術的研究積累，以及計算機技術水平的快速發展，越來越多的自然語言處理技術正逐步走向實用，並且創造了巨大的經濟價值和社會價值。互聯網、電子文本、短消息、語音通訊等等自然語言媒介的快速增長，也為自然語言處理技術的研究和應用提供了非常好的機遇。

語音聽寫技術與語音識別技術的不同在於，語音聽寫不需要基於某個具體的命令詞列表，其識別範圍是整個語種內的詞條。

----以上內容引用自語音雲開放平台

所以，要實現「通過對手機下達語音指令，手機的APP可執行某個動作。」，起碼會應用到語音識別技術。

介紹下老東家科大訊飛的語音雲開放平台，為多種終端環境提供了語音開發介面，主要包含Android、iOS、Windows Phone、Windows、Linux、Java、Flash等。是免費的，當然國內也不止這一家提供開放SDK，客觀來說訊飛的效果是最好的。

有了語音技術，剩下的就交給程序員開發DEMO了。

這個問題我之前也在思考，到底VUI該如何設計。之前寫的是偏方法論，前幾天剛好看到一篇文章講到VUI設計的具體操作，覺得更好的回答了這個問題，所以進行補充。

一，VUI設計的方法論（節選來自我之前的文章： 10分鐘看懂谷歌語音交互設計規範都講了些什麼）

二，VUI設計的具體操作（ 引用來自Rachel Hu，阿里雲OS VUI交互設計師：VUI語音交互設計：三步打造任務導向型對話場景 | 人人都是產品經理）

一，VUI設計的方法論

這部分可以參考谷歌語音交互設計規範中的第三章《設計原則與方法》，其中講到的設計語音交互的5個步驟

1).選擇正確的用戶場景。

適合對話UI的場景通常比較簡單、直觀，不需要太複雜性的互動。

2).創建用戶畫像。

你的對話表達與功能的呈現方式能夠體現一致性、品牌訴求和人的個性特徵。

3).撰寫對話。

這個過程中你會構思出大量的對話，並探索出最好的實現方式。

4).進行測試。

大聲念出對話，用模擬工具進行測試，確保對話聽起來比較自然，接近人類的對話方式。

5).實現和迭代。

使用API.AI實現對話功能，或用Actions SDK在你自己的工具平台中開發。

二，VUI設計的的具體操作

作為語音產品設計人員，如何以短平快的方式設計一個任務導向型對話場景呢？具體來說就是三個步驟：理清對話邏輯（Chat Flow）、設計語法（Grammer）以及設計應答 (Confirmation)。

第一步：對話邏輯——從哪裡來，到哪裡去？

如同圖形用戶界面以點擊-觸發為各個節點的交互邏輯，VUI也需要一從query到answer的流轉邏輯，將一個場景的對話流程流暢的貫穿起來。

假設你設計的對話場景是查詢空氣質量，請考慮在這番對話中可能出現的任何情況以及相應的反饋動作：

下圖展現了該場景可能的Chat Flow

即便是詢問天氣這樣看上去很簡單的對話場景，也可以設計出十分複雜的對話邏輯，根據該場景在你產品中的重要程度決定細節邏輯的粒度。

第二步：設計語法 ——用戶會對你說什麼？

語法就是用戶輸入的指令集，對話設計者需要設計對話的意圖（Intent），以及盡量考慮用戶可能表達方式，將其中最核心、最常用的表達方式提取為指令集模板。設計的指令集越多越全面，對話覆蓋率就會越高。

想像場景還是查詢空氣質量，請考慮用戶會用怎樣的表達方式來提出自己的要求：

「幫我查詢空氣質量」
「北京空氣質量指數」
「今天PM2.5值是多少」
「我需要戴口罩嗎」
「今天的空氣怎麼樣」
……

中華語言，博大精深，簡單的查詢空氣質量，就有茫茫多的問法。不過不用著急，你只需要提取一些最典型的句式，至於「么」「嗎」「呢」這些語氣詞，或者虛詞、助詞等，語義理解模塊（NLU）會幫忙泛化。

下圖為查詢空氣質量對話指令集，其中&

和&是槽位（Slot）。Slot是NLU從用戶指令中抽取的關鍵信息點，NUL模塊通過這些關鍵信息及其取值定義（Slot-Value），理解用戶指令的具體要求。

第三步：設計應答——你要如何回答用戶？

語音交互中最主要的應答方式是TTS（Text To Speech），就是將設計者寫好的應答腳本，通過TTS引擎轉化為語音播放出來。應答帶給用戶最直觀的感受，應答的好壞，直接關係到語音產品的體驗。鑒於過長的語音內容會增加用戶的記憶負載，設計應答時應該盡量簡潔。同時，如果你的語音產品具備自己的個性特點，在應答時也請按照該特點的語言風格撰寫腳本，保持角色的一致性。

還是查詢空氣質量的例子，在第一步，設計對話邏輯的過程中，我們已經定義了該對話可能出現的幾類應答。分別是：

A1.詢問用戶想查詢哪裡的空氣質量
A2.反饋沒有查到相關地區相關時間的空氣質量
A3.根據空氣質量級別的優劣反饋相應提示

接下來，你只需要在對話腳本（script）文檔里，發揮你強大的語言天賦，進行完型填空就可以了。

轉發一下自己的原文，也許可以給你一些回答和幫助。

作者：ShifuMarc 鏈接：https://zhuanlan.zhihu.com/p/25544672 來源：知乎著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

。寫在前面：

原文檔出處：Alexa Skills Kit Voice Design Best Practices

文章來自於Amazon Alexa的文檔資料，文章主要是幫助翻譯和解讀，半註解的形式和大家一起學習一下無屏語言交互的做法。文章最後會有總結的乾貨（不過建議還是結合全文一起看會比較好）主要分以下四點：

從用戶獲取信息向用戶提供信息有效的把文本轉化成語音處理對話錯誤

1 Getting Information from the User（從用戶那裡獲得信息）

Make It Clear that the User Needs to Respond（讓用戶清楚的知道我們需要它的響應）

單獨呈現選項不足以告知用戶機器需要他做出響應，所以請確保向用戶提出問題，從而確保他們會回答問題。

User: Alexa, 開始Trivia Challenge.（這是一個Skill的名字類似一個功能模塊或者app）

Do Trivia Challenge: 這裡是你的類別：80年代的流行歌曲，Potents Potables或歐洲歷史。你想要哪一個？ Don』t Trivia Challenge: 您可以從以下類別中選擇：80年代流行歌曲，Potents Potables或歐洲歷史

第一種在給出選項後做出來提問告訴用戶他需要挑選並且是選一個，第二種可能會導致用戶多選或者不選，從而引起程序出錯的風險。

Don』t Assume Users Know What to Do（不要假設用戶知道怎麼做）

當用戶第一次體驗或者使用時，他們可能只給予最少的信息，只是告訴你他要使用什麼功能（類似打開一個程序或者一個網站的過程），並不會提供你其他的任務細節。當發生這種情況時，需要告訴他們具體的選項和內容。

User: Alexa, 和Car Fu對話.

Do Car Fu: Car Fu. 你可以直接叫車也可以詢問車費大概的價格. 你需要哪一個? User: 直接叫車 Car Fu: 正在發送您的請求。當您的汽車到達時，手機會提醒將通知您。感謝您使用Car Fu. Don』t Car Fu: 正在打開 Car Fu. User: (Here, it may not be obvious to users what they can do unless you give them some options)

很明顯，如果沒有告知選項，用戶就會無從下口或者亂說一通。順帶注意一下，由於是無屏設備，智能通過語言，這裡把詢價和坐車做了明確的功能拆分以避免經常坐車的人重複收聽價格表單（要知道沒有屏幕，報個價格也是挺久的）。

Clearly Present the Options（清楚的顯示選項）

當使用一組選項提示用戶時，構造提示的語言，以便用戶清楚地知道它是一個陳述還是一個問題。

User: Alexa, 讓 Food Taxi 為我定一個漢堡.

Do Food Taxi: 你喜歡哪一個？炸薯條還是沙拉？ User: Salad Don』t Food Taxi: 你喜歡炸薯條還是沙拉？ （這裡有可能用戶聽到一半就以為是問你喜歡炸薯條么？） User: Yes

Keep It Brief（保持簡短）

語音是線性的，基於時間的，用戶不能像可視化內容那樣瀏覽內容。用戶需要做出快速決定以回應他們提出的問題，因為時間在流逝中。因此，提示應該簡潔明了，同時仍然清晰。

User: Alexa, 讓 Astrology Daily 給我占撲一個星座（這裡用戶除了叫醒程序也提出了目的）

Do Astrology Daily: 你想要哪一個星座? Don』t Astrology Daily: 一共有十二個星座，我可以給你其中一個的運勢，請問您要哪一個（這裡十二星座是常識且Astrology Daily的名字也提供了每日和占星兩個信息）

Avoid Overwhelming Users with Too Many Choices（避免淹沒式的給用戶太多的選項）

當向用戶提供可供選擇的選項列表時，請確保清楚地陳述選項，不要超過三個選項，並避免重複的措詞。

User: Alexa, 讓 Dairy Shack 幫我定一份奶昔.

Do Dairy Shack: 你喜歡什麼風味：巧克力，香草或草莓? Don"t Dairy Shack: 你想要什麼口味？對於巧克力，說巧克力。對於香草，說香草。或者對於草莓說草莓.

這裡就是典型的重複措辭，至於三個選項看個人，真的超過三個可以用其他和更多來翻頁，後面會提到

Offer Help for Complex Skills（對於複雜技能給予幫助）

當你的應用能做了很多事情（三個以上）或者需要很多參數，不要為了適合每個選項單獨做一個提示。首先介紹最重要的選項，然後用幫助做下級目錄。如果用戶請求幫助，就列出所有的功能。記住在給出選項後向用戶詢問一個問題。

User: Alexa, 開始 Score Keeper（計分功能）

Do 記分員：記分員。你可以給玩家點數，要求得分，或者說幫助。你喜歡什麼？ 用戶：幫助 記分員：這裡有一些你可以說：添加約翰，給約翰5分，告訴我分數，開始一個新遊戲，或重置所有玩家。你也可以說，停止，如果你完成了。那麼我現在為您做什麼？（這裡採用幫助避免出現過多選項的問題） Don"t 記分員：記分員。你可以給一個玩家點數，添加一個新玩家，要求得分，開始一個新遊戲，清除所有玩家，或者如果你完成，停止。現在，你想要什麼？ 用戶：得分是多少？

Ask Only Necessary Questions（值詢問必要問題）

應該儘可能做出明智合理的假設，以避免不必要的問題。詢問非必要問題會增加用戶體驗的下降，並使服務感覺起來不那麼周到。

如果你的技能只做一件事，不要問用戶他們是否想做這件事。
適當時做出有根據的猜測（不會使其難以糾正）。
基於用戶的定製提示示例（例如，用戶簡檔）。

用戶：Alexa，開始笑話銀行。

Do Joke Bank: What』s black, white, and red all over? An embarrassed skunk.（一個美式幽默，本人不太明白笑點在哪 - -！）這裡就是明確要笑話銀行，就直接說笑話不要詢問要不要聽 Don』t Joke Bank: Would you like to hear a joke? User: Yes.

Use Confirmation Selectively（使用選擇即確認）

避免創建太多確認的對話框，除了高度後果的操作，例如：

? 公開顯示的操作（例如，發布到社交媒體）

? 影響其他人的操作（例如，發送消息）

? 涉及金錢的行為（例如，當用戶購買東西時）

User: Alexa, 詢問 Astrology Daily 我的星座運勢.

Astrology Daily: 您是哪個星座?

User: 天秤

Do Astrology Daily: Today』s outlook for Libra is… 直接播報運勢 Don』t Astrology Daily: You want the horoscope for Libra, right? User: Yes

一個沒有必要的確認對話框

Obtain One Piece of Information at a Time（一次獲取一條信息）

用戶可能不會總是提供所需的所有信息。如果不能預測信息（用戶為新用戶），請逐步向用戶詢問缺少的信息。

User: Alexa, 向 Date Night 今晚預訂Haymarket .

Do Date Night：Haymarket預訂。今晚什麼時候？ User：大約7：30. Don』t Date Night：要預訂，您需要說出位置，時間，日期和人數。請重新開始

第二種方法雖然可以很快說完信息，但是目前的技術而言還是用戶的表現而言，要一次全部完成並且正確的概率很低，效率反而沒有1by1來的快。

Use the Amazon Alexa App to Enhance Discovery（使用Alexa的應用程序增強發現能力）

介紹技能或者應用時要說明通途或者使用示例

? "Alexa, ask Score Keeper to start a new game" ? "Alexa, ask Score Keeper to add John to the game" ? "Alexa, ask Score Keeper to give 5 points to John." ? "Alexa, ask Score Keeper for the score"

Don"t

? "Alexa, open Score Keeper" ? "Alexa, start Score Keeper" ? "Alexa, talk to Score Keeper"

2 Presenting Information to the User（提供信息給用戶）

Make Sure Users Know They are in the Right Place（確保用戶知道他們在正確的步驟位置）

在短期互動中，沒有必要告知用戶他們正在進入或退出這些過程，但讓他們知道他們在哪處在什麼階段，以幫助確認他們在正確的地方。在純語言交互中，用戶不能像在用有屏設備時來定位自己的步驟位置（所處界面），使用標識語告訴用戶機器聽到他們正確的消息，給予他們安全感。

User: Alexa,問Astrology Daily今天雙魚座的運勢.

Do Astrology Daily:Here』s today』s Pisces horoscope: You』ve got a friend who can help you overcome today』s problems.（提示一下是雙魚座的） Don』t Astrology Daily: You』ve got a friend who can help you overcome today』s problems.

Present Information in Consumable Pieces（當前信息是可被消化的）

人類只能保留他們聽到的小片信息。因此，只展示絕對需要的，以保持互動儘可能短。當呈現較長的列表時，將它們分成三到五個小塊，並詢問用戶在提交每個塊之後是否繼續。這也幫助用戶感覺他們在可控的交互中。

User: Alexa, 問一下 Savvy Consumer 在花園中什麼最暢銷.

Do Savvy Consumer：花園部分中最暢銷賣是排斥檸檬桉樹天然驅蟲劑的4盎司泵噴霧，你想聽聽其他的嗎？ 用戶：「是」 Savvy Consumer：第2號：TERRO螞蟻殺手液體螞蟻誘餌，編號3：韋伯12英寸三面格柵刷，編號4：黑色和Decker 30英尺線字元串修剪更換線軸，你想聽更多麼？用戶：」否「 Don"t Savvy Consumer：這裡是花園部門的暢銷書第1號：排斥檸檬桉樹天然驅蟲劑，4盎司泵噴霧第2號：TERRO螞蟻殺手液體螞蟻誘餌編號3：韋伯12英寸三面格柵刷編號4：黑色和Decker 30英尺線字元串修剪更換線軸第5位：...

先推薦一個，幫助用戶快速決策（當然也是一個廣告入口機會），後面注意加上編號，方便用戶不用說全名，最後還是老原則，最後加上問題保持對話不斷裂。

Write for the Ear, not the Eye（為耳朵而寫不是為眼睛）

為語音體驗所寫的提示是用來聽的，而不是讀，所以重要的是寫他們的口語對話。如果在口語對話中聽起來自然，片段句子和帶介詞的結束句是可以接受的。另外，請記住，在紙上看起來不錯的文字聽起來可能不OK。

User: Alexa ask NHL tracker 給我鯊魚隊比賽的數據。

Do HHL Tracker：鯊魚隊在第三節落後於星隊，比分3比2。 Don』t NHL追蹤：聖荷西鯊魚（40-33-9）：2個進球。達拉斯明星（41-31-10）：3個進球。剩餘時間：4:35，第三節。

這裡可以運用上述的再提問，以幫助用戶得到詳細數據，並且不要用括弧等文本數據。

Avoid Technical and Legal Jargon（避免技術好法律術語）

誠實地向用戶說明發生了什麼，但不要使用用戶不會理解或聽起來不自然的技術術語。類似地，由於合法消息通常包含長而不自然的語言，用於閱讀，而不是語音對話，它們可能干擾語音體驗並且可能使用戶混淆。法律免責聲明可以添加更多或者作為一個選項，或者作為一個推送給用戶在其他設備閱讀。

User: Alexa, 問Flight Stats 有關Alaska 328的狀態.

Do Flight Stats：從西雅圖到聖何塞的阿拉斯加航班328由於機械修理而延遲，現在預定於6:25離開 Don』t Fight Stats：阿拉斯加328，西雅圖到聖荷西，目前處於DELAY :: XFM5341狀態。重新出發時間為1825。

User: Alexa, 問Taxi Broker問題.

Do Taxi Broker: Taxi Broker. Where to? 先提供服務問題，免責條款以其他方式傳達。 Don』t Taxi Broker: Taxi Broker. The Taxi Brokers terms and conditions may apply; if you are a resident of New York then NY law… Where to?

3 Using Text-to-Speech Effectively（有效的把文本轉化成語音）

這裡由於格式問題很多錄音無法播放，很難展現效果所以就跳過，有興趣的朋友可以去Alexa網站中聽一下。

簡單總結就是實現方式可以利用類似劇本的代碼讓語音抑揚頓挫起來。

4 Handling Dialogue Errors（處理對話錯誤）

Use Re-Prompting to Provide Guidance（使用重新提示來提供指導）

如果用戶說的是機器不理解的東西，或者用戶根本沒有回應，可以採取重新提示（錯誤後播放的提示）。注意，您編寫的提示需要給用戶指導您期望什麼樣的響應。可以接受重新提示比用戶聽到的第一個提示稍微冗長，但是內容需要清楚地呈現期望用戶說什麼。

User: Alexa, 詢問 Tide Pooler高潮水位的時間.

Tide Pooler: 哪個城市的?

User: Las Vegas

Do Tide Pooler：我只能為沿海城市，如聖地亞哥或波士頓提供潮汐信息。現在，你想要哪個城市？ User: Virginia Beach. Don』t Tide Pooler：請告訴我一個城市 User: Uh…

在重複提示前加上一個提示以幫助用戶知道問題在哪，從而說出正確而內容。

Offer a Way Out if the User Gets Stuck（如果用戶被卡住，提供一個新方法）

當設備不正確地理解用戶說的並繼續使用錯誤的信息時，會發生錯誤接受。如果設備給出了錯誤的技能，或者用戶在其他情況下停留在互動中，那麼您應該在幫助提示中提供一個解決方案，以幫助他們意識到「停止」命令可用。

User: Alexa, 啟動 Store Finder

Alexa: [誤解為「start Score Keeper」]

Do Score Keeper: Score Keeper. You can give a player points, ask for the score, or say help. What would you like? User: Help Score Keeper: Here are some things you can say: (lists several options) You can also say, stop, if you"re done. So, how can I help? User: Stop. Don"t Score Keeper: Score Keeper. You can give a player points, ask for the score, or say help. What would you like? User: Help Score Keeper: Here are some things you can say: (lists several options) So, how can I help? Note no indication of how to exit the skill.

主要區別就是，第一種提供了退出機制，但是第二種沒有做出提示。

Don』t Blame the User（不要責備用戶）

當錯誤發生時，不要將責任歸咎於用戶，但也不要刻意說抱歉（這樣做會使用戶覺得你不自信，進一步降低用戶對你的技能的信心）。

用戶：問酒店Hub找到一家酒店

酒店中心：酒店預訂哪些城市？

用戶：[背景噪音]

Do 酒店中心：這是什麼城市 Don』t 酒店中心：你給的城市是無效的。請說出你想預訂的城市。

簡單的換一種方式再次提問，不要刻意道歉也不要怪用戶給你的是錯的、

Expect the Unexpected（期望意外）

與可視界面不同，用戶只能選擇屏幕上呈現的內容，但是沒有辦法限制用戶在語音交互中可以說什麼。因此，重要的是推測用戶可能說的不支持的事情，然後智能地處理它們。

用戶：請Date Night在明天預訂Haymarket。

Date Night：Haymarket預訂。明天什麼時候？

用戶：下午10:30

Do Date Night：Haymarket在5:00至9:30之間預訂。您想預訂什麼時間？ User：9點 Date Night：多少人？ Don"t Date Night：對不起，您想預訂什麼時候？ User：10：30pm Date Night：我無法理解。& [stream closing ; 對話結束]

給於錯誤的情況對應的提示性語句從而引導用戶回答正確答案。

-------------------------------------------華麗的分割線-----------------------------------------------

總結一下：

1，確保提出問題，避免利用陳述句或者反問句提問

2，不要假設用戶知道怎麼做，該有的提示還是要有

3，但是又不可以把用戶當傻瓜，有些廢話不提也罷

4，顯示選項要清楚且不要超過三個，超過的用更多或者幫助等語言命令

5，在給出選項後想用戶提出一個問題

6，避免創建太多確認的對話框，除了高度後果的操作，例如：

? 公開顯示的操作（例如，發布到社交媒體）

? 影響其他人的操作（例如，發送消息）

? 涉及金錢的行為（例如，當用戶購買東西時）

7，提供語言示例或者介紹時要說明功能。

8，注意提示用戶他們所處的位置和讓他們確保輸入正確

9，最後加上問題保持對話不斷裂。

10，選項後面注意加上編號，方便用戶不用說選項全名

11，不要用括弧等文本數據

12，重要的但是不適合語音表達的內容可以採用推送等方式告知

13，在重複提示前加上一個提示以幫助用戶知道問題在哪，從而說出正確而內容。

14，每個功能總要留有餘地的給用戶留一個退出機制並且提示

15，當錯誤發生時，不要將責任歸咎於用戶，但也不要刻意說抱歉

16，要推測用戶可能說的不支持的事情，然後智能地處理它們。

想了半天，好像目前真的只能找研發同事做demo……貌似……還真的沒有簡單的方式……如果是交互設計師的話，還是創建好會話流，自己多念幾遍多想想(?í _ ì?)

隨便溜達看到這個問題，覺得我最近翻譯的一篇討論語音交互設計的文章，可能題主會感興趣：

語音交互界面的聲音標記

人工智慧顯然是未來的科技發展重頭戲，而與其相關的必然是語音交互。