从读框架到搭项目：基于 Ant Design X Vue 和 RICH 范式搭建 AI 前端工作台

前言

前面一段时间，我主要在做一件事：

先把 AI 组件框架看懂，再尝试基于它搭建一个更接近真实业务的 AI 前端项目。

一开始我并没有直接上来就写业务页面，而是先从框架本身开始看。

因为现在公司里做 Agent 产品，很多时候并不会从零开始造一套 AI UI 组件库，而是会基于已有的成熟框架进行选型、理解、改造和二次封装。

所以我的学习路线大致是这样的：

先了解现在有哪些 AI 前端组件框架；
再选定一个和公司技术栈更匹配的框架；
然后从一个具体组件开始读源码；
最后再把这个框架真正用到一个前端 AI 项目里。

目前我选择的基础框架是 Ant Design X Vue。

原因也比较直接：

公司主流技术栈是 Vue；
Ant Design 生态比较成熟；
Ant Design X 本身就是面向 AI 交互场景设计的；
它提供了消息气泡、输入框、会话列表、思考过程等常见 AI 组件；
后续如果要做公司内部二次封装，也比较容易找到切入点。

这篇文章主要做个承上启下的作用，承接前面几篇内容，简单总结一下：

前面做了什么；
为什么下一步要从"读组件"走向"搭项目"；
什么是 RICH 设计范式；
如何用 RICH 的思路去搭建一个 AI 前端工作台。

前面做了什么

前面的内容主要分成两个阶段。

第一个阶段，是了解框架。

我先大致看了 Ant Design X Vue 的项目结构，包括：

组件目录怎么组织；
每个组件一般包含哪些文件；
index.ts 是做什么的；
interface.ts 是做什么的；
Vue 单文件组件负责什么；
hooks 负责什么；
style 样式文件怎么组织；

这个阶段的目标不是把源码每一行都看懂，而是先建立一个整体印象。

比如看到一个组件目录时，至少能知道：

text 复制代码

index.ts        负责组件导出
interface.ts    负责类型定义
Bubble.vue      负责组件主体逻辑和模板
hooks           负责复用逻辑
style           负责样式生成

这样后面再看具体代码，就不会完全迷路。

第二个阶段，是以 Bubble 组件为例，具体学习怎么读一个组件。

Bubble 是 AI 对话界面里非常基础的组件，也就是消息气泡。

一个 AI 对话页面里，用户发出的问题、AI 返回的回答、loading 状态、打字机效果、操作按钮，最后基本都会落到消息气泡上。

所以我选择先从 Bubble 开始看。

围绕 Bubble，前面主要看了这些内容：

interface.ts：组件 props、类型、ref 是怎么定义的；
index.ts：组件如何导出；
Bubble.vue：组件主体如何接收 props、处理 slot、渲染内容；
content.ts：不同 variant 样式是怎么生成的；
useTypingConfig.ts：打字机配置是怎么处理的；
useTypedEffect：内容是如何一点点输出的；
BubbleList：多条消息是怎么管理和展示的；
header / footer / actions：消息顶部、底部和操作区怎么扩展。

这个过程让我慢慢意识到：

学组件源码，不是为了背源码，而是为了知道以后业务要改哪里。

比如：

想改消息样式，就看 variant、shape、style 文件；
想加复制、重试、反馈按钮，就看 footer 或 actions 扩展；
想改打字机效果，就看 typing 相关 hooks；
想改消息列表滚动，就看 BubbleList；
想支持不同角色，就看 roles 配置。

当这些点串起来之后，框架就不再只是一个黑盒。

为什么接下来要开始搭项目

只读组件源码有一个问题：

很容易陷入细节。

比如只看 Bubble，会一直纠结：

这个类型为什么这么写；
这个 &-filled 是什么意思；
token 从哪里来；
slot 和 props 谁优先；
computed 返回的到底是什么；
hooks 里面的状态怎么变化。

这些问题当然重要，但如果一直停留在单个组件里，就很难理解它在真实产品中的位置。

因为在实际 AI 产品里，用户看到的不是一个孤立的 Bubble。

