0. 背景：云原生到了“体验与智能同时要”的阶段

在很多团队里，云原生基础设施早已铺开：Kubernetes、服务网格、微服务治理、DevOps 流水线、可观测性平台……
前端这边的现实情况却往往是：

• 控制台、平台、内部工具越来越多，但风格和交互各搞一套；
• 表格 + 表单 + 弹窗堆叠成“操作面板森林”，上手门槛很高；
• 引入大模型、智能体之后，AI 功能经常被“外挂”在某个角落，很难融入主流程。

如果没有一套统一的前端解决方案做“底座”，再叠加 AI，就很容易陷入体验割裂 + 成本失控的局面。

华为云的前端技术体系给出的一个答案，是用两条核心技术线组合成“一套”：

• DevUI：面向企业中后台 / 云平台 / 研发工具的前端解决方案（Design System + Angular / Vue 组件库）。
• MateChat：面向智能化场景的前端 UI 组件库，专注 GenAI 对话体验，已服务 CodeArts、InsCode AI IDE 等落地场景。

这两个东西的角色可以简单理解为：

• DevUI：把“业务界面”统一建好；
• MateChat：把“智能交互”统一建好。

接下来我们就从工程实践角度，分别拆 DevUI 和 MateChat，然后再看它们如何在云原生场景里组合成一体化方案 ✨

相关官方地址汇总如下：

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

一、DevUI：云原生前端的“界面基础设施”（约 50%）

1.1 DevUI 技术生态全景：Design System + 多技术栈组件家族

官方对 DevUI 的定位是：

“面向企业中后台产品的开源前端解决方案”，核心是 DevUI Design 设计系统 + 各技术栈组件实现。([DevUI Design Of Angular][1])

几个最关键的信息：

• DevUI Design：

  • 包含规则、设计语言、最佳实践的组合；
  • 目标是让开发更关注业务逻辑，设计更聚焦用户体验与交互流程。([Gitee][3])

• Angular 家族：ng-devui

  • Angular UI Component Library based on DevUI Design；([Gitee][3])
  • 面向企业中后台场景，配套字体图标库与主题系统；
  • 官方说明当前支持较新的 Angular 版本（如 ^16.0.0）。([Gitee][3])

• Vue 家族：Vue DevUI

  • “一个基于 DevUI Design 设计体系的 Vue3 组件库”，使用 Vite + Vue3 + TS + JSX 搭建；([GitHub][4])
  • 包含 60+ 组件，覆盖布局、表单、数据展示、导航、反馈等类别；
  • 特别强调面向前端工程师与研发工具场景，社区活跃度高。([GitHub][4])

注意一点：
DevUI 技术线里，Angular 版 ng-devui 与 Vue3 版 Vue DevUI 是目前企业项目里使用非常多的版本；这也对应了你大纲中的“DevUI 主要版本为 Angular 与 Vue 版本”的要求 ✅。

1.2 从“设计系统”到“工程组件”的映射方式

想要用好 DevUI，最好先把它当成一个“设计系统驱动的组件家族”，而不是单纯的 UI 组件集合。

1.2.1 DevUI Design 的几个关键词

从 DevUI 官方站点和介绍里，可以抽象出几条设计原则：([DevUI Design Of Angular][1])

• 企业级组件优先：天然服务数据密集、操作繁多的中后台 / 云平台场景；
• 开箱即用：提供完善的示例、模板和文档，减少二次封装成本；
• 统一性：颜色、间距、交互动效、状态表达全部有一套明确规范；
• 高扩展性：强主题能力、可定制化的 token，使得品牌化和多产品线扩展成本可控。

1.2.2 映射到 Angular & Vue 两条技术线

• 在 ng-devui 中，DevUI Design 映射为 Angular 组件、指令、服务模块；([Gitee][3])
• 在 Vue DevUI 中，映射为 Vue3 + JSX 组件集合，并且和 Vite / TS 的现代工程体系深度结合。([GitHub][4])

你可以把 DevUI 理解为：

“一套统一的设计语言 + 多个技术栈的具体实现”，
可以在不同技术栈的前端项目里复用相同交互语义。

1.3 入门路径：用 DevUI 快速搭起一个“云原生中后台骨架”

1.3.1 Angular + ng-devui 的典型流程

