一、引言：云原生时代的“界面效率 + 智能交互”命题

当企业数字化全面转向云原生架构时，前端不再只是“画页面”的角色，而成为承载业务体验、链接后端能力、编排智能服务的关键一环。

• 一方面，云控制台、运维平台、B 端管理系统等复杂中后台应用，对界面一致性、交互效率、可维护性提出了更高要求；
• 另一方面，生成式 AI、智能助手、大模型应用迅速涌现，“怎么把 AI 稳定、可控、可解释地呈现在前端”成为新的挑战。

在这一背景下，华为云围绕前端体验构建了两条互补的技术生态：

• DevUI：面向企业中后台的前端解决方案，提供设计系统 + 组件库 + 工程化工具链，主打高一致性界面与高效开发；
• MateChat：面向智能化场景的 UI 组件库与体验体系，为生成式 AI 提供统一的对话交互语言和可复用的前端能力。

两者一静一动：

• DevUI解决“如何快速、稳定地搭好企业级前端界面”；
• MateChat解决“如何在这些界面中，以专业且一致的方式嵌入 AI 能力”。

本文将从架构设计、组件生态、实战落地与创新探索四个维度，系统展开 DevUI 与 MateChat 的实践方法，并重点探讨在云原生场景中如何实现两者的协同，让“界面效率”和“智能交互”形成一条完整的技术闭环。

相关官方地址汇总如下：

• MateChat：https://gitcode.com/DevCloudFE/MateChat
• MateChat官网：https://matechat.gitcode.com
• DevUI官网：https://devui.design/home

声明：如上内容部分配图来源官网及公开互联网，若有侵权，请联系删除！

二、DevUI：企业级前端界面的“基建工程”

2.1 DevUI 的定位与设计理念

从官方定义看，DevUI 是“一款面向企业中后台产品的开源前端解决方案”，不仅包含组件库，还包括完整的设计系统与最佳实践。

核心特征可以概括为三点：

1. 企业级设计系统

   • 提供统一的设计规则、组件规范、图标库与设计 Token；
   • 通过设计系统让设计与开发共享同一套语言，减少沟通与返工。

2. 丰富的组件生态

   • 提供覆盖中后台常见场景的高频组件：表格、表单、弹窗、导航、图表、步骤条等；
   • 提供大量业务增强能力：虚拟滚动、树表、穿梭框、复杂筛选、步骤流程等。

3. 多技术栈支持（但重心在 Angular & Vue）

   • 已有成熟的 Angular 版本（ng-devui），官方支持到 Angular 16+；
   • 逐步完善 Vue 生态（vue-devui），同时业界资料显示正向 React 拓展。
   • 在本期内容大纲要求语境下，可以明确：DevUI 的主战场仍是 Angular 与 Vue。

这意味着：在一个企业云控制台项目中，你可以把 DevUI 视为“设计规范 + 组件库 + 工程化方法”的综合方案，而不是单纯的 UI 组件集合。

2.2 高频组件进阶：表格、表单、弹窗的“深水区用法”

在 B 端系统中，页面的 70% 往往由 表格 + 表单 + 弹窗 三类组件组成。DevUI 对这三类高频组件做了大量的工程化增强，如果只停留在“基础用法”，就浪费了其生态优势。

2.2.1 表格：从“展示数据”到“操作中枢”

DevUI 表格组件（如 d-table / d-data-table 等）一般具备以下特性（在官方文档与示例中可以看到相应能力）：

• 大数据量优化

  • 虚拟滚动、懒加载、服务端分页；
  • 支持列宽自适应、固定列、列拖拽、列显示/隐藏配置。

• 复杂交互能力

  • 多选、树形数据、合并单元格、行内编辑；
  • 支持自定义单元格模板，方便嵌入按钮、图标、状态标签等。

• 工程化友好

  • 配合响应式布局与主题变量，可在不同屏幕下保持良好阅读体验；
  • 支持国际化文本、无障碍属性等企业合规要求。

实战避坑建议：

