一、云原生深水区：前端和 AI 不再是“两条平行线”

过去几年，云原生架构把应用拆成了无数个小块：微服务、Serverless、Job、Pipeline……
但对终端用户而言，他们只看得到两层东西：

  1. 屏幕上的界面

    • 能不能快速找到入口？
    • 表格查得动不动？
    • 表单是不是一改就报错？

  2. 屏幕里的智能

    • 能不能懂我的自然语言？
    • 能不能帮我“少点几次按钮”？
    • 能不能把复杂操作串起来？

这两层，正好对应华为 DevUI 团队的两大开源成果：

  • DevUI —— 面向企业中后台的前端通用解决方案，既是设计系统也是组件生态，目前已提供成熟的 Angular 版本（ng-devui）和基于 DevUI Design 的 Vue3 组件库（vue-devui）。
  • MateChat —— 面向智能化场景的 UI 组件库，专门为生成式 AI 场景设计交互体验，目前已在 CodeArts 智能助手、InsCode AI IDE 等多个产品中落地。

从技术形态看：

  • DevUI 更偏“横向的基础设施”：设计规范 + 组件库 + 工程实践；
  • MateChat 则是“竖向的智能能力界面”：给各种 GenAI / 智能体铺一条统一的交互通道。

相关官方地址汇总如下：

二、DevUI：企业级前端的“稳定底座”

2.1 DevUI 在生态中的位置：不是简单组件库，而是“解决方案”

官方对 DevUI 的定位可以概括为一句话：

面向企业中后台产品的开源前端解决方案，基于 DevUI Design 设计系统，为设计师和研发提供统一语言。

关键点有三个：

  1. 设计系统先行
    DevUI Design 把颜色、字号、间距、动效等抽象为一套设计 Token，并配套规则与最佳实践，让开发和设计讨论“语义化的变量”而不是“某个页面上第 3 行的那个蓝色”。

  2. 多技术栈实现

    • ng-devui：Angular 组件库，目前官方文档显示已支持到较新的 Angular 主版本，并强调企业级组件与开箱即用。
    • vue-devui：基于 DevUI Design 的 Vue3 组件库，建设在 Vite + Vue3 + TypeScript 上，包含几十个企业常用组件。

  3. 开源与企业级并存
    DevUI 遵循开源协议，代码公开，强调“企业中后台产品”的实际落地，包括控制台、B 端管理系统、研发平台等。

换句话说：在 DevUI 的视角里，“前端组件”不是目的，而是让企业在几十个系统里做到统一体验、统一技术栈、统一工程规范的手段。

2.2 高频组件深挖：表格、表单、弹窗、导航

中后台界面有个“80/20 定律”：
80% 的页面结构，都是表格 + 表单 + 弹窗 + 导航的不同组合。

DevUI 在这几块上做了很多“工程级打磨”，如果只当普通组件用，等于白白浪费。

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

以 ng-devui 为例，它在表格相关组件中支持：

  • 大数据场景：

    • 虚拟滚动、按需渲染；
    • 客户端或服务端分页。

  • 复杂交互：

    • 多选、行内编辑、行展开、树形结构；
    • 自定义单元格模板，支持按钮、Tag、进度条等各种内容。

  • 企业级能力：

    • 国际化支持；
    • 空状态、加载状态、错误状态的统一视觉。

在云原生控制台中的典型用法：

假设你要做一张“容器实例列表”，常见的增强方式有：

  1. 统一查询模型

    • 把分页条件、过滤项、排序字段抽象成一个 QueryModel，表格组件对它一视同仁；
    • 所有列表页面共享这套模型，便于日志追踪和 API 网关治理。

  2. 行内快操作

    • 在“操作”列中放入 DevUI 的 Button、Dropdown、Popover，支持 “重启”、“扩容”、“查看日志” 等；
    • 使用气泡确认组件包好危险操作（删除、重置），减少误点。

  3. 状态可视化

    • 把状态字段使用 Tag 或 Badge 呈现：运行中、失败、等待中；
    • 配合 Tooltip 提示“失败原因摘要”，用户无需点进详情就能知道大致情况。
