本系列文字是一位創業者的投稿《面向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個詞槽！可以明確一個結論，我們此前的的一部分工作被浪費掉了！
從這個例子，我們可以得出一個思考：面對難題，每個人都能出方案，而難題有多種不同的解法，方案有優劣之分，話術覆蓋有先後順序，精力的分配有側重考量……
希望大家儘快達到這種境界，能從多個看似不同的方案中，挑選出不同情況下的最優解，即通過大家的覆盤總結，迭代出自己的語音交互設計方法論。
關聯閱讀：
——DuerOS 相關——
https://dueros.baidu.com/dbp