当云原生前端遇上 GenAI：基于 DevUI 与 MateChat 的一体化实践路线

云原生与智能化的前端双底座解决方案在云原生与AI技术快速发展的背景下，企业面临界面碎片化、交互重复和AI能力难以融入业务流程的挑战。华为云推出DevUI和MateChat双技术生态： DevUI提供企业级设计系统与多技术栈组件库（Angular/Vue/React），支持云控制台、DevOps等复杂场景，确保跨系统一致性。 MateChat专注GenAI对话交互，通过标准化UI库实现智能助手体验

思碎微

817人浏览 · 2025-11-26 22:01:56

思碎微 · 2025-11-26 22:01:56 发布

摘要

在很多团队里，云原生已经不是“要不要上”的问题，而是“怎么稳住复杂度、同时把智能化做好”。
一边是云控制台、DevOps 平台、企业级中后台应用源源不断地冒出来；
另一边是大模型、智能体、MCP、RAG 等新能力不断加入战场。

如果只是单纯去拼组件库 + 各种 AI SDK，往往会变成：

界面风格碎片化，体验割裂；
交互逻辑重复造轮子；
AI 能力“外挂式”存在，很难真正融入业务流程。

华为云的两条技术生态——DevUI 企业级前端解决方案 和 MateChat 前端智能化场景 UI 库，就是在这种背景下长出来的一对“组合拳”：

DevUI：面向企业中后台、云原生工具、B 端系统的 设计系统 + 组件家族；([DevUI Design Of Angular][1])
MateChat：专攻 GenAI 对话体验的 前端智能化场景解决方案 UI 库，已经在 CodeArts 智能助手、InsCode AI IDE 等场景落地。

相关官方地址汇总如下：

MateChat：https://gitcode.com/DevCloudFE/MateChat

MateChat官网：https://matechat.gitcode.com

DevUI官网：https://devui.design/home

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

一、云原生 + 智能化：为什么需要“一套前端技术双底座”？

1.1 云原生前端的“现实压力”

典型云原生团队在前端上同时承受这些压力：

产品线多样：云控制台、微服务治理、监控告警、流水线平台、制品管理、内部开发工具……
使用场景复杂：大量表格 / 表单 / 弹窗 / 向导 / 仪表盘叠加；
交互负载高：频繁切换环境、租户、项目、集群等上下文；
跨场景一致性要求强：不同子系统之间需要统一的视觉、交互、操作路径。

与此同时，大模型与智能体进场之后，又提出一套额外要求：

需要统一的 对话式交互体验；
需要充分利用上下文（当前页面、当前项目、当前流水线）；
需要兼容不同模型服务（盘古、内部模型网关、第三方大模型）。

如果在每个子系统里分别造一套 UI + AI 交互，整体成本会非常惊人，还会直接拉高维护难度。

1.2 DevUI：设计系统 + 多技术栈组件家族

DevUI 不只是一个 UI 库，而是一整套企业级前端解决方案，官方明确强调：

面向企业中后台 / B 端场景；
提供 设计系统（Design System）+ 组件库 + 工程化工具 的组合能力；
设计价值观基于“高效、开放、可信、乐趣”等理念；
支持 Angular、Vue、React 多种技术栈，其中 Angular 与 Vue 家族最成熟稳定。([51CTO][5])

技术家族大致包括：

ng-devui：基于 Angular 的企业级组件库；([DevUI Design Of Angular][1])
Vue DevUI：基于 DevUI Design 的 Vue3 组件库，采用 Vite + Vue3 + TS + JSX，包含 60+ 组件，偏向研发工具场景。([vue-devui.github.io][6])

它提供的不是零散组件，而是：

成体系的布局 / 导航 / 表单 / 表格 / 反馈组件；
面向研发工具的扩展组件（Code Editor、GitGraph、Markdown 编辑器等）；([vue-devui.github.io][6])
多主题能力与暗黑模式支持。

1.3 MateChat：GenAI 体验系统 + 前端 UI 解决方案

MateChat 则是 DevUI 团队发布的、专攻 GenAI 交互的 UI 库：([MateChat][2])

定位为 “前端智能化场景解决方案 UI 库”；
目标是构建统一的 GenAI 体验语言，让不同业务场景里的 AI 助手体验保持一致；
当前已经服务华为内部多款应用，并用于 CodeArts 智能助手、InsCode AI IDE 等；([MateChat][2])
全部代码开源，MIT 协议，企业可免费商用。([MateChat][2])

