当前位置：首页 > article >正文

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

article 2025/3/17 7:12:20

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”功能。

为了优化用户体验，我们需要在推理过程中提供实时的反馈机制。以下是一些可能的解决方案：

进度指示器：在推理过程中，前端可以显示一个进度条或加载动画，告知用户系统正在处理请求。这可以帮助用户理解当前的状态，并减少等待的焦虑感。
分阶段反馈：将推理过程拆分为多个阶段，并在每个阶段完成后向前端发送部分结果。例如，可以先返回一个初步的文本响应，然后再逐步补充图表或其他复杂内容。这样，用户可以在等待最终结果的同时，先看到部分内容。
状态更新：在推理过程中，系统可以定期向前端发送状态更新，例如“当前的推理结果”、“正在分析数据”、“正在生成图表”等。这些状态信息可以帮助用户了解当前的操作进展。
交互式等待：在等待过程中，可以提供一些轻量级的交互功能，例如让用户补充缺少的参数，预览部分数据。这不仅可以减少用户的等待时间，还能增强他们的参与感。
错误提示与重试机制：如果推理过程中出现错误，系统应能及时反馈给用户，并提供重试或调整的选项。这可以避免用户因为长时间的等待而感到沮丧。