Chat-Driven Business：靈活交互的新范式

1. 引言

一次偶然的機會，讀到了CSDN上的一篇文章，自定義markdown的展示(很遺憾，時間有點久，找不到具體的鏈接了），當時我覺得這很有啟發意義，因為我做的cli_assistant就是以markdown的形式返回的，自定義markdown的展示意味著可以有更加豐富的展示內容；

又是一次偶然的機會，在和一位銷售老總聊業務功能時，我發現已有的系統功能和他的描述即相符合又相去甚遠。說“符合”是因為他所描述的功能，我們的系統都支持；說相去甚遠，是因為我們的系統中沒有一個頁面能夠和他的訴求相吻合。也就是說，從用戶的角度來看，實現這一功能需要經歷多個頁面的跳轉，結合上下文輸入參數，整個過程復雜且耗時，體驗并不友好。

當這兩個東東相互碰撞時，“Chat-Driven Business”主題便迎面向我走來。

2. 問題背景: 現有系統的局限性

2.1. 頁面布局的歷史淵源

頁面布局的概念可以追溯到互聯網的早期，甚至更早的印刷時代。在Web 1.0時代，頁面是信息展示的基本單位，用戶通過點擊鏈接從一個頁面跳轉到另一個頁面。這種設計模式在當時的技術條件下是合理的，因為它簡化了信息的組織和展示。然而，隨著互聯網技術的發展，用戶對信息獲取的效率和交互體驗的要求越來越高，頁面布局的局限性逐漸顯現。

頁面布局的本質是將信息分割成多個獨立的單元，每個單元（頁面）負責展示特定的內容。這種設計模式在信息量較小、用戶需求單一的情況下是有效的。然而，隨著業務復雜度的增加，用戶需要在多個頁面之間頻繁切換，才能獲取完整的信息。這不僅增加了用戶的操作負擔，還降低了系統的使用效率。

2.2. 基于頁面的框架的局限性

基于頁面的框架通常采用從抽象到具體、從大類到細類的邏輯來組織信息。這種展示方式在理論上是合理的，因為它符合人類對事物的認知邏輯。然而，在實際的業務場景中，用戶的需求往往是多維度的，涉及多個特性或大類。例如，在討論一個銷售業務時，用戶可能需要同時查看銷售數據、客戶信息、產品庫存等多個維度的信息。

在現有的頁面布局下，用戶需要熟悉系統的結構，并主動打開多個頁面，才能獲取完整的信息。這不僅要求用戶具備較高的系統操作技能，還要求用戶能夠準確地判斷需要打開哪些頁面。在大多數情況下，用戶可能只打開了部分頁面，導致系統功能無法充分發揮。換句話說，現有的系統在大部分情況下，相比于最初的設計，可能只發揮其中的一部分價值。

此外，基于頁面的框架還存在以下問題：

信息割裂：信息被分散在多個頁面中，用戶需要手動整合，增加了認知負擔。
操作繁瑣：用戶需要在多個頁面之間頻繁切換，操作步驟復雜，降低了使用效率。
靈活性不足：頁面布局固定，無法根據用戶的具體需求動態調整展示內容。

2.3. 用戶需求的動態性與系統設計的靜態性矛盾

用戶需求的動態性與系統設計的靜態性之間存在矛盾。現有的系統設計往往基于通用的業務邏輯，無法滿足不同用戶的個性化需求。例如，銷售老總可能需要快速查看銷售數據，而財務總監可能需要詳細的分析報告。在現有的頁面布局下，系統無法根據用戶的具體需求動態調整展示內容，導致用戶體驗不佳。

此外，用戶的需求往往是動態變化的，現有的系統設計無法快速響應這些變化。例如，在銷售旺季，用戶可能需要重點關注銷售數據，而在淡季，用戶可能需要關注庫存管理。現有的系統設計無法根據業務場景的變化動態調整展示內容，導致系統功能無法充分發揮。

當然，在低代碼平臺的加持下，這種矛盾在一定程度上得到了緩解，但仍然不能從根本上解決這對矛盾。

3. 解決方案

隨著ChatGPT（DeepSeek）等大語言模型的誕生與流行，對話式交互有可能成為解決傳統頁面布局局限性的有效方案。

通過對話的方式，用戶可以直接輸入訴求，系統則通過大模型理解用戶意圖，并返回相應的結果。這種交互方式不僅簡化了用戶操作，還打破了傳統頁面布局的束縛，能夠根據用戶的具體需求動態返回可交互的UI，從而提升系統的靈活性和用戶體驗。

對話式交互的核心在于用戶可以通過自然語言表達需求，而無需熟悉復雜的頁面結構和操作流程。例如，銷售老總可以直接輸入“查看本季度銷售數據”，系統會自動理解并返回傳統頁面上的銷售表格部分，沒有復雜的查詢條件。

當然，我也是在摸著石頭過河，上面所說的，看似已經勾勒出了一個解決方案，但從理論到實踐，這僅僅是邁出了第一步。如果想要真正落地，探索的旅程才剛剛開始。

下面，將從自然語言處理（NLP）、UI展示框架這兩個方面，對解決方案進行進一步的討論。
沒有“頁面”的束縛，對話式交互可以根據用戶的輸入，動態返回相關的傳統交互元素（如表格、圖表、表單等），從而滿足用戶的個性化需求。

3.1 自然語言處理（NLP）與用戶意圖理解

大模型的核心作用

大模型（如DeepSeek）在對話式交互中扮演著至關重要的角色。它能夠分析用戶的自然語言輸入，并將其轉化為可執行的意圖。例如，當用戶輸入“查看上個月的銷售數據”時，大模型如何準確地識別出用戶的意圖是“查詢銷售數據”，并提取關鍵參數“上個月”？這是我們需要解決的一個問題。

這個問題已經在我的Demo階段，通過Deepseek大模型已經實現，并且命中率很高。

具體的方法是在Prompt中，加入業務系統的參數，以及參數的中文邏輯，然后讓Deepseek去匹配相應的數據。

上下文管理

在多輪對話中，如何確保系統能夠保持邏輯一致性？例如，用戶在查詢銷售數據后，可能會進一步詢問“環比增長了多少？”，系統需要結合之前的上下文給出準確的回答。如何實現這種上下文的無縫銜接，是提升用戶體驗的關鍵。

這個問題，解決方案有不少，例如“對話狀態跟蹤”，“記憶網絡”，“上下文嵌入”。但這些方案都需要落地不斷的實驗和調試，才可能得到能夠用于產品的結果。

意圖分類與實體抽取

通過意圖分類模型，系統如何將用戶輸入歸類為具體的業務功能（如“查詢數據”“生成報告”等）？同時，如何通過實體抽取技術提取關鍵參數（如時間范圍、地區等）？這些技術的實現細節將直接影響系統的準確性和效率。

對于這些問題，我目前使用的是最簡單粗暴的信息分類算法–余弦相似度，但最終可能還是需要通過微調模型，添加分類器等方式，最終，也是要經過多輪的對比和調試之后，才可能得到一個可用于商用的結果。

這個環節尤為重要，因為用戶的輸入最終要落實到系統的功能上，我們不可能（至少現階段是這樣）讓大模型幫我們臆想出一個功能或者數據，然后將其返回給用戶。而系統API是我目前認為的系統功能的最小粒度，即大模型返回的內容中所包含的數據，表單等內容，最終都是以這些API為基礎返回的。

另外，還有一個重要的原因，API是可測試的。

3.2 UI展示框架與Markdown渲染

如今，大模型返回的文本內容基本都采用markdown格式，因為markdown是一種成熟且可輕松轉換為HTML DOM的格式。

然而，由于我們采用對話方式返回業務交互的UI元素給用戶，傳統的markdown格式已無法滿足我們的需求。，比如:

{ "param": {...}, "api": { "url": "/business/orders", "method": "post" }, "parsingMethod": "orders" }

上述代碼是我在Demo中使用的markdown內容，我需要將其渲染成一個折線圖。但顯然，目前的markdown解析器無法實現這一功能，因此我們需要對現有的UI框架進行進一步的定制和改造。

但這改造不僅限于markdown本身的渲染部分，還可能包括整個對話過程的展示部分。

在現階段的Demo中，我們采用了復合推理的方式來生成最終的內容，整個過程耗時10秒鐘左右。然而，由于這一推理過程對前端用戶完全不可見，用戶可能會在屏幕前等待5到20秒不等的時間，卻沒有任何實時的反饋。這種等待體驗顯然不夠理想，尤其是在現實的業務場景中，推理過程可能會更加復雜，耗時也更長。如果用戶在等待過程中沒有任何視覺或交互上的反饋，他們很可能會失去耐心，進而放棄使用“Chat-Driven Business”功能。

為了優化用戶體驗，我們需要在推理過程中提供實時的反饋機制。以下是一些可能的解決方案：

進度指示器：在推理過程中，前端可以顯示一個進度條或加載動畫，告知用戶系統正在處理請求。這可以幫助用戶理解當前的狀態，并減少等待的焦慮感。
分階段反饋：將推理過程拆分為多個階段，并在每個階段完成后向前端發送部分結果。例如，可以先返回一個初步的文本響應，然后再逐步補充圖表或其他復雜內容。這樣，用戶可以在等待最終結果的同時，先看到部分內容。
狀態更新：在推理過程中，系統可以定期向前端發送狀態更新，例如“當前的推理結果”、“正在分析數據”、“正在生成圖表”等。這些狀態信息可以幫助用戶了解當前的操作進展。
交互式等待：在等待過程中，可以提供一些輕量級的交互功能，例如讓用戶補充缺少的參數，預覽部分數據。這不僅可以減少用戶的等待時間，還能增強他們的參與感。
錯誤提示與重試機制：如果推理過程中出現錯誤，系統應能及時反饋給用戶，并提供重試或調整的選項。這可以避免用戶因為長時間的等待而感到沮喪。