官方总结了 MateChat 的几条设计理念：([MateChat][2])

体验无边界，业务无侵害：既要沉浸式体验，又不能破坏原业务逻辑；
构建跨场景一致的 GenAI 语言交流系统；
聚焦研发工具与 DevOps 等场景下的对话组件。

更关键的一点是——从官方「如何接入模型服务」的示例可以看出：MateChat 不内置任何大模型 SDK，而是通过第三方 SDK（如 openai）或自建 HTTP 接口集成模型服务。([GitHub][3])

所以你可以把 DevUI 和 MateChat 理解成：

DevUI：通用界面骨架 + 组件体系

MateChat：GenAI 对话交互层 + 场景化智能入口

二、DevUI：从组件生态到云原生落地的全流程实践

本节只聚焦 DevUI 本身，从 “怎么把界面搭好” 的角度系统展开。

2.1 DevUI 家族与设计体系：不仅仅是“组件库”

2.1.1 多技术栈、多产品线的一致体验

从 DevUI 的公开资料可以看到，它一开始就是以“企业中后台产品”为核心目标：([DevUI Design Of Angular][1])

支撑金融、政务、医疗、云平台、DevOps 等多行业；([CSDN][4])
通过统一的设计系统输出颜色、间距、图标、动效、交互模式等标准；
Angular、Vue、React 家族共用一套 DevUI Design 体系。([51CTO][5])

这种“多栈共享一套设计系统”的路线，对大企业非常重要：

产品线之间可以迁移设计资产；
不同技术栈项目可以共享组件语义与交互习惯；
统一的设计语言给用户带来连贯体验。

2.1.2 Vue DevUI：更贴近“研发工具”的那一支

Vue DevUI 的 README 中写得很直接：它是一个 基于 DevUI Design 的 Vue3 组件库，面向研发工具与中后台开发场景。

几个特征：

基于 Vite + Vue3 + TS + JSX 搭建；
超过 60 个组件，覆盖布局、表单、数据展示、导航、反馈等；
内置 ActionTimeline、Code Editor、Markdown 编辑器、GitGraph、ECharts 图表封装 等更偏向 DevTools 场景的组件。([vue-devui.github.io][6])

这也解释了为什么 MateChat 的主题是基于 Vue DevUI 的主题化能力实现的——两者在 Vue 技术栈下天然是“亲兄弟”。

正比如如下截图所示：

2.2 DevUI 上手：从空项目到“可维护的云原生页面”

2.2.1 Angular + DevUI：偏“平台级中后台”的组合

一个典型的 ng-devui 上手路径可以概括为（伪流程）：

使用 Angular CLI 创建项目：

ng new cloud-console
cd cloud-console
npm i ng-devui

在根模块中引入 DevUI 模块或按需模块：

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { DevUIModule } from 'ng-devui';

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

在模板中使用布局 + 导航 + 表格组件快速搭出“控制台雏形”。

官方的文档中还提供了 “Environment Setup”“DevUI Travel” 等从零到一的教程，帮助开发者完成一个完整应用的构建过程。([DevUI Design Of Angular][1])

2.2.2 Vue + DevUI：偏“轻量高效的研发工具 / 云原生前端”

Vue DevUI 官方站点给出了一条非常清晰的“快速开始”路线：([vue-devui.github.io][6])

用 Vite 初始化 Vue3 + TS 项目；
安装 vue-devui，在入口文件中全局注册；
引入通用样式并开始使用组件。

npm create vite@latest devui-vue-demo -- --template vue-ts
cd devui-vue-demo
npm i vue-devui

// main.ts
import { createApp } from 'vue';
import App from './App.vue';
import DevUI from 'vue-devui';
import 'vue-devui/style.css';

createApp(App).use(DevUI).mount('#app');

上手之后，建议第一件事不是“先怼复杂表格”，而是：

搭出统一的布局框架（Layout + Header + Sidebar + Content）；
把菜单、面包屑、面板结构统一下来；
把常见的按钮、搜索、面板标题、空状态统一风格。

这一步打好基础，会极大降低未来“加场景、加页面、加 AI 面板”的边际成本。

正比如如下截图所示：

2.3 高频组件深度实践：表格 / 表单 / 弹窗完整打法

企业级云原生系统大多数交互都绕不开这三个：表格、表单、弹窗。下面从工程实践角度拆一下。

