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

---

1. 为什么要把 UI 框架和智能助手绑在一起考虑

单看 DevUI 和 MateChat，各自都已经很成熟：

• DevUI 负责把表格、表单、弹窗、布局这些企业级 UI 场景做扎实；
• MateChat 负责把大模型、工具调用、知识检索这些“脑力活”接进来。

但在我所在的项目里，我们发现：

如果只把 MateChat 当成一个“单独的聊天页面”，那它顶多是个高级 FAQ；
只有让它真正“驱动 UI 行为”，才能体现组合带来的价值。

所以这篇文章，就是完整记录我们如何用 DevUI 做控制台界面，用 MateChat 做智能层，两者配合一起实现“会说话的控制台”的过程。

---

2. 架构全景：DevUI 前端 + MateChat 智能层 + 后端服务

先用一张简化的架构图表（文字版）描述下整体结构：

层级	角色	说明
前端 UI 层	DevUI 控制台	负责页面布局、表格、表单、图表、侧边聊天面板等交互展现
智能交互层	MateChat	负责意图识别、对话管理、知识检索、工具调用等能力
业务服务层	各类微服务 / 云原生组件	提供查询指标、查询日志、执行变更等实际能力

数据流大致是这样走的：

1. 用户在控制台某个页面上点击“智能排障”，侧边打开 MateChat 面板；
2. 用户用自然语言描述问题，比如“这个集群最近为什么老有 CPU 告警？”；
3. MateChat 解析意图，必要时通过 MCP / 内部 API 查监控、查日志；
4. MateChat 给出分析结论和建议操作，同时把部分结果通过前端事件“抛回” DevUI 页面；
5. DevUI 控制台根据这些“智能事件”，自动跳转到对应 Tab、选中相关资源行、展开日志弹窗等。

---

3. 一个完整场景：从“看到告警”到“和控制台对话排障”

先用一个真实发生过的场景具体展开：

1. 运维同事在 DevUI 控制台的“告警中心”看到某个集群的错误率告警；
2. 以前的做法是：点详情 → 看图表 → 再打开日志中心，手动筛选服务和时间范围；
3. 现在，他直接在右侧的 MateChat 面板里输入：

“帮我看看 prod 环境 gateway 这个服务最近 10 分钟为什么告警这么频繁？”

系统内部发生了哪些事：

• MateChat 从当前页面上下文拿到了环境、服务名等信息（这一点后面细说）；
• 触发一个“告警排查”工作流：查询监控 → 查询近期配置变更 → 生成排查建议；
• 同时往前端发出一个事件，指示 DevUI 把“日志中心” Tab 打开，并预先带好过滤条件。

在 DevUI 页面上，用户看到的是：

• 右侧 MateChat 在对话里给出了“初步结论 + 建议操作步骤”；
• 中间的主视图自动切到日志页面，并高亮了与告警时间段重叠的日志段落。

这就是“UI 框架 + 智能助手”组合带来的体验差异：

不再是“看完建议自己再点半天页面”，而是建议和页面行为是联动的。

---

4. 前端集成实践：在 DevUI 控制台里接入 MateChat 面板

4.1 侧边面板布局

我们在 DevUI 控制台里增加了一个固定的“智能助手抽屉”，简化版结构：

<d-layout>
  <d-aside class="app-sider">
    <!-- 左侧导航 / 菜单 -->
  </d-aside>

  <d-content class="app-content">
    <!-- 主内容区域：各业务页面 router-outlet -->
  </d-content>

  <d-aside class="app-matechat" *ngIf="showMateChat">
    <app-matechat-panel
      [context]="currentContext"
      (smartEvent)="handleSmartEvent($event)"
    ></app-matechat-panel>
  </d-aside>
</d-layout>

这里有两个关键点：

• currentContext：把当前页面的上下文（环境、资源 ID、当前选中行等）传给 MateChat；
• smartEvent：把 MateChat 的“智能决策”以事件形式再抛回给控制台页面。

4.2 上下文注入：让 MateChat 知道“你现在在看什么”

上下文是这套方案好用与否的关键之一。我们提炼了一个简单的上下文对象：

export interface PageContext {
  env: 'dev' | 'test' | 'prod';
  module: 'cluster' | 'gateway' | 'log' | 'alarm';
  resourceId?: string;
  selectedItems?: string[];
}