按照 ng-devui 官方说明，一个标准流程大概是：([Gitee][3])

1. 使用 Angular CLI 初始化项目；
2. 安装 ng-devui（可选安装图标库 @devui-design/icons）；
3. 在 AppModule 或业务模块中引入 DevUI 模块或按需模块；
4. 使用 Layout + Menu + DataTable + Form 等组件快速搭 skeleton。

简化一下代码结构（示意）：

// app.module.ts（简化示意）
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 {}

<!-- app.component.html（简化示意） -->
<d-layout>
  <d-header>Cloud Platform</d-header>
  <d-content>
    <d-container>
      <d-aside> <!-- 菜单 / 项目树 --> </d-aside>
      <d-main>
        <!-- 资源列表 / 详情 / 图表等 -->
      </d-main>
    </d-container>
  </d-content>
</d-layout>

很快就能搭出类似云控制台的基础骨架。

1.3.2 Vue3 + Vue DevUI 的典型流程

Vue DevUI 仓库与文档给出了清晰的“快速开始”指引：([GitHub][4])

1. 用 Vite 初始化 Vue3 + TS 项目；
2. 安装 vue-devui；
3. 在入口文件中全局注册并引入样式。

// 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');

然后就可以把 Vue DevUI 的 Layout、Grid、Form、Table 等组件作为基础积木，搭出 DevOps 平台、研发工具、监控大屏等界面。

1.4 高频组件深度实践：表格 / 表单 / 弹层的“工程用法与避坑”

云原生与 B 端场景有一个特点：

80% 的交互集中在 20% 的组件上，而这 20% 就是——表格、表单、弹层。

1.4.1 表格：高密度数据展示 + 可操作性

DevUI / Vue DevUI 的 DataTable/Table 组件，天生就是为大型数据列表设计的。([Gitee][3])

在云原生控制台里，典型表格包括：

• 集群 / 节点 / Pod / Service 列表；
• 流水线运行记录、任务队列；
• 告警、事件、审计日志等。

工程实践建议：

1. 服务端分页 + 排序 + 过滤统一到查询对象

   • 统一维护一个 queryState（页码、排序字段、过滤条件）；
   • Table 只消费 queryState 和 dataSource，不直接接触接口逻辑；
   • 这样可以在不同列表之间复用查询逻辑。

2. 大数据场景下开启虚拟滚动

   • 对日志、监控事件这类“几千行起步”的列表，应使用 DevUI 提供的虚拟滚动能力；([CSDN][5])
   • 前提是行高需要可预测或固定，否则滚动计算会不准确。

3. 列配置驱动 + 权限控制

   • 用配置数组描述列（字段、标题、宽度、排序、权限码等）；
   • 渲染前先根据用户权限过滤列；
   • 避免在 template 里到处写 *ngIf="hasPermission(...)" / v-if。

4. 状态表达尽量用 Design System 提供的 Tag / Badge

   • 不要每个业务模块自己定一套颜色；
   • 使用 DevUI 预设的状态色：成功 / 失败 / 警告 / 进行中，保证视觉统一。

1.4.2 表单：动态配置 + 跨字段校验 + 分步向导

云原生环境里的表单往往非常复杂，例如：

• 创建集群 / 告警策略 / 服务路由 / 发布策略；
• 字段之间强依赖，“选了 A 类型才出现 B 选项”；
• 名称唯一性、端口范围、资源配额等校验都依赖后端。

DevUI 的 Form 系统为此提供了：表单容器、表单项、校验、布局等能力。([DevUI Design Of Angular][1])

实践建议：

1. 使用 表单 Schema 驱动 渲染组件

   • 将字段类型、控件类型、校验规则、显示条件统一描述在配置里；
   • Vue / Angular 部分逻辑只负责解析 schema → 渲染 DevUI 组件。

2. 复杂流程尽量拆成 分步表单（Wizard）

   • DevUI / Vue DevUI 都有 Step / Wizard 相关组件可以使用；([Gitee][6])
   • 每一步只聚焦一类决策（基础信息、资源配额、网络、安全、审计）。

3. 异步校验要有“节流设计”

   • 名称唯一性这类校验不要每次输入都打接口；
   • 可用 blur 触发或防抖处理。

1.4.3 弹层：Modal / Drawer 的边界与用法