2.3.1 表格：从“能看”到“能扛住业务体量”

DevUI / Vue DevUI 提供的数据表格组件（DataTable/Table 系列），在设计上就是为中后台高密度信息展示准备的。([DevUI Design Of Angular][8])

云原生典型表格场景包括：

集群列表、节点列表、Pod 列表、流水线运行历史；
支持多字段筛选、联动过滤、列显隐、导出等；
动辄上万行，或者多维度聚合展示。

实践中建议重点关注：

服务端分页 + 虚拟滚动双管齐下
- 数据量大时：
  - 后端负责分页、排序、过滤；
  - 前端只保留当前页数据，减少内存占用；
- 极端场景（如日志视图、指标列表）可以开启虚拟滚动特性，避免 DOM 爆炸。

列配置驱动，而非“标签堆砌”

将表格列抽象成配置：

interface ColumnDef {
  field: string;
  title: string;
  sortable?: boolean;
  width?: number | string;
  align?: 'left' | 'center' | 'right';
  formatter?: (row: any) => string;
  permission?: string;
}

在 Vue DevUI 中基于 v-for 动态生成列，既方便修改，又可以统一做权限过滤、国际化等。

状态表达统一：Tag / Icon / Color 统一来自 Design System
- 不同服务不要自己定义一套颜色体系；
- 用 DevUI 提供的 Tag / 状态色，统一“成功 / 失败 / 警告 / 进行中”等视觉。
表格与详情面板的配合
- 不推荐所有细节都挤在表格里；
- 更好的形式是“表格 + 抽屉详情”或“表格 + 详情面板”，DevUI/ Vue DevUI 都提供 Card / Drawer 等组合组件，可以轻松搭出来。([vue-devui.github.io][6])

正比如如下截图所示：

2.3.2 表单：动态场景 + 跨字段校验是关键

DevUI 的 Form 体系，天然适合云原生里的“复杂表单”场景：([DevUI Design Of Angular][1])

创建集群 / 创建流水线 / 创建告警规则；
大量依赖选择器、级联、开关、数值输入；
条件字段、隐藏字段、跨字段关联校验。

实践中可以采用“表单 schema 驱动 + 分步向导”的组合：

表单配置 schema 描述字段、控件类型、校验规则、显示条件；
渲染层只负责根据 schema 生成对应 DevUI 控件；
使用向导组件（Steps / Wizard）把长表单拆成几步，降低认知负担。

校验建议：

把同步校验和异步校验拆开，避免逻辑混乱；
异步校验（如名称唯一）注意节流 / 防抖；
错误提示使用统一视觉（DevUI 已给出规范）。

正比如如下截图所示：

2.3.3 弹窗：让“操作”与“上下文”保持合理距离

弹窗组件在 DevUI 体系里通常包括 Modal / Drawer / Dialog 等。([DevUI Design Of Angular][8])

云原生里常见的几种弹层模式：

确认类 Modal
- 删除资源、强制重启、批量操作；
- 推荐始终搭配二次确认文案 + 风险提示。
编辑类 Drawer
- 从列表右侧滑出编辑面板；
- 用户可以保持对“原列表上下文”的感知。
结果反馈 / 告警提示
- 操作成功 / 部分失败 / 异常信息展示；
- 在 DevOps 场景中，“部分成功”这种状态很常见，建议用 Tag + 描述文字清晰表达。

最佳实践：

避免“弹窗套弹窗”；一旦需要二级弹窗，通常说明信息架构需要拆分；
提交时要锁定按钮、阻止重复提交，并用 Loading 状态给出反馈；
关闭弹窗前，应检测是否有未保存修改，提醒用户确认。

正比如如下截图所示：

2.4 自定义组件与插件：在 DevUI 生态里长出“团队资产”

在 DevUI 基础上，成熟团队通常会再长出一层“业务组件库”，例如：

统一的资源标签（ResourceTag）；
统一的告警条、风险提示条；
统一的“项目选择器 / 集群选择器 / 环境选择器”。

建议的做法是：