1. 严格区分“前端分页”与“服务端分页”

   • 若数据量超过几千条，应优先采用服务端分页 + 条件筛选，否则浏览器渲染压力极大；
   • 可以将分页事件与后端查询参数强绑定，采用统一的 QueryModel。

2. 统一封装“列配置中心”

   • 将列定义（字段名 / 显示名 / 宽度 / 是否可见 / 权限）抽象为 JSON Schema；
   • 表格组件只关心“如何渲染”，业务端可以在运行时动态调整列集合。

3. 表格与表单联动时避免“多处维护”

   • 同一个字段在表格列与表单字段中尽量共用同一份元数据（如校验规则、枚举定义），可通过 TypeScript 类型与配置对象统一管理。

正比如如下截图所示：

2.2.2 表单：从“校验输入”到“规则中枢”

DevUI 的表单组件通常支持：表单分组、校验规则、动态增删行、联动控制等能力。

在实际项目中，可按以下思路“进阶使用”：

• 表单模型 Schema 化

  • 将表单配置抽象为一个描述对象，例如：字段类型、必填、默认值、校验模式、布局比重；
  • 前端根据 Schema 渲染表单组件，后端则共享同一份规则（例如通过 JSON Schema 或后端 DTO 扩展）。

• 校验逻辑前后端统一

  • 对复杂规则（如“开始时间必须早于结束时间且在同一工作日内”），可在前端使用 DevUI 表单钩子进行即时校验，同时在后端复用同逻辑，避免“两套规则不一致”。

• 表单状态可视化

  • 借助 DevUI 的消息提示组件 / 标签组件，对表单整体状态进行提示，如“信息完整度”、“风险提示等级”等，而不仅仅是字段错误红框。

正比如如下截图所示：

2.2.3 弹窗：从“模态对话框”到“任务容器”

DevUI 的弹窗组件（Dialog/Modal）除了基本的模态展示外，还不断新增诸如最大化、拖拽、全屏等能力。

工程实践建议：

1. 服务化管理对话框

   • 统一封装一个 DialogService，由它来创建 / 关闭弹窗，并接收 Promise 或 Observable 结果；
   • 业务组件只需要调用 openConfirm() 或 openFormDialog()，不直接操作模板中的 <d-dialog>。

2. 对话框即“子流程”

   • 将弹窗内部视为一个小型流程（如审批、变更确认），在内部集成表单、步骤条、提示信息；
   • 通过 DevUI 的步骤条组件 / 消息组件，丰富对话框内部的引导体验。

3. 控制好“弹窗层级”

   • 尽量避免多层嵌套弹窗；
   • 如果确实有必要，可通过路由 + 抽屉组件组合替代“弹窗套弹窗”的场景。

正比如如下截图所示：

2.3 自定义组件 & 插件：从“用组件”到“造组件”

DevUI 提供了大量基础组件，但企业项目中往往需要封装自己的“业务组件”和“业务插件”。

2.3.1 自定义组件的典型路径（Angular 例）

基于 ng-devui 的 Angular 项目中，可以采用如下套路：

1. 选定基础组件

   • 例如业务需要一个“可配置的复杂表单卡片”，可选用 DevUI 的 Card + Form + Select + Input 等组件作为基础。

2. 封装业务语义

   • 将“表单字段 + 校验 + 展示逻辑”抽象到一个业务组件中，如 ConfigFormCardComponent；
   • 提供明确的 @Input() 与 @Output()，避免业务逻辑直接散落在页面模板中。

3. 复用样式与主题变量

   • 使用 DevUI 定义好的 CSS 变量或 SCSS mixin（在主题系统与样式规范中有说明），保证与整体视觉一致。

4. 发布为内部组件库

   • 将这类复用度高的业务组件抽取到企业内部的 @corp/devui-ext 包中，形成自己的“二次封装层”。

2.3.2 插件化扩展：从Figma到代码、从工程脚手架到低代码

根据社区与官方介绍，DevUI 在工程化层面提供了若干“插件化能力”：

