作者：兰瓶Coding（移动开发转型鸿蒙 & 前端中级）
如果这篇对你有帮助，欢迎点赞 & 收藏支持一下～🙏

一、云原生 + AI 时代：前端不再只是“页面实现”

在云原生体系里，应用被拆解为大量服务与能力：容器、微服务、服务网格、Serverless……这些技术都在基础设施层演进。但对用户而言，最终感知到的，依然是：

• 我在什么界面里操作？
• 我能否用自然语言与系统沟通？
• 这些操作是否稳定、一致、可解释？

从这个角度看，前端在云原生 + AI 时代的职责可以拆成两块：

1. 界面底座：统一、稳定、可扩展的企业级前端解决方案——这正是 DevUI 的角色。
   DevUI 基于 DevUI Design 设计系统，面向企业中后台产品，提供一整套设计语言、组件库与工程能力，支持 Angular / Vue 等多技术栈，并配套主题定制与工程工具。

2. 智能交互层：统一的 GenAI 对话体验体系——这正是 MateChat 的定位。
   MateChat 是“前端智能化场景解决方案 UI 库”，帮助在 Web 应用、DevOps 平台、IDE 等场景中快速搭建 AI 对话界面，已在华为内部多款应用、CodeArts、InsCode AI IDE 等场景落地。

特别强调：

• DevUI 目前的 主要版本为 Angular 与 Vue 版本，并逐步拓展到更多栈。
• MateChat 是 UI 库而不是 SDK，也没有提供“后端 SDK 形式”；官方示例是通过前端或自建后端对接 OpenAI、盘古等模型服务。

在这样的前提下，本文后续会采用“双主线叙事”：

• 上半部分：DevUI 组件生态：使用、实践与创新
• 下半部分：MateChat 智能应用：落地实践与创新探索

两条线最后在云原生实践中汇合，形成“界面 + 智能”的完整技术路径。

相关官方地址汇总如下：

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

二、DevUI 组件生态：使用、实践与创新

2.1 从 DevUI Design 到多框架组件库：企业级界面的“公共底盘”

2.1.1 DevUI 的整体画像

官方对 DevUI 的定义可以浓缩成一句话：

“一款面向企业中后台产品的开源前端解决方案” —— 不只是组件库，而是包含设计系统、组件与工具在内的一整套生态。

核心特点包括：

• DevUI Design 设计系统
  以规则、设计语言和最佳实践为中心，帮助开发者专注业务逻辑，设计师专注流程与体验。

• 多框架组件实现

  • Angular 版 ng-devui：用于大型企业级应用，当前支持较新 Angular 版本
  • Vue 版 vue-devui：基于 Vue3 + TypeScript + Vite，主打高扩展、主题化与企业应用场景

• 工程与生态能力
  提供主题系统、图标库、脚手架、Admin 模板等，帮助在表格、表单、导航、图表等高频场景下快速成型。

在云原生开发背景下，这些能力意味着：
DevUI 可以成为跨多个业务系统的“统一界面底盘”，降低多团队、多项目并行带来的 UI 分裂问题。

2.2 组件使用进阶：表格、表单、弹窗的“深水区”指南

企业级 B 端系统中，真正决定体验上限的，往往是那几类高频组件。下面从三类组件入手，结合云原生典型场景，讨论进阶用法与避坑要点。

2.2.1 表格：从“列表”到“运营工作台”

DevUI 的表格组件在 Angular / Vue 版本中都提供了分页、排序、筛选、固定列、复杂表头、选择、虚拟滚动等能力，适配大数据量与复杂交互。

典型云原生场景：

• 云资源列表：实例、容器、数据库、负载均衡；
• DevOps 任务列表：流水线运行历史、构建任务队列；
• 运营数据：告警记录、审计日志、变更记录等。

进阶实践关键点：

1. 筛选条件“上移”到搜索区
   高复杂度筛选条件（环境、租户、标签、状态等）尽量用 DevUI 的表单组件在表格上方统一呈现，而不是堆在表头的“列内筛选”里，这样便于：

   • 统一构造 queryModel，向后端传递参数；
   • 做条件持久化（如 URL Query / 本地缓存）。