用户看到的是一个完整工作台：

左边有历史会话；
中间有对话消息；
底部有输入框；
AI 回复时有 loading；
复杂任务有执行过程；
生成结果可能展示在右侧；
文件、代码、页面预览可能需要单独承载；
用户还需要复制、重试、反馈、确认、应用结果。

也就是说，真实产品不是"一个组件"，而是"一组组件组成的体验"。

所以接下来更重要的是：

把前面读过的组件真正组合起来，搭一个完整的 AI 前端项目原型。

这也是我现在准备做的事情：基于 Ant Design X Vue 搭建一个类似 Agent 工作台的前端项目。

为什么需要 RICH 范式

在搭 AI 产品之前，还有一个问题需要先想清楚：

AI 前端页面到底应该怎么设计？

如果只是把页面做成一个聊天框，其实是不够的。

因为 Agent 产品和普通聊天产品不太一样。

普通聊天产品的核心是：

text 复制代码

用户问一句，AI 回一句。

但 Agent 产品往往是：

text 复制代码

用户表达一个目标，AI 理解目标、拆解任务、执行步骤、生成结果，用户再确认和使用结果。

这时候，界面就不能只负责"展示聊天内容"，还需要负责：

帮助用户表达意图；
告诉用户 AI 是什么角色；
展示 AI 正在做什么；
让用户能够确认和干预；
把最终结果以合适的 UI 形式展示出来。

这也是 RICH 范式的价值。

Ant Design X 官方提出的 RICH 设计范式，主要包含四个要素：

要素	含义
Role	角色
Intention	意图
Conversation	对话
Hybrid UI	混合界面

简单理解，RICH 不是一个具体组件，也不是一段代码。

它更像是一个思考 AI 产品界面的框架。

它提醒我们，设计 AI 产品时不能只盯着聊天框，而要同时考虑：

AI 在产品中扮演什么角色；
用户真正想完成什么任务；
用户和 AI 如何通过对话逐步对齐；
哪些内容适合用聊天展示，哪些内容更适合用传统 UI 展示。

R：Role，角色

Role 指的是 AI 在产品里扮演什么角色。

它不是简单地给 AI 起一个名字，而是要回答：

这个 AI 到底是助手、客服、代码生成器、数据分析师，还是业务流程执行者？

角色不同，界面设计也会不同。

比如：

客服机器人更强调问题解答和服务引导；
编程助手更强调代码、文件、执行日志；
数据分析助手更强调图表、指标和结论；
零代码生成助手更强调需求理解、页面结构、生成产物和预览。

如果我要做的是一个 Zero Code AI 工作台，那么 AI 的角色就不是普通聊天助手，而更像：

一个帮助用户生成应用页面的前端搭建助手。

这个角色会影响很多 UI 细节。

比如消息气泡中可以展示：

AI 名称；
当前能力说明；
执行阶段；
生成目标；
相关产物；
操作按钮。

在 Ant Design X Vue 里，Role 可以和 BubbleList 的 roles 配置对应起来。

比如：

ts 复制代码

const roles = {
  user: {
    placement: 'end',
    variant: 'filled',
  },
  assistant: {
    placement: 'start',
    variant: 'borderless',
  },
};

这里的 user 和 assistant，本质上就是在告诉消息列表：

用户消息应该怎么展示；
AI 消息应该怎么展示；
不同角色的头像、位置、样式是否不同。

所以从 RICH 的角度看，roles 不是单纯的样式配置，它其实承载了产品中的"角色感"。

I：Intention，意图

Intention 指的是用户想要完成什么。

AI 产品里，用户输入的往往不是一个非常明确的按钮操作，而是一段自然语言。

比如：

text 复制代码

帮我做一个企业官网。

这句话看起来很简单，但里面其实有很多不明确的地方：

是什么行业的企业？
需要哪些页面？
风格偏科技还是商务？
是否需要登录？
是否需要后台管理？
是否需要表单提交？
是否需要移动端适配？

所以 AI 产品的界面需要帮助用户更好地表达意图。

在前端页面上，这可以通过很多方式实现：