2.2.2 表单：从“数据录入”到“规则中枢”

企业场景的表单，远比“登录表单”复杂得多：

  • 动态字段（选了某项才出现额外参数）；
  • 级联校验（时间区间、范围值）；
  • 布局压缩（配置项很多，但屏幕有限）。

DevUI 的表单能力，主要体现在：

  • 表单项分组、栅格布局支持；
  • 校验规则、多状态反馈（成功/警告/错误）；
  • 配合 Select、DatePicker、TreeSelect 等富交互控件。

实战建议：

  1. Schema 驱动表单
    把表单结构抽象成一个 JSON / TS 配置，而不是把所有字段写死在模板里：

    interface FieldSchema {
  name: string;
  label: string;
  component: 'input' | 'select' | 'switch' | 'number';
  required?: boolean;
  options?: { label: string; value: string }[];
  colSpan?: number;
  dependencies?: string[]; // 依赖字段
}

    然后由一个通用的 SchemaForm 组件，根据 Schema 拼接 DevUI 的表单组件。

  2. 前后端共用校验逻辑

    • 将复杂规则（例如：磁盘容量必须大于某个阈值且小于配额）定义在公共模块；
    • Angular/Vue 前端只负责触发校验，后端使用同一逻辑保证“永远不出现前端放行后端拒绝”的尴尬。

  3. 表单与表格联动

    • 使用 DevUI 步骤条 + 表单组成“向导流程”
    • 最终确认页用一个只读表格展示配置信息，让用户在提交前有清晰确认。

2.2.3 弹窗：从“对话框”到“小流程容器”

传统对话框只负责一句确认：是 / 否。
DevUI 的弹窗体系可以承载更复杂的小流程：

  • 支持自适应宽度、拖动、全屏；
  • 支持在内部嵌套 Tab、Form、Step、Timeline 等组件。

典型用法：

  • “新建资源向导”放在对话框里分 3–5 步走完；
  • “查看执行历史”用弹出侧滑面板展示，不打断当前页面操作；
  • “MateChat 智能建议”也可以作为弹窗形式，后文会提到。

2.2.4 导航与布局：复杂系统的“骨架”

云原生控制台常见的布局形态：

  • 顶部品牌栏 + 左侧菜单 + 内容区域；
  • 左侧多级菜单支持折叠、固定、滚动；
  • 面包屑导航帮助用户记住自己“在系统哪一层”。

DevUI 提供的 Layout / Nav / Menu / Breadcrumb 组件，可以比较轻松地组合出一套控制台骨架。

工程层面的建议：

  • 把菜单配置与权限系统绑定，渲染菜单时仅依赖一份“后端下发的树”；
  • 对微前端场景，主框架使用 DevUI 布局，子应用只占用“内容区”，保持整体统一视觉。

2.3 主题与样式：把“好看”变成一种可治理能力

DevUI 的主题系统强调：设计 Token + 多主题机制。

核心思路是：

  1. 把色板、字号、圆角、阴影等全部抽象为 Token 名称；
  2. 不同品牌 / 产品只需切一套 Token 值；
  3. 通过 CSS 变量或类名切换，实现运行时主题切换；

官网的主题指南明确说明了 DevUI 主题如何应用在 Angular 项目中，并支持暗黑模式等需求。

在 Vue 生态中，vue-devui 也配套了主题定制能力，适合在统一品牌下快速搭多个前端项目。

为什么这对 MateChat 也重要？
因为 MateChat 官网明确写到：其主题化能力基于 vue-devui 主题系统来实现，这意味着 DevUI 的主题可以“天然下沉到 AI 聊天体验里”。

2.4 自定义组件与插件：从“会用”到“会造”

DevUI 提供了大量基础组件，但企业真正的竞争力往往是在“自己封装了一层业务组件”。