以 DevUI 组件为基础做二次封装
- 例如基于 Button + Icon + Tooltip 组合成“危险操作按钮组件”；
- 基于 Tag + Tooltip 封装统一的状态标签。
完全跟随 DevUI 的 Design Token
- 不自己硬编码颜色，将变量绑定到 DevUI 的主题变量；
- 这样切换暗黑 / 品牌主题时，业务组件也能跟着一致变化。([DevUI Design Of Angular][1])
组件 API 风格向 DevUI 看齐
- 属性命名、事件命名尽可能与 DevUI 习惯保持一致；
- 减少使用者心智负担。
把这些业务组件沉淀为独立 npm 包 / monorepo 子包
- 方便在多个项目中复用；
- 也方便后续把 MateChat 的智能对话入口嵌入到这些组件里（例如“带 AI 解释的指标卡片组件”）。

2.5 主题、暗黑模式与响应式：企业级多产品线统一的“外观层”

DevUI 官方资料明确提到，其设计系统支持多主题与高可定制性，强调“开箱即用的企业级产品体验”。([DevUI Design Of Angular][1])

2.5.1 品牌主题统一

常见需求：

不同产品线共享主品牌色，但支持小幅调色；
不同云 / 不同租户使用不同主题（例如私有云 vs 公有云）。

DevUI 的处理方式一般是：

将颜色、字体、圆角、阴影等统一收敛为 Token；
主题切换本质上就是 Token 的组合切换。

你可以在 Vue DevUI 或 Angular DevUI 的基础上：

定义多个品牌主题配置（如 JSON / SCSS 变量表）；
用“主题服务”（ThemeService / ThemeStore）统一管理主题加载；
让所有业务组件只引用 Token，而不用直接写颜色值。

2.5.2 暗黑模式与高对比模式

研发工具、IDE、监控平台用户几乎天然偏好暗色主题。

DevUI / Vue DevUI 在设计上已经考虑到多主题适配，MateChat 也声明自己的主题化是基于 Vue DevUI 的主题系统实现的。([Gitee][7])

实践建议：

在根部挂载一个 data-theme 或 CSS 变量前缀，用于切换主题；
监听 prefers-color-scheme，进行首次加载时的自动适配；
将主题切换后的状态持久化到 localStorage，保持用户偏好。

正比如如下截图所示：

2.5.3 响应式与“IDE 内嵌场景”

云原生工具经常出现在 IDE 插件面板中（宽度窄、高度受限），这就要求：

布局具有良好的“缩放弹性”，在窄宽度下依然可用；
表格列在窄屏幕需要支持优雅折叠或隐藏；
右侧 MateChat 区域要能在宽屏中常驻，在窄屏中折叠为浮动入口按钮。

在 DevUI 的 Layout / Grid 体系下，可以：

将页面拆成 Sidebar + Content + AssistantPanel 三栏；
给 AssistantPanel（即未来挂 MateChat 的区域）设计不同断点下的行为：
- 宽屏：右侧常驻抽屉；
- 中等：底部折叠为 Tab；
- 窄屏：悬浮入口按钮 + 全屏弹层。

2.6 云原生落地范式：DevUI 在三类代表性系统中的用法

结合 DevUI 面向行业场景的定位与组件能力，我们可以抽象出三类典型落地范式。([DevUI Design Of Angular][8])

2.6.1 云控制台 / 管控面板

特征：

资源层级复杂（租户 / 项目 / 区域 / 集群 / 实例）；
大量列表 + 详情页 + 监控图表；
多租户、多区域切换频繁。

推荐组合：

DevUI Layout + Menu + Breadcrumb：统一导航框架；
DataTable + Tabs + Card：资源列表 + 详情tab；
图表组件（如 Vue DevUI 的 ECharts 封装）：可视化监控指标。([vue-devui.github.io][6])

在此基础上，再挂上 MateChat 作为“智能运维助手”，就是后半部分要讲的内容了😉。

2.6.2 DevOps / 研发工具平台

Vue DevUI 尤其适合用来构建 DevOps / 研发工具：([vue-devui.github.io][6])

CodeEditor 组件展示构建脚本、配置文件；
GitGraph 显示分支 / 提交历史；
ActionTimeline 展示流水线或部署事件轴；
MarkdownEditor 用于规范、说明、变更记录。

这些能力组合起来，把原本“干巴巴”的流水线/日志/包管理界面变成了一套完整的研发工作空间，再配合 MateChat 的智能对话，就可以自然扩展出“流水线/日志/代码的智能助手”。

2.6.3 低代码 / 可视化编排工具

DevUI 的 Design System + 组件库，也非常适合作为低代码平台的“物料层”：