在每个关键页面进入时，更新全局的 PageContext，并通过输入属性传入 MateChat 面板：

this.pageContextService.update({
  env: currentEnv,
  module: 'alarm',
  resourceId: alarmId,
});

有了这个上下文，MateChat 在解析用户问句时可以更有针对性地：

• 自动补全“你是在哪个环境问的”；
• 推断你说的“这个服务”具体是哪个；
• 在需要时发起带上下文的工具调用。

4.3 接收智能事件：让页面“跟着对话动起来”

我们约定了一些通用的“智能事件”类型，例如：

export type SmartEvent =
  | { type: 'NAVIGATE_LOG'; payload: { service: string; range: string } }
  | { type: 'HIGHLIGHT_ALARM'; payload: { alarmId: string } }
  | { type: 'OPEN_DETAIL_DRAWER'; payload: { module: string; id: string } };

在 App Shell 里统一处理这些事件，并分发到具体业务模块。例如：

handleSmartEvent(event: SmartEvent) {
  switch (event.type) {
    case 'NAVIGATE_LOG':
      this.router.navigate(['/log'], {
        queryParams: event.payload,
      });
      break;
    case 'HIGHLIGHT_ALARM':
      this.alarmService.highlight(event.payload.alarmId);
      break;
    // ... 其它事件
  }
}

这样 DevUI 页面就变成了一个“可被智能层驱动的 UI 引擎”。

---

5. 智能交互设计：自然语言如何驱动 UI 行为

5.1 先设计“意图 → UI 行为”的映射表

我们在设计交互时，先不是想 MateChat 能聊多花哨，而是画了一张简单的表：

用户意图	典型问法	对应 UI 行为
查看某服务日志	“帮我看看 prod 环境 gateway 的最近日志”	自动跳转到日志中心，选中服务和时间范围
查看告警详情	“这条告警具体是什么情况？”	高亮对应告警行，展开右侧详情抽屉
查看版本变更记录	“最近有没有改过这个服务的配置？”	打开变更记录面板，按服务过滤

MateChat 负责识别“意图 + 参数”（服务名、环境、时间范围等），前端负责执行对应的 UI 行为。两边边界清晰，调试也更可控。

5.2 自然语言不一定要“覆盖所有说法”

真实使用下来，我们发现没必要追求“各种花式问法都能识别”：

• 运维同事本身就习惯比较精确的表达，比如直接写服务名；
• 大部分问题格式都比较接近我们的内部术语。

所以我们更关注的是：

• 保证主干问法稳定可用；
• 在回答里适当给出“可选问法提示”，引导大家往更容易识别的表述靠。

---

6. 真正落地后的利与弊：团队反馈和数据

6.1 直观收益

• 页面跳转步骤减少：
  • 以前排查一个告警，至少要点 3～4 次页面；
  • 现在往往是一句话 + 1～2 次确认就能到达关键界面。
• 新人上手更快：
  • 新人可以先用 MateChat 问“这个模块一般怎么排查问题”，
  • 再看 DevUI 页面怎么跟着变化，比单看文档直观得多。

6.2 也带来了一些新问题

• 前端复杂度提高：
  • DevUI 页面要同时支持“人点”和“智能事件驱动”；
  • 状态管理稍微处理不好，就会出现 UI 状态不一致的问题。
• 对话与 UI 状态同步：
  • 一些用户习惯先手动操作一轮，再回头看对话；
  • 这时候 MateChat 里记录的步骤和当前 UI 状态可能已经不同步，需要设计好“状态刷新”机制。

实践里，我们通过：

• 在关键事件上统一用全局状态管理（而不是组件内自管）；
• 在 MateChat 面板里显示当前上下文概要（环境、模块、资源），

来缓解了大部分同步问题。

---

7. 建议

结合这次 DevUI + MateChat 的实践，我有几点比较主观但真实的建议：

• 先把 DevUI 控制台打磨到“好用”：
  • 表格、表单、告警中心这些基础模块先做好，
  • 再引入 MateChat 做“体验加成”，否则容易本末倒置；
• 给 MateChat 设计一个“有限但清晰”的能力边界：
  • 比如只负责排查路径和信息聚合，
  • 不直接下命令、不替你做高风险变更；
• 尽早考虑“上下文传递”和“智能事件”机制：
  • 这决定了未来扩展新场景的成本；
  • 做得好，MateChat 新增能力时前端几乎不用动太多。