2.4.1 二次封装业务组件

典型做法：

  1. 基于 DevUI 的 Table / Form / Card 等组合出一个业务组件，比如“云主机规格卡片”；
  2. 抽象出业务语义的属性：cpuCores、memorySize、price、recommendReason；
  3. 对外隐藏所有 DevUI 的细节，让其他团队只面对业务语义。

接下来可以把这些组件统一放在一个内部 NPM 包中，比如 @corp/cloud-devui-ext，成为企业自己的“行业层组件库”。

2.4.2 与设计工具、低代码平台的串联

从官方资料与社区内容可以看到，DevUI 团队在以下方向做了大量探索：

  • Figma 对接：

    • 设计师使用 DevUI 组件库完成界面设计；
    • 通过插件导出结构信息，对接到前端项目里。

  • 低代码支持：

    • DevUI 组件具备清晰的属性 / 事件定义，适合做成低代码“物料”；
    • 常见的“三板斧页面”（查询表单 + 列表 + 详情）可以保存为搭建模板。

这让 DevUI 从“组件库”升级成“前端方案集”的基础。

2.5 云原生控制台案例：用 DevUI 起一套“资源统一管控台”

下面构造一个贴近真实的案例，完整串联 DevUI 的能力。

2.5.1 场景设定

你需要为企业搭建一个“云资源统一管控”控制台：

  • 管 VM、容器、数据库、消息队列、函数计算等多个资源；
  • 需要统一登录、统一导航、统一告警中心；
  • 团队里既有 Angular 项目也有 Vue 项目。
2.5.2 方案骨架

  1. 主应用

    • 使用 Angular + ng-devui 构建主框架：顶部栏、侧边菜单、面包屑、统一主题；
    • 通过微前端容器（如 qiankun）挂载子应用。

  2. 子应用 A：云主机管理

    • 使用 Angular + ng-devui；

    • 页面结构：

      • 左侧资源树（区域/可用区/项目）+ 右侧主机列表表格；
      • “新建主机”走 DevUI 步骤条 + Form 组合的向导；
      • 详情页使用 Tab + Card 呈现监控、网络、安全组。

  3. 子应用 B：函数计算管理

    • 使用 Vue3 + vue-devui；

    • 页面结构：

      • 顶部筛选条 + 函数列表表格 + 右侧详情抽屉；
      • “快速新建函数”通过弹窗 + Markdown 编辑器组件完成。

  4. 统一主题

    • 基于 DevUI Design 主题系统抽取“CloudX” 品牌 Token；
    • Angular 与 Vue 两端均引入同一套主题配置。

  5. 后续扩展

    • 新增“AI 运维助手”时，前端不需要推倒重来，而是直接在控制台右下角引入 MateChat 组件（下一大节会展开）。

通过这个案例，DevUI 主要解决的是：

  • 多技术栈、多子系统的视觉统一；
  • 通用中后台交互模式的复用；
  • 与设计、低代码、DevOps 的互联。

2.6 DevUI 入门路线图（Angular & Vue 双线）

这里不做“纯安装手册”，而是整理一个从 0–1 的学习路线，方便在征文或内部培训中作为“附录”。

2.6.1 Angular + ng-devui 路线

参考 ng-devui 官方 README：

  1. 环境准备

    • 安装 Node.js（LTS）；
    • 安装 @angular/cli。

  2. 新建项目 & 安装 ng-devui

    ng new cloud-console --routing --style=scss
cd cloud-console
npm i ng-devui @devui-design/icons

  3. 引入模块与样式

    • 在 app.module.ts 中导入 DevUIModule 与 BrowserAnimationsModule；
    • 在 angular.json 中引入 DevUI 的 CSS。

  4. 从 Demo 开始

    • 优先实现一个“查询表单 + 表格列表”的典型页面；
    • 再逐步引入 Breadcrumb、Dialog、Drawer 等组件。

  5. 再往上是二次封装

    • 把“列表页”的逻辑封装成基类，把“详情抽屉”做成通用组件；
    • 引入主题 / 国际化 / 权限控制。