组件元数据描述属性 / 事件 / 插槽；
用数据驱动的 schema 渲染 DevUI 组件；
将 DevUI 的表单 / 表格/ 图表作为低代码可视化组件。

后续如果要做“自然语言生成界面/工作流”，就可以通过 MateChat + DevUI 的组合：
用户用自然语言描述需求 → 模型输出 schema → DevUI 负责渲染 → 用户在 UI 中微调。

三、MateChat：智能应用的落地与创新

前面 DevUI 把“界面骨架”搭好了，接下来轮到 MateChat 上场，去把 AI 能力变成“看得见、用得顺”的对话体验。

正比如如下截图所示：

3.1 MateChat 能力盘点：一套 GenAI 体验系统语言

从官网与官方文章，可以提炼出 MateChat 的几条核心标签：([MateChat][2])

前端智能化场景解决方案 UI 库
- 聚焦 GenAI 对话式交互，而不是通用组件；
- 面向 Web 网站、企业平台、DevOps 工具、IDE 等多场景。
体验无边界，业务无侵害
- 可以嵌入已有平台而不强行改变原有业务结构；
- 支持协作式、沉浸式、情境式等多种交互形态。
组件级能力非常明确
- 消息气泡组件（承载对话消息）；
- 输入框组件（支持扩展、建议、快捷键）；
- 快捷使用组件（根据上下文给出推荐操作 / 问题）；
- 头部 / 布局等包装组件。
基于 Vue DevUI 的主题化能力
- MateChat 的主题系统基于 Vue DevUI 的主题化实现，两者在视觉上天然一致。
开放式模型接入方式
- 官方文档给出的是用 openai SDK 对接大模型的示例；
- 开发者可以接入盘古大模型、内部模型网关或其它第三方模型；
- MateChat 自己不提供封装后的 SDK，只负责对话 UI。([GitHub][3])

3.2 全流程实践：从空页面到“有大模型接入的对话助手”

这一小节按照官方指南 + 实战经验，总结出一条比较完整的落地路径。

3.2.1 初始化项目与引入 MateChat

假设我们基于 Vue3 技术栈：

创建基础项目（略）；
安装 MateChat 依赖（以文档为准）；
在入口文件中注册组件 & 引入样式。

pnpm i matechat
# 或 npm / yarn 视项目而定

// main.ts（示意）
import { createApp } from 'vue';
import App from './App.vue';
// import MateChat from 'matechat';
// import 'matechat/dist/style.css';

createApp(App)
  // .use(MateChat)
  .mount('#app');

注意：实际包名与注册方式以最新官方文档为准，上面只是参照通用 Vue 组件库的使用惯例进行示意。([GitHub][3])

3.2.2 构建基础对话布局与消息模型

MateChat 提供的典型组件可以看成三类：([MateChat][2])

对话容器与布局；
消息气泡（Bubble）；
输入 & 建议组件。

一个最简结构大概是：

<template>
  <div class="mc-shell">
    <McHeader title="AI Assistant" />
    <div class="mc-body">
      <McBubble
        v-for="msg in messages"
        :key="msg.id"
        :content="msg.content"
        :align="msg.from === 'user' ? 'right' : 'left'"
        :loading="msg.loading"
        :avatar-config="msg.avatarConfig"
      />
    </div>
    <McInputArea
      v-model="inputValue"
      :suggestions="suggestions"
      @submit="handleSubmit"
    />
  </div>
</template>

消息模型可以定义为：

interface ChatMessage {
  id: string;
  from: 'user' | 'model';
  content: string;
  loading?: boolean;
  avatarConfig?: {
    name?: string;
    imgUrl?: string;
  };
}

这一步更多是“把 UI 基座搭好”，暂时先不接模型，让对话结构跑通。

3.2.3 按官方建议对接大模型服务

MateChat 官方「如何接入模型服务」一节给出了完整示例：通过 openai SDK 调用模型，并在前端进行流式处理。([GitHub][3])

官方示例核心逻辑大致如下（在此基础上做了结构化处理）：

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: '',   // 模型 API Key
  baseURL: '',  // 模型服务网关地址
  dangerouslyAllowBrowser: true,
});

const messages = ref<ChatMessage[]>([]);
const inputValue = ref('');
const startPage = ref(true);