2. 服务端分页 + 排序
   在云原生环境下，数据源通常来自后端分页 API。建议：

   • 将表格的分页、排序事件统一转换为接口参数；
   • 不做“全量加载再前端分页”，避免内存与性能问题。

3. 虚拟滚动与单元格复杂度控制
   对于需要呈现大量行的数据：

   • 启用 DevUI 的虚拟滚动，保障渲染性能；
   • 避免把复杂图表/富组件塞进每个单元格，建议改为“点击详情”下钻。

4. 批量操作与行内操作的责任划分

   • 高风险操作（批量删除、重启）放在工具栏，通过二次确认弹窗触发；
   • 行内操作适合低风险或频繁操作，如“编辑备注”“复制 ID”。

常见坑点与规避：

• 固定列 + 横向滚动场景下，注意表格容器宽度计算与窗口 resize；
• 表格高度自适应时，应避免在父级容器上混用多套滚动策略带来的滚动条错位。

2.2.2 表单：把复杂配置拆解为可完成的路径

DevUI 提供从基础输入（文本、数字、选择、日期、开关）到高级组件（多选、级联、上传）的表单体系，并配合校验与布局能力。

云原生表单典型任务：

• 创建云资源（实例、集群、数据库）
• 配置伸缩策略与告警策略
• 设置访问控制规则与路由规则

进阶设计建议：

1. 多步表单与分组卡片

   • 对“创建集群”这类复杂任务，不要用一个巨大的单页表单；
   • 使用 Steps + 分组卡片，将流程拆成“基础配置 → 网络与安全 → 监控与告警 → 标签与元数据”等步骤，每步字段控制在用户可承受范围内。

2. 表单模型分层

   • formModel：对接 DevUI 的表单控件，负责视图绑定；
   • domainModel：面向后端接口的数据结构；
   • 提交时做一次映射，便于在不同表单视图中复用同一业务转换逻辑。

3. 错误提示策略

   • 字段旁提示要贴近业务含义，而不是抽象的“格式错误”；
   • 当表单提交失败时，使用消息组件给出“全局汇总”，并自动滚动至第一个错误字段，增强可修复性。

4. 配置化表单的演进方向

   • 利用 JSON Schema 或内部 DSL 描述表单结构；
   • 基于 DevUI 基础控件实现统一的“表单渲染引擎”；
   • 在云控制台这类大量配置页面的系统中极大提升复用度（特别适合云原生的平台化团队）。

2.2.3 弹窗 / Drawer：把控操作节奏与风险

DevUI 提供完整的弹窗、抽屉、提示类组件，用于各种微流程。

场景划分与实践原则：

• 对话框 Modal：删除、停机、简单确认；
• Drawer：中等复杂度配置（如调整单个资源的高级配置）；
• 独立页面：流程长、风险高的操作（如大规模变更）。

避坑点：

• 避免“弹窗里再弹窗”，建议重构为分步流程或分段界面；
• 对复杂弹层（表单、预览、二次确认等）进行组件化封装，通过服务统一管理其打开/关闭逻辑；
• 注意锁定背景滚动，尤其在浏览器小窗口或内嵌环境（如 iframe 控制台）中。

2.3 自定义开发实践：自定义组件与插件开发流程与案例

虽然 DevUI 组件库本身已经覆盖大量通用场景，但真实项目不可避免会遇到业务专属组件需求。此时更推荐做法是：

站在 DevUI 之上“长出”业务组件，而不是在旁边“另起炉灶”。

2.3.1 自定义组件开发流程

以一个“资源拓扑图组件”为例，开发流程大致可以是：

1. 与 DevUI 设计语言对齐

   • 节点使用类似 Card / Tag 风格；
   • 交互沿用 Hover 提示、点击展开详情的既有模式；
   • 颜色与状态映射使用 DevUI 的颜色 Token，而非硬编码色值。