2.6.2 Vue3 + vue-devui 路线

参考 Vue DevUI 官方站点：

  1. 使用 Vite 创建 Vue3 + TS 项目；
  2. 安装 vue-devui，在入口文件中按官方文档注册；
  3. 先用 Button、Layout 组件拼出一个最简单的管理页；
  4. 再逐步替换为 Table、Form、Tabs、Drawer 等更复杂组件；
  5. 最后接入 theme 机制，与全站风格打通。

到这里，DevUI 就从“组件库”真正变成了你的“中后台基础设施”。

三、MateChat：为 GenAI 打造统一的“前端门面”

如果说 DevUI 搭好了“系统壳子”，那 MateChat 就是在这个壳子里挖出一个“智能入口”，把模型、工具、知识库、工作流等复杂能力划归到一个易用的交互空间里。

3.1 MateChat 的正式定义：前端智能化场景解决方案 UI 库

MateChat 官网的描述可以抓住两个关键词：

  1. 前端智能化场景解决方案 UI 库

    • 它不提供模型本身，只负责 UI 与交互；
    • 已被用于华为内部多个应用的智能化改造，并服务于 CodeArts 智能助手、InsCode AI IDE 等场景。

  2. GenAI 体验系统语言

    • 致力于在不同业务场景（DevOps 平台、IDE、网站）中构建高度一致的对话体验；
    • 强调“体验无边界、业务无侵害”，尽可能少地打扰原业务流。

一个很重要的事实：

  • MateChat 只提供前端组件与集成指南，不内置针对某个模型的 SDK；
  • 模型调用（盘古、ChatGPT、本地 LLM）都由业务后端或前端自定义完成，官网文档使用 OpenAI 作为示例来说明对接方式。

这与题目中“MateChat 没有 SDK 形式”完全吻合。

3.2 体验设计理念：把“会聊天”进化为“会被理解”

MateChat 官网对自己的体验原则给出了一个很清晰的框架：

  1. 快速唤醒

    • 固定入口、情境建议、快捷键……
    • 不管是 DevOps 平台还是 IDE，总要有“随手可用”的触发方式。

  2. 轻松使用

    • 通过引导提示、示例问题降低新用户心智负担；
    • 避免“我该怎么问？”的尴尬。

  3. 自由表达

    • 特化的输入区域，支持多行编辑、快捷换行、Markdown、附件等；
    • 为 GenAI 对话做了专门优化，而不是复用普通的表单输入。

  4. 过程可监督

    • 明确展示“正在思考”、“正在检索”、“正在调用工具”等状态；
    • 对结果来源进行标记，提高用户对 AI 的信任度。

  5. 可读性强

    • 对长文、结构化文本、代码段采用层次分明的 Markdown 渲染；
    • 让回答不仅“聪明”，而且“好读、好用、好操作”。

这些理念决定了 MateChat 的组件设计都围绕一个核心问题：如何让复杂的智能后台（模型、工具、RAG）被用户“看得懂，用得顺”。

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

无限主题 infinityTheme 效果演示：

追光主题 galaxyTheme 效果演示：

3.3 组件族一览：从气泡到布局的全链条

MateChat 文档与示例中列出了系列组件，我们可以把它们拆成几类来理解：

3.3.1 消息组件：对话流的“细胞”

  • 消息气泡（Bubble）

    • 用于承载用户消息、模型回复、系统提示；
    • 支持左右对齐（区分 speaker）、头像配置、loading 态等；
    • 支持 Markdown、代码高亮、多段内容。

通过气泡的属性，可以表达：

  • 谁在说（user / model / tool / system）；
  • 现在是输出中还是已完成；
  • 这条消息是否有“引用来源”“工具调用结果”等附加信息。
3.3.2 输入组件：把自然语言变成结构化请求