欢迎语告诉用户可以做什么；
prompt 提示用户怎么提问；
输入框支持附件、快捷指令；
发送前展示用户输入内容；
AI 回复时拆解用户需求；
对不明确的地方继续追问。

在 Ant Design X Vue 中，和意图表达相关的组件主要有：

Sender：用户输入；
Prompts：快捷提示；
Welcome：欢迎引导；
Attachments：附件输入；
Suggestion：建议指令。

对于 Zero Code 场景来说，Intention 可以落到这些功能上：

用户输入一句应用需求；
系统给出常用生成模板；
用户可以上传参考文件；
AI 将模糊需求拆成页面结构；
AI 生成前让用户确认关键配置。

所以输入框不是简单的 textarea。

它是用户表达意图的入口。

C：Conversation，对话

Conversation 指的是用户和 AI 之间如何通过对话持续推进任务。

很多人一开始会把 AI 对话理解成：

text 复制代码

消息列表 + 输入框

但真实场景里，对话不只是展示文本。

它还包括：

历史会话管理；
当前会话上下文；
多轮追问；
用户修改需求；
AI 重新生成；
中断生成；
针对某条消息继续操作；
保留之前的生成记录。

所以在 AI 工作台里，Conversation 通常对应两个部分：

第一，是左侧的会话列表。

比如使用 Conversations 组件展示历史记录：

vue 复制代码

<Conversations
  :items="conversationItems"
  :active-key="activeKey"
/>

第二，是中间的消息流。

比如使用 BubbleList 展示当前会话里的多条消息：

vue 复制代码

<BubbleList
  :items="messages"
  :roles="roles"
/>

在我的项目里，左侧历史会话和中间消息列表就是 Conversation 这一层的主要体现。

它解决的是：

用户如何在多轮对话中持续推进一个任务。

H：Hybrid UI，混合界面

Hybrid UI 是我觉得最重要的一点。

它提醒我们：

AI 产品不应该只有聊天框，也不应该完全抛弃传统图形界面。

很多任务用自然语言表达很方便。

比如：

text 复制代码

帮我生成一个企业官网首页。

但很多任务用传统 UI 操作更清楚。

比如：

选择主题色；
查看页面预览；
切换文件；
下载产物；
确认执行；
编辑表单字段；
查看执行日志；
对某个模块进行局部修改。

这些内容如果全部塞进聊天消息里，用户反而会很累。

所以更合理的做法是：

对话负责表达和推进，界面负责展示、确认和操作。

这就是混合界面的思路。

在 Zero Code AI 工作台里，我会把页面设计成三栏结构：

text 复制代码

左侧：历史会话
中间：AI 对话
右侧：执行过程和生成产物

中间对话区适合放：

用户输入；
AI 回复；
需求拆解；
任务说明；
简短结论。

右侧面板适合放：

生成页面预览；
文件列表；
代码片段；
执行步骤；
附件；
产物状态；
发布入口。

这样用户既可以通过自然语言和 AI 沟通，也可以通过界面直接查看和操作结果。

这比单纯聊天框更适合 Agent 产品。

用 RICH 重新看 AI 工作台

如果用 RICH 来重新拆我的 AI 前端项目，大致可以这样理解：

RICH 要素	页面中的体现
Role	AI 是一个应用生成助手，不是普通聊天机器人
Intention	用户通过输入框、快捷提示、附件表达生成需求
Conversation	左侧历史会话 + 中间消息流承载多轮交互
Hybrid UI	右侧过程面板、产物预览、操作按钮承载图形界面能力

这样一看，页面结构就比较清楚了。

它不是随便摆三个区域，而是每个区域都有自己的职责：

左侧解决"我在哪个任务里"；
中间解决"我和 AI 怎么沟通"；
右侧解决"AI 做了什么，结果在哪里"。

这也是我后面搭项目时会遵循的主线。

当前项目准备怎么搭

我准备新建一个前端项目，用 Ant Design X Vue 来搭一个 Zero Code AI 工作台原型。

这个项目不会一开始就接完整后端，也不会一口气把所有业务写完。