在 DevUI 中一般会使用 Modal / Drawer / Dialog 处理弹层交互。([Gitee][3])

常见模式：

• Modal：危险操作确认、配置提交确认、批量操作结果总结；
• Drawer：右侧滑出“编辑详情”或“配置面板”，上下文感知更强；
• 全屏弹层：复杂创建向导或可视化编排（如流水线 / 工作流）。

避坑要点：

• 避免“弹窗里再弹窗”（典型可读性灾难）；
• 关闭弹层时如果有未保存变更，要给出友好提示；
• 弹层内表单的错误信息要与 DevUI 的表单校验一致，避免双重样式。

1.5 自定义组件与插件：把团队经验沉淀到 DevUI 生态里

对于长期维护的大型平台，只用 DevUI 原生组件肯定不够，通常会在它之上再构建一层“业务组件库”。

1.5.1 典型业务组件类型

• 统一的资源标签组件（集群、环境、租户标签）；
• 标准化的告警条 / 风险提示条；
• 封装好的项目选择器 / 集群选择器 / 告警策略选择器；
• 对云产品特定概念的“微型面板”（例如某个中间件实例的健康状态卡片）。

实现策略：

• 尽可能用 DevUI 的 Button / Tag / Tooltip / Card 等组成复杂业务组件；
• 样式基于 DevUI 主题变量，而不是写死颜色值；
• 事件命名、插槽思路向 DevUI 看齐，降低使用门槛。

1.5.2 作为“插件生态”的雏形

当这类业务组件足够多时，可以：

• 将其拆为单独 npm 包（如 @org/devui-biz-components）；
• 在 Angular 与 Vue 项目中统一引入；
• 甚至为 MateChat 提供“业务结果展示组件”（比如 AI 分析后的结果卡片）。

---

1.6 主题 / 暗黑模式 / 响应式：多产品线的统一“皮肤层”

DevUI 官方文档与仓库强调了其主题化能力和可定制性，尤其是适配企业品牌与暗黑模式方面。([DevUI Design Of Angular][1])

1.6.1 品牌主题

• 将主色、辅色、文本色、背景、边框等收敛到 Design Token；
• 不同产品线可以复用同一套 token 组合（大集团统一风格）；
• 定制品牌时仅需调整 token，而不用改所有组件样式。

1.6.2 暗黑模式

• 大部分云平台 / DevOps / IDE 用户都偏好暗色主题；

• Vue DevUI 与 MateChat 主题都是基于 Vue DevUI 主题化能力来实现。([Gitee][6])

• 建议：

  • 用 CSS 变量或 data-theme 管理主题；
  • 初次加载时根据 prefers-color-scheme 决定默认值；
  • 用户选择后写入 localStorage 保持偏好。

1.6.3 响应式布局与“嵌入型场景”

云原生工具经常会出现在 IDE 内嵌面板、窄屏窗口中：

• 在 DevUI 布局里预留右侧“助手栏”（稍后挂 MateChat）；
• 宽屏：助手栏常驻显示；
• 中宽：助手栏折叠为底部 tab；
• 极窄：助手入口变成悬浮按钮 + 全屏弹层。

这样可以保证同一套界面，在网页 / IDE 插件 / 小窗场景下都有可用体验。

1.7 DevUI 在云原生中的代表性落地模式

结合 DevUI 文档和社区案例，可以总结三类典型落地模式：([DevUI Design Of Angular][1])

1. 云控制台 / 多云管理平台

   • 树形导航 + 资源列表 + 详情页 + 监控图表；
   • DevUI Table + Card + Tabs + 图表组件构成主工作区；
   • 日志 / 审计做 Drawer + CodeEditor 展示。

2. DevOps / CI/CD 平台

   • Vue DevUI 提供 Code Editor、GitGraph、ActionTimeline 等；([GitHub][4])
   • 适合构建流水线可视化、构建历史、代码评审、制品管理等界面。

3. 低代码 / 规则编排平台

   • DevUI 组件作为“物料库”，利用 schema 描述页面；
   • 通过可视化拖拽和配置生成 DevUI 页面；
   • 后续引入 MateChat 做“自然语言生成页面 / 流程”的智能辅助。

---

二、MateChat：智能交互的统一“对话外壳”（约 50%）

