本系列文字是一位創業者的投稿《面向NLP的AI產品方法論》，老曹盡量不做變動和評價，盡量保持系列文章的原貌，這是第2篇。

設計語音技能跟軟件開發一樣集體協作完成，本文主要討論，產品經理在業務各階段開發中，應該處理的任務。

在產品設計階段，產品經理應該需要思考的3個任務，以及在后續【業務開發】【功能驗收】【更新迭代】階段的2個任務。

給自己做一個命題作文，比如，電影。（其實是從外賣，電影、酒店3個里面隨機選的）

電影有2類服務，一個是通過語音購買電影票，屬于多輪語音交互，一個是通過語音點播電影節目，單輪語音交互。討論多輪的時候順帶上單輪。

語音購買電影票，本文不討論語音下單支付。語音點播電影，本文不討論語音控制（暫停/播放/快進/換一個/音量控制）。

不討論與開發溝通、需求文檔、數據埋點、后臺工具接入、風控預警、支付訂單、GUI的設計……只討論如何做好多輪語音交互技能設計。

1、使用場景與用戶畫像

產品的基本功，怎樣的用戶在什么情況下，使用什么硬件設備，使用語音達成目標？

語音技能是專門對不同的群體而設計的，比如對盲人設計訂餐功能，比如專門為外賣/快遞小哥，設計打/接電話，群發短信的服務等，都是要考慮好用戶畫像。為方便大眾理解，以電影作為例子。

點播電影使用場景:

用戶在家/辦公室，使用智能電視/有屏音箱，通過語音點播電影。

用戶在車里，通過車機，使用語音點播電影。

在車里語音點播電影節目，可以是“播放喜羊羊第5集”給后座帶屏幕的小孩看。

主屏的車機只做操控，不適合播放任何電影，干擾司機駕駛（即使是副駕駛有觀影需求）這個就是一個權衡，必要的時候，還要通過攝像頭檢測司機的眼動以保證駕駛安全，當然自動駕駛到達某種程度，我們交付給用戶的體驗，又會進行改變。

同時也要考慮一下其他語義之間的沖突和關聯。比如說，“我想看窗外”（假設有個這個名字的電影，或者是誤識別）會不會跟“語音控制車窗打開”這類技能互相沖突。

買電影票使用場景:

用戶在車里通過語音購買電影票。

用戶在任意地方通過語音買電影票。

買電影票而言，用戶雖然是全程填槽，但是在家使用，和在車機使用是完全不同的場景。

在室內使用，買電影票，用戶沒有明確某個電影，話術可以是“為你找到如下電影”加展示列表的方案，然后用戶可以使用眼睛做篩選，手指滑動電影列表，點觸選場次、座位等。

在車內使用，用戶同樣沒有明確，我們盡量不希望干擾司機的視線和手指，會采用，報電影名的方案，“評分前三的是《電影1》《電影2》《電影3》你想看那一部？”這種選擇的方案，盡量保護司機的眼睛和手不受打擾，后面的設計邏輯以此類推。

買電影票買的是服務，用戶有明確某個電影，然后找電影院的需求。同樣有為了消遣時間（電影是其中一個選項），先找電影院，然后選擇看什么電影的需求。這些都是不同的場景行為。

這種就是在怎樣的場景下，用戶如何用語音技能服務，在設計技能的時候，這一類思考一定要到位，后面的所有設計，也是基于場景開展。

2、中控設計與業務邊界

添加一個技能并不是那么簡單，要站在全局角度去思考問題。

點播電影，從發起需求到電影播放。

買電影票，從發起需求到生成訂單進入支付環節。

此處存在幾種情況。

• 情況1、此前沒有，從0到1搭建一個新技能，如此業務處理就簡單。

• 情況2、已有一種技能存在，新增另外一個技能，要考慮并行情況。

比如當用戶說“我想看電影”，如果是情況1，單個技能則很容易處理。

