1. 项目概述与方案整体设计思路1.1 为什么我们需要一套EMS零碳园区原型做能源管理这个方向的人应该都有同感方案讲得天花乱坠客户却总是“嗯嗯听了但还是想象不出来”研发排期排到三个月后商务那边却追着要演示截图一个园区项目动辄几十个页面没有统一原型规范的话设计稿东拼西凑开发标准全靠群里喊。我在好几个能源数字化项目踩过这些坑之后得出一个比较实用的解法在需求确认阶段就拉出一套高保真EMS智慧能源与零碳园区管理原型系统用它来统一客户、产品、研发和UI的认知。这套原型不是拿来炫技的而是要回答三件事——园区有哪些能源资产、系统怎么管这些资产、零碳指标怎么落到页面上。用Axure来做这件事是因为它天然适合快速迭代改一个交互逻辑比改一套前端代码快得多画一个页面只要拖拽元件不用等UI切图。这套原型覆盖了能源数据采集、设备监控、储能调度、碳排放核算、告警运维、报表分析这些核心场景。它适合这几类人负责能源管理系统产品规划的产品经理做园区级能碳项目的实施顾问以及接智慧园区项目的UI/UX设计师。即便你手头没有真实项目这套原型的业务逻辑拆解也值得看一遍它基本代表了一类典型项目的通用需求框架。1.2 这套原型的核心业务逻辑拆解从业务层面看零碳园区能源管理系统的逻辑主线是一条“数据采集—分析诊断—优化调度—溯源认证”的链路。园区里的电表、水表、气表、光伏逆变器、储能PCS、充电桩、环境传感器先把数据汇聚到采集层再由能源管理平台完成指标计算与可视化呈现。整套原型的核心页面也遵循这条主线。我把原型拆成五个模块综合能源驾驶舱、配电与负荷监测、储能与微网调度、碳资产管理、运维告警中心。每个模块下再拆子页面比如综合驾驶舱里包含能源总览、碳排总览、成本总览三个页签储能调度里包含充放电策略、SOC曲线、收益统计。这样拆的好处是开发拿到原型之后能直接对应到功能菜单和接口列表客户也能按模块逐一确认需求不会出现“我说的和你做的不一样”这种事后扯皮。模块命名的逻辑和行业里的通用叫法保持一致。很多项目死在不统一的术语上——有人叫“能管平台”有人叫“电力监控”有人叫“能耗系统”其实做的是一件事。原型里统一叫EMS、碳资产、微网调度客户看多了行业方案也熟悉这套叫法沟通成本反而低。1.3 为什么选Axure而不是其他原型工具之前也试过用Figma画这套东西画UI确实漂亮但做复杂交互时效率和Axure比还是有差距。零碳园区里有一个很典型的交互场景页面左侧是设备列表点击一台储能变流器右侧要同时更新设备参数、运行状态、SOC曲线和当前告警中间还要联动地图上的设备点位。Axure用动态面板加条件判断就能实现这种业务系统的高保真场景联动而其他工具往往需要额外插件或者复杂的状态管理。做能源系统的原型本质上是在做一套后台业务系统不是做营销官网。这类系统的特点是表格多、表单多、弹窗多、状态多Axure的表格、中继器、动态面板正好是干这个的。我的经验是用Axure做的原型可以直接拿来做开发标注元件命名规范的话UI还原度很高。还有一点很重要Axure的交付门槛低。客户那边不一定装了Figma账号但Axure原型通过发布链接就能在线查看点开就能点、就能填、就能看弹窗效果。做TO B的售前项目一个能在线演示的原型链接比二十页PPT管用多了。2. 高保真原型制作的核心技能准备2.1 搭建可复用的能源管理元件库原型要做到高保真不能画完一个页面再从零拖第二个。必须先把公共元件库搭出来后面做几十个页面时才能效率翻倍。我习惯在Axure里建一个“EMS组件库”包含这样几类元件。导航类左侧菜单、顶部标题栏、页签切换标签、面包屑导航。这些元件用母版功能维护一个母版改了全站跟着变。能源系统最常见的坑就是页面多了之后左侧菜单改文案改到崩溃母版能一次解决。比如把“储能收益”改成“储能经济性分析”只用改一次母版所有页面同步生效。数据展示类KPI卡片、趋势图容器、仪表盘容器、表格组件。用中继器来做表格组件是效率最高的做法字段名和行数据都在中继器里维护后面接入示例数据时直接改数据集就行不用每一行手动画。KPI卡片做成一个带图标位、数值位、单位位、涨跌箭头的组合元件放在元件库里使用时改文本内容即可。业务组件类设备状态标签运行/待机/故障、告警等级徽标紧急/重要/次要、能耗排名条、进度环。这些组件决定原型的行业感很多原型做得像网站模板就是因为缺了这种业务化的小组件。建议给元件库里的公共元件命名用统一前缀比如“EMS_导航_左侧菜单”“EMS_卡片_设备KPI”。原型动不动几十个页面统一命名是后面维护和走查的基础。元件库建好之后新页面基本就是拖母版、拖卡片、填数据、连跳转逻辑。2.2 动态面板和中继器在业务系统里的正确用法动态面板是Axure里做交互最核心的元件。能源系统里大量存在“同一个区域在不同状态下显示不同内容”的场景比如储能设备详情弹窗待机态和运行态显示的字段不一样普通做法是画两个弹窗加人多的时候用显隐控制不推荐维护成本太高。我的做法是做一个动态面板放两个状态——State1待机、State2运行用条件判断决定显示哪个状态。后续新增状态直接在动态面板里加State逻辑清晰、改起来方便。中继器则是做能源数据表格的神器。比如设备台账页面里面有几十台设备的名称、型号、安装日期、状态、容量。如果用普通表格一个一个填页面一多就废了。中继器可以维护一套数据还能按列排序、筛选、分页。我在做告警列表时用中继器实现“按告警等级筛选、按时间排序”演示的时候给客户现场筛一遍效果非常直观。还有一点交互细节值得提表格的操作列查看详情、远程控制、编辑建议用中继器单元格里的按钮元件给按钮加“鼠标单击时打开详情弹窗”的交互。这样每行数据的操作逻辑都是统一的不用给每一行单独配置交互。2.3 用真实数据驱动原型展示很多原型看起来假是因为数据太“空”。能源系统页面里全是数字如果KPI卡片写“77”“10086”客户一眼就看出是假的演示效果大打折扣。我的经验是提前准备一套“演示数据包”让原型里的每个数字都有业务含义。比如园区总负荷写“2.68 MW”而不是“1000”今日光伏发电量写“3268 kWh”储能SOC写“76%”。这些数据要和场景匹配某个生产车间的负荷就是比办公楼高夜间光伏出力就是接近于零储能晚上放电白天充电。客户看原型的时候有代入感方案的可信度自然就高了。对于趋势图、曲线图这类无法用静态元件画出来的内容可以提前截好数据可视化的图片放在元件里。也可以用Axure的矩形边框加水平线来做简易折线图虽然不如图片精致但胜在可交互——配合动态面板切换不同时间范围的数据图片展示效果也很能打。如果手头有第三方可视化插件的授权可以直接嵌入图表库的HTML代码Axure支持引入HTML文件这样图表的高保真度就更强了。3. 零碳园区EMS原型从页面布局到交互闭环3.1 页面信息架构与原型目录规划一套完整原型的目录规划决定了项目的交付观感。很多原型做着做着页面就乱了原因是最初没有规划好页面树。我打开一个原型如果左侧页面树是乱的基本可以断定这个项目后期维护是灾难级的。这套EMS原型我按业务域组织页面树一级目录是驾驶舱、设备监控、储能管理、碳资产管理、告警运维、系统设置二级目录在设备监控下分成配电监测、光伏监测、充电桩监测储能管理下再分运行监视、控制策略、收益分析。页面树的组织尽量保持和前端菜单一致。这样做的好处是客户在原型里点击左侧菜单跳转时交互逻辑和最终上线系统保持一致演示时不容易蒙圈。页面命名也要带上编号比如“DASH-01 驾驶舱-能源总览”“STOR-03 储能-充放电策略”这样沟通时说“STOR-03页面”就知道是哪个比说“那个储能页”高效很多。而且如果后面出了新版本原型编号能帮助团队做版本比对哪些页改了、哪些页新增了一目了然。3.2 驾驶舱大屏的栅格体系与视觉动线综合能源驾驶舱是原型的门面也是客户第一眼看到的东西。我做驾驶舱大屏时有一个框架性思路把页面当成一套栅格系统来设计而不是凭感觉摆元件。整个页面的宽度按1920px设计栅格分成四列从上到下划分几个功能区。顶部是园区基本信息条园区名称、日期天气、总体能碳指标综合能耗、碳排放强度、非化石能源占比这个区域高度占8%左右。视觉上做成深蓝色半透明背景这是能源行业大屏的通用风格。中间部分是核心可视化区分三栏左栏占25%放光伏发电实时功率、储能充放电状态、充电桩运行状态中栏占50%是园区地图底座地图上标注各建筑的实时负荷右栏占25%放碳排放实时曲线、能耗排名、告警最新动态。底部一条占15%放未来一周负荷预测趋势、电价时段信息、设备在线率。这套栅格体系里的每个区块在原型里都做成独立动态面板。演示时点左侧光伏卡片中栏的地图自动切换到光伏专题展示光照辐射和屋顶光伏点位点右侧告警列表的某条告警中栏自动弹窗定位到具体设备位置。这种联动交互比静态图表堆砌高出好几个层级客户体验感很强。3.3 储能调度页面的状态联动实现储能调度是零碳园区EMS里业务逻辑最复杂的模块也是原型里最有价值的一个部分。它要求页面同时展示一次系统图、设备状态、运行曲线和控制操作入口而且这些内容之间还有逻辑关联。我做储能调度页时主视觉是一张储能系统拓扑图包含电池簇、PCS变流器、变压器和并网点。在拓扑图上每个设备对应一个热区鼠标悬停时弹出该设备的实时参数卡。这个交互在Axure里实现并不难用动态面板做“鼠标移入时显示弹层”就能搞定。页面右侧放当前控制模式手动/自动/定时。切换不同模式时下方的“充放电指令”区域联动变化——手动模式下显示功率输入框和执行按钮定时模式下显示时间段设置表自动模式下显示策略选择下拉框。这个交互用动态面板加条件逻辑实现我给每个模式建一个动态面板状态用“当前控件值手动模式”这种条件判断切换。故障状态也要在原型里体现。我专门做了一个“模拟告警”的动态交互演示时点击“电池簇3温度异常”按钮整个拓扑图上的电池簇3变成红色右侧告警栏新增一条紧急告警同时页面顶部出现告警提示条。这种交互向客户展示的不只是界面而是系统对故障的联动响应能力方案的说服力直接拉满。4. 操作过程中的关键实现方法与参数细节4.1 零碳指标计算模型在原型中的落地碳资产管理模块是零碳园区的核心差异化内容也是客户最关心的部分。这块做原型的时候不能光放几张折线图必须把碳核算的逻辑可视化出来。我在碳资产管理页面里放了四个核心指标卡园区总碳排放量tCO₂、碳减排量tCO₂、碳强度kgCO₂/m²、绿电占比%。碳排放量在原型里是按实时值展示的但逻辑上它是各排放源的加总包括外购电力碳排放、天然气燃烧碳排放、柴油消耗碳排放、空调制冷剂逸散碳排放。我在原型的碳核算页里放了一张“排放源拆分表”用的是中继器字段包含排放源类别、活动数据、排放因子、碳排放量、占比。活动数据和排放因子都是可编辑的配合中继器的排序功能按碳排放量降序排列客户一眼能看出园区碳排最大的来源在哪里。排放因子的数值参考行业通用做法外购电力排放因子是0.5703 tCO₂/MWh天然气排放因子是2.1622 tCO₂/万Nm³。这些参数在原型里做成可配置项主要考虑是不同区域、不同电网的排放因子存在差异原型阶段把参数暴露出来等于告诉客户这套系统是支持自定义的而不是写死的演示数据。碳减排量的计算逻辑核心是对比基准情景和当前情景的排放差。原型的减排贡献页面展示了光伏发电替代外购电力减排多少吨、储能削峰填谷提升绿电消纳减排多少吨、充电桩有序充电迁移负荷减排多少吨。每一项都做成一条进度条附上减排量的具体数值和占比客户看完这个页面基本就能理解零碳园区的运行逻辑。4.2 告警规则配置原型的设计思路告警运维中心的大致框架也是EMS原型的重中之重这块页面做得好能直接打动运维背景的客户。告警页面包含四个核心区域告警统计总览、实时告警列表、历史告警查询、告警规则配置。告警统计总览做成四张KPI卡展示今日告警总数、紧急告警数、已处理数、未处理数。核心交互在实时告警列表我用中继器实现、按告警等级显示不同左侧色条——紧急红色、重要橙色、次要黄色。点击列表中任意一条告警右侧弹出告警详情面板包含告警发生时间、设备位置、告警描述、处理建议。再往下是“处理操作”按钮点击后这条告警的状态从未处理变成处理中这个状态切换用动态面板实现。告警规则配置页是我比较得意的一个设计。它模拟了运维人员设置告警阈值的过程选择设备类型、选择监测指标如电池温度、PCS效率、负荷率、设置阈值条件大于、小于、区间、设置告警等级。配置完成后原型有一个“模拟触发”按钮点击后系统按新规则自动生成一条告警记录。这个交互我给客户演示过多次客户看完就说“这个逻辑就是我们需要的”比讲一百页文档都管用。4.3 用Axure制作动态数据图表的实用方案做能源系统的原型图表是绕不开的而Axure自带的图表元件有限做不出ECharts那种炫酷效果。这方面我的做法分三档简单场景直接用原生元件拼中等场景用图片替代复杂场景用内嵌HTML。对于KPI卡片上的趋势小图用Axure的原生线段和曲线路径就够了再加一个渐变填充矩形当面积图。这种做法文件体积小加载快而且避免外部依赖。对于驾驶舱大屏和碳排趋势这类需要精细效果的大图我直接引入ECharts示例图片。图片方案需要注意一个细节图片尺寸最好做成1920宽屏的2倍图也就是3840px宽这样在高分辨率屏幕上放大查看时依然清晰。我一般用ECharts官网的在线示例调整好配色截图导出PNG再做透明背景处理。如果是给客户做可交互演示内嵌HTML会更好用。Axure支持通过“内联框架”元件嵌入本地HTML文件ECharts的折线图、地图、热力图都能在里面渲染。鼠标悬停有tooltip提示拖动有缩放客户点起来体验和真实系统几乎一致。这个方案还能顺便在原型阶段验证一下图表选型和ECharts版本的兼容性后面开发的时候能少走弯路。4.4 版本管理与团队协作实践一套几十页的Axure原型文件如果不注意版本管理很容易出现改崩了、回不去、多人协作时版本冲突这类问题。我的实操经验是坚持小步提交、定期存档的原则。我会把原型源文件放在Git仓库里管理每个里程碑版本打一个Tag比如“v0.9-首版确认”“v1.0-客户演示版”“v1.1-研发移交版”。每次做较大改动前先复制一份存档放到“archive”目录原件继续改。这样做的好处是随时可以回退到上一个稳定版本演示现场就算原型出问题也能快速切到备份文件顶上。如果团队多人协作一个Axure文件我建议把工作拆分到多个文件最后再用“合并”的方式整合。比如A负责画驾驶舱和大屏B负责储能调度和碳资产C负责告警运维和系统设置每人维护一个独立的.rp文件在定稿时统一合并到主文件。Axure的文件合并功能支持导入其他文件中的页面和母版合并时选择“仅导入母版和元件”就能避免样式冲突。5. 常见问题与排查技巧实录5.1 页面加载卡顿与文件体积过大问题做过Axure原型的人基本都遇到过这种问题页面多了、图片多了之后原型预览越来越卡点一个交互要等两三秒。原因主要是文件体积过大和单个页面承载的元件过多。我踩过最狠的一次坑是一个驾驶舱页面里放了四十多张截图图片每张都是1920宽度的未压缩PNG文件直接飙到两百多MB打开原型就像在拖动一张巨图。后来我总结出一套优化方法图片统一压缩到Web显示级别普通图表宽度控制在1280到1600像素之间大屏背景图控制在1920像素不追求2倍图的地方就不用2倍图。压缩工具我用的是TinyPNG能源系统里的图表截图压缩率通常能在70%以上肉眼几乎无差别。另外一个页面的元件数量也需要控制。如果某个页面画得太满交互逻辑复杂到几十个动态面板嵌套预览时的渲染压力会很大。建议把信息密度过高的页面拆分成多个子面板用页签或下拉切换展示。比如把“设备监控”下的配电、光伏、充电桩拆成三个页签而不是一个页面全放出来。5.2 动态面板条件判断不生效的排查方法动态面板的交互是Axure原型里最容易出错的地方。排查条件判断不生效的问题时先从“事件触发条件”和“条件判断节点”两个环节分别检查。事件触发条件是指在哪个交互事件下开始执行比如“单击时”“鼠标移入时”“选中时”。条件判断节点则是指“如果当前元件值等于某个值”这类逻辑分支。常见错误是事件设置没问题但条件判断里引用的元件写错了——比如想判断列表中被选中的行的状态结果引用了元件库里母版副本的行数据一直对不上。我的排查方法是在条件判断里加一个“设置文本”的动作把当前引用的元件值显示到一个临时文本框里预览时一眼能看到引用值到底是多少。还有一个常见问题动态面板切换状态时闪烁或显示白底。这通常是因为动态面板的“自适应内容”选项没打开。在Axure里给动态面板加状态切换时如果面板尺寸是固定的新状态的内容超出或小于面板都会导致显示异常。我的习惯是把所有动态面板都勾选“自适应内容”让面板尺寸跟随状态内容变化保证切换时过渡干净。5.3 原型在不同终端上的兼容性问题演示场景往往是多变的客户可能用笔记本电脑也可能用平板有的还要求手机上看一眼。Axure默认的页面尺寸可能在不同屏幕下出现错位或内容截断的问题。解决思路是原型尽量采用固定宽度设计配合自适应缩放。我在制作时的标准做法是页面宽度统一设为1440px这个宽度在主流笔记本和办公大屏上展示效果最好。如果你预判演示设备是1920宽的大屏可以把原型页面宽度设置成1920再配合百分比的栅格布局。页面高度允许滚动这在业务系统里是正常的不用刻意追求一屏显示完所有内容。对于手机端查看的需求最好单独做一个移动端版本的页面集。Axure支持给同一套原型生成不同尺寸的预览版本在“发布原型设置”里可以添加移动端页面尺寸比如375×812。如果你只做了一个桌面版直接在手机上打开预览链接体验会大打折扣。我的做法是把驾驶舱里的核心指标卡单独做几个移动端页面用于给客户在手机上快速浏览园区当日能碳情况妥妥够用。5.4 原型在客户现场演示时的备用方案客户现场演示是原型系统方案的高光时刻但它也是翻车概率最高的时刻——投影仪分辨率不对、网络延迟、浏览器兼容性问题这些我都经历过。演示前我固定做三件事。第一把原型发布成HTML文件存放在本地不依赖网络。第二在Chrome、Edge、Firefox三个浏览器里分别预览一遍大多数兼容性问题能提前暴露。第三准备一个“演示脚本”列出演示时要说的话和要点的交互按钮到了现场不至于卡壳或漏掉关键环节。演示时如果网络稳定可以考虑用Axure Cloud的在线链接它会自动适配浏览器不过离线版更稳妥。另外给客户演示时尽量用Chrome浏览器。Axure的交互逻辑在Chrome下是测试最充分的客户的电脑上如果没有提前发邮件附上安装包或者演示前五分钟先安装好。这些小细节看着琐碎但都能直接影响客户对方案专业度的感知。6. 基于这套原型的后续扩展方向原型做到能演示、能确认需求只是第一步。EM系统方向的项目后续往往还会延伸出很多新需求原型的框架如果预留得好扩展起来就不会伤筋动骨。基于我的经验这几个方向比较有代表性。第一个方向是移动端协同。园区能源管理不只是管理人员坐在电脑前看大屏运维人员更多是在现场巡检时用手机查看设备状态、接收告警、填报巡检记录。原型可以在现有基础上增加移动端的告警推送页面、设备扫码页面、现场拍照上传页面。这类页面和PC端是同一套数据交互逻辑不同但原型阶段就可以把状态流转设计清楚。第二个方向是AI分析与预测。这类需求通常出现在二期或三期项目中比如用机器学习做负荷预测、光伏发电预测、设备故障预测。原型可以预留“AI分析报告”页面把这个页面的信息架构先设计出来预测曲线、准确率、模型版本、特征重要性等。先有框架再让算法团队填内容原型阶段就把产品边界定义清楚能少扯不少皮。第三个方向是接入三维可视化。园区级的零碳管理客户很容易提出“我要一个三维园区地图点哪栋楼看哪栋楼的数据”这类需求。Axure支持内嵌Three.js或ECharts GL的HTML页面原型阶段就能做一个简版的三维园区地图Demo页面切换和交互逻辑先跑通给开发留出降低技术风险的参考。我建议这个扩展放在核心业务确认之后再做因为三维可视化的工作量不小而且容易让需求会跑偏——大家只顾着看“炫”忘了数据准确和业务闭环才是核心。这套原型的核心价值在于把一个复杂系统的业务流程、数据指标、交互逻辑在开发之前完整呈现出来让所有干系人看到同一个东西。它不是一个“画得好看就行”的界面稿而是一个业务逻辑闭环、数据有依据、交互能走的完整方案。做能源数字化项目能早一点把“说不清的系统”变成“看得见的系统”后面所有的沟通和交付都会顺畅很多。