有了 DevUI 打地基，接下来就是怎么把 AI 能力以“好用、好看、好维护”的方式放进来，这就是 MateChat 要解决的问题。

2.1 MateChat 是什么？更重要的是，它不是什么

官方 README 和官网介绍给出了非常明确的定义：([GitCode][2])

• MateChat 是：

  • “前端智能化场景解决方案 UI 库”；
  • 专注 GenAI 对话体验；
  • 帮你“轻松构建 AI 应用”的 UI 外壳；
  • 已经服务华为内部多个应用，并助力 CodeArts、InsCode AI IDE 等智能助手的搭建。([GitHub][7])

• MateChat 不是：

  • 不是后端 SDK，也不是大模型服务本身；
  • 不提供“MateChat 专用模型 API”，也没有封装专有 SDK；
  • 官方文档明确示例：对接模型时通过 openai 等 SDK / HTTP 调用自己的模型服务（如盘古大模型、ChatGPT 等）。([MateChat][8])

也就是说：

MateChat 只负责 “对话 UI + 交互流程 + 体验语言”，
模型调用、智能体逻辑、工作流等全部由你自己的后端 / 中间层负责。

这一点与你在题目中强调的“MateChat 无 SDK / 没有 SDK 形式”完全一致 ✅

当前 MateChat 自定义主题基于 DevUI Theme 实现。 DevUI Theme 是DevUI提供的一个框架无关的通用主题定制方案，内置丰富的主题，并支持自定义主题。

无限主题 infinityTheme 效果演示：

追光主题 galaxyTheme 效果演示：

2.2 核心组件与消息模型：把聊天这件事模型化

从 MateChat 官网和文档来看，它的能力集中在几类组件上：([GitCode][2])

1. 消息气泡组件（Bubble 类）

   • 用来展示“用户 / 模型 / 系统消息”；
   • 支持左右对齐、头像、加载状态、不同视觉风格等。

2. 输入区与建议组件

   • 输入框、发送按钮、快捷提示（suggestion chips）；
   • 可以根据业务上下文生成建议问题或快捷操作。

3. 头部 / 布局组件

   • 用于构建“助手面板”的标题栏、操作入口；
   • 通常会嵌入在右侧面板或单独页面。

4. 多主题适配能力

   • 主题系统基于 Vue DevUI 主题化实现，可与 DevUI 应用整体风格统一。([MateChat][8])

为了使用这些组件，一般会在前端维护一个类似这样的消息模型：

interface ChatMessage {
  id: string;
  role: 'user' | 'assistant' | 'system';
  content: string;
  loading?: boolean;
  avatarConfig?: {
    name?: string;
    imgUrl?: string;
  };
  // 可扩展：工具调用结果、多模态内容等
}

MateChat 组件的职责，就是把这个 ChatMessage[] 渲染成对话 UI。

---

2.3 官方推荐的“对接模型服务”方式：UI 与模型彻底解耦

MateChat 官网的「对接模型服务」章节，给出了一个非常清晰的流程：([MateChat][8])

1. 通过 npm 安装 openai 包；
2. 使用 OpenAI 初始化客户端，配置 API Key 与 BaseURL；
3. 调用 client.chat.completions.create，开启 stream: true；
4. 遍历流式响应，把内容不断写入 messages 最后一条消息。

文档中的片段（这里做了充分意译与重组）大致是这样的：

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 onSubmit = (text: string) => {
  inputValue.value = '';
  startPage.value = false;

  // 1. 用户消息
  messages.value.push({
    role: 'user',
    content: text,
    avatarConfig: { name: 'user' },
  });

  // 2. 请求模型
  fetchData(text);
};

const fetchData = async (ques: string) => {
  // 先追加一条空的模型消息，后续流式填充
  messages.value.push({
    role: 'assistant',
    content: '',
    avatarConfig: { name: 'model' },
    id: '',
    loading: true,
  });

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

  for await (const chunk of completion) {
    const last = messages.value[messages.value.length - 1];
    last.loading = false;
    const delta = chunk.choices[0]?.delta?.content || '';
    const chatId = chunk.id;

    last.content += delta;
    last.id = chatId;
  }
};

可以看到：MateChat 本身不做任何模型推理，只要求你最终拿到一个 messages 列表，剩下交给 UI。

这也解释了为什么很多社区文章都强调：