• Figma 组件库 + 插件：

  • 设计师在 Figma 中基于 DevUI 组件进行设计，再通过插件导出对应技术栈代码；
  • 减少“视觉稿还原”带来的重复劳动。

• CLI 脚手架：

  • 基于 Angular CLI、DevUI CLI 快速初始化中后台项目，内置路由、权限、布局等基础骨架。

• 低代码 / 可视化搭建集成：

  • DevUI 组件提供标准化元数据（属性、事件、插槽），可被低代码平台解析并拖拽编排；
  • 鼓励把常用页面结构（表单 + 列表 + 详情）沉淀为可视化模板。

这些“插件化入口”本质上是：把 DevUI 从“组件库”升级为“前端平台能力”。

正比如如下截图所示：

2.4 主题与样式：从“好看”到“可管理的品牌资产”

设计系统的价值，很大程度体现在“主题可控”上。DevUI 的主题能力主要体现在：

1. 设计 Token 标准化

   • 颜色、字号、间距、圆角、阴影等全部归纳为 Token；
   • 不同品牌主题实质上是“同一套语义 Token，不同的取值组合”。

2. 多主题 & 暗黑模式

   • 支持在运行时切换主题（如“标准主题 / 品牌主题 / 暗黑主题”）；
   • 通过 CSS 变量或特定的 theme 类名挂载，配合 JS 逻辑控制。

3. 响应式布局与适配

   • 借助网格系统 / 栅格组件实现多终端布局；
   • 提供典型中后台布局模板，如顶部导航 + 侧边菜单 + 工作区。

实践建议：

• 将“品牌主题配置”视为企业资产，集中管理在一个独立仓库；
• 面向各业务线输出：主题包 + 使用说明 + 示例页面；
• 若后续与 MateChat 结合，可复用同一套 Token，让 AI 聊天区域与整体控制台风格保持一致。

正比如如下截图所示：

2.5 云原生落地：DevUI 在控制台与 B 端系统中的应用范式

从公开资料与文章可以看出，DevUI 已广泛应用于各种云控制台、企业管理系统中。

在云原生场景下，可以总结出一套典型架构：

1. 前端层

   • 技术栈：Angular 或 Vue + DevUI；
   • 职责：界面呈现、路由与状态管理、表单与表格交互、权限控制（按钮级 / 菜单级）。

2. 微前端与多应用聚合

   • 在大型控制台中，不同子系统可能使用不同框架；
   • DevUI 通过统一设计系统与主题，结合微前端框架（如 qiankun、single-spa 等）实现视觉一致；

3. 与后端 / 云原生基础设施集成

   • 通过 API 网关访问各微服务或 Serverless 函数；
   • 使用 DevUI 组件呈现监控数据、配置项、告警信息等。

4. 与 DevOps / 研发工具链的联动

   • DevUI 本身参与构建华为 DevCloud 等平台界面，这使得它天然适合构建类似的云原生研发控制台。

2.6 DevUI 入门实战：从 0 到 1 的项目搭建示例（简化版）

下面以 Angular + ng-devui 为例，演示一个简化的“从空项目到 DevUI 界面”的路径。步骤基于 ng-devui 官方 README 但进行了整理与再表述：

2.6.1 创建 Angular 项目

# 安装 Angular CLI（若已安装可跳过）
npm install -g @angular/cli

# 创建新项目
ng new devui-demo --routing --style=scss

cd devui-demo

2.6.2 安装 DevUI

npm install ng-devui @devui-design/icons

2.6.3 引入模块与样式

// app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';
import { NgModule } from '@angular/core';

import { DevUIModule } from 'ng-devui';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, BrowserAnimationsModule, DevUIModule],
  bootstrap: [AppComponent],
})
export class AppModule {}

在 angular.json 中加入 DevUI 样式：

"styles": [
  "src/styles.scss",
  "node_modules/ng-devui/devui.min.css"
]

2.6.4 写一个最小 Demo