2. 复用已有组件做结构拼装

   • 顶部工具条使用 Button / Select / Checkbox 组件作为过滤器；
   • 节点详情用 Tooltip / Popover 展示；
   • 侧边详情 Panel 使用 Drawer 实现。

3. 封装统一的 Props & Events

   • Props 定义：数据源（资源节点与关联关系）、展示模式（分层/分组）、交互开关（是否允许拖拽等）；
   • Events 定义：节点点击、节点高亮、过滤条件变化等。

4. 沉淀为团队级可复用组件

   • 将其打包为内部组件库模块；
   • 在多个控制台页面中作为统一的“资源拓扑视图”复用。

2.3.2 插件与工程工具：增强 DevUI 的“落地能力”

围绕 DevUI，可以在以下几个方向做扩展：

• VSCode 代码片段插件：内置“基于 DevUI 的列表页面”“表单页面”“表单 + 表格组合页面”模板；
• 脚手架 / CLI 集成：在创建 Angular/Vue 项目时直接包含 DevUI、主题、路由和权限基础配置。
• 低代码平台集成：将 DevUI 组件描述为元数据 Schema，支持在低代码平台中拖拽与可视化配置。

这些实践可以让 DevUI 从“组件库”升级成真正的“企业前端基础设施”。

2.4 主题与样式定制：品牌主题、暗黑模式、响应式布局

2.4.1 DevUI Theme：框架无关的主题方案

DevUI 提供了 DevUI Theme 方案，实现框架无关的主题定制，并内置多套主题，如 infinityTheme、deepTheme 等，可作为基础主题直接使用或派生。

基本使用方式包括：

• 引入 theme 包并初始化默认主题；
• 根据业务需要切换主题或动态加载主题配置。

这为企业品牌定制提供了可靠的“技术支点”。

2.4.2 品牌主题适配：从设计规范到主题 Token

品牌适配实践可分为三步：

1. 收集品牌视觉规范：主色、辅助色、警告色、成功色、字体规范等；
2. 映射到 DevUI Theme Token：将设计中的色板映射到对应 Token（primary / success / warning 等）；
3. 统一引用 Token：所有 DevUI 组件和自定义组件通过 Token 引用颜色与尺寸，避免散落色值。

通过这种方式，可以实现跨多个产品线的“品牌主题统一”，同时保留每个产品的差异化。

2.4.3 暗黑模式：监控与运维大屏的默认选项

暗黑主题在运维监控、日志大盘等场景尤其常见。利用 DevUI Theme 的多主题能力，可以：

• 定义一套暗黑主题（如基于 deepTheme 修改）；
• 与默认明亮主题提供切换入口；
• 在 DevUI 图表、表格、自定义组件内全部走 Token，保障暗黑模式下的可读性与统一性。

注意图表配色需要单独适配暗黑背景，例如调整坐标轴/网格线/标注对比度，这部分通常由图表封装组件与主题系统联动完成。

2.4.4 响应式布局：PC 为主，小屏有策略

DevUI 提供布局与栅格系统，可用于实现响应式界面。

云原生 B 端系统的主战场仍然是桌面端，但应兼顾：

• 13 寸笔记本这类中等屏幕；
• 少量移动端“只读 + 轻操作”需求（查看资源状态、浏览工单等）。

实用策略：

• 桌面端：三栏或两栏布局（侧边导航 + 顶部导航 + 内容区）；
• 窄屏：侧栏折叠为图标或抽屉，内容区全宽呈现；
• 移动端：使用卡片替代表格，保留关键字段，去除非必要内容。

---

2.5 云原生应用落地：DevUI 在云控制台、企业系统、B 端应用中的实践复盘

结合 DevUI 官方定位与典型行业实践，可以总结出一条通用落地路径：

2.5.1 云控制台场景

• 资源管理页

  • DevUI 表格 + 筛选表单组合，呈现多云/多区域资源列表；
  • 抽屉展示资源详情、监控概览和快捷操作。

