智慧园区方案核心拆解：数据中台与异构系统整合实战

“智慧园区”这个词前两年还只是PPT里的概念今年已经有大量园区在真金白银地推。我之前参与过一个占地近千亩的产业园区项目前后折腾了将近一年最后方案汇报用的就是一份七十多页的PPT今天这篇博文就把我当时做智慧园区系统方案的核心思路、数据中台与异构系统整合的实操路径以及方案里不会写但实际一定会踩的坑全部拆开讲一遍。无论你是正在立项的园区方、负责售前方案的工程师还是准备接手这类项目的集成商这份拆解应该都能帮你把思路捋顺少走不少弯路。1. 方案整体设计与架构思路拆解1.1 智慧园区的本质不是堆设备是打破孤岛很多第一次接触智慧园区的人第一反应是“装摄像头、上人脸闸机、搞一堆传感器”。这个理解不算错但只摸到了皮毛。我在跟园区管理方沟通时经常打一个比方智慧园区不是给园区装“眼睛和耳朵”而是给它装“大脑和神经”。眼睛和耳朵负责采集信息大脑负责做决策神经负责把决策传达到手脚。一个园区如果只是买了几千路摄像头、几百个物联网传感器却没有一套统一的平台把这些数据汇聚起来、分析出来、反馈下去那这些设备本质上就是一堆独立运行的孤岛各管各的甚至比传统方式更添乱。真正的智慧园区核心价值在于打破信息孤岛。传统园区里安防系统管安防消防系统管消防能耗系统管能耗门禁系统管出入财务系统管收费物业系统管报修——每个系统都有自己的一套数据库、一套登录账号、一套操作界面。出了问题要找三个部门、开五次协调会、翻六套系统才能定位。而智慧园区的目标就是把这些原本割裂的系统通过一个统一的平台底座通常叫“园区大脑”或“IOC智能运营中心”整合起来让数据在一个池子里流动让业务在一个界面上操作让决策在一张图上完成。1.2 方案整体架构四层一平台怎么搭做方案第一件事就是定架构架构定不住后面全是补丁。我在这类项目里一般用“四层一平台”的框架来组织整个系统方案这也是我见过的大多数头部厂商的标准打法。从下往上数第一层是感知层也就是前端设备层包括视频监控、门禁闸机、车辆道闸、消防烟感、温湿度传感器、水表电表气表、电梯运行监测等各类物联感知终端。这一层解决的是“数据从哪里来”的问题。第二层是网络层解决“数据怎么传”的问题。园区光缆骨干网、5G/4G无线覆盖、物联网专网、Wi-Fi全覆盖这几张网要统筹规划。做方案时最容易漏的是物联网专网——很多园区只规划了办公网络和监控网络结果后期装了一堆传感器才发现NB-IoT信号覆盖不足或者Wi-Fi带不动海量设备连接只好返工补网。第三层是平台层这是整个方案的技术核心包括物联网平台、视频云平台、数据中台、业务中台、AI算法平台等。这一层解决的是“数据怎么管、怎么算”的问题。数据中台的建设尤其关键后面我会专门用一整节来讲异构系统整合和数据迁移的实操。第四层是应用层解决“数据怎么用”的问题。包括IOC智能运营中心、智慧安防、智慧通行、智慧能源、智慧物业、智慧招商、产业服务等各类业务应用直接面向园区管理者、运营人员、企业和员工。最后横跨四层的是安全保障体系和运维管理体系包括网络安全等级保护、数据安全、运维监控等。在方案评审时安全体系经常被低估但现在无论是合规要求还是实际风险这一块都是硬性的。我在方案里一般会把网络安全单独列预算按等保二级或三级要求来做。1.3 为什么这套架构能落地而不是纸上谈兵选这套架构不是因为它听起来高级而是因为它在实际项目中经受过验证具备三个关键特性。第一个特性是解耦。感知层、网络层、平台层、应用层各自独立设备厂商和应用厂商可以分开招标、分别建设不会出现“绑定一家供应商后续想换都换不掉”的困境。我曾经见过一个园区因为早期被某家厂商用私有协议绑死了后面每次加一个子系统都要交高额的对接费整个项目后期成本翻了一倍多。用标准化的分层架构至少在招标和采购层面能留有更多的主动权。第二个特性是统一物联接入。平台层里有物联网平台作为统一接入网关支持MQTT、CoAP、Modbus、BACnet等多种物联协议。园区里的设备品牌五花八门协议各不相同如果没有一个统一的物联接入层每加一种设备就要做一次定制开发这个项目就永远干不完。统一接入之后前端设备就像插头一样插在同一个插座上就能用电。第三个特性是数据驱动闭环。数据从感知层采集上来在平台层完成治理和存储在应用层形成业务闭环——发现问题、生成工单、派单处理、结果反馈、数据沉淀整个过程全部在线化。这个闭环一旦跑通园区运营效率的提升是肉眼可见的这也是智慧园区区别于传统“安防工程弱电工程”的最核心差异。2. 数据中台与异构系统整合迁移方案设计的核心难点2.1 异构系统整合为什么是智慧园区最大的坑智慧园区项目里公认最难、最容易翻车的不是前端设备安装也不是App开发而是老系统数据迁移和新旧系统整合。正常一个已经运营数年的园区手上至少会有三五套存量系统财务用的金蝶或用友、物业用的某个物业管理系统、安防用的海康或者大华平台、停车用的某家道闸厂商系统、招商用的Excel表格加CRM……每一套系统来自不同厂商运行在不同时期、不同技术栈上数据库可能是MySQL、SQL Server、Oracle混着来表结构千奇百怪数据格式一个系统一个样。新建的智慧园区平台必须从这些异构系统中把历史数据抽取、清洗、转换后迁入新的数据中台同时还要保证新旧系统并行期间的业务连续性。这绝不是“导一张表”那么简单它涉及数据采集口径的统一、编码规则的映射、主数据治理、清洗去重、增量同步、校验回退等一系列问题。用生活化的类比来说这就好比把一家杂货铺升级成连锁超市杂货铺里的货物贴着五花八门的旧标签堆在不同的仓库角落里要把它们全部搬到新超市的货架上重新贴上新标签还得保证账实相符、一个新东西都不能丢、老顾客的赊账记录都得对得上。2.2 数据迁移的完整步骤拆解我当时在方案中把数据迁移拆成了七个步骤每一个步骤都在项目计划里单独列了工时因为任何一步省了后面都会以更大的问题形式找回来。第一步是存量系统盘点。把园区现有的所有系统列一个清单逐一记录系统名称、厂商、版本、数据库类型、数据规模、接口开放程度、部署方式。这一步看起来简单实际做起来很费劲——有些老系统厂商已经联系不上了文档也丢了只能从数据库底层去逆向梳理。我在项目里专门留了两周时间做系统盘点最后发现园区方自己都不完全清楚自己有多少套系统摸底下来一共发现了11套系统比一开始口头说的多了4套。第二步是数据字典梳理。对每一套系统梳理核心业务表结构、字段含义、主外键关系、枚举值含义。比如有的系统里“1”代表男“0”代表女另一个系统里恰好反过来有的系统里“A”代表租户“B”代表业主另一个系统里用数字代表。这些不梳理清楚后面数据一合并就会出大乱子。第三步是映射关系设计。设计源系统字段到目标系统字段的映射规则包括一对一映射、一对多拆分、多对一合并、枚举转换、单位换算。这一步是整个迁移方案中的技术核心。比如老物业系统里停车费按月收新系统里按天计费就需要设计费率换算规则老系统里房屋编号是“3-1-101”新系统里要拆分成楼栋号、单元号、房号三个独立字段需要写正则拆分规则。第四步是抽取策略制定。确定全量抽取还是增量抽取、每晚定时同步还是实时接口级联。老系统还活着的时候一般建议先做全量迁移做历史数据初始化再通过定时任务或者中间库方式做增量同步保证新旧系统并行期间数据一致。第五步是清洗规则落地。包括去重、空值处理、格式规范化、脏数据修正。清洗规则要固化到ETL脚本里不能靠人肉去数据库改否则无法持续维护。比如统一手机号格式、统一身份证校验、统一日期格式为“YYYY-MM-DD”这些都是最基础但最容易被忽视的清洗内容。第六步是迁移演练与数据校验。这一步我特别想说真正有经验的项目组一定会做但很多方案里没写或者写了也是一笔带过。正确做法是先做一次完整的“影子迁移”——把生产环境数据的副本迁移到测试环境在测试环境里跑通全流程逐项核对数据条数、关键业务字段、汇总统计值。校验通过后再在正式窗口中执行真实迁移。迁移完成后还要做多轮业务验证包括租户余额核对、工单历史完整性抽查、车牌号模糊匹配抽样等。第七步是回退预案设计。迁移不是只准成功不准失败的现实里总会出幺蛾子。方案里必须写明如果迁移到一半发现数据严重偏差如何停止迁移、如何切换回老系统、增量数据如何补偿。我在这个环节会要求开发团队提前写好回滚脚本和补偿脚本而不是等到出问题了再临时写。2.3 迁移过程的冲突处理与数据校验迁移过程中最考验方案设计水平的不是正常数据怎么迁而是冲突数据怎么处理。最典型的是主数据冲突。同一个租户在物业系统里叫“某某科技有限公司”在招商CRM里叫“某某科技有限公司老园区”在停车系统里车牌号是京A12345在门禁系统里登记的工牌号又是另一个统一信用代码。怎么确认这三条是同一个企业这个需要在迁移前先做企业主数据治理建立统一的企业信息模型用统一信用代码作为唯一标识通过清洗算法把别名、简称、历史名称全部关联到主数据下。还有一类冲突是权限与角色冲突。老系统里张三是“物业经理”李四也是“物业经理”但两人在新系统里对应的权限范围不同——一个管A区域一个管B区域。迁移的时候如果只迁角色名称不迁数据权限范围后面就会出权限越界或者漏配权限的问题。所以迁移方案里必须包含权限数据的专项梳理把角色、组织、数据权限范围一并映射到新系统。数据校验是迁移能否过关的关键。我在方案里一般设三层校验缺一不可。第一层是数量校验。源表行数等于目标表行数源系统汇总值等于目标系统汇总值。比如老系统里“当前租户数量是387”迁移后新系统里必须是“387”差一条都要追查原因。第二层是关键字段抽样校验。随机抽10%的明细数据做人工比对特别关注金额、日期、状态这类业务敏感字段。第三层是业务场景端到端验证。模拟真实用户的操作路径比如新系统里登录、查工单、提交缴费、生成报表确保业务流程能走通而不只是数据在库里放着。提示数据迁移方案一定要在合同里明确责任边界。我见过一个项目老系统厂商不配合开放数据库权限导致迁移方案一直到实施阶段都无法落地最后靠园区方、集成方、老系统厂商三方开了四次协调会才解决。所以方案里就要写明“老系统接口与数据支持由园区方协调老厂商提供”并且要列到项目里程碑里。3. 核心应用系统与业务模块的建设优先级3.1 IOC智能运营中心智慧园区的中枢IOC在大多数方案里都是最出彩、最吸引眼球的部分因为它是整个园区运营的“驾驶舱”也是领导汇报时的“门面”。我在方案里对IOC的定位是一屏统览、一网统管、一键调度。一屏统览指的不是一个大屏上堆满数据图表而是按角色定制化呈现——决策层看运营总览产值、税收、企业数量、能耗趋势运营层看工单处理与设备状态安全层看实时视频和告警事件。每类用户登录进去看到的东西不一样和传统的“一个大屏所有人看同一个画面”有本质区别。一网统管指的是把所有子系统的运行状态都集中到IOC平台上进行统一的监控和管理。以前安防系统的事件告警在安防大屏上弹能耗告警在能耗管理系统的电脑上弹消防告警在消防控制室弹——现在全部汇聚到IOC这张图上。告警要分级处理消防火警是紧急级自动弹出视频并通知值班员门禁离线是重要级生成工单推送到运维人员手机能耗超阈值是一般级汇总到周报里统一处理。分级处理的目的是避免“所有告警都弹窗”导致真正重要的告警反而被忽略。一键调度指的是应急事件发生时管理者可以在IOC上直接调取对应的预案流程系统按照预案自动下发指令——通知安保人员到场、推送疏散广播、联动门禁打开闸机、切换楼层视频为轮巡模式。这个功能平时用不到但真正发生火灾或者治安事件时能省下黄金几分钟价值不可估量。3.2 智慧安防与智慧通行最高频、也最容易出彩在所有子系统里安防和通行是智慧园区里使用频率最高、展示效果最直接、用户感知最强的两块基本是所有园区方案中的必选项。智慧安防的核心不是监控摄像头多而是AI能力的引入。人脸识别应用在园区入口和重点区域一旦可疑人员出现可以自动比对报警周界入侵检测通过视频算法识别翻越行为比传统红外对射误报率低很多智能视频巡检可以识别人员倒地、车辆违停、区域入侵等事件。这里要特别提醒一点AI算法的效果高度依赖前端摄像头的点位合理性和图像质量点位布得不好、夜间补光不到位再贵的算法平台也是摆设。所以做方案时点位设计一定让算法厂商参与评审不能只让安防设计院拍脑袋定。智慧通行分人员通行和车辆通行两条线。人员通行包括人脸门禁、访客系统、员工考勤。访客系统值得一提——访客通过小程序提前预约审批通过后获得临时二维码或人脸通行权限到访时间到期自动失效。很多园区的访客管理是严格合规要求所以访客系统要和公安要求的访客登记报备打通这个细节在方案里一定要写清楚。车辆通行包括车牌识别道闸、车位引导、反向寻车、共享车位管理等。我这里多说一句地下车库反向寻车是使用率很高的功能但很多园区觉得是“花架子”不做。实际上对员工来说在几千车位的地下停车场里找车是每个月都会发生的真实痛点。方案里加上这个功能对内部用户好感度提升非常明显成本也不算高。3.3 智慧能源与设备运维园区省下来的才是利润如果说安防和通行是“花钱”的模块能源管理就是“省钱”的模块而且省下来的是纯利润。智慧能源的核心是能耗分项计量和精细化管控。在方案里我会设计在每个楼栋、每个楼层、每个租赁单元分别安装智能电表和水表数据实时上传到物联网平台自动生成分项能耗报表。哪栋楼用电异常、哪家租户用水波动、空调系统能耗占比多少一切尽在掌握。能源管理做深一层就是节能策略。比如根据室外温度和光照度自动调节空调机组运行参数根据人员密度自动调节公共区域照明亮度根据分时电价自动调节充电桩充电时段。这些策略看起来不复杂但落地后节能率通常能到10%到20%两三年省下的电费就够回收整个智慧园区系统的大部分投资。设备运维模块的重点是设备资产台账数字化和预测性维护。每台重要设备在平台上有独立的电子档案——厂商信息、维保记录、配件更换历史、运行参数曲线。设备联网以后传感器实时监测运行状态比如电梯的振动频率、水泵的电流波动、空调机组的压缩比一旦偏离正常区间系统自动发出维修工单而不是等到设备“罢工”了才报修。我参与过的一个项目就是因为这套预测性维护机制把一次潜在的水泵烧毁事故提前三天排查出来了业主后来专门在验收会上表扬了这个点。4. 实施路径、组织保障与成本预算4.1 分期建设先建什么后建什么智慧园区项目的实施最忌讳的是“一口吃成胖子”。一次建设贪多求全不仅预算压力大而且实施周期拉长以后前期建好的模块可能已经过时后期模块还没上线整个项目变得非常被动。我常用的分期策略是一期打底座二期上应用三期做增值。一期建设重点放在基础设施和平台底座。包括网络改造升级、物联感知设备的基础铺设水电表、烟感、摄像头、物联网平台和数据中台搭建、IOC基础框架上线。一期建完园区至少具备“数据采得上、传得回、存得住、看得见”的能力。二期建设重点放在高频刚需应用。包括智慧安防、智慧通行、智慧物业、智慧能源这四类业务系统都是日常运营每天都离不开的。这四套跑起来以后园区已经从“能看到数据”上升到“能用数据管业务”了。三期建设重点放在产业服务和增值应用。包括产业招商分析、企业服务超市、政策匹配推送、产业地图、智慧楼宇精细化控制等。这一阶段的应用更偏软性、偏增长型投入相对少但对园区的招商引资和企业留存有很大帮助。为什么会采用这个节奏核心逻辑是先让项目产生看得见的短期价值再循序渐进铺开。一期底座是后面所有应用的地基二期应用解决最痛的日常运营问题让使用者真正感受到系统替代人工的价值三期增值则顺应招商运营需求自然延展。这种节奏能有效控制风险、保障验收效率对甲乙双方都是一个相对稳定的推进节奏。4.2 组织协调比技术更难的往往是人的问题做智慧园区项目久了我最大的感受是技术方案再复杂都赶不上人的配合问题复杂。一个园区项目涉及的干系方至少有园区管理公司的领导层、信息部门、物业部门、安保部门、招商部门、财务部门再加上施工方、各子系统厂商、运营商、设计院。这么多角色每个人对智慧园区的理解、诉求、配合意愿都不一样。在方案里我会专门用一整页来写“组织保障与实施协同机制”核心要点包括三个。第一是成立联合项目组园区方指定一名项目负责人集成方指定一名项目经理双方定期开例会、写周报、对里程碑。没有这个机制协调全靠临时沟通项目十有八九延期。第二是明确需求确认流程。智慧园区项目最怕的就是需求无限蔓延业务部门今天提一个想法明天提一个需求。我会在方案里明确需求变更流程所有新需求必须填写需求变更单评估工时和费用后由项目决策委员会审批。这一步看着像“走流程”实际上是对项目范围最有力的保护。第三是重视使用部门培训。系统建得再好使用部门不认可、不会用项目验收就是“形式上通过、实际上空转”。方案里要把培训计划列为正式交付物明确培训次数、培训对象、考核方式和上线陪跑期时长。我一般会在上线后安排至少一个月的“陪跑期”技术人员驻场或者远程值守帮助运营团队逐渐适应新系统。4.3 预算结构一份可参考的软硬投入比例很多园区管理者问的第一个问题是“这套系统大概多少钱”。说实话这个问题没法一句话回答因为园区规模、现状、需求深度差异非常大。但经验上有个大致的预算参考结构可以分享。以一座10万平方米的产业园区为例智慧园区系统总投入通常在1000万到3000万这一档。其中硬件设备费用含摄像头、传感器、门禁道闸、网络设备等约占40%到50%软件平台与开发实施费用含物联网平台、数据中台、应用开发、系统集成约占35%到45%剩下约10%到15%是设计咨询、项目管理、培训运维等费用。很多园区管理者对“软件为什么这么贵”不理解觉得软件不就是“写代码”吗我一般会解释一套数据中台要兼容园区已有的10套异构系统的数据每个对接都是开发量和测试量光异构系统对接联调可能就要占软件费用的三成以上。而且软件需要持续迭代不是一次性交付就结束了。所以预算里我还会建议留出一块“年度运维与迭代费”一般按项目总额的8%到12%每年计。这部分钱不能省——省了运维费系统过两年就变成了“僵尸系统”。5. 方案落地中的避坑经验与关键细节5.1 选型时的隐藏标准不是设备越贵越好接口开放性比什么都重要做智慧园区方案必然要面对选型题摄像头选哪个牌子、物联网平台选哪家、道闸选哪家、门禁选哪家。不少园区管理者倾向于选“大牌”、选贵的设备但实际项目里我踩过最大的坑是设备和平台的接口开放性不足。举一个真实案例。我在一个园区项目里道闸厂商的合同里写的是“提供标准协议对接”结果进场实施时才发现所谓的“标准协议”其实是厂商私有的SDK只支持他们自家平台要实现对接第三方平台需要额外购买“开放接口授权”报价好几万。更麻烦的是这家厂商务服团队响应非常慢每次联调都要排队等排期。后来我们总结了一条教训——在招标文件里就要明确“所有设备必须支持标准协议ONVIF/GB28181/MQTT/Modbus等必须提供开放API接口文档必须配合第三方平台联调”这些条款写进合同才能约束厂商。所以选型环节不要光看参数表要单独做一个“接口开放性评审”。让各厂商提供接口文档样例、联调案例、REST API列表评估他们的平台是否真正支持第三方集成。这套评审做完后面系统集成阶段能省一半的扯皮时间。5.2 网络规划设计智慧园区最容易返工的地方网络是智慧园区的基础但也是方案里最容易被低估、实施中最容易返工的地方。我遇到过不止一个园区前期网络规划只考虑了办公网络结果实施到一半发现视频监控需要独立的视频专网或VLAN隔离否则占用办公带宽物联网终端的接入协议很多走LoRa/NB-IoT需要单独部署网关安防系统按等保要求必须物理或逻辑隔离不能和办公网混在一起地下管廊和电梯井内需要专用网络覆盖普通Wi-Fi根本穿不透。这些问题返工起来代价远超前期规划成本。所以我在方案里会有专门的网络规划章节按“办公网视频专网物联网专网”三网隔离来设计同时考虑5G覆盖补盲和骨干环网冗余。平面图上每个点位都要标注清楚接入方式——是走光纤直连、走交换机级联、还是走无线AP。这块图纸可能需要反复修改三四轮但每一轮修改都是在给实施阶段省钱。5.3 数据安全合规从立项就要纳入方案数据安全在智慧园区项目里越来越重要而且这是一块硬性合规要求。方案里至少要覆盖三个层面的安全设计。第一是系统安全。按照网络安全等级保护要求设计安全防护体系包括防火墙、入侵检测、日志审计、漏洞扫描等。绝大多数园区需要按等保二级做有政务数据交互的可能要按三级做。等保测评费用要预先列入预算项目验收时测评报告往往是硬性交付物。第二是数据安全。包括数据传输加密HTTPS/国密算法、敏感数据脱敏身份证号、手机号、数据库访问权限控制、数据备份与灾备。尤其是视频监控数据的存储与调用权限现在的要求越来越严格方案里必须明确存储期限、调阅审批流程和操作留痕机制。第三是系统间的访问安全。智慧园区平台要和政务平台、公安平台、消防平台等外部系统对接时必须走安全边界设备通过专线或者安全数据交换平台完成数据交互。这块在方案阶段就要和相关主管部门确认技术接口要求不要等项目上线了再去申请审批周期可能长达数月。5.4 关于75页PPT方案文档的正确用法和下载建议写到最后回应一下标题里“75页PPT”这个事。很多人拿到一份几十页的方案PPT第一反应是从头翻到尾结果看到一半就看不下去了觉得内容“虚”。其实成熟的方案PPT它的价值主要在于结构化呈现思路和关键决策点而不是提供完整的施工蓝图。我在拿到这类PPT时通常会按照“看架构、看数据流、看接口、看分期”的顺序来读先总览整体架构图理解建设思路然后找数据流向和接口清单判断集成风险最后看分期计划和预算结构评估落地可行性。具体到每个子系统细节、每张数据表结构那是深化设计阶段的事情不在方案PPT的范畴里。很多这类“附下载方式”的资料包给出的下载渠道五花八门。我自己建议通过三类渠道获取一是行业解决方案平台例如此前许多从业者常用的行业方案分享站点二是厂商官方的案例方案库三是行业社群中转来的最新版本。不管从哪里下载下载后第一件事应该是看页脚和版本日期——方案这类文档更新频率很快用错了版本做汇报被领导问住某个细节答不上来是最亏的处境。5.5 我踩过的坑甲方技术和业务“两张皮”这里分享一个非常普遍的坑。很多园区项目推进到一半陷入僵局原因不是技术做不出来而是甲方内部技术与业务“两张皮”——信息部门提需求物业部门和安保部门不参与系统做出来以后使用部门觉得“这不是我要的东西”拒绝使用。我现在的做法是在项目启动初期就要求把各业务部门的关键用户拉进项目组在需求调研阶段进行多轮面对面访谈让使用部门提真实诉求而不是只听信息部门的转达。每次原型评审会会让门卫代表、物业主管、客服主管实际操作原型界面当场收集意见。听上去多花了一点时间但对比系统上线后大面积返工、使用部门抵触带来的损失这点前期投入非常值得。另一点就是方案中永远要有一条“最小可行路径”。不管是多宏大的智慧园区蓝图我在汇报时一定会强调哪一块投入最省、见效最快、最能打动使用的人。通常我会建议聚焦在高频刚需模块先打出一个样板标杆让园区切身感受到系统带来的改变后续的分期建设推进会顺很多。方案可以做得很全面但下手一定要聚焦。做了这么多年智慧园区项目我个人最深的一个体会是智慧园区方案真正比的不是谁的技术名词更花哨而是谁更懂园区管理的真实痛点谁能把数据的“毛细血管”和业务的“主干神经”真实打通。尤其是数据中台建设与异构系统整合这往往是整个项目里技术含量最高、踩坑最多、也最容易被外行低估的一部分。希望这篇拆解能帮你把这件事看得更透即便你拿到的PPT只有75页也能顺着这条主线撑起一个能落地、能验收、能真正产生价值的智慧园区项目。