但是如果是情況2，兩個技能同時存在，“我想看電影”就是一個模糊表述。

接下來的業務流程處理，就十分值得討論和考究了。

單個技能并不難，難得是如何處理好與其他已存在技能之間的關系。用戶在對話過程中的每一句話，都會被識別意圖。

用戶的第一句，使用顯性跳轉，直接進入對應的邏輯即可，這種情況非常容易處理，中控很容易根據用戶的意圖做分配行為。

難得是，用戶不使用顯性跳轉，采用模糊表述。

上面兩種選擇都是方案選擇，從實現難度上而言，從體驗層面而言，產品經理做得都是基于各種約束條件下的效用選擇。

以下兩種情況，用戶全程無意識，但是造成了，連續兩句話都是模糊表述的情況。

我們先假設自己的語音助手同時存在，電影點播和買電影票2個技能，來看看用戶連續2句話都是模糊表述的情況。

語言表述就是如此，隨場景和時間變化，在某些情況下表述，就是是模糊，過一段時間（比如院線排片下線）表述，就不會引起歧義。

當用戶模糊表述的時候，如果每次都采用追問的方案，就非常尷尬了，這個后面會講，一方面用戶在某些語境下實際上就是“你應該懂我”當下我所指的是什么，而計算機則未必明白。

所謂業務邊界，相對而言比較容易理解。

點播電影歸類于【語音&內容】，取決于接口方提供的作品，要考慮未來播放其他的內容的邊界。比如有些經典作品名，存在音樂歌曲、戲劇、有聲小說、電影、MV、等多種形式，而咱們做的技能，恰好又包含上述，且接口豐富每種資源都能夠搜到，那么就需要通過上下文的理解去處理好每一種指代，繼而做好邊界處理。

買電影票歸類于【語音&服務】，通過篩選電影院、作品名、場次、座位等，最終達成下單的結果，流程清晰明確，那么買電影票的其他相關服務，比如買爆米花可樂一類的零食，辦理影城的會員卡一類附加的，則是邊界外的內容。

往往把點播電影做好了，點播其他的音頻、視頻內容，也大同小異。同理買電影票做好了，買其他的（音樂會、演唱會、戲劇、景點）票，也大同小異。相對而言就是主槽位和輔槽位的變化不同。

一開始就窮盡所有情況，后續管理和添加技能庫也方便拓展，而一開始想得比較簡單，后續想要加想要改，那就麻煩得多了。不光說業務邏輯層麻煩，訓練數據也很麻煩。

故而一開始就講了，這一塊是全局性的考量。

3、槽位設計與對話設計

自然語言處理，本質是結構預測，基于用戶的表述，提取用戶的話術里面的詞槽，通過服務接口，完成后續行為。

對話設計是基于場景設計業務邏輯，通過對話管理，最終幫助用戶達成目標。

點播電影需求明確，直接得到結果的有：播放電影星球大戰、播放周星馳的功夫、播放電鋸驚魂第三部等等。

還有一些篩選的行為，好萊塢最近有什么新電影、我想看喜劇片/動作片、評分前10的好萊塢電影、詹姆斯卡梅隆導演的電影等，然后基于搜索結果，確認播放行為。

故而歸納出點播電影的槽位：[影片名]、[主演]、[導演]、[影片類別]、[評分]……

點播電影相對簡單，篩選后即可播放。而買電影票則復雜的多，畢竟買電影買的是服務，篩選條件較多。

常規來看，用戶定電影票的流程一般有如下兩種情況。

已經想好了看某個電影，然后基于此，尋找電影院。例如：我想看IMAX版本的阿凡達，基于此完成后續的追問，最終完成填槽行為。

另一種純粹是為了消遣時間，先找附近的電影院，然后基于此完成后續的追問，最終完成填槽行為。

繼而提煉出買電影票的槽位。

通過例句我們可以看出，輔助槽位是用來幫助主槽位做查詢行為的。