const handleSubmit = (text: string) => {
  if (!text.trim()) return;

  inputValue.value = '';
  startPage.value = false;

  // 1. 追加用户消息
  messages.value.push({
    id: crypto.randomUUID(),
    from: 'user',
    content: text,
    avatarConfig: { name: 'user' },
  });

  // 2. 调用模型
  requestModel(text);
};

const requestModel = async (ques: string) => {
  // 先压入一条“空消息”，用于接收流式内容
  const index = messages.value.push({
    id: crypto.randomUUID(),
    from: 'model',
    content: '',
    loading: true,
    avatarConfig: { name: 'model' },
  }) - 1;

  const completion = await client.chat.completions.create({
    model: 'my-model',
    messages: [{ role: 'user', content: ques }],
    stream: true,
  });

  for await (const chunk of completion) {
    messages.value[index].loading = false;
    const content = chunk.choices[0]?.delta?.content || '';
    messages.value[index].content += content;
  }
};

可以看到：

MateChat 不关心你怎么拿到 completion，只要最后给到一个 messages 列表；
通过 loading 状态和“流式拼接内容”，可以实现可见的、连续的回答过程；
同样的模式可以用在盘古大模型或自建模型网关，只要接口契合 OpenAI 风格即可。

正比如如下截图所示：

3.3 落地案例解构：从 Web 网站到 IDE 的多形态智能助手

3.3.1 通用网站 & B 端系统：协作式 / 沉浸式 / 情境式

MateChat 官网与介绍文章把应用场景概括为三种模式：([MateChat][2])

协作式
- 在原有业务界面中嵌入一个 AI 协同助手；
- 用户在执行任务过程中随时向 AI 咨询问题、寻求建议；
- 典型例子：云控制台右侧的“运维助手”。
沉浸式
- 用 MateChat 打造一个专门的 AI 对话应用；
- 界面设计可以更自由，适合“AI 聊天 / AI 工作空间”场景；
- 例如：站点型 AI 互动页面、内部知识助手门户。
情境式
- 更适合研发场景，把 MateChat 入口放在真正“干活的地方”；
- 例如 IDE 内的 AI 面板、代码托管平台中的智能助手、流水线配置界面上的“问问 AI”按钮。

3.3.2 InsCode AI IDE：在开发工具中自然嵌入 AI 对话

官方案例中，InsCode AI IDE 使用 MateChat 作为核心交互 UI，帮助快速完成 AI 插件的设计与搭建。

一个典型架构是：

IDE 提供 WebView / 插件容器；
容器里运行一个 Vue + MateChat 应用；
IDE 将当前编辑文件、选中代码块等上下文传给 MateChat 应用；
MateChat 应用将上下文和用户输入打包后发送给后端大模型服务；
返回结果以气泡形式展示，并提供“插入到光标处”等快捷操作。

这里真正体现的是 MateChat 的两个优势：

UI 能力贴合研发场景（代码展示、结构化信息展示）；
跟业务逻辑保持“低侵入”，IDE 插件依旧掌握上下文和执行权。

3.3.3 CodeArts 智能助手：平台级 DevOps AI 助手

在华为云 CodeArts 智能助手场景下，MateChat 承担的是“平台级对话入口”的角色：([GitHub][3])

右侧面板集成 MateChat；
对话上下文包含项目 ID、流水线 ID、最近构建记录等；
用户可以问诸如：“最近三次构建失败的核心原因是什么？”
后端联动日志检索、监控数据与大模型分析，生成结构化答案；
MateChat 用气泡 + 卡片 + 表格形式展示。

这类场景最关键的一点是：

MateChat 负责统一“AI 交互语言”；
CodeArts 负责业务上下文和实际执行能力。

正比如如下截图所示：

3.4 创新玩法：MCP、智能体、记忆、RAG、工作流、多模态

本大纲中特别提到的一堆“关键词”，在 MateChat 的世界里可以这样理解👇：

MateChat 不直接实现 MCP / 智能体 / 工作流，而是提供 承载这些能力的 UI 外壳。

3.4.1 MCP 工具调用可视化

如果后端使用 MCP 协议管理工具列表与调用过程：

前端 MateChat 可以在对话过程中展示“工具调用状态”：
- 正在检索日志……
- 正在拉取 Kubernetes Pod 列表……
- 正在查询最近 10 次告警……
调用完成后，将结果以易读的卡片 / 表格形式展示：
- 这里可以直接复用 DevUI 的 Table / Tag / 状态色。

通过这种方式：

用户可以清楚知道 AI 在“做什么”；
也更容易对 AI 行为建立信任。

