本体模型-AI原生应用UI建模规范与原型实践总结

大家好，我是人月聊IT。

在前面我已经详细介绍过了完整的本体建模规范参考，但是少了UI建模。而且我也专门提出了，在当前思路下实际是不需要对用户需求进行详细的UI功能建模，而是仅仅需要输出一套UI建模规范参考。AI大模型在构建应用的时候自动根据UI建模规范来实现UI界面的生成。

任何UI交互，仅仅是方便为了人机交互和输入的一个工具媒介，这个完全没有必要体现在核心的本体模型里面。只是在AI原生应用生成的时候才需要。而且大家要意识到，在企业级软件开发进入“本体驱动（Ontology-Driven）”和“AI 原生（AI-Native）”的今天，传统的、僵化的 SaaS 界面已经无法满足复杂业务逻辑与 AI 智能决策的深度协同。

在输出了UI建模规范yaml文件后，我们整体的建模文档实际就相当完整的，后续需要进一步验证的就是重新再跑一遍我前面谈到的workflow。

这篇文章重点分享下我重构UI界面原型和UI建模规范的完整过程思路，实际我在前面已经让AI输出了一套静态的UI Demo原型。因此我核心重点是从一个传统的 HTML 演示原型出发，解构其视觉逻辑，重构出一套支持 三栏动态布局、多标签管理、AI 智能助理深度融合 的现代化 React 原型，并最终抽象出一套通用的 UI 建模规范（m9-ui-model.yaml）。

定义 AI 原生布局骨架

1. 布局的进化：三栏式动态空间

AI 原生应用的核心特征在于“协同”。我们摒弃了传统的顶部+左侧的 L 型布局，采用了更具扩展性的 三栏式（Triple-column） 布局：

• 左侧：树形导航（Sidebar）。采用白色底色，辅以 Lucide 精美图标，支持多级展开。它代表了系统的静态业务结构。
• 中间：功能区（Main Area）。支持多标签页（Multi-Tab）展示，是业务处理的核心战场。
• 右侧：AI 智能助理（AI Copilot）。这是一个现代化的 AI 对话区，它不仅是信息输出端，更是操作触发端。

2. 交互的灵活性：拖拽与自适应

为了满足不同业务场景下对视野的要求，我们实现了 Resizable 布局。用户可以自由拖拽左侧菜单和右侧 AI 栏的宽度。关键技术点： 我们编写了一个自定义 React Hook useResizable，通过监听 mousemove 事件动态计算 Flex 布局的像素宽度，确保中间功能区在两侧变动时能够完美自适应。

// useResizable 核心逻辑片段
const resize = (mouseMoveEvent: MouseEvent) => {
  if (isResizing) {
    let newWidth = direction === 'left' 
      ? mouseMoveEvent.clientX 
      : window.innerWidth - mouseMoveEvent.clientX;
    
    if (newWidth >= minWidth && newWidth <= maxWidth) {
      setWidth(newWidth);
    }
  }
};

视觉规范的“克制”与“纯净”

在视觉设计上，我们遵循了 “扁平化、无立体感、高间隙” 的极简主义原则：

• 消除立体感：全局移除 box-shadow 和 border-radius。界面不再通过阴影来区分层级，而是通过精细的边框（#e2edf2）和背景色块（#f0f2f6）进行语义分割。
• 呼吸感间隙：功能区页面四周固定保持 15px 的留白。这种间隙的一致性，使得复杂的 ERP 表单在视觉上也能保持清爽。
• 色彩策略：保留了深受用户喜爱的深色导航栏（#111827）和品牌蓝（#2266e3），在专业感与现代感之间取得了平衡。

AI 智能助理的深度融合

AI 对话区不再是一个孤立的聊天框，而是系统的“第二入口”。同时不仅仅是一个实现Chat问数的对话框，而是真正可以实现业务协同操作，核心业务需求功能推理的AI原生交互对话框。

1. 指令联动（Command Execution）

当用户在 AI 对话框输入“我要录入供应商”时，AI 助手会解析用户意图，通过回调函数 onExecuteAction 触发 OPEN_TAB 指令，自动在中间区域新建或激活对应的功能标签页。

2. 多态输出（Poly-Output）

AI 的返回结果被建模为三种形态：

• 文本（Text）：支持富文本与 Markdown 说明。
• 表格（Table）：针对统计类需求（如“按类型统计供应商数量”），AI 渲染出一个自适应宽度的内嵌表格。
• 图表（Chart）：集成 ECharts，自动绘制如“月度采购分析”的柱状图，并确保图表在 AI 面板宽度调整时实时重绘（Resize）。

// AI 响应逻辑片段
if (lowerInput.includes('统计') && lowerInput.includes('供应商')) {
  aiResponse = {
    type: 'table',
    content: {
      title: '供应商类型统计表',
      headers: ['供应商类型', '供应商数量', '占比 (%)'],
      rows: [['民营企业', '45', '56%'], /* ... */]
    }
  };
}

新增加UI 建模规范Yaml文件

这是整个项目最关键的产出。我们将所有的视觉经验和交互逻辑抽象成了可供程序读取的 元数据模型。

1. 为什么需要 UI 模型？

传统的代码编写是“一次性的”，而通过 m9-ui-model.yaml，我们可以将 UI 规范与具体的业务实现解耦。未来，只要业务逻辑（m1-object-model）发生变化，UI 生成引擎可以根据这套规范自动推导并生成界面。

2. 模型核心结构解析

• Layout Specification：定义了物理世界的骨架（边距、宽度限制、扁平化开关）。
• Navigation Model：定义了树状目录的元数据结构，包括图标映射。
• Component Templates：定义了两大核心页面模式。
  • search_table_template：定义了“上面查询，下面列表”的通用布局。
  • entry_form_template：定义了单表录入与主从表（Master-Detail）录入的布局策略。
• AI Interaction Protocol：这是 AI 原生特有的部分，定义了对话框内的组件渲染协议和语义意图到 UI 动作的映射关系。

3. 代码片段展示

# m9-ui-model.yaml 片段
main_area:
style:"multi-tab"
content_padding:"15px 15px 0 15px"# 严格执行的间隙标准
elevation:"flat"# 消除立体感的建模定义

ai_interaction_protocol:
message_renders:
    chart:
      engine:"echarts"
      style:"auto-fit-container"# 自适应宽度协议

完整原型Demo参考输出

为了验证这套建模规范的有效性，我们构建了两个极具代表性的功能原型：

1. 供应商录入（单表模式）： 展示了如何在扁平化布局下，利用 grid-2-columns 快速生成自适应宽度的表单。
2. 采购订单录入（主从表模式）： 这是一个典型的复杂业务场景。上部是订单主信息（Master），下部是可动态增删行的明细表格（Detail）。它验证了 m9-ui-model.yaml 中对于 master_detail 布局的支持能力。

同时，我们通过一个模拟登录系统完成了整个闭环：

• 用户访问 -> 登录页面（admin/123456） -> 进入主界面。
• 点击右上角“退出” -> 清除状态 -> 回到登录。

结语：基于建模规范的生成式UI

通过本次实践，我们不仅交付了一个可运行的、美观的 AI 原生应用原型，更重要的是，我们建立了一套可落地的 UI 建模规范。

在未来的开发中，UI 不再是前端工程师一行行手写的像素，而是根据 m9-ui-model.yaml 规范，结合业务本体模型自动喷涌而出的交互实体。这就是“模型驱动交互”的魅力所在。

下一步动作。进一步验证我整个核心思路，实现建模字系统，AI生成子系统，AI运行子系统的协同和联动。

今天分享就到这里，希望对大家有所启发。