• 监控与告警中心

  • 图表组件用于展示时序指标；
  • 表格与时间轴展示告警事件；
  • DevUI Tab 管理不同视图（概览/单资源/日志视图）。

• 策略配置与运维工具

  • 使用多步表单构建复杂策略；
  • 使用 Modal + Drawer 处理策略编辑与预览。

2.5.2 企业级 B 端系统：工单、审批与运营

在工单系统、审批平台、运营后台中：

• DevUI 表格 + 表单承担“列表 + 详情 + 编辑”的基本任务；
• 时间轴组件可用于展示工单/审批流转历史；
• 结合 DevUI 主题能力，实现跨多个内部系统的界面统一。

2.5.3 云原生微前端与多团队协作

随着微前端架构的引入，不同业务团队可能使用不同技术栈（Angular / Vue）。DevUI 的多栈支持使得：

• 每个子应用可以在自身栈内使用 DevUI；
• 在主应用层面通过 DevUI Theme 统一主题与基础样式，降低跨子应用显著风格差异。

2.6 入门实战教程：从环境搭建到新手常见问题

结合官方文档与社区实践，这里给出一套“从 0 到 1”的入门路径（以 Vue DevUI 为例）。

1. 初始化项目

   • 使用 Vite 创建 Vue3 + TS 工程；
   • 安装 vue-devui 与相关依赖。

2. 引入 DevUI 组件与样式

   • 在入口文件中注册 DevUI；
   • 引入基础样式文件与图标。

3. 完成第一个页面：表格 + 搜索 + 弹窗表单

   • 使用 Layout 构建基础布局；
   • 使用表格 + 分页构建列表；
   • 使用弹窗 + 表单完成“新建/编辑”操作。

4. 新手常见问题与解法

   • 样式未生效：检查样式引入顺序、是否被全局 reset 覆盖；
   • TS 类型报错：对照官方依赖版本要求，调整 TypeScript 与 DevUI 版本；
   • 组件行为与预期不符：先对照官方 Demo 再排查业务代码，必要时查文档或社区文章。

2.7 跨场景创新探索：DevUI × AI 可视化 × 低代码

2.7.1 DevUI 与 AI 可视化场景结合

DevUI 在数据展示和复杂组件（如图表、时间轴、行业专用组件）方面提供了坚实基础。

结合 AI 能力，可以探索：

• 智能表格：用户用自然语言描述筛选条件，由后端 AI 转换为结构化查询参数，DevUI 表格负责展示；
• 智能表单：AI 根据用户的业务描述生成表单草稿，开发者再用 DevUI 组件进行精细化调整；
• 智能布局：AI 根据用户角色和历史行为，给出推荐布局方案，DevUI 栅格与布局组件负责渲染。

2.7.2 DevUI 与低代码平台的深度集成

DevUI 已被实践在多个低代码平台中，通过组件元数据（Schema）、事件描述与联动规则，使组件可以被拖拽、配置和组合。

典型做法：

• 用 JSON Schema 描述 DevUI 组件：属性、事件、插槽；
• 低代码平台解析 Schema，生成可视化配置面板；
• 最终编排结果仍然输出为 DevUI 组件组合代码，确保生成页面与手写页面一致。

在这样的体系里，DevUI 不只是“写页面的组件库”，而是“支持开发与低代码协同的前端基础设施”。

可比如如下，DevUI 就提供了一系列组件，供大家使用：

三、MateChat 智能应用：落地实践与创新探索

如果说 DevUI 解决的是“云原生应用的界面基础设施”，那么 MateChat 解决的是另一个问题：

如何在这些界面里，以统一、可复用的方式承载 GenAI 能力？

3.1 MateChat 的定位与特性：GenAI 体验系统语言

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

核心特征包括：

• 面向 DevOps 平台、IDE、业务系统等智能化场景，提供统一的对话 UI 套件；
• 聚焦构建高一致性的 GenAI 体验系统语言：快速唤醒、轻松使用、自由表达、过程监督、可读性强；
• 已服务华为内部多应用、CodeArts、InsCode AI IDE 等智能助手场景；
• 采用 MIT 开源协议，企业与个人均可免费使用。