<!-- app.component.html -->
<div d-container>
  <d-card dFlexDirection="column">
    <h2>DevUI Demo 控制台</h2>
    <d-form [layout]="'horizontal'">
      <d-form-item label="关键字">
        <input dInput [(ngModel)]="keyword" />
      </d-form-item>
      <d-form-item>
        <button d-button bsStyle="primary" (click)="search()">查询</button>
      </d-form-item>
    </d-form>

    <d-data-table [dataSource]="data">
      <thead>
        <tr dTableRow>
          <th dHeadCell>名称</th>
          <th dHeadCell>状态</th>
          <th dHeadCell>操作</th>
        </tr>
      </thead>
      <tbody>
        <tr dTableRow *ngFor="let item of data">
          <td dCell>{{ item.name }}</td>
          <td dCell>{{ item.status }}</td>
          <td dCell>
            <a (click)="openDetail(item)">详情</a>
          </td>
        </tr>
      </tbody>
    </d-data-table>
  </d-card>
</div>

这只是最基础的示例，在实际项目中可以进一步引入路由、侧边导航、国际化、权限等能力。

正比如如下截图所示：

2.7 DevUI 的跨场景创新：AI 可视化、低代码与智能组件

在官方与社区文章中，可以看到 DevUI 正在向“智能化组件”“低代码集成”“行业解决方案”方向演进：

1. AI 可视化与智能组件

   • 智能表单：根据自然语言或上下文自动推荐字段与校验规则；
   • 智能表格：支持自然语言筛选与排序，如“展示最近一周失败的任务”；
   • 智能布局：根据用户角色与使用频次自动生成个性化仪表盘布局。

2. 低代码平台集成

   • DevUI 组件拥有清晰的属性 / 事件定义，便于低代码平台生成配置界面；
   • 页面结构可通过拖拽组合“表单区 + 列表区 + 详情区”，大幅缩短业务页面开发周期。

3. 行业场景模板

   • 金融、政务、医疗等行业可基于 DevUI 封装“行业专属组件”和“典型流程模板”；
   • 例如“政务申报向导页”“金融风控看板”等。

在后续章节，当我们把 MateChat 引入这些场景时，可以把 DevUI 视为“承载业务与 AI 的基底 UI”。

三、MateChat：智能化应用的“交互前台”

如果说 DevUI 是云原生应用界面的“地基”和“骨架”，那 MateChat 则更像是为这些应用带来“AI 神经”的交互前台。

3.1 MateChat 的角色：GenAI 体验系统 + 前端 UI 库

MateChat 在官网上被描述为：

“前端智能化场景解决方案 UI 库，轻松构建你的 AI 应用。”

关键点有三个：

1. 专注智能场景，不做通用 UI

   • 它不是另一个“中后台组件库”，而是专门为对话式 / 智能交互设计的 UI 套件；
   • 聚焦聊天消息流、智能提示、输入区域、会话管理等。

2. 围绕 GenAI 构建统一的交互语言

   • 官网强调 MateChat 致力于构建“高一致性的 GenAI 体验系统语言”，在不同工具 / 平台间保持体验一致性；
   • 例如同样是“AI 助手”，在 DevOps 平台、IDE、知识库中采用一致的布局、气泡风格、引导方式。

3. 以组件库形式存在，而非“模型 SDK”

   • MateChat 提供的是前端 UI 能力，不封装具体大模型的调用逻辑；
   • 在官方与开源仓库中可以看到，它通过 Vue 插件的形式集成（如 @matechat/core），但并不提供服务端 SDK 或模型调用 SDK，模型对接需由业务方自己实现。

这与本期内容大纲要求中“MateChat 无 SDK（即不封装模型调用侧）”的强调是一致的：

MateChat = 专注 GenAI 交互体验的前端组件库，而不是 AI 服务的后端 SDK。

3.2 体验理念：从“会说话”到“可被理解的 AI”

MateChat 官网对其设计理念有较详细的描述：

• 体验无边界，业务无侵害

  • 目标是在不同业务系统中，以最小侵入方式为产品增加 AI 能力；
  • 对原有业务逻辑影响尽量小，更像是“外挂式”的体验增强层。