MateChat的输入框并不是普通的 <textarea> 套一层壳，而是专门为对话交互设计：

  • 支持多行编辑、快捷键配置（Enter 发送 / Ctrl+Enter 换行）；
  • 支持预置 placeholder 和输入建议；
  • 输入区域底部可以挂载“智能体切换”“模型切换”“上传附件”等快捷入口。

它解决的不是“如何打字”，而是“如何高效地告诉 AI 我想做什么”。

3.3.3 快捷提示组件：减少“从空白开始”的焦虑

类似 PromptCard 或 QuickPrompt 的组件，通常用于：

  • 欢迎页上的“你可以这样使用我”；

  • 场景化入口，比如：

    • 在日志页面列出“分析最近一小时错误日志”；
    • 在数据库页面列出“帮我检查这个 SQL 是否有性能风险”。

点击这些提示卡，通常会自动把问题填入输入框，或者直接触发一次对话请求。

3.3.4 布局组件：一套“AI 聊天页”的标准骨架

MateChat 给出的 Layout 相关组件帮助开发者快速搭出一个完整的 AI 页面：

  • 头部区域（Header）：标题、副标题、入口按钮、设置入口；
  • 主体区域（Content）：展示欢迎画面或历史对话；
  • 底部发送区（Sender）：承载输入框、快捷按钮。

这套 Layout 可以嵌入到任何 DevUI 页面中，比如：

  • 作为右侧抽屉里的一个完整 AI 助手；
  • 作为一个完全独立的“智能助手中心”应用页面。
3.3.5 扩展位：为智能体、知识库、多模态预留空间

从文档和演示来看，MateChat 还刻意预留了多处“扩展挂点”：

  • 输入区 footer 的图标位：可用来放“知识库选择”“智能体切换”“上传文件”；
  • 对话区域侧边栏：可放会话列表、知识卡片、工具执行历史；
  • 气泡附加区：可显示“引用文档”“使用工具”等信息。

这些扩展位是后面接入 MCP、RAG、多模态的关键。

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

3.4 MateChat 与模型的关系：无 SDK，但连接方式清晰

官方使用 OpenAI SDK 给出了一个流式调用的示例，核心思路是：MateChat 产生的输入 -> 你自己的调用代码 -> 再回写 MateChat 的消息列表。

3.4.1 官方示例的抽象

示例中主要有几步：

  1. 安装 OpenAI 客户端：

    npm install openai

  2. 初始化客户端并开启流式返回：

    import OpenAI from 'openai';

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

  3. 在 onSubmit 回调中：

    • 把用户输入 push 到 messages 列表（from: ‘user’）；
    • 插入一条空的 model 消息（from: ‘model’, loading: true）；
    • 调用 client.chat.completions.create({ stream: true, ... })；
    • 在 for await (const chunk of completion) 循环中，不断往最后一条 model 消息的 content 字符串追加片段。

这个代码并没有跟 MateChat 强耦合，只要你把 messages 绑定给 MateChat 的消息组件，就能让 UI 自动表现出“流式生成”的体验。

3.4.2 泛化为“任意模型接入”的模式

无论是盘古大模型、自研模型，还是其它云厂商的大模型，只要满足：

  • 能接受一个文本问题和上下文；
  • 能进行流式或一次性返回；

就可以被接入 MateChat。

你只需要保证三件事：

  1. 把提交事件和 inputValue 对接好；
  2. 对接的接口返回格式转换为 messages 列表里那样的结构；
  3. 正确维护 loading 等状态，给用户友好的过程反馈。

这也解释了为什么 MateChat 没有 SDK：它有意保持模型侧的开放度，把“模型选型权”完全交给业务方。

3.5 落地实践：三个典型场景拆解

结合官网展示的案例与社区文章，我们可以总结出三类最典型的使用场景。

3.5.1 网站智能客服 / 问答助手

目标：
为公司官网、产品站、社区站提供一个统一的 AI 问答窗口。