再次强调：

MateChat 不提供 SDK，也不是后端能力包装。它是纯前端 UI 库，负责对话界面与交互体验；模型调用需由业务方通过 HTTP、SDK 或后端网关自行实现。

所以说，如果你对其感兴趣，欢迎下载体验：

3.2 组件与体验结构：构成一个“可复用对话工作台”的积木

从官网与文档可以看到，MateChat 主要提供以下类型组件与能力：

• 消息气泡组件：用于承载对话内容，支持角色、状态、头像等配置；
• 输入框组件：专为 GenAI 对话设计的输入区域，支持多行、快捷操作、扩展工具栏；
• 快捷使用（Quick Usage）组件：根据上下文给出便捷可点击的提问建议；
• 对话区域 / 布局容器：组合多个气泡，提供滚动、锚点等行为；
• 主题与适配能力：支持主题切换，与 vue-devui 主题体系可协同；

结合这些组件，可以实现一个“通用对话工作台”的基本骨架：

• 顶部 Header：展示助手名称、模型状态、设置入口等；
• 中部消息区：气泡列表 + 过程状态展示；
• 底部输入区：文本输入 + 发送按钮 + 辅助工具入口。

3.3 落地实践案例一：使用 MateChat 构建智能应用的完整流程

本小节围绕大纲中的“落地实践案例”要求，以一个抽象但贴近实际的场景展开：

为一个已有的“DevOps 平台”添加 MateChat 智能助手，从需求理解到上线运行。

3.3.1 需求拆解

业务目标：

• 在现有 DevOps 平台中增加自然语言交互入口；

• 支持以下类型问题：

  • 最近一周流水线失败情况；
  • 某条流水线失败原因与修复建议；
  • 关键服务的部署历史与版本变化。

非功能性要求：

• 不影响原有控制台的导航与主流程；
• 交互风格与平台现有视觉体系保持协调；
• AI 过程可解释，可被人工干预。

3.3.2 前端架构 & MateChat 接入

1. 界面嵌入方式

   • 平台主体采用 DevUI 布局；
   • MateChat 以右下角悬浮入口出现，点击弹出对话面板；

2. 消息管理模型

   定义前端 messages 数组，每条消息包含：

   • from: ‘user’ | ‘model’ | ‘tool’；
   • content: 文本或 Markdown；
   • loading: 是否处于生成中；
   • meta: 包含流水线 ID、关联资源等上下文信息。

3. 发送与流式接收流程

   • 用户在 MateChat 输入框发送提问时，插入一条 from: user 消息；
   • 随后插入一条 from: model 且 loading: true 的占位消息；
   • 前端调用后端 /ai/devops-chat 接口；
   • 后端通过流式方式与大模型交互，前端在循环中不断拼接内容到该模型消息上，最终将 loading 置为 false。

4. 自适应主题与样式

   • 使用 vue-devui 主题与 MateChat 主题能力，实现与平台一致的主色与暗色模式；

3.3.3 后端智能组件与流水线数据集成

后端整体可分为三层：

1. 对话层：统一的 /ai/devops-chat 接口

   • 接收用户问题与当前上下文（项目、环境、角色等）；
   • 调用对话引擎模块。

2. 模型层

   • 使用大模型（如盘古、OpenAI 等）处理自然语言理解与回答生成；
   • 可采用 RAG，将流水线日志与配置片段检索后注入上下文。

3. 工具层（DevOps API）

   • 封装流水线查询、日志查询、服务状态查询等 API；
   • 由智能体逻辑决定是否调用工具，并将结构化结果返回给对话层。

MateChat 在此体系中扮演的是“前端呈现层”和“用户交互入口”，并不介入上述后端逻辑，这也符合其“UI 库而非 SDK”的角色定位。

3.4 落地实践案例二：为已有产品加一层 MateChat 智能助手