3.4.2 智能体 + 记忆化：让“助手”有人格与长期记忆

智能体 + 记忆化更多是后端职责（向量存储 + 用户画像 + 会话管理），前端可以做的是：

在 UI 中提供“智能体选择器”（如顶部切换：代码助手 / 流水线助手 / 安全助手）；
在对话中明确显示当前智能体身份与能力范围；
将“记住偏好”的操作显式化，例如：
- “记住我偏好的部署策略”；
- “下次默认使用蓝绿发布”。

MateChat 的气泡组件 + 快捷操作组件很适合承载这些“记忆开关”，而 DevUI 的设置面板 / Drawer 可以用来呈现高级配置页面。

3.4.3 知识检索、RAG 与自然语言生成 UI

在 RAG 场景里，前端主要有三个任务：

把检索到的知识片段可视化呈现（文档片段、FAQ 条目、配置片段等）；
标注引用来源（文档名、章节名、链接等）；
给用户足够的控制感（继续追问本文档 / 展开更多细节 / 打开原文）。

MateChat 可以：

把“生成的回答”与“引用的文档”拆成多个气泡；
使用 DevUI 的 Tabs / 折叠面板展示详细引用内容；
提供“基于当前文档继续提问”的快捷按钮。

自然语言生成 UI 的典型用法是：

用户：
“帮我生成一个展示最近 7 天构建成功率、按项目分组的看板。”

后端流程：

模型解析意图；
生成一个 DevUI 页面 / 图表的 schema；
返回 schema + 一段说明。

前端流程：

DevUI 根据 schema 渲染表格 / 图表 / 过滤器；
MateChat 用消息气泡解释“我帮你生成了这个看板的结构，可以修改参数”。

3.4.4 工作流与思维链（Chain-of-Thought）

在运维 / DevOps 工作流中，AI 助手常常需要执行多步操作：

步骤 1：收集最近一次失败流水线的日志；
步骤 2：识别异常阶段和关键错误；
步骤 3：匹配历史失败模式；
步骤 4：给出修复建议；
步骤 5：提供“一键重试 / 回滚”操作。

在前端里，可以用 MateChat 把这些步骤清晰展示出来：

每一步作为一条系统消息；
每条消息内用 DevUI 的时间轴 / Step 组件表示进度；([vue-devui.github.io][6])
对关键节点提供交互按钮（确认执行 / 取消 / 改参数）。

这种“可视化的 Chain-of-Thought”既能提高可解释性，又能满足企业场景对可控性的要求。

3.4.5 多模态：文件 / 图片 / 语音

MateChat 的 UI 完全可以承载多模态内容：

上传日志文件 / YAML 配置文件 → 显示解析结果；
展示拓扑图截图 → 模型做视觉理解后给出分析；
语音输入 / 播报 → 用气泡展示文字版内容，并附带音频播放器。

DevUI 在这里可以提供：

文件上传组件；
图片预览组件；
播放器或第三方多媒体组件封装。

前后端需要约定好消息格式，例如：

interface MultiModalChatMessage extends ChatMessage {
  files?: { name: string; url: string; type: string }[];
  images?: string[];
  audioUrl?: string;
}

MateChat 气泡根据不同字段选择不同展示方式即可。

正比如如下截图所示：

3.5 演进与社区：MateChat 未来的空间

从 GitHub / GitCode 仓库来看，MateChat 目前正在持续迭代，并公开了“特性规划”和“贡献指南”：([GitHub][3])

已发布多个版本 Tag；
提供本地开发脚手架（pnpm i && pnpm run docs:dev）；
社区贡献者不断增加；
官方主动邀请反馈与贡献。

结合当前趋势，可以预测 MateChat 可能在这些方向上继续增强：

更多场景模板（DevOps、运维、客服、知识助手）；
更丰富的结果呈现组件（例如和 DevUI 图表/时间轴更深度集成）；
更强的多会话管理与会话配置能力；
与企业统一身份 / 权限 / 审计系统的集成方案。

四、DevUI × MateChat：一体化云原生智能前端蓝图

说到这里，我们可以把 DevUI 与 MateChat 放到一张“体系图”里看。

4.1 从下到上的分层视图

可以把整个前端 + AI 交互体系抽象成四层：