UI 形态：

  • 右下角悬浮按钮（MateChat 触发入口）；
  • 点击后弹出聊天窗口，内部使用 MateChat Layout + Bubble + Input 的标准结构；
  • 顶部展示“网站 AI 助手”的头像与简介。

能力要点：

  • 后端使用 RAG，从产品文档、FAQ、知识库构建向量库；
  • 模型层对用户问题进行改写、检索、生成回答；
  • 前端 MateChat 负责展示回答，并显示“答案引用自哪些文档”。

优势：

  • 得益于 MateChat 的可主题化能力，聊天窗口可以完全跟站点风格对齐；
  • 不改动站点路由结构，只是在全局挂一个浮动入口，符合“业务无侵害”的原则。
3.5.2 研发工具 AI 助手（以 InsCode AI IDE 为例）

官网已给出 InsCode AI IDE 作为应用案例：IDE 使用 MateChat 组件迅速搭好了一个 AI 插件，为开发者提供智能编程支持。

典型交互：

  • 在 IDE 侧边栏放一个“AI 助手” Tab，内部是 MateChat 对话界面；

  • 输入框旁边增加几个快捷按钮：

    • “解释当前选中代码”；
    • “为当前函数生成单测”；
    • “帮我修复当前报错”。

上下文注入：

  • 在前端，把“当前文件内容 / 选中区域 / 报错信息”作为隐藏字段传给后端；
  • 模型侧做 Prompt 工程，把这些信息转成自然语言上下文。

MateChat 承担的角色：

  • 承载代码块展示，保证可读性；
  • 对复杂回答进行 Markdown 渲染，支持嵌套列表、标题、代码高亮；
  • 提供“复制代码”快捷按钮。
3.5.3 企业知识助手 / 内部问答平台

把 MateChat 嵌入企业内部门户或知识平台，构建统一的“企业 AI 知识助手”。

特点：

  • 语料来源广泛：制度文档、研发手册、运维手册、OKR、项目记录；
  • 权限敏感：不同员工看到的内容不可完全一样。

MateChat 的优势：

  • 简化了“问问题”这件事：员工只需自然语言提问；
  • 利用快捷提示组件预设常用问法，比如“帮我看一下公司 OKR 模板”；
  • 利用主题系统融入到企业统一品牌形象里。

3.6 创新方向：MCP、智能体、记忆化、多模态与工作流

虽然官方文档还未对 MCP 等方案给出成套示例，但结合其扩展位设计，我们可以规划一条实践路线。

3.6.1 与智能体框架集成

后端使用 MCP 或任意智能体框架编排多个工具（日志检索、资源管理、CI/CD 调度），前端 MateChat 只需要：

  • 在输入区 footer 提供一个“智能体选择器”；
  • 把用户选定的智能体 ID 与问题一起发给后端；
  • 在对话气泡中显示“当前由【日志分析助手】为你服务”。

这样，用户眼里的世界只有“不同角色的 AI 助手”，而不是复杂的 Tool / Agent 体系。

3.6.2 会“记住你”的 AI

MateChat 本身不做长时记忆存储，但可以与后端记忆系统联动：

  • 后端为每个用户维护一个记忆向量库或结构化 Profile；
  • 每次生成回答时把记忆作为辅助上下文；
  • 前端 MateChat 在气泡里显式提示“我记得你上次问过 XXX，这次帮你做进一步优化”。

这种“可感知的记忆”对提升用户好感度非常有效。

3.6.3 多模态交互：不仅仅是文本

MateChat 在示例中已经预留了“附件”入口，结合多模态模型可以扩展为：

  • 允许上传图片、日志文件、PPT；
  • 后端多模态模型解析后，返回结构化结论；
  • 前端 MateChat 使用卡片组件或表格组件（可以复用 DevUI）展示分析结果。
3.6.4 思维链与工作流可视化