• 构建通用的 GenAI 交互体系

  • 强调对话式交互中的共性：如何唤醒、如何输入、如何反馈、如何解释 AI 状态；
  • 通过统一的 UI 行为，降低用户在不同产品之间切换的心智负担。

• 核心体验关键词：

  1. 快速唤醒：固定入口、情境建议、快捷键等方式，让用户随时召唤 AI；
  2. 轻松使用：适时引导与提示，减少“不会问 / 不敢问”的心理负担；
  3. 自由表达：为自然语言输入区域提供增强能力（多行输入、Markdown 支持、快捷命令等）；
  4. 过程监督：清晰展示模型执行状态、加载过程、流式输出等；
  5. 可读性强：通过分层的 Markdown 渲染与版式设计提高复杂内容的阅读效率。

可以看到，MateChat 把传统“聊天 UI”提升为一个完整的 AI 体验系统，关注点不仅是“展示答案”，还包括：

• 如何唤起需求；
• 如何给用户信心；
• 如何让模型行为透明可控。

正比如如下截图所示：

3.3 组件生态：从泡泡到布局的完整对话骨架

根据 MateChat 文档与示例，可以大致归纳出几类核心组件：

3.3.1 消息层：McBubble / 消息气泡组件

• 用于承载对话内容；

• 支持：

  • 左右对齐（区分用户与 AI）；
  • 加载状态（streaming 时展示骨架或“正在思考”状态）；
  • 头像配置：可以展示不同智能体、角色或用户形象；
  • 样式变体：填充、边框等。

通过这些能力，可以在一个对话流中表达：

• 谁在说话（user / agent / system）；
• 当前是否还在生成；
• 是否是引用、代码块、表格等内容。

3.3.2 输入层：McInput / 输入框组件

• 核心职责：把“人类自然语言输入”变成结构化的“请求事件”；

• 通常具备：

  • 多行文本编辑；
  • 提交快捷键（Enter / Ctrl + Enter）配置；
  • 附件入口、工具栏区域（如“添加智能体”、“切换模型”、“上传文件”）；
  • 显示当前 token/字符长度等提示。

在官方示例中，McInput 常与快捷提示、输入区 footer（显示智能体、词库、附件图标）联动，形成一套上下文丰富的输入体验。

3.3.3 引导层：McPrompt / 快捷提示组件

• 常用于“给用户一些可以直接点击的问题”，例如：

  • “帮我写一个快速排序”；
  • “你可以帮我做些什么？”；
  • “如何绑定项目空间？” 等。

• 支持：

  • 横向或纵向排布；
  • 图标 + 标题 + 描述；
  • 点击事件与输入框联动（点击后直接触发提问或预填输入）。

这类组件非常适合：

• 新用户首次接入时的“欢迎页”；
• 为特定业务场景预置问题模板，如“生成 API 文档”、“分析日志”等。

3.3.4 布局层：McLayout / Header / Sender 等

MateChat 提供了一整套布局组件，使开发者可以用组件组合的方式搭建一个完整的 AI 对话页面，而无需从零搭建布局：

• McLayout：整体容器，负责页面基本结构；
• McHeader：顶部头部，展示标题、Logo、操作区域（如设置、帮助、账号信息）；
• McLayoutContent：中间对话内容区或欢迎页内容区；
• McLayoutSender：底部发送区，通常容纳 McInput；
• 配合 DevUI 的 Button、Icon 等常规组件，可以轻松构建完整体验。

3.3.5 辅助层：智能体、历史记录、多模态入口等

在示例代码与文档中，可以看到 MateChat 预留了丰富的“辅助入口”，例如：

• 输入区 footer 上的“智能体”、“词库”、“附件”图标；
• 左侧会话列表 / 新建对话按钮；
• 为多模态交互（上传文件、图片等）预留扩展位。

这些 UI 钩子为后续接入MCP、智能体系统、多模态模型提供了天然空间。