设计规范层
- DevUI Design：组件规范、交互规范、视觉规范；([DevUI Design Of Angular][1])
- MateChat GenAI 体验系统：对话消息、过程监督、状态提示、Markdown 渲染规范。([MateChat][2])
基础组件层
- DevUI / Vue DevUI / ng-devui：布局、表格、表单、图表、编辑器等；([vue-devui.github.io][6])
- MateChat：气泡、输入区、快捷建议、头部、容器等；([MateChat][2])
业务组件与场景组件层
- 基于 DevUI 封装的业务组件：集群卡片、流水线视图、指标看板组件等；
- 基于 MateChat 封装的场景助手：日志分析助手、流水线助手、代码助手、知识助手等。
智能服务与业务后端层
- 模型服务：盘古大模型 / 内部模型网关 / 第三方大模型；([GitHub][3])
- MCP / 智能体 / 工作流编排 / 检索服务；
- 业务 API：云控制、DevOps、监控、日志等。

前端团队的职责重点在第 2、3 层：

用 DevUI 保证所有页面的一致性与可维护性；
用 MateChat 建立统一的智能交互入口；
用一套状态管理与 API 访问层把二者连接起来。

正比如如下截图所示：

4.2 完整场景串联示例：一次发布事故的“AI 辅助排查”

下面用一个更具画面感的故事把 DevUI 和 MateChat 串起来 👇

场景： 某云原生平台中的 DevOps 发布出事故，值班同学需要快速排查原因。

主界面（DevUI 搭建）
- 左侧：项目与流水线列表（DevUI Tree + Menu）；
- 中间：流水线运行历史表格（DevUI DataTable）；
- 点击某条失败记录，右侧抽屉展示详细步骤 / 日志重点（Card + Timeline）。
智能助手面板（MateChat）
- 右侧固定一个 MateChat 面板，自动注入当前项目、流水线上下文；
- 面板顶部显示当前助手身份：“发布分析助手”。
用户提问
- 用户在 MateChat 中输入：
  “帮我分析最近 3 次失败的发布，有没有共性原因？”
- MateChat 将用户输入 + 上下文打包，发送给后端。
后端智能分析流程
- 调用流水线服务 / 日志服务拉取数据；
- 存入检索或直接组装为 Prompt；
- 利用大模型做模式识别与分析；
- 生成结构化结果：
  - 失败步骤集中在“灰度验证”阶段；
  - 同一 API 返回错误码；
  - 建议回滚到上一版本、修复参数配置。
MateChat 与 DevUI 联动展示
- MateChat 用多条气泡展示分析过程和结论；
- 在其中一条气泡中嵌入 DevUI 表格，展示三次失败记录对比；
- 提供“查看相关日志片段”按钮，点击后调用 DevUI 的 Drawer 打开日志视图；
执行操作
- MateChat 提供“回滚到上一稳定版本”按钮；
- 点击后，调用后端工作流服务，触发回滚；
- 回滚过程的状态通过 MateChat 气泡实时更新（结合 MCP 工具调用状态）。

这个故事里，每一个参与者的边界都很清晰：

DevUI：负责业务 UI 与可视化；
MateChat：负责智能对话与过程监督；
模型服务 / 后端：负责真正的分析与执行。

正比如如下截图所示：

4.3 项目落地建议：从“改造旧系统”到“设计新一代智能平台”

最后，从实践视角给几条落地建议，方便你在文章结尾时做总结性陈述：

先统一界面，再引入智能
- 先引入 DevUI，对现有界面做“标准化升级”；
- 统一布局、表格、表单、反馈组件；
- 再选择几个高价值场景引入 MateChat，而不是一上来在所有页面塞一个聊天框。
坚持“UI 与模型解耦”的原则
- MateChat 负责 UI；
- 模型服务通过独立 SDK / HTTP 接口接入；
- 未来更换模型供应商时，只需调整后端集成与调用层。
从单一场景开始，逐步演进为“智能助手家族”
- 第一阶段：
  - 日志分析助手 / 流水线诊断助手 / 代码解释助手三选一；
- 第二阶段：
  - 扩展到更多业务域，并引入智能体 / 工具调用；
- 第三阶段：
  - 统一对话入口与身份体系，让不同助手共享部分记忆和能力。
用 Design System 约束“创新”的边界
- 再新潮的 AI 玩法，落到前端仍然回到按钮、卡片、列表、弹窗这些基本形态；
- 通过 DevUI + MateChat 统一体验，可以让“创新”不会带来“混乱”。