“只要你的模型兼容 OpenAI 风格的 Chat Completion 协议，就可以用几行配置完成切换”。([掘金][9])

---

2.4 典型落地场景拆解：MateChat 到底适合哪里用？

官方开源宣讲与资料中，已经提到 MateChat 适用多类场景：([掘金][10])

• 各类 Web 网站（企业官网、电商、教育、社区等）的智能助手；
• 企业内部中后台的协作式 AI 助手；
• DevOps / 研发工具平台的内嵌式助手；
• IDE / Cloud IDE 内的 AI 对话侧栏（典型如 InsCode AI IDE）。

2.4.1 网站 / 中后台助手：协作式 & 沉浸式

MateChat 官方将场景分为“协作式”与“沉浸式”等模式：([掘金][10])

• 协作式：

  • 嵌入在业务界面右侧或底部；
  • 让 AI 成为“跟着页面工作的助手”，而不是一个完全独立的聊天框。

• 沉浸式：

  • 整个页面就是一个 AI 交互空间；
  • 可以定制独特的视觉风格与交互动效。

从工程角度看：

• 协作式模式特别适合云控制台、运维平台、DevOps；
• 沉浸式适合对外展示的“产品级 AI 助手”或者内部知识问答系统。

2.4.2 DevOps / Code 平台：CodeArts 智能助手的范式

MateChat 官网列举了“华为云 CodeArts 智能助手”作为落地案例之一：([MateChat][8])

在这种场景下，典型流程是：

1. 在 CodeArts 的界面右侧嵌入 MateChat 面板；
2. 将当前项目、分支、流水线 ID、最近构建信息等上下文传给后端服务；
3. 用户提问：“最近几次流水线失败的原因？”
4. 后端调用流水线 API、日志服务，再结合大模型处理；
5. MateChat 将结果以气泡 + 表格 + Tag 形式展示，并提供“跳转到对应构建记录”的按钮。

2.4.3 IDE / Cloud IDE：InsCode AI IDE 的插件模式

官方也提到 MateChat 支持 InsCode AI IDE 这类场景：([GitCode][2])

一个典型模式：

• IDE 提供一个 WebView 面板；
• 里面运行 Vue + MateChat 应用；
• IDE 通过消息通道（postMessage / RPC）将当前文件、选中代码等上下文传递给 MateChat 应用；
• MateChat 将这些上下文加到 Prompt 中，发送给模型；
• 返回结果以代码块气泡、操作按钮（“插入光标处”“创建新文件”）的方式呈现。

这类场景下，MateChat 的优势在于：

• 视觉风格和 DevUI / Vue DevUI 保持一致，嵌在开发工具里不会违和；
• 内建对话流程，可以少写很多 UI 状态管理代码。

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

本大纲中提到的一系列关键词——MCP、智能体、个性化与记忆化、知识检索、自然语言生成 UI、工作流、思维链、多模态交互——在 MateChat 的架构里可以这样理解：

MateChat 负责 “展示与交互”，
这些能力由后端或中台实现，再通过结构化结果反射到 MateChat 的对话中。

2.5.1 MCP：把工具调用过程变成“可视化剧本”

• 后端用 MCP 或其他协议管理工具列表与调用；

• 前端 MateChat 在对话中展示类似：

  • “正在检索最近 10 次构建记录…”
  • “正在调用监控 API 获取 CPU 指标…”

• 每一步工具调用都可以以系统消息 / 进度提示的形式显示；

• 调用完成后，用 DevUI 的 Table / Chart 组件展示数据，再嵌入到 MateChat 气泡中。

这样用户可以清楚看到 AI 的“思考过程”，而不是黑盒子 👍

2.5.2 智能体 + 个性化记忆：从“无脸助手”到“熟悉的搭档”

• 智能体逻辑在后端维护（不同角色、工具列表、系统 Prompt）；

• 前端 MateChat 提供：

  • “助手选择器”（顶部切换不同智能体）；
  • 会话设置面板：记忆范围、风格偏好、安全级别等；
  • 气泡提示：“已记住你的偏好：默认使用灰度发布”。

UI 层的小交互（开关、提示、标记）会极大提升“AI 有人格、有记忆”的感知。

2.5.3 知识检索 / RAG + 自然语言生成 UI

在 RAG 场景中：