对于耗时较长或步骤复杂的任务（如“生成一篇完整的技术方案并拆分任务”），可以：

  1. 在对话区插入一个“流程卡片”，显示“分析需求 → 调研资料 → 生成初稿 → 生成任务清单”；
  2. 每推进一步，就更新卡片状态；
  3. 用户可以在某一步中途插入反馈，例如“这一步别用 A 方案，用 B 方案”。

这能大幅提升 AI 行为的透明度，也为后续“AI 治理”提供基础。

四、DevUI × MateChat：从云原生控制台到智能助手的全链路方案

讲完两大技术栈，各自的边界已经比较清晰：

  • DevUI：主攻“界面骨架 + 中后台交互”；
  • MateChat：主攻“智能交互 + GenAI 体验”。

真正有价值的是 如何把它们拼成一套整体解决方案。

下面给出一个较完整的架构蓝图，可以作为征文中的“综合案例”。

4.1 整体架构：三层一体

  1. 前端表现层

    • 控制台框架：Angular / Vue + DevUI

      • 提供导航、布局、列表、表单、告警面板等；
      • 实现统一主题、响应式适配、国际化。

    • 智能助手入口：MateChat

      • 作为右下角悬浮对话框、右侧抽屉、独立页面等形式出现；
      • 使用 MateChat 组件呈现完整对话体验。

  2. 中台服务层

    • API 网关 / BFF（Backend for Frontend）

      • 为控制台提供资源查询、操作接口；
      • 为 MateChat 提供统一的 /api/ai/chat 或 /api/agent/execute 接口。

    • AI 网关 / 智能体服务

      • 负责跟各类大模型（盘古、ChatGPT、自研模型）对接；
      • 编排 RAG、工具调用、工作流等。

  3. 基础设施层

    • 云原生日志、监控、告警、CMDB、CI/CD 等；
    • 文档系统、知识库、资产库。

整个系统的“观感”是：

  • DevUI 把业务能力以可见、可操作的方式呈现在 UI 中；
  • MateChat 把这些能力抽象成自然语言接口，让用户“跟 AI 说话就能调度云资源”。

4.2 典型交互流：一次“跨多服务的故障排查”

我们通过一个复杂但典型的用例来展示二者协同。

场景：
运维工程师在云控制台上看到某个业务集群异常，希望快速定位问题。

步骤：

  1. 在 DevUI 控制台中发现异常

    • DevUI 表格列出所有集群，某一行状态标红；
    • 点击行展开，显示最近几个告警的概要。

  2. 在同一页面唤起 MateChat

    • 右下角有一个“智能运维助手”按钮，点击后弹出 MateChat 对话窗口；
    • MateChat 自动将当前集群 ID 和最近告警信息注入上下文，并在欢迎气泡中告诉用户“我已经知道你正在查看的是集群 A，有近 24 小时的告警记录”。

  3. 用户自然语言提问

    “帮我分析这个集群最近的异常原因，并给一个排查建议列表。”

  4. 后端智能体工作

    • AI 网关从 CMDB 获取集群拓扑；
    • 调用日志服务检索最近错误；
    • 对监控指标进行聚类分析；
    • 最后把结果以结构化 JSON 返回。

  5. MateChat 展示结果

    • 用气泡展示一段自然语言“结论摘要”；
    • 用 DevUI 的表格组件嵌在气泡内部列出“可能原因列表”；
    • 用步骤条展示“推荐排查步骤”。

  6. 一键执行操作

    • 每个排查步骤旁边有“去执行”按钮，点击后调用 DevUI 对话框，确认后真正去重启某个服务或扩容某个节点；
    • 完成后再通过 MateChat 给出“执行结果反馈”。

在这个过程中：

  • DevUI 提供列表、表单、对话框等“操作载体”；
  • MateChat 提供统一的“智能问答与决策辅助手段”；
  • 用户并不需要知道后端到底是哪个模型、哪个服务在起作用。