正比如如下截图所示：

3.4 无 SDK 条件下：MateChat 如何对接大模型与智能体

如前所述，MateChat 本身不封装具体模型调用，也不提供后端 SDK。开源仓库中的示例会用 OpenAI、盘古大模型等作为“接入参考”，但本质是：开发者自行实现模型服务调用，再与 MateChat 的事件结合。

3.4.1 典型集成架构

可以抽象为四层模型：

1. UI 层（MateChat）

   • McInput 捕获用户问题；
   • McBubble 展示对话内容；
   • McPrompt 处理快捷提问；
   • McLayout* 负责整体布局。

2. 前端交互层

   • 将 MateChat 发出的“提交事件”转换为一个统一的请求对象（包含会话上下文、智能体 ID、知识库 ID 等）；
   • 管理流式响应：通过 SSE/WebSocket/Fetch + ReadableStream 按块更新 McBubble 的内容。

3. 后端网关层

   • 提供统一的 AI 网关接口，例如 /api/chat/completions；
   • 封装对不同大模型（盘古、ChatGPT、本地 LLM 等）或智能体框架（如 MCP、工具调用引擎）的调用细节。

4. 智能体与工具层

   • 真正进行“思考”和“工具调用”的地方；
   • UI 无需感知其复杂度，只透过流式响应与最终结果。

3.4.2 事件级集成示例（思路级）

以 Vue + MateChat 为例，可以采用如下思路（伪代码级别）：

// 伪代码：在 App.vue 或某个对话容器组件中
const messages = ref<ChatMessage[]>([]);

const handleSubmit = async (content: string) => {
  // 1. 更新本地对话：加入用户消息
  messages.value.push({ from: 'user', content });

  // 2. 预先插入一条“空”的模型消息
  const modelMsg = { from: 'model', content: '', loading: true };
  messages.value.push(modelMsg);

  // 3. 调用后端网关，采用流式接口
  const stream = await callChatApi({ content, history: messages.value });

  // 4. 持续读取流并更新 modelMsg.content
  for await (const chunk of stream) {
    modelMsg.content += chunk.partialText;
  }

  modelMsg.loading = false;
};

页面上再把 messages 传给 McBubble 列表即可。需要注意的是：

• MateChat 不规定你如何调用模型，只提供“如何展示”与“何时触发”的约定点；
• 这种分层让团队可以灵活替换大模型或智能体实现，而不影响前端 UI 结构。

正比如如下截图所示：

3.5 落地实践：以 InsCode AI IDE 为例的“智能助手嵌入”

MateChat 官网展示了一个典型应用案例：InsCode AI IDE。

InsCode AI IDE 由 CSDN、GitCode 与华为云 CodeArts IDE 联合开发，使用 MateChat 灵活丰富的组件资源，快速完成 IDE AI 插件的设计与搭建，为开发者提供高效便捷的 IDE 编程体验。

从这个案例中，可以抽象出一套通用的“MateChat 嵌入路径”：

1. 选定嵌入方式

   • 侧边栏浮出面板（IDE 常见模式）；
   • 底部对话抽屉；
   • 或独立窗口模式。

2. 设计上下文注入

   • 针对 IDE 场景，AI 需要感知当前文件、光标位置、选中代码、项目结构等信息；
   • UI 层可以提供“上下文标签区”，提醒用户当前上下文已被纳入提示中。

3. 构建“开发者导向”的 Prompt 模板

   • 通过 McPrompt 提供诸如：

     • “解释选中代码”；
     • “根据错误信息给出排查建议”；
     • “生成单元测试模板”。

4. 增强可视 Feedback

   • 通过 Markdown 渲染展示代码块、Diff、步骤说明；
   • 必要时提供“复制代码”“一键应用到编辑器”等操作按钮（可通过 DevUI / IDE API 实现）。

5. 统一体验风格

   • InsCode、CodeArts 等工具通过 MateChat 保持相似的聊天界面风格，使得开发者迁移时几乎无需重新学习。

