設計和控制對話流程

適用于: SDK v4

在傳統應用程式中,使用者介面 (UI) 包含一系列畫面,而單一應用程式或網站可以視需要使用一或多個畫面來與使用者交換資訊。 大部分的應用程式都會從使用者最初登陸的主畫面開始,而該畫面會提供流覽,以引導其他畫面使用各種功能,例如啟動新訂單、流覽產品或尋求協助。

如同應用程式和網站,Bot 具有 UI,但是由訊息 而非螢幕所組成 。 訊息可能包含按鈕、文字和其他元素,或完全以語音為基礎。

雖然傳統應用程式或網站可以一次要求螢幕上的多個資訊片段,但 Bot 會使用多個訊息收集相同的資訊量。 如此一來,從使用者收集資訊的程式就是主動體驗:其中一個使用者正在與 Bot 進行作用中的交談。

設計良好的 Bot 會有自然的交談流程。 Bot 應該能夠順暢地處理核心對話,並能夠正常處理中斷或切換主題。

程式性對話流程

與 Bot 的對話可以專注于 Bot 嘗試達成的工作,這稱為程式性流程。 Bot 會詢問使用者一系列問題,以收集處理工作之前所需的所有資訊。

在程式性對話流程中,您可以定義問題的順序,而 Bot 會依照您定義的順序來詢問問題。 您可以將問題組織成邏輯群組,以保留程式碼 cMicrosoft Entralized,同時持續專注于引導對話。 例如,您可以設計一個模組來包含可協助使用者流覽產品和個別模組的邏輯,以包含可協助使用者建立新訂單的邏輯。

您可以將這些模組結構化,以任何您想要的方式流動,範圍從自由格式到循序。 Bot Framework SDK 提供對話方塊程式庫,可讓您建構 Bot 所需的任何交談流程。 程式庫包含 瀑布式對話方塊 ,可建立一連串的步驟,以及詢問使用者問題的提示。 如需詳細資訊,請參閱 對話方塊程式庫

Diagram comparing application GUI flow against bot conversation flow.

在傳統應用程式中,所有專案都以 畫面開始。 主畫面會叫用 新的訂單 畫面。 新的訂單畫面會保持控制狀態,直到它關閉或叫用其他畫面,例如 產品搜尋 畫面。 如果新的訂單畫面關閉,則會將使用者傳回主畫面。

在使用對話的 Bot 中,所有專案都會 以根對話 開始。 根對話會叫用 新的訂單對話方塊 。 此時,新訂單對話方塊會控制對話,並維持控制狀態,直到它關閉或叫用另一個對話方塊,例如 產品搜尋對話方塊 。 如果新的順序對話方塊關閉,交談的控制權會傳回根對話。

如需如何使用對話程式庫實作交談流程的範例,請參閱 實作循序對話流程

處理中斷

假設使用者會以整齊有序的方式逐一執行程式性工作,這很誘人。 例如,在使用對話的程式性對話流程中,使用者將會從根對話開始,並叫用新的訂單對話方塊。 從新的訂單對話方塊中,他們會叫用產品搜尋對話方塊。 然後,選取產品搜尋對話方塊中所列的其中一個結果時,會叫用新的訂單對話方塊。 完成訂單之後,他們會回到根對話。

雖然使用者一律會移動如此線性、邏輯路徑,但很少發生。 人員不一定會依序通訊。 他們往往經常改變他們的想法。 請考慮下列範例:

Example of a user asking a question in response to a question from the bot.

雖然 Bot 可能以程式為中心,但使用者可能會決定執行完全不同的動作,或詢問可能與目前主題無關的問題。 在上述範例中,使用者會詢問問題,而不是提供 Bot 預期的是/否回應。 Bot 應該如何回應?

  • 堅持使用者先回答問題。
  • 忽略使用者先前所做的一切,重設整個對話堆疊,然後嘗試回答使用者的問題,從頭開始。
  • 嘗試回答使用者的問題,然後返回該是/否的問題,然後嘗試從該處繼續。

這個問題沒有 正確的 答案,因為最佳解決方案將取決於您案例的具體細節,以及使用者如何合理預期 Bot 回應。 瞭解如何處理 Bot 的使用者中斷 ,其設計目的是要處理某些類型的中斷。

讓交談過期

有時候從頭開始重新開機交談會很有用。 例如,如果使用者在特定時段後沒有回應。 結束交談的不同方法包括:

  • 追蹤上次從使用者收到訊息的時間,並在收到使用者下一則訊息時,如果時間大於預先設定的長度,則清除狀態。
  • 使用儲存層功能,例如 Cosmos DB 的 生存 時間功能,在預先設定的時間長度之後清除狀態。

如需詳細資訊,請參閱如何 讓交談 過期。

下一步

管理使用者跨對話流覽和設計對話流程的方式,讓使用者能夠達成其目標(即使是以非線性方式),是 Bot 設計的根本挑戰。 設計 Bot 流覽 文章會檢閱設計不佳的流覽的一些常見陷阱,並討論避免這些陷阱的策略。