• 检索结果（文档片段、FAQ、配置说明）可以作为“引用气泡”展示；
• 可使用 DevUI 的折叠面板 / Tabs 展示详细引用内容；
• 气泡里给出“基于这篇文档继续提问”的按钮，构建上下文延续。

自然语言生成 UI 的典型流程：

1. 用户自然语言描述想要的界面 / 报表 / 工作流；
2. 后端模型生成一个 DevUI 页面 / DSL 的 schema；
3. DevUI 负责渲染实际界面；
4. MateChat 在对话中解释“我为你生成了如下页面 / 流程，可以继续调整”。

这就是“DevUI 负责渲染，MateChat 负责解释”的典型协作模式。

2.5.4 思维链 / 工作流：让 CoT 变成可操控的步骤流

• 将复杂推理过程拆成多个步骤消息：

  • Step 1：分析错误日志；
  • Step 2：匹配历史故障库；
  • Step 3：生成修复方案；
  • Step 4：列出执行步骤。

• 对于需要自动执行的工作流：

  • 每一个关键步骤前让用户确认；
  • 使用 DevUI 的 Steps / Timeline 组件可视化执行进度；([Gitee][6])
  • MateChat 气泡中同步展示执行状态。

这样既能保留大模型的“思考链路”，又能保证企业场景里必要的可控性与审计性。

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

MateChat 本身聚焦 UI，很适合展示多模态结果：

• 文件：上传日志 / YAML / 配置文件 → 解析结果以文本 + 高亮结构呈现；
• 图片：展示拓扑图、报错截图 → 模型做视觉理解后给出分析；
• 语音：输入 / 输出都可以在 UI 中同时提供文本与音频控件。

数据结构可以在前面的 ChatMessage 基础上扩展：

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

MateChat 负责“怎么展示这些内容”，DevUI 可以提供文件列表、图片预览等基础组件。

其中针对Theme 主题类，主题类用来创建自定义主题，主要包含以下属性：

2.6 工程实践关注点：性能、可观测性与团队协作

MateChat 虽然是 UI 库，但在工程落地时建议考虑：

1. 消息数量与虚拟列表

   • 长对话需要考虑虚拟滚动，避免 DOM 过大；
   • 历史消息可以分页加载。

2. 错误友好性

   • 模型调用失败时，气泡中要给出清晰错误信息与重试按钮；
   • 对超时、网络异常等要有一致的提示风格。

3. 可观测性

   • 对关键操作（提交问题、调用工具、执行工作流）做埋点；
   • 前端日志与后端链路打通，便于问题排查。

4. 组件文档与示例

   • MateChat 官方提供了示例页面和演示场景；([MateChat][8])
   • 团队内部可在此基础上沉淀自己的“场景模板”（如“日志分析助手模板”“流水线诊断助手模板”）。

---

三、DevUI × MateChat：云原生智能应用的一体化蓝图

前面我们分别从 DevUI 与 MateChat 的视角拆了一圈，现在该把它们放到同一张架构图里看了 😊

3.1 分层架构：UI 层如何拆分职责？

从前端 + 智能交互的角度，可以做这样一个拆分：

1. 设计与体验层

   • DevUI Design：统一的企业级设计系统；([DevUI Design Of Angular][1])
   • MateChat GenAI 体验语言：对话气泡样式、输入方式、过程提示等。([掘金][10])

2. 基础组件层

   • DevUI / Vue DevUI 组件：表格、表单、布局、图表、编辑器等；([GitHub][4])
   • MateChat 组件：对话容器、气泡、输入区、建议区域、头部等。([GitCode][2])

3. 业务组件与助手层

   • 基于 DevUI 封装的业务组件：资源卡片、流水线视图、健康状态面板等；

   • 基于 MateChat 封装的“场景助手”：

     • 日志分析助手
     • 流水线失败诊断助手
     • 资源容量规划助手
     • 安全配置检查助手……

4. 后端智能服务层

   • 大模型服务（盘古 / ChatGPT / DeepSeek / Qwen / 内部模型网关等）；([掘金][9])
   • MCP 工具、智能体编排、RAG 服务；
   • 业务 API（K8s、流水线、监控、日志、审计等）。

从这个分层你能看到一个好处：任何一层升级或替换，其他层只要契约不变，成本都可控。

3.2 端到端示例：构建一个“云原生智能运维控制台”