主槽位一般是服務于整體流程需求的進行設計，輔助槽位是基于接口情況，以及自身理解進行設計歸類。

對話設計分為兩個部分，定義主流程和對話管理。

點播電影，只有一個，即為影片，所有的服務都是為了選中影片而服務的，選中了就直接播放。而買電影票則是，因為其業務屬性，需要4個主槽位都填寫完畢。

主體流程設計基于用戶習慣，只要在后續的對話過程中，把4個主槽位確認完畢，即可完成買電影票的下單行為。

對話管理。此處是引用一段在其他文章里面的內容。

———————————————————————————————— 在對話服務過程中，反向管理用戶的表達，完善槽位的引導。例如在買電影票的場景，從需求到下單至少需要4個核心槽位。A電影名，B電影院，C場次，D幾張票。（選座可以提供默認規則）想要完成訂單的確認，則成功引導用戶填充ABCD四個槽位即可。好的完善和引導，則是：如果用戶填充了AB，AI應該追問CD的例子：我想看《魔童哪咤》，幫我在附近找個最近的電影院。此時AI需要展示哪幾個場次可以選擇，然后追問要買幾張票如果填充了ABC，應該追問D的例子：我想看《魔童哪咤》，附近找個最近的電影院，8點鐘左右開場的。此時AI只需要追問要買幾張票即可。ABCD四個主槽位，無論用戶的先后順序，先填充哪個槽位，后續能夠完善填充即可。人類的表述千奇百怪，無論多少個槽位，人類都可以組織語言聯合起來表述。亂序填充槽位才是智能化，自然表述的的基本要求。 ————————————————————————————————

自然語言處理中，用戶僅能依靠有限的語音提示以及短期記憶來完成操作。因此對話設計需要通過明確提示用戶需要進行的反饋，以及能進行的選擇，逐步的縮小用戶的對話走向，幫助用戶明確意圖，并完成最終的服務提供。

4、異常情況與自查清單

用戶按照正常情況來，一般而言都能夠完成任務。但是總會遇見異常情況的，服務的完整性需要保障，包含以下但不限于：

1、接口服務故障，導致的無法查詢。故障如何上報，或是自家公司運維層面的故障錯誤。

2、接口服務正常，查不到對應的東西，推薦近似內容規則如何設計。如某個系列電影被買斷，但是沒有播放版權，如何給予近似推薦。

3、用戶在對話過程中如果歧義表述，如何修復對話，并把業務拉回到正軌上。

4、未覆蓋話術如何兜底、沖突條件如何做取舍，模糊表述如何應對。例如：

• 有沒有團購券，爆米花，介紹一下這個電影的劇情。

• 幫我找一個距離我最遠的電影院，買一張最貴的電影票。

• 有沒有10塊錢以內的IMAX電影票。（顯然是不可能的事）

還有一些否定表述，雙重否定，前后矛盾的表述。

異常情況有太多種類型，分布于業務設計中的各個階段。

• 階段1：產品經理憑借業務理解和設計經驗去思考異常情況。

• 階段2：測試過程中，其他人員發現了異常情況。

• 階段3：產品上線后，用戶遭遇了異常情況。

由于業務類型太多，無法逐一窮舉。

但是在這個過程中，我們可以為自己設計一套業務的自查清單，來幫助自己完善思考的維度。

可以自己從經驗中提煉，也可以學習其他的規范，典型如《Google對話式交互規范指南》《阿里語音交互設計指南》《亞馬遜語音交互設計規范》一類是用來管理話術設計的清單。

清單越多，自己的專業度越好，交付的產品質量保障越好。

很多的東西都是自我不斷完善，總結提煉，復盤消化后，最終內化為自己的專業能力。

5、技能測試與版本迭代

通過了自查清單后，然后進入了內部流程測試，一般而言分為兩個測試步驟。

內行自測：產品經理（VUI設計師）自己編寫對話測試用例。

外行復測：找小白用戶（非而業務相關的行政人事等）自由放飛測試。