当前阶段先做前端骨架：

路由；
主布局；
顶部导航；
历史会话；
消息列表；
输入框；
AI loading；
打字机回复；
执行过程；
右侧产物区域；
基础视觉风格。

项目结构上，会尽量按照比较规范的方式组织。

比如：

text 复制代码

src
├── components
├── features
│   └── workbench
│       ├── components
│       ├── data
│       └── types.ts
├── layouts
├── pages
├── router
├── styles
└── main.ts

其中 features/workbench 会作为 AI 工作台的核心业务模块。

这样后面继续扩展接口、store、hooks、组件封装时，不会全部堆在页面文件里。

和前面 Bubble 学习的关系

这一步不是推翻前面的学习，而是把前面学过的东西用起来。

比如前面读过 Bubble 之后，就能更清楚地知道：

用户消息和 AI 消息怎么区分；
variant 可以控制不同气泡样式；
roles 可以控制不同角色的展示；
footer 可以加复制、重试、反馈按钮；
typing 可以实现打字机输出；
loading 可以表示 AI 正在生成；
BubbleList 可以管理多条消息和滚动。

这些源码阅读的结果，最后都会落到实际项目里。

举个例子：

vue 复制代码

<BubbleList
  :items="messages"
  :roles="roles"
  :auto-scroll="true"
>
  <template #footer="{ item }">
    <div v-if="item.role === 'assistant'">
      <button>复制</button>
      <button>重新生成</button>
      <button>反馈</button>
    </div>
  </template>
</BubbleList>

这段代码背后，其实就对应了前面几篇文章学过的内容：

BubbleList 怎么接收 items；
roles 怎么控制角色；
slot 怎么扩展内容；
footer 怎么放操作区；
AI 消息为什么需要 actions。

所以读源码和搭项目不是两件割裂的事情。

读源码是为了知道框架能做什么、哪里能改。

搭项目是为了知道业务真正需要什么、哪些地方值得改。

后续准备怎么继续写

接下来我会从"搭项目"的角度继续推进。

后面的文章可以按这个顺序写：

项目初始化：基于 Vue 3 + Ant Design X Vue 搭建 AI 工作台骨架；
页面布局：搭建左侧历史、中间对话、右侧产物区；
消息流：用 BubbleList 管理用户消息和 AI 消息；
输入区：用 Sender 实现用户输入、发送、停止生成；
执行过程：用 ThoughtChain 展示 AI 的任务拆解；
产物区：设计右侧文件、预览、结果应用区域；
样式统一：抽离公司内部的视觉 token；
组件封装：把业务中的 AI 交互沉淀成内部组件。

这个顺序会比直接改源码更贴近真实业务。

因为公司里真正需要的，往往不是"我看懂了一个组件"，而是：

我能基于组件库搭出一个符合业务需求的 AI 前端工作台，并且知道后续哪里可以二次开发。

总结

前面我主要做的是从框架和组件源码入手，理解 Ant Design X Vue 的基本结构。

以 Bubble 为例，我学习了一个 AI 消息组件从类型定义、组件导出、主体渲染、hooks 到样式生成的大致流程。

这一步的价值在于：

不再把组件库当黑盒；
知道业务要改样式时该看哪里；
知道要扩展交互时该从哪里入手；
对 AI 消息组件有了比较完整的认识。

但只看组件还不够。

接下来更重要的是把它真正用起来。

所以后续我会基于 Ant Design X Vue 搭建一个 AI 前端工作台原型，并且用 RICH 范式作为设计思路：

用 Role 明确 AI 的产品角色；
用 Intention 设计用户表达需求的入口；
用 Conversation 承载多轮对话和上下文；
用 Hybrid UI 把对话、过程、产物和操作结合起来。

这样，前面的源码学习就能自然过渡到真实项目搭建。

也就是说，我的目标不是单纯学习一个组件，而是逐步完成：

从框架认知，到组件理解，再到业务落地和二次封装的完整前端实践。

从读框架到搭项目：基于 Ant Design X Vue 和 RICH 范式搭建 AI 前端工作台