这个案例说明：MateChat 的价值不局限在“对话框长什么样”，而是帮助在特定领域打造一套可推广的 AI 使用方式。

3.6 创新玩法：MCP、智能体、记忆化与多模态的组合探索

虽然官方暂未直接提供 MCP 或智能体框架集成的完整示例，但从 MateChat 的设计和预留接口来看，非常适合与这些能力结合。下面从架构与体验角度做一些可行的探索方向。

以下内容是基于 MateChat 官方特性与组件能力进行的设计推演，并不代表官方已提供现成方案，但实现路径与生态方向是契合的。

3.6.1 集成 MCP / 智能体编排

• 在后端构建基于 MCP（Model Context Protocol）或其他智能体框架的编排系统；

• 在前端 MateChat 中：

  • 使用 McPrompt 提供“选择智能体”的入口；
  • 使用输入区 footer 的“智能体”图标打开一个智能体列表；
  • 在消息气泡中展示“当前智能体正在执行的工具调用步骤”。

效果是：用户可以自然地与“日志分析智能体”、“数据库问答智能体”、“文档助手智能体”等不同角色对话，而前端不需要了解复杂的工具编排细节。

3.6.2 个性化 / 记忆化体验

利用 MateChat 的消息流与上下文展示特性，可以实现更具“人格与记忆”的交互，例如：

• 在头部区展示智能体的 persona 简介与当前状态；
• 使用“标签气泡”展示当前会话绑定的项目、文档、组织身份；
• 在对话中显式提示“我记得你之前问过……，这次帮你做进一步优化”。

技术实现上：

• 在后端维护用户画像与会话记忆；
• 前端 MateChat 仅负责将“记忆片段”以友好的方式嵌入聊天流中。

3.6.3 知识检索 + 自然语言生成 UI

结合 RAG（检索增强生成）与 MateChat，可以设计如下体验：

1. 用户提出问题，MateChat 展示“正在检索相关文档…”的状态气泡；
2. 检索结果以“可折叠卡片”的形式插入消息流，例如“来自《XX 文档》章节 3.2”；
3. 大模型基于检索结果生成回答，同时引用相关文档链接；
4. 用户可点击“展开原文”，在旁边弹出 DevUI 对话框 / 抽屉展示文档详情。

MateChat 负责“呈现过程”和“解释出处”，RAG 系统负责“找资料”和“生成答案”。

3.6.4 工作流与思维链可视化

对于复杂任务（如“帮我从日志中找异常并生成一份报告”），可以借助 MateChat 实现：

• 在消息流中插入“任务步骤卡片”，展示当前执行到哪一步；
• 使用时间轴或步骤条组件（可以复用 DevUI 对应组件）呈现 AI 的“思维链”概要；
• 提供“暂停 / 重试 / 跳过某步”的控制按钮。

这样，用户看到的不再是一个“黑盒回答”，而是一条可监督的 AI 工作流。

正比如如下截图所示：

3.7 MateChat 的未来演进方向：从“聊天 UI”到“智能体验基础设施”

从开源仓库和特性规划可以看到，MateChat 仍在快速演进中：

可能的演进方向包括：

1. 更多场景组件

   • 面向代码、表格、图表、知识图谱等内容的专用展示组件；
   • 面向团队协作的多用户对话组件（如“多人共享会话”）。

2. 更丰富的主题与适配能力

   • 与 DevUI 主题系统进一步打通，实现“企业统一设计 Token，MateChat 自动适配”；
   • 为 IDE、Web Console、桌面应用等提供不同的“体验预设”。

3. 更强的工程化工具

   • CLI / 模板仓库，帮助快速生成“AI 助手应用骨架”；
   • 结合 Storybook / 文档站提供全面的组件说明。

MateChat 可能会逐步扮演“企业 GenAI 体验基础设施”的角色，就像 DevUI 是“企业中后台 UI 基础设施”一样。

四、DevUI + MateChat：从云控制台到智能助手的一体化体验

