談了好幾天的學習之後, 來分享一下自己的實戰經驗吧, 今天跟各位分享的是我所帶領與整合的雲端團隊, 過去的一年多裡三次大改版的Alexa Custom Skill的上架送審經驗, 其實如果你的對話設計, 沒有很多Intent, 也沒有很多層對話, 其實應該也不是太困難的事, 但我們設計的Custom Skill是為了要配合操作我們的IoT產品所設計的, 也因此在一開始光是在想說, Alexa Skill Certification Team又沒有我們家的產品, 他們怎麼知道Skill該如何操作, 講了這句話之後, IoT device又會伴隨做了什麼動作呢? 就問了很多種客服管道...甚至查閱論壇, 但最終的經驗顯示 - "他們完全不需要裝置的", 因為他們審查是看"對話邏輯", 以及相關的基本要求規範...所以其實你講了A動作, 也回應了完成A動作, 但實際裝置上是做了B動作, 那也是你lamda設定的問題XD (他們審查時也不會知道....誤@@) 總之, 若是你的skill是跟控制裝置有關的, 不用去想要怎麼送裝置去審查了, 他們也不可能去接受(收納)全世界如雪片般飛來的各種裝置的

第二個特別的經驗是, 其實第一次送審是最複雜的, 因為第一次你必須先完成各種欄位的填寫說明, 與RD一起檢查Checklist上的每一項檢查事項是否都完成, 對話結束後該要繼續listening的要繼續listening, 該要有prompt的要有該有的回應, 該結束的對話就不能再繼續, 這些對話設計上所透露出讓User直覺應該要繼續講話呢? 還是不需要繼續講話了的"對話邏輯"是審查的重點, 而且我們在猜說是人工審查, 而不是機器人審查, 因為從三次送審的經驗上來看, 每次review都會被發現之前設計的內容不被認可的地方, 例如有審查員認為這句對話應該要結束, 不該繼續, 可是下次又有審查結果說, 這邊應該要繼續才對...當然, 最好的做法, 不是review教你改怎樣就怎樣, 這樣下次又可能被推翻, 最好的就是重新設計Utterance的語法, 不要模凌兩可, 讓user不混淆,

第三個值得一提的經驗, 就是審查時間了, 雖然Alexa網頁上有表定的好幾個工作天, 但根據經驗, 或許第一次較久, 等了兩三天, 之後兩次審查, 都大概下班前送出審查, 隔天或隔兩天就會收到第一次的Review結果, 修完Bug之後, 再送審基本上都很快, 幾乎等一天(或許是時差的關係?) 就可再次收到審查結果了, 而且基本上bug是收斂的, 就是隨著設計經驗越來越豐富, 還加入了state management等等進階功能, 但幾乎都能在預計的三天內完成審查, 然後上架更新公開, 因為自己本身介入VUI的設計部分較多, 所以當bug issue是對話邏輯問題時, 通常就第一時間與RD討論該怎麼改, 另外作為PM, 那些有的沒的敘述欄位與檢查表格也得自己去張羅, 該請英文Review去Review, 幾次下來也基本上形成了一個上架審查SOP的經驗, 當然過程中沒說的是, 除了正式的DQA部門在送審前協助檢查各種可能的bug之外, 自己也是逐句逐句的去測試, 當自己是QA或user, 才能完全掌握整個skill的狀況與品質了!