本期大纲中提到的另一种落地方式是：结合已有产品，通过 MateChat 添加智能助手。下面以“某企业内部云资源管理系统”为例。

3.4.1 现状

• 系统 UI 基于 DevUI 构建，功能较完备；

• 用户痛点在于：

  • 对资源关系理解成本高；
  • 常见操作路径长；
  • 对报错与告警信息的解释缺乏“人话”。

3.4.2 智能助手的设计方向

1. “问一问”入口

   • MateChat 嵌入首页与关键详情页；
   • 支持基于当前页面上下文进行智能问答。

2. 典型能力

   • “帮我用一句话总结这个资源的状态”；
   • “列出这台主机过去 24 小时的关键操作事件”；
   • “根据这些告警，列一个排查步骤”。

3. 与 DevUI 的协同表现

   • 问答结果中的关键资源以 DevUI Tag / Button 形式展现，点击即可跳转对应 DevUI 页面（如资源详情页、告警列表）。

通过这种方式，MateChat 补齐了“理解层”： DevUI 负责“看得见、点得着”，MateChat 负责“说得清、建议得出”。

比如：「帮我生成一个查看近 7 天营收与订单转化率的仪表盘页面」

3.5 创新玩法探索：MCP、智能体、记忆、知识检索、自然语言 UI、工作流、思维链、多模态

MateChat 自身聚焦前端 UI，但由于其组件化与场景通用性，很适合作为各种智能框架的“可视化入口”。下面对内容中提到的几个方向做系统性展开（偏架构与交互层面）。

3.5.1 集成 MCP / 工具调用：可视化“模型 + 工具”的协作

在具备 MCP 或类似工具调用机制的后端系统里，可以采用如下模式：

• 模型根据用户意图决定调用某个工具（如“获取某服务的最近日志”）；

• 工具执行结果返回后，由模型进行总结；

• MateChat 前端中：

  • 在过程阶段插入一条“正在调用 xxx 工具”的系统消息；
  • 完成后展示工具结果卡片（表格 / 列表 / 图表）；
  • 用户可以基于结果继续追问或发起新任务。

在这个过程中，MateChat 的消息气泡与卡片组合成为“工具调用可视化界面”，帮助用户理解 AI 正在做什么。

3.5.2 智能体 + 个性化与记忆化

若后端实现了“记忆化智能体”（存储用户偏好、历史项目、常用资源等），MateChat 可以：

• 在界面上标出“基于你的历史操作，为你优先推荐了项目 A、环境 prod”；
• 提供“查看 / 管理记忆”的入口，列出当前会话用到的记忆片段，允许用户删除或忽略；
• 在回答中插入小提示（例如“根据你上次排查类似问题的习惯，我优先展示了日志视图”）。

这样一来，“记忆行为”从黑盒变为用户可感知、可干预的一部分，增强信任感。

3.5.3 知识检索（RAG）与自然语言生成 UI

RAG 模式已是企业知识问答标配。配合 MateChat，可以形成如下 UI 策略：

• 对话气泡中呈现模型综合后的答案（支持 Markdown）；
• 在气泡下方区域展示“引用文档列表”：标题 + 摘要 + 来源标签；
• 用户点击引用条目后，在 DevUI Drawer 中打开原文，完成知识可追溯。

扩展到“自然语言生成 UI”场景，则可以：

• 用户用自然语言描述需求（如“我想创建一个限流策略：在高峰期控制每秒请求数不超过 500”）；
• 后端生成策略配置草案；
• MateChat 用卡片形式展示“预生成策略表单”，用户确认后再用 DevUI 表单页面打开，让用户做细节微调。

3.5.4 工作流与思维链（CoT）：对话驱动流程执行

在复杂任务（例如变更实施、风险评估、排障操作）中，可以把“思维链 + 工作流”结合起来，由 MateChat 承载其交互形态。

• 模型在后端分解任务为多个步骤；
• 每一步通过对话向用户确认或收集信息；
• 后端工作流引擎驱动实际操作；
• MateChat 前端显示每一步的执行结果或中间状态（类似小型“对话版流水线视图”）。