真正具有竞争力的云原生产品，往往不是单点技术堆叠，而是“从界面到智能”的一体化体验。DevUI 与 MateChat 正好分别站在这条链路的两端：

• DevUI：负责“业务界面 + 控制台 + 管理系统”的整体 UI 与工程效率；
• MateChat：负责“在这些界面中，为用户提供统一的 AI 助手体验”。

4.1 技术层面的协同

1. 统一设计系统与主题

   • DevUI 提供企业级设计 Token 与主题机制；
   • MateChat 基于 vue-devui 的主题化能力，使聊天区域可以继承同一套视觉体系。

2. 统一组件模型与工程栈

   • 两者都支持 Vue 技术栈（DevUI 也支持 Angular 主战场），在一个大型 Vue 应用中可以无缝并存；
   • 组件用法、样式组织、按需加载策略可以统一规划，降低工程复杂度。

3. 微前端场景下的统一体验

   • 主应用采用 DevUI 搭建整体框架；
   • 子应用中只要有 AI 需求，即可引入 MateChat，并通过主题与 CSS 变量保证视觉一致；
   • 无论用户进入哪个子模块，都会看到“长得一样”的 AI 助手，增强整体感。

4.2 体验层面的协同

设想一个云控制台场景：

1. 整体控制台：

   • 菜单、列表、详情、设置页全部基于 DevUI 构建；
   • 使用 DevUI 的 Layout、Nav、Table、Form 等组件。

2. 页面右下角 / 右侧栏：

   • 使用 MateChat 提供“智能助手”入口；

   • 默认展示几个基于当前页面场景的快捷问题（例如：

     • “帮我分析当前集群的资源使用情况”；
     • “根据当前告警生成排查步骤”；
     • “解释这个配置项的影响”）。

3. 用户点击日志详情、告警列表时：

   • MateChat 自动获取上下文（如当前资源 ID、告警信息），并以提示方式告诉用户“我已经知道你正在查看的资源是 XXX，是否要根据这些信息进行诊断？”。

4. 若用户打开 DevOps 流水线页面 / IDE 插件：

   • 仍然是同一套 MateChat 风格，只是上下文由“集群信息”变成“代码 / 构建日志”。

这样，用户在整个云原生产品体系中，体验到的是：

“无论我走到哪里，都有一个风格统一、行为一致的 AI 助手在旁边。”

而对研发团队而言：

• 前端 UI 部分由 DevUI 和 MateChat 两套生态支撑；
• 后端 AI 能力可以持续演进，而前端体验结构基本稳定。

正比如如下截图所示：

五、结语：在云原生深水区，搭好“稳固的船”和“聪明的桨”

站在架构和实践角度看：

• DevUI 像是一艘云原生大船的“船体结构”：

  • 负责稳、负责快、负责标准化；
  • 让企业能够持续、安全地构建和演进中后台界面。

• MateChat 则像这艘船上的“智能桨和导航系统”：

  • 让产品不只是被动地呈现信息，而是可以主动帮助用户分析、决策和执行；
  • 为各种复杂业务工作流注入 AI 的能力。

在云原生开发进入深水区的今天，一套好的技术栈不再只是“选什么框架”，而是：

1. 是否有成熟的 设计系统与组件生态（DevUI）；
2. 是否有可复用的 AI 交互基座（MateChat）；
3. 是否能够在同一套工程体系下，让“界面效率”与“智能能力”形成稳定闭环。

通过合理地组合 DevUI 与 MateChat，我们可以为企业构建出这样的产品形态：

• 界面统一、品牌一致、体验专业；
• 开发高效、工程可控、维护成本低；
• AI 能力可插拔、可升级、可治理。

希望本期内容，能够为你在创作与实际项目中，提供一套系统的思考框架与落地路径。

相关官方地址汇总如下：

• MateChat：https://gitcode.com/DevCloudFE/MateChat
• MateChat官网：https://matechat.gitcode.com
• DevUI官网：https://devui.design/home

声明：如上内容部分配图来源官网及公开互联网，若有侵权，请联系删除！