4.3 DevUI 与 MateChat 的协同要点

  1. 主题统一

    • MateChat 主题基于 vue-devui 主题能力实现，可以让聊天窗口和控制台保持颜色体系一致；

  2. 交互统一

    • DevUI 的表格、表单、按钮交互与 MateChat 提供的快捷按钮、对话控制保持同一套交互风格（hover、点击反馈、loading 动画等）；

  3. 工程统一

    • 在 Vue 技术栈下，DevUI 和 MateChat 都可以通过 Vite + pnpm 等工具统一管理依赖；
    • 在 Angular 技术栈下，MateChat 也推出了 Angular 版本组件 & demo 站点，可与 ng-devui 一起使用。

  4. 治理统一

    • DevUI 负责界面一致性治理；
    • MateChat 负责 AI 体验一致性治理（何处放入口、如何展示提示、如何反馈错误）；
    • 合在一起可以为企业构建一套“从 UI 到 AI 的统一设计准则”。

最后，我们再来瞅瞅，MateChat助手的对话界面：

五、总结与展望：把“可用”做成“好用”，再做成“常用”

在云原生应用进入深水区之后，单纯“功能可用”已经不够：

  • 前端界面要经得住长期演进与多人协作；
  • AI 能力要从“几个 Demo”变成“真正融入业务流程”。

DevUI 和 MateChat 分别从两个方向给出了答案：

  • DevUI

    • 以设计系统为核心，构建多技术栈一致的中后台前端解决方案；
    • 提供表格、表单、弹窗、导航等一整套企业级组件，并支持跨项目的主题治理与工程实践。

  • MateChat

    • 以 GenAI 体验系统为目标，为智能应用提供统一的对话式 UI 库；
    • 聚焦“快速唤醒、轻松使用、自由表达、过程监督、可读性强”等体验元素，在 CodeArts、InsCode 等场景已验证可行。

对于想在征文中展示“云原生 + 前端 + AI”综合能力的团队而言，一条非常清晰的路线是：

  1. 用 DevUI 搭好企业级中后台的整体界面与工程基建；
  2. 用 MateChat 在关键节点挂上智能入口，把模型、RAG、智能体等能力包装成一致的交互体验；
  3. 在两者之上建立属于企业自己的设计规范和 AI 体验规范，让后续的所有新系统可以沿用。

如果你正在准备征文、技术白皮书或者内部方案说明，可以考虑：

  • 选一个真实或虚构的云原生场景（如“智能运维控制台”“研发一体化平台”）；
  • 用 DevUI 和 MateChat 各自承载一半能力；
  • 再通过完整的架构图与交互流程，把“从界面到智能”的闭环讲清楚。

相关官方地址汇总如下：

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

# 云原生 # 前端 # 交互
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

【2025年生成式引擎优化（GEO）白皮书，内容破局是关键】

avatar 2048 AI社区

告别大模型 “瞎胡说”：RAG（检索增强生成）如何让 AI 更懂事实？

RAG 的本质，是给生成式 AI 加上了 “事实锚点”。它没有抛弃大模型的生成能力，而是通过检索让生成的内容 “有据可依”；它也没有局限于检索的死板，而是通过生成让答案更流畅、更灵活。对于技术从业者来说，RAG 提供了一种 “参数高效” 的解决方案 —— 不用追求更大的模型，通过结合外部知识库，就能在知识密集型任务上实现 SOTA；对于普通用户来说，RAG 让 AI 的答案更可信、更实用，减少了

avatar 2048 AI社区

AI Agent在智能城市噪声管理中的实践

随着城市化进程的加速，城市噪声污染问题日益严重，对居民的生活质量和健康造成了负面影响。智能城市的发展为解决噪声管理问题提供了新的思路和技术手段。本文的目的是探讨AI Agent在智能城市噪声管理中的应用实践，研究如何利用AI Agent的自主决策和学习能力，实现对城市噪声的有效监测、分析和控制。研究范围涵盖了AI Agent的基本原理、相关算法，以及在智能城市噪声管理中的具体应用场景和实现方法。

avatar 2048 AI社区