# SoftBus 运维控制台前端设计说明 ## 1. 文档说明 本文档用于定义 `softbus_daemon` 运维控制台的界面功能设计，目标不是单纯罗列接口字段，而是明确以下内容： - 当前控制台面向哪些角色 - 页面为什么存在，各自解决什么任务 - 页面之间如何组成一条完整的操作闭环 - 每个页面依赖哪些接口与状态数据 - 哪些能力属于当前核心版本，哪些属于后续扩展版本 本文档覆盖两类范围： - 当前已形成原型方向的核心页面 - 已进入产品规划、尚未全部实现的扩展页面 ## 2. 产品定位与设计目标 ### 2.1 产品定位 SoftBus 运维控制台是一个面向设备接入、运行监控、规则配置和数据映射的后台管理界面，主要服务于以下角色： - 设备接入调试人员 - 协议与插件开发人员 - 运维人员 - 配置管理人员 - 前后端联调人员 ### 2.2 核心目标 控制台需要同时承担四类职责： - 查看系统当前运行状态，包括健康、版本、计数器、异常和规则状态 - 支撑 discovery 到 mapping 的接入配置流程 - 支撑 filter、transform、mapping 三类规则的查看与配置 - 为设备、Pipeline、插件、Metadata、Profiles 等信息提供统一的浏览入口 ### 2.3 设计原则 - 以工作流为核心组织页面，而不是仅按接口目录平铺 - 首页负责判断状态和分发任务，不承载所有详情 - 高频配置优先采用“筛选区 + 列表/表格 + 抽屉/侧栏”的后台交互模型 - 对“已生效”和“仅注册未接入执行链路”的能力必须明确区分 - 对实时状态、空态、异常态和后端能力边界做清晰提示 ## 3. 信息架构与导航设计 ### 3.1 总体导航结构 建议后台采用左侧导航，结构如下： - 总览 Dashboard - 发现接入工作台 - 规则映射中心 - 过滤规则 - 转换规则 - 映射规则 - 设备管理 - Pipeline 监控 - 插件中心 - Metadata - Profiles ### 3.2 当前原型与规划页面分层 当前文档需要明确区分“已经进入当前原型主线”的页面与“后续继续建设”的页面： - 当前核心原型页 - Dashboard - 发现接入工作台 - 过滤规则 - 转换规则 - 映射规则 - 规划扩展页 - 设备管理 - Pipeline 监控 - 插件中心 - Metadata - Profiles ### 3.3 页面关系图 ```mermaid flowchart TD dashboard[总览Dashboard] discoveryWorkbench[发现接入工作台] rulesCenter[规则映射中心] deviceCenter[设备管理] pipelineCenter[Pipeline监控] pluginCenter[插件中心] metadataCenter[Metadata与Profiles] dashboard --> discoveryWorkbench dashboard --> rulesCenter dashboard --> pipelineCenter dashboard --> deviceCenter discoveryWorkbench --> mappingFlow[发现到映射闭环] rulesCenter --> filterRules[过滤规则] rulesCenter --> transformRules[转换规则] rulesCenter --> mappingRules[映射规则] deviceCenter --> deviceTree[设备树] deviceCenter --> deviceRuntime[运行态设备] pluginCenter --> protocolMatrix[协议能力矩阵] metadataCenter --> metadataPage[Metadata] metadataCenter --> profilesPage[Profiles] ``` ### 3.4 当前原型对应关系 当前项目已经围绕以下结构形成原型入口： - `Dashboard` 作为系统总览首页 - `发现接入` 作为 discovery 和 mapping 的工作流页 - `规则映射` 作为规则中心，拆分为过滤、转换、映射三个页面 这一结构已经体现在路由层： ```33:109:src/router/index.js export const constantRoutes = [ { path: '/', component: Layout, redirect: '/dashboard', children: [{ path: 'dashboard', name: 'Dashboard', component: () => import('@/views/dashboard/index'), meta: { title: 'Dashboard', icon: 'dashboard', affix: true } }] }, { path: '/discovery', component: Layout, children: [ { path: 'index', name: 'DiscoveryWorkbench', component: () => import('@/views/prototype/discovery/index'), meta: { title: '发现接入', icon: 'search' } } ] }, { path: '/rules', component: Layout, redirect: '/rules/filter', name: 'RuleCenter', meta: { title: '规则映射', icon: 'table' }, children: [ // ... ] } ] ``` ## 4. 当前核心工作流 ### 4.1 首页总览工作流 首页的职责不是展示所有细节，而是让用户在进入系统后立刻判断： - 系统是否健康 - 当前是否存在错误、丢包和风险提示 - Discovery 是否活跃 - 当前规则配置状态是否正常 - 下一步应进入哪个功能页继续操作 ### 4.2 发现到映射闭环 核心业务闭环应围绕以下路径组织： 1. 开启 Discovery 2. 查看发现样本 3. 识别 `compositeKey` 与业务语义 4. 绑定 `domPath` 5. 配置 `scale / offset / unit` 6. 按需联动创建 filter 或 transform 规则 7. 回到状态页验证结果 ### 4.3 规则配置闭环 规则中心负责承接工作流中的沉淀配置，功能上分为三类： - 过滤规则：负责注册和条件约束，但需强调其执行链路边界 - 转换规则：负责换算和单位转换，当前已进入执行链路 - 映射规则：负责 `compositeKey -> domPath` 的绑定关系维护 ## 5. 页面功能设计 本章按统一模板描述每个页面： - 页面定位 - 目标用户与核心任务 - 页面布局 - 核心模块 - 关键交互 - 接口来源 - 状态与异常提示 - 页面关系 ### 5.1 Dashboard #### 页面定位 Dashboard 是控制台首屏，负责承接控制面信息、全局状态判断和任务分流。 #### 目标用户与核心任务 - 运维人员快速判断系统健康 - 接入人员判断是否需要进入 Discovery 工作台 - 配置人员判断当前规则数量和规则状态 #### 页面布局 建议采用“顶部页头 + 指标卡片 + 左右两列摘要区”的结构： - 顶部页头：页面标题、说明、主操作按钮 - 第一屏卡片区：设备、规则、Discovery、错误等核心指标 - 中部区域：Pipeline 计数器与系统控制面 - 下部区域：规则状态摘要与风险提示 当前原型已经采用这一结构： ```1:18:src/views/dashboard/index.vue ``` #### 核心模块 1. 状态卡片 - 在线设备 - 规则总数 - Discovery 样本数 - Pipeline 错误数 2. Pipeline 摘要 - `in / out / drop / error / mergeDrop` - 趋势图或柱状图摘要 3. 系统控制面 - 健康检查结果 - 当前版本 - PID - Discovery 开关状态 4. 规则状态摘要 - 过滤规则数量 - 转换规则数量 - 映射规则数量 - 规则生效范围说明 5. 风险提示区 - filter 是否只注册未执行 - transform 是否已生效 - mapping 是否已形成闭环 #### 关键交互 - 点击卡片跳转对应详情页 - 支持导出状态快照 - 支持从首页直接进入发现接入页 - 错误和异常使用醒目标签或提示卡片 #### 接口来源 - `GET /v1/status` - `GET /health` - `GET /api/v1/rules/status` - `GET /api/v1/pipeline/status` - `GET /api/v1/pipeline/counters` - `GET /api/v1/discovery/status` - `GET /api/v1/devices` #### 状态与异常提示 - `running = false` 时置顶异常提示 - `drop > 0` 或 `error > 0` 时高亮 counters - filter 类规则必须显示“注册中/实验性”提示 #### 页面关系 - 跳转到 `发现接入工作台` - 跳转到 `规则映射中心` - 跳转到 `Pipeline 监控` - 跳转到 `设备管理` ### 5.2 发现接入工作台 #### 页面定位 发现接入工作台是本系统最核心的业务流程页，用于承接 discovery、mapping 和规则补充配置。 #### 目标用户与核心任务 - 设备接入调试人员发现未映射字段 - 配置人员建立字段映射关系 - 规则配置人员在映射过程中补充转换或过滤规则 #### 页面布局 建议采用三栏布局： - 左栏：样本筛选与样本列表 - 中栏：字段解析与映射建议 - 右栏：映射绑定表单与补充规则入口 - 底部：最近操作与校验反馈 当前原型已经围绕该模型实现： ```16:33:src/views/prototype/discovery/index.vue
``` #### 核心模块 1. Discovery 控制区 - 开启 Discovery - 停止 Discovery - 清空发现池 - 显示 TTL 与当前状态 2. 样本筛选区 - 按 `protocol` 筛选 - 按 `endpointHash` 搜索 - 列表按更新时间倒序显示 3. 字段解析区 - 展示 `sampleId` - 展示 `protocol` - 展示 `endpointHash` - 展示 `stableKey` - 展示 `compositeKey` - 展示 `valuePreview` 4. 映射建议区 - 推荐 `domPath` - 推荐单位 - 推荐置信度 5. 映射绑定区 - 绑定 `compositeKey` - 选择 `domPath` - 设置 `scale` - 设置 `offset` - 设置 `unit` - 按需勾选创建过滤规则或转换规则 6. 结果验证区 - 最近操作时间线 - 绑定结果 - 规则联动结果 - 校验状态 #### 关键交互 - 选中样本后，中右两栏自动联动 - 绑定成功后支持直接联动创建转换规则 - 已映射样本在列表中自动弱化或过滤 - 最近操作区展示闭环反馈 #### 接口来源 - `POST /api/v1/discovery/start` - `POST /api/v1/discovery/stop` - `POST /api/v1/discovery/clear` - `GET /api/v1/discovery/status` - `GET /api/v1/discovery/samples` - `POST /api/v1/mapping/bind` - `POST /api/v1/mapping/unbind` - `GET /api/v1/mapping/list` - `POST /api/v1/rules/filter` - `POST /api/v1/rules/transform` #### 状态与异常提示 - Discovery 未启动时，顶部显示空态引导 - 样本为空时，提示继续采样或检查协议链路 - 绑定失败时，在右栏表单下展示字段级错误 #### 页面关系 - 可跳转到 `映射规则` - 可跳转到 `转换规则` - 可从 `Dashboard` 直接进入 ### 5.3 过滤规则 #### 页面定位 过滤规则页负责管理过滤条件的注册与查看，并明确说明该能力当前更偏规则注册表管理。 #### 目标用户与核心任务 - 配置人员录入过滤规则 - 联调人员验证条件表达式 - 运维人员区分“已注册”和“已真正生效”的规则状态 #### 页面布局 推荐采用统一的后台页面模型： - 顶部页头 - 筛选区 - 规则表格 - 右侧抽屉表单或详情抽屉 #### 核心模块 1. 列表区 - 规则 ID - 作用范围 - 条件表达式 - 执行说明 - 状态 - 更新时间 2. 表单区 - `id` - `endpointHash` - `deviceId` - `stableKey` - `condition` 3. 状态提示区 - 强调“注册中” - 标明当前执行链路边界 #### 关键交互 - 支持按 `id`、`stableKey`、`scope` 搜索 - 支持新建、查看详情、删除 - 保存后刷新状态摘要 #### 接口来源 - `GET /api/v1/rules/status` - `POST /api/v1/rules/filter` - `DELETE /api/v1/rules/filter/{id}` #### 状态与异常提示 - 必须在显眼位置展示“当前主要是注册表管理能力” - 对未知表达式、非法参数和删除失败给出明确反馈 #### 页面关系 - 可由 `发现接入工作台` 在绑定后联动跳入 - 可返回 `规则映射中心` ### 5.4 转换规则 #### 页面定位 转换规则页用于管理数值换算、偏移量和单位配置，是规则中心中的高频操作页。 #### 目标用户与核心任务 - 配置人员维护转换参数 - 运维人员确认规则是否已实际生效 - 联调人员验证单位转换是否正确 #### 页面布局 与过滤规则保持一致，统一为： - 筛选区 - 表格区 - 抽屉表单 #### 核心模块 1. 列表字段 - 规则 ID - 作用范围 - `scale` - `offset` - `unit` - 执行说明 - 状态 2. 表单字段 - `id` - `endpointHash` - `deviceId` - `stableKey` - `scale` - `offset` - `unit` 3. 状态说明 - 明确标记“已生效” - 说明当前在 Pipeline 中的执行位置 #### 关键交互 - 支持新增、删除、校验和批量检查 - 从映射工作流中带入默认参数 - 编辑后支持回看最近变更 #### 接口来源 - `GET /api/v1/rules/status` - `POST /api/v1/rules/transform` - `DELETE /api/v1/rules/transform/{id}` #### 状态与异常提示 - 转换参数缺失时禁止提交 - 单位异常或非法数值范围要在表单层直接提示 #### 页面关系 - 与 `发现接入工作台` 双向跳转 - 与 `映射规则` 形成配置链路 ### 5.5 映射规则 #### 页面定位 映射规则页负责沉淀 `compositeKey -> domPath` 的绑定结果，是工作流页之后的规则归档中心。 #### 目标用户与核心任务 - 查看当前所有映射关系 - 对已绑定规则进行维护、导出或解绑 - 从规则中心回看业务域路径映射状态 #### 页面布局 保持与规则中心一致： - 筛选区 - 表格区 - 抽屉表单 #### 核心模块 1. 映射列表 - `compositeKey` - `domPath` - `scale` - `offset` - `unit` - 状态 - 更新时间 2. 编辑表单 - `compositeKey` - `domPath` - `scale` - `offset` - `unit` 3. 关系说明 - 映射与 Discovery 工作台的来源关系 - 映射与转换规则的联动关系 #### 关键交互 - 支持按 `compositeKey` 与 `domPath` 搜索 - 支持新建、查看、解绑和导出 - 支持从工作台带着上下文跳入 #### 接口来源 - `GET /api/v1/mapping/list` - `POST /api/v1/mapping/bind` - `POST /api/v1/mapping/unbind` #### 状态与异常提示 - 已绑定状态使用明确视觉标签 - 解绑操作应有二次确认 #### 页面关系 - 来源于 `发现接入工作台` - 与 `转换规则` 共享换算参数上下文 ### 5.6 设备管理 #### 页面定位 设备管理页用于展示设备树、运行态设备和节点详情，是配置管理和设备排查的基础页面。 #### 目标用户与核心任务 - 查看设备树结构 - 查看设备在线状态与运行态信息 - 编辑可变节点字段 #### 页面布局 建议采用左中右结构或双栏结构： - 左侧：设备树或树形筛选面板 - 中间：节点详情 / 运行态列表切换 - 右侧：编辑表单或详情抽屉 也可以采用两个页签： - `设备树` - `运行态设备` #### 核心模块 1. 设备树 - 展示 `id` - 展示 `name` - 展示 `type` - 展示 `endpoint` - 展示 `enabled` - 展示 `params.online` - 支持树形展开 2. 节点详情 - 基础字段 - 运行态字段 - 识别字段 - 关联能力字段 3. 节点编辑 - 可编辑 `name` - 可编辑 `enabled` - 可编辑 `type` - 可编辑 `endpoint` - 可编辑 `driver` - 可编辑 `capabilitiesRef` - 可编辑业务配置型 `params` 4. 运行态设备列表 - 展示 `id` - 展示 `name` - 展示 `protocol` - 展示 `kind` - 展示在线状态 - 展示最近活跃时间 #### 关键交互 - 点击设备树节点刷新右侧详情 - 保存后同步刷新树和运行态设备列表 - 运行态设备支持按类型、状态和关键字筛选 #### 接口来源 - `GET /api/v1/device-tree` - `PATCH /api/v1/device-tree/nodes/{id}` - `GET /api/v1/devices` - `GET /api/v1/devices/{id}` #### 状态与异常提示 - 以下字段前端视为只读： - `id` - `params.stableKey` - `params.online` - `params.lastSeenTs` - 节点不存在、保存失败和字段冲突要明确提示 #### 页面关系 - 可从 Dashboard 的设备卡片进入 - 可在设备详情中联动查看相关 Profiles ### 5.7 Pipeline 监控 #### 页面定位 Pipeline 监控页用于定位吞吐、丢包、错误、线程状态和运行配置问题，是面向运维和排障的关键页面。 #### 目标用户与核心任务 - 观察运行状态是否稳定 - 排查 counters 异常 - 确认运行配置是否符合当前环境 - 查看插件加载摘要 #### 页面布局 建议采用“状态卡片 + counters 区 + 配置区 + 插件摘要区”的结构。 #### 核心模块 1. 运行状态区 - `running` - `parseWorkerCount` - `framerSessionCount` - `parserSessionCount` - `mapperSessionCount` - `endpointFramerCount` - `trackedEndpointCount` - `hasPluginManager` 2. Counters 区 - `in` - `out` - `drop` - `error` - `mergeDrop` - 关键派生指标：`dropRate`、`errorRate`、`out/in` 3. 运行配置区 - `parallelPipeline` - `orderedEgress` - `parseWorkerCount` - `framedQueueMax` - `maxReorderDepth` 4. 插件摘要区 - `parserPlugins` - `framerPlugins` - `mapperPlugins` #### 关键交互 - 自动轮询刷新 - 支持手动刷新 - 支持暂停轮询 - 支持对异常阈值进行高亮 #### 接口来源 - `GET /api/v1/pipeline/status` - `GET /api/v1/pipeline/counters` - `GET /api/v1/pipeline/config` #### 状态与异常提示 - `drop > 0` 与 `error > 0` 使用告警颜色 - 配置为空或状态不可用时，使用区域级空态说明 #### 页面关系 - 可从 Dashboard 的计数器区域跳入 - 与插件中心共享插件摘要信息 ### 5.8 插件中心 #### 页面定位 插件中心用于确认 parser、framer、mapper 三类插件是否完整加载，是协议能力检查页。 #### 目标用户与核心任务 - 协议开发人员确认插件加载结果 - 运维人员查看能力完整性 - 联调人员快速判断协议链路缺口 #### 页面布局 建议拆为三个功能区： - 插件列表 - 协议能力矩阵 - Mapper 专项视图 #### 核心模块 1. 插件列表 - `category` - `pluginId` - `protocol` - `protocolValue` 2. 协议能力矩阵 - 每个协议是否具备 parser - 每个协议是否具备 framer - 每个协议是否具备 mapper 3. Mapper 视图 - mapper 列表 - 所属协议 - pluginId #### 关键交互 - 支持按插件类别筛选 - 支持按 `pluginId` 和 `protocol` 搜索 - 支持从协议矩阵跳转到插件列表 #### 接口来源 - `GET /api/v1/plugins` - `GET /api/v1/plugins/protocols` - `GET /api/v1/plugins/mappers` #### 状态与异常提示 - 协议能力缺项要明确标注 - 插件为空时给出“未加载/未注册/接口异常”区分提示 #### 页面关系 - 与 `Pipeline 监控` 共享插件摘要概念 - 与 `发现接入工作台` 共享协议上下文 ### 5.9 Metadata #### 页面定位 Metadata 页面是数据字典与语义定义中心，用于说明业务含义、单位、读写能力和边界。 #### 目标用户与核心任务 - 配置人员查看语义定义 - 联调人员确认数据字段口径 - Profiles 页面联动查看 metadata 详情 #### 页面布局 建议采用“列表 + 详情抽屉”或“左列表右详情”的结构。 #### 核心模块 1. Metadata 列表 - `metadataId` - `name` - `domain` - `semanticType` - `unit` - `minValue` - `maxValue` - `deadband` - `isWriteable` 2. Metadata 详情 - 完整元数据定义 - 字段说明 - 业务解释 - 可选关联 profile 数量 #### 关键交互 - 支持按 `metadataId` 搜索 - 支持按 `domain` 筛选 - 支持点击行查看详情 #### 接口来源 - `GET /api/v1/metadata` - `GET /api/v1/metadata/{metadataId}` #### 状态与异常提示 - 字典为空时明确提示“未配置”而不是“加载失败” - 详情不存在时提示 metadata 已失效或未注册 #### 页面关系 - 可从 Profiles 页联动进入 ### 5.10 Profiles #### 页面定位 Profiles 页面用于展示设备画像及点位映射结构，是设备与语义之间的桥梁页面。 #### 目标用户与核心任务 - 查看某设备的 profile 快照 - 查看点位与 metadata 的映射关系 - 为后续接入和排障提供结构化参考 #### 页面布局 建议采用“左侧设备列表 / 右侧 mappings 详情表”的双栏布局。 #### 核心模块 1. Profiles 列表 - `deviceId` - `protocol` - `mappings.length` 2. 点位映射详情 - `pointId` - `metadataId` - `registerAddress` - `byteOffset` - `byteLength` - `bitOffset` - `endianness` - `rawType` - `scaleFactor` - `offsetFactor` - `expression` #### 关键交互 - 点击设备切换右侧 mappings - 点击 `metadataId` 联动 Metadata 详情 - 支持按 `deviceId` 搜索 #### 接口来源 - `GET /api/v1/profiles` - `GET /api/v1/profiles/{deviceId}` #### 状态与异常提示 - profile 不存在时明确提示设备尚未生成画像 - 详情为空时提示当前设备未配置 mappings #### 页面关系 - 与 `设备管理` 共享设备上下文 - 与 `Metadata` 页面双向联动 ## 6. 通用交互规范 ### 6.1 统一布局规范 后台页面统一采用以下视觉模型： - 顶部页头：标题、说明、状态标签、主操作按钮 - 内容区优先使用卡片承载信息模块 - 列表类页面统一采用“筛选区 + 表格/列表 + 抽屉” - 流程页优先采用多栏工作台布局 - 只读信息优先使用详情面板，减少重复跳页 ### 6.2 页面跳转规范 - Dashboard 负责主分流 - Discovery 工作台负责流程内操作 - 规则页负责配置沉淀 - 设备、Pipeline、插件、Metadata、Profiles 负责浏览和验证 ### 6.3 状态标签规范 建议统一使用以下语义： - `success`：已生效、已绑定、运行正常 - `warning`：注册中、待确认、部分异常 - `danger`：错误、失败、关键告警 - `info`：只读、未启用、等待中 - `primary`：当前主路径或推荐操作 ### 6.4 表单与操作规范 - 所有危险操作使用二次确认 - 保存成功后提示并刷新当前视图 - 删除成功后应自动刷新列表 - 表单校验失败时优先在字段旁提示，不仅依赖全局 message ## 7. 数据刷新与异常处理 ### 7.1 刷新策略 | 页面 | 刷新方式 | 建议周期 | |---|---|---| | Dashboard | 自动轮询 + 手动刷新 | 3~5 秒 | | 发现接入工作台 | Discovery 状态自动刷新，样本按需刷新 | 3~5 秒 | | 过滤规则 | 手动刷新 | 按需 | | 转换规则 | 手动刷新 | 按需 | | 映射规则 | 手动刷新 | 按需 | | 设备管理 | 手动刷新 + 保存后刷新 | 按需 | | Pipeline 监控 | 自动轮询 + 暂停轮询 | 2 秒 | | 插件中心 | 首次加载 + 手动刷新 | 不轮询 | | Metadata | 首次加载即可 | 不轮询 | | Profiles | 首次加载 + 切换设备时刷新 | 按需 | ### 7.2 错误处理原则 前端统一处理以下几类异常： - 网络失败 - 接口返回失败 - 空数据 - 权限或状态不满足 - 参数校验失败 建议统一提供： - 顶部 `message` 提示 - 区域级错误占位 - 表格空态文案 - 关键模块重试按钮 ### 7.3 特殊业务提示 - filter 规则必须明确标注“仅注册，不保证已参与真实过滤” - transform 规则必须标注“已进入执行链路” - mapping 绑定失败必须保留上下文，避免用户重复填写 - Discovery 样本为空时优先引导检查采集状态，而不是简单提示空列表 ## 8. 组件抽象建议 以下模块适合抽成通用组件： - `PageHeader` - `StatusCard` - `MetricCard` - `SectionCard` - `RuleWorkspace` - `DiscoverySamplesList` - `DiscoveryBindingForm` - `DeviceTreePanel` - `DeviceDetailDrawer` - `PipelineCountersPanel` - `ProtocolCapabilityMatrix` - `MetadataTable` - `ProfileMappingsTable` ## 9. 版本范围与迭代顺序 ### 9.1 当前核心版本 当前版本优先围绕三条主线建设： 1. Dashboard 总览 2. 发现接入工作台 3. 规则映射中心 原因： - 这三部分已经能构成状态查看、发现、绑定、规则沉淀的主闭环 - 最能体现 `softbus_daemon` 当前接口文档的核心价值 - 也是最适合形成高保真原型的界面范围 ### 9.2 第二阶段 第二阶段重点补齐浏览与验证能力： 1. 设备管理 2. Pipeline 监控 3. 插件中心 ### 9.3 第三阶段 第三阶段补齐语义与画像能力： 1. Metadata 2. Profiles ## 10. 附录：当前原型页对齐说明 当前设计说明已与现有原型方向对齐，主要依据如下： - 首页强调状态总览、规则状态、Discovery 活跃度和风险提示 - 发现接入页采用三栏工作台布局 - 规则中心拆分为过滤、转换、映射三个页面 示例数据结构也已经体现这一方向： ```1:44:src/views/prototype/mock-data.js export const statusCards = [ { label: '在线设备', value: '128', trend: '+12.4%', trendType: 'up', hint: '来自 /api/v1/devices' }, { label: '规则总数', value: '42', trend: '+6', trendType: 'up', hint: 'filter / transform / mapping' }, { label: 'Discovery 样本', value: '1,284', trend: '运行中', trendType: 'neutral', hint: '来自 /api/v1/discovery/status' } ] ``` 以及规则中心的数据分类： ```112:173:src/views/prototype/mock-data.js export const ruleFilters = { filter: [ { id: 'flt_temp_guard', scope: 'stableKey: boiler_temp', condition: 'value >= -40 && value <= 180', status: 'registered' } ], transform: [ { id: 'tr_temp_celsius', scope: 'stableKey: boiler_temp', scale: '1.0', offset: '0', unit: 'C', status: 'active' } ], mapping: [ { compositeKey: 'boiler.temp.01', domPath: 'site.boiler.temperature', status: 'bound' } ] } ```