这样，用户得到的是“流程可见、思路可见、结果可见”的综合体验。

3.5.5 多模态交互：文本 + 图片 + 代码 + 结构化数据

随着多模态模型的普及，MateChat 可以作为多模态交互的统一容器。例如：

• 支持用户上传报错截图，由后端多模态模型解读后给出排查建议；
• 对于代码相关问题，显示专用代码气泡（高亮、折叠、复制）；
• 对结构化数据（如监控指标摘要）使用卡片、表格或小图形展示。

MateChat 的角色始终是：用合适的 UI 形式表达模型给出的结果，并保持对话上下文的连贯。

所以说，如果你对我写的感兴趣，可直接上官网克隆代码，直接上手操练一波：

3.6 未来趋势洞察：MateChat 的发展潜力与应用可能性

结合官网、GitHub 与社区文章，可以对 MateChat 的演进方向做一些洞察。

1. 组件更丰富、场景更细分

   • 针对任务卡片、多模态输出、工具面板、会话管理等推出更多专用组件；
   • 对不同业务类型（DevOps、客服、知识问答、办公协作）形成相对成熟的“场景套件”。

2. 多框架适配与工程一体化

   • 基于现有 Vue 生态，进一步改进与 Angular / React 的集成体验（官方 Playground 已出现 Angular 版本 Demo）；
   • 深度协同 DevUI Theme，成为企业统一智能交互层的一部分。

3. 与企业 AI 平台的深度结合

   • 通过示例与最佳实践，强化与盘古、ModelArts Studio 等平台的组合使用；
   • 为企业构建“前端统一 AI 入口”的推荐方案。

从更长远的视角看，MateChat 代表的是这样一种趋势：

前端不再单独构造每一个独立的“AI 聊天窗口”，而是基于统一的 UI 库和体验原则，把各类智能体、模型服务和工具能力整合在一个可理解、可扩展的对话系统中。

可直接从官方寻得相关对接教程：

当然，你还可以与它正常对话，演示如下：

四、DevUI + MateChat：云原生前端的“界面地基”与“智能中枢”

把前文的两条主线放在一起，可以得到一个相对清晰的整体图景：

• DevUI：

  • 提供统一的设计系统、组件库和工程工具；
  • 在云控制台、DevOps 平台、企业管理系统中，构建“一致、可维护、高效”的 B 端界面；

• MateChat：

  • 提供统一的对话 UI 套件与 GenAI 体验系统语言；
  • 在上述系统之上，以“嵌入式方式”承载大模型、工具调用、知识检索、工作流等智能能力。

对一个正在经历云原生与智能化转型的团队来说，一条非常务实的路径是：

1. 用 DevUI 统一界面与工程基础

   • 新项目默认采用 Angular/Vue DevUI；
   • 老项目逐步迁移关键模块至 DevUI 组件体系；
   • 通过主题与品牌适配，在多个系统间保持视觉一致。

2. 用 MateChat 标准化智能交互层

   • 先在开发者工具、内部控制台中试点接入 MateChat；
   • 再扩展到更多业务系统，以“对话 + 操作”的形式暴露 AI 能力；
   • 在后端持续迭代模型、工具与知识库，而前端交互层保持稳定。

3. 在两者之上沉淀企业级前端方法论

   • 形成“DevUI 组件规范 + MateChat 对话交互规范”的双规范；
   • 将实践串联为模板、脚手架、低代码元件，为后续项目提供可复制的参考。

在这个过程中，前端不再只是“把 UI 写出来”，而是参与搭建一整套 “界面地基 + 智能中枢” 的基础设施：
既关心表格、表单、弹窗等细节，也关心智能体、工具调用与对话体验；既兼顾云原生架构的复杂性，也拥抱大模型带来的新交互范式。

从 DevUI 到 MateChat，是一条从“规范化的界面构建”走向“智能化的人机协同”的演进路径。
而云原生时代的前端，也正好站在这条路径的中央。

相关官方地址汇总如下：

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

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