我们用一个完整示例把 DevUI 和 MateChat 串起来 👇

3.2.1 界面布局（DevUI）

• 顶部：全局导航 + 环境切换 + 全局搜索；

• 左侧：集群 / 命名空间 / 服务树（DevUI Menu + Tree）；

• 中间：

  • 上：集群指标看板（图表组件）；
  • 下：Pod 列表 + 告警列表（DataTable + Tabs）。

• 右侧：MateChat 智能运维助手面板。

3.2.2 交互流程

1. 用户在 Pod 列表中看到多个 Pod 处于 CrashLoopBackOff 状态；

2. 点击某个 Pod，详情面板里显示最近事件与日志摘要；

3. 用户打开右侧 MateChat 面板，直接问：

   “帮我分析这个 Pod 最近反复重启的原因，并给出修复建议。”

4. 前端把如下信息组装成请求上下文：

   • 当前集群 / 命名空间 / Pod 名称；
   • 最近 N 次重启时间；
   • 部分日志片段 / 事件信息；
   • 用户输入的问题。

5. 后端流程：

   • 通过 API 拉取完整日志 / 监控数据；
   • 调用大模型进行分析（可结合 RAG 检索内部知识库：故障手册 / FAQ）；([CSDN][11])
   • 得到带结构化字段的回答（原因列表、关键证据、建议步骤等）。

6. MateChat 展示结果：

   • 第一条气泡：用自然语言概括“最可能的原因”；

   • 第二条气泡：用 DevUI 表格嵌入“最近 5 次重启的时间线与 Exit Code”；

   • 第三条气泡：列出可执行操作（附带按钮）：

     • “查看相关配置文件差异”
     • “回滚到上一版本”
     • “仅重启当前 Pod”

7. 用户点击“查看配置差异”，DevUI 打开一个 Drawer：

   • 利用 CodeEditor 显示两个版本的配置 diff；
   • 同时 MateChat 继续在气泡里解释差异的含义。

整个过程里：

• DevUI 负责 业务 UI、数据可视化、操作入口；
• MateChat 负责 自然语言对话、过程解释、引导下一步操作；
• 大模型与工具调用都在后端完成，前端只做展示与控制。

3.3 项目落地路线图：从“有系统没助手”到“系统内生智能”

如果你要以 DevUI + MateChat 为基础做云原生智能化改造，一条可行路线是：

1. 第一阶段：DevUI 化界面

   • 用 DevUI / Vue DevUI 替换零散组件库；
   • 统一布局、配色、控件风格；
   • 把表格 / 表单 / 弹层做一次结构性梳理和抽象。

2. 第二阶段：MateChat 单场景试点

   • 选一个最痛点的场景，比如“流水线失败分析”；
   • 在页面右侧挂一个 MateChat 面板；
   • 仅对接单一大模型或内部模型网关；
   • 剪裁好上下文，做出一个真正能帮到研发/运维的助手。

3. 第三阶段：扩展为“助手族群”

   • 在 MateChat 顶部提供助手选择：DevOps 助手、运维助手、日志助手等；
   • 后端引入工具调用 / RAG / 智能体等能力；
   • 不同助手复用 DevUI 的业务组件与 MateChat 的 UI 组件。

4. 第四阶段：自然语言驱动的工作流 / 低代码

   • 用户用自然语言描述需求；
   • 模型输出 DevUI schema / Pipeline DSL；
   • DevUI 渲染界面 / 流程编排画布；
   • MateChat 在旁持续解释 + 协助调优。

在这个过程中，你可以一直保持这条原则：

“界面与交互标准化 → 能力和场景不断叠加 → 统一体验不被破坏”。

结语：让云原生前端既“稳”又“聪明”

• DevUI 给了我们一套 稳定、统一、工程化友好 的中后台界面基础设施；
• MateChat 给了我们一套 可复用、可扩展、与模型解耦 的智能交互外壳；
• 两者合在一起，可以在云原生场景里支撑从 业务操作 → 数据可视化 → 智能辅助 的全链路。

如果用一句话总结这篇稿子的主线，那就是：

用 DevUI 打造云原生前端的“骨架与皮肤”，
再用 MateChat 为它接上“会说话、会思考的大脑”。 🧠✨

相关官方地址汇总如下：

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

---

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