這2個過程中，往往會產出各種數據，業務邊界及異常情況，以及各種修改建議，然后重新迭代調整，直至數據和體驗達到一定標準后，即可更新上線。

上線前，依照流程標準，已經做好了數據埋點，并搭建好了完整的用戶對話log分析后臺。

上線后，通過業務后臺觀察業務數據，和實際真實用戶的表述，繼而迭代技能，提升體驗。

舉一個例子，是筆者在后續觀察用戶對話日志時的一些發現。

《速度與激情8》剛剛上映，用戶會表述是我想看速度與激情、速激、速8等等；《魔童哪咤》上映的時候，用戶的表述是，我想看哪咤的電影；《葉問3》上映的時候，用戶的表述會是，葉問。甚至是甄子丹的那個電影；

這些就是真實的用戶表述，此處就需要考慮這類應對方案，增加NER，模糊查詢，動態詞庫管理。最終完成語音交互技能的迭代。

這類問題如果有共性特征，我還會進行業務自查清單的迭代，當下次處理同樣類型的業務時，便可提前考慮到位。

從這個例子可以得出：“一開始就做好”相比“通過各種渠道反饋發現不好，然后通過迭代去做好”，從產品設計基本功上來看，根本是兩種境界。

再列舉一個筆者在開發過程中印象深刻的例子，。

我們在設計電影票技能的時候，內部曾經討論到，如果用戶需求明確，且一口氣完整滿足4個詞槽，是否應當直接給予結果？例如：我幫我買2張《魔童哪咤》的電影票，附近找個最近的電影院，晚上8點鐘左右開場的，隨便什么座位都行。

為了完成這個，我們花費了不少精力。從我們后臺的實際數據表現去看，實際上用戶并不會這么說，很少有用戶做多個復合條件疊加查詢的，且從來沒有用戶會一口氣說出4個詞槽！可以明確一個結論，我們此前的的一部分工作被浪費掉了！

從這個例子，我們可以得出一個思考：面對難題，每個人都能出方案，而難題有多種不同的解法，方案有優劣之分，話術覆蓋有先后順序，精力的分配有側重考量……

希望大家盡快達到這種境界，能從多個看似不同的方案中，挑選出不同情況下的最優解，即通過大家的復盤總結，迭代出自己的語音交互設計方法論。

關聯閱讀：

一篇文章深入理解VUI和GUI的優劣對比

面向NLP的AI產品方法論——尋找語音交互的業務場景

——DuerOS 相關——

• https://dueros.baidu.com/dbp

• DuerOS的零編程技能實現

• 揭秘“語音交互”背后的AI硬核黑科技！

• 《智能語音時代》的讀書筆記
  

• 再看語音交互設計

• 語音交互設計的一點認知
  

• 百度AI開發者大會之DuerOS 回顧
  

• AI開發者大會中的公開課解讀——DuerOS技能開發與CFC編程
  

• AI開發者大會中的公開課解讀——如何在DuerOS技能中實現用戶支付購買
  

• DPL 來了——百度2019AI開發者大會DuerOS公開課解讀之三
  

• 故事工廠在DuerOS技能開發中的應用——百度2019AI開發者大會DuerOS公開課解讀之四

• 企業賦能 ?AI 服務生活
  

• DuerOS 走進初夏的成都
  

• 放心用吧！淺談DuerOS的安全性
  

• 智能音箱場景下的性能優化
  

• 在校大學生能成為DuerOS 的獨立開發者嗎？
  

• 生動化你的表達——DuerOS中的SSML應用
  

• 用JavaScript打造AI應用-從Nodejs SDK 看DuerOS的技能開發

• 從Java SDK看DuerOS的技能開發

• 面向接口/協議？看DuerOS的技能開發

• 感知自然語言理解（NLU）

• 感知人工智能操作系統

總結

以上是生活随笔為你收集整理的面向NLP的AI产品方法论——如何设计多轮语音技能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。