企业官网建设流程全解析

做水利数字化这几年，我越来越觉得一个尴尬：行业里不差数据，差的是把数据“用起来”的能力。水文站、雨量站、水质监测点、视频监控，一年下来数据量惊人，但大多数时候这些数据只是躺在数据库里，被报表和曲线消耗掉。真正遇到暴雨洪水，调度人员还是靠经验拍板，系统给不了“如果这样调度会怎样”的答案。数字孪生这个概念的走红，恰好戳中了这个痛点——把物理流域完整映射到数字空间，不但能看，还能算、能试、能推演。这篇文章我结合自己实际参与的项目经验，讲清楚数字孪生水利到底怎么落地，从架构选型到建模实操再到常见坑点，尽量给你一套可以直接参考的路径。

不是说建个三维大屏就叫做数字孪生。我见过太多项目，花大价钱做了漂亮的可视化场景，结果数据不联动、模型算不动，业务人员看两眼就再也不开了。真正的数字孪生，核心在“孪生体”这三个字上——数字空间里那个虚拟对象，能不能真实反映物理对象的状态，能不能基于当前状态推演未来，这才是衡量项目好坏的标尺。这篇文章适合正在做智慧水利、数字孪生流域项目的技术人员，也适合负责项目立项的管理人员，至少让你知道钱该花在哪儿、哪些环节最容易翻车。

1. 数字孪生到底解决了水利行业的什么痛点

1.1 水利行业的老问题：数据有，但“算”不出来

水利行业和别的行业有个明显区别——天然就是“空间型”业务。一条河流流经几十个县，上下游之间有物理联系；一座水库拦蓄洪水，作用范围覆盖下游整个防洪保护区。这种强空间关联性决定了水利决策不能只看单一断面数据，必须把全流域放在一起统筹。传统信息化系统恰恰在这个环节最薄弱。

过去十年建的水利业务系统，大多遵循“采集-传输-存储-展示”的套路：数据通过遥测终端传到中心站，中心站做入库处理，然后生成各类统计图表。这套模式解决的是“数据看得见”的问题，但回答不了三个关键问题：当前流域整体态势如何？未来几个小时到几天水情怎么变化？采取某种调度方案后结果会怎样？

第一个问题勉强能用GIS加图表回答，第二个问题依赖专业水文预报模型，第三个问题基本没有系统能解决。数字孪生把这三问统一到一个框架里：数字空间里有完整的水系、工程、地形、气象要素，有实时数据不断更新孪生体状态，有专业模型在后台持续计算，有业务系统把计算结果变成调度建议。这个框架的本质不是可视化，而是“可计算”。

1.2 数字孪生体的核心组成：不是一个三维模型那么简单

很多人把数字孪生等同于三维建模，这是最大的认知偏差。水利数字孪生体由四个部分组成，哪一块缺了都会导致项目变味。

第一部分是几何模型，也就是看得见的那些东西：河道地形、堤防、水闸、泵站、水库大坝、泄洪洞，全部按真实尺寸和位置在三维空间里重建。这里有个容易被忽视的细节：水利工程的几何模型不只要“像”，还要能和计算网格对接。精细的三维景观模型往往有上百万个三角面，但水动力计算需要的是规整的网格，两者之间需要一套映射机制。做项目和做效果图的不同就在这儿。

第二部分是数据模型，也就是孪生体的“状态”。水位、流量、雨量、水质、闸门开度、机组运行状态，这些实时数据像血液一样让孪生体活起来。数据模型的关键在于统一编码和时空基准——同一个监测点，在数据库里叫“XX站”，在三维场景里叫“XX断面”，在模型计算里叫“XX节点”，如果三个名称对应不起来，点位映射就崩了。

第三部分是计算模型，这是数字孪生和三维可视化的分水岭。水文模型用来算产汇流，给出各控制断面的来水过程；水动力模型用来算洪水演进，给出淹没范围和到达时间；调度模型用来优选出库流量，给出闸门操作建议。计算模型把物理规律固化下来，让孪生体从“看起来像”升级到“算起来也像”。

第四部分是业务规则，也就是调度规程、预警指标、应急响应流程这些“人为逻辑”。没有这层逻辑的数字孪生只是计算器，有了它才算真正参与到业务决策里。比如汛限水位是多少、超警流量是什么级别、不同量级洪水对应什么响应措施，这些规则必须与模型计算联动，才能让推演结果服务实际调度。

1.3 为什么是现在：算力、数据、建模三件事凑齐了

数字孪生水利不是什么全新概念，早在2010年前后就有研究机构做流域三维可视化试点，但当时做不出真正意义的产品。原因很直白：第一，算力不够。洪水演进模型动辄需要解数千个网格点的方程组，传统服务器跑一遍要好几个小时，做不到“实时推演”。第二，数据太薄。雨量站、水文站密度不足，卫星遥感数据精度不够，涔涔的数据撑不起一个像样的分析模型。第三，建模工具门槛高，三维建模和数值模拟是两套技能栈，能把两者打通的人极少。

这几年情况全变了。GPU算力让三维渲染场景能达到交互级帧率，高精度地形数据（比如全国范围的5米分辨率数字高程模型）让流域地形重建的成本大幅下降，IoT技术让监测设备布设成本降低了一个量级，再加上Unity、UE等商业引擎越来越成熟，大量开发资源可以直接复用。更关键的是，国产水动力模型这几年进步明显，像OpenTELEMAC-Macarte这类开源模型、以及国内一些自研模型系统的可用性已经能支撑业务。

这三件事凑齐之后，数字孪生才从“演示品”变成“生产工具”。但工具归工具，能不能用出效果，还得看架构设计和实操水平。接下来我就重点讲怎么搭这个系统。

2. 水利数字孪生系统的整体架构与技术选型

2.1 数据底板：从水文站、雨量站到卫星遥感

数字孪生水利系统的底座是数据，数据不全或者不准，上层模型和场景全部白搭。我习惯把数据底板分成三个圈层来设计。

内圈是工程运行数据。大坝的安全监测数据（渗压、位移、扬压力）、闸门开度、泵站机组状态、水库水位、出入库流量，这些数据频率高、实时性强，通常通过SCADA系统或者RTU遥测站直接采上来，走专网进数据中心。这类数据的特点是“脏”——传感器漂移、通信中断、异常跳变是常态，必须做实时质量标记和清洗。

中圈是流域监测数据。雨量站、水文站、蒸发站、水质站，这些由国家基本水文站网和地方补充站网组成。数据频率通常5分钟到1小时不等，通过北斗短报文、4G/5G、自组网等方式回传。这里要注意的问题是站点密度——有些西部河流上百公里才有一个水文站，模型参数率定的基础数据严重不足，这种流域做数字孪生时模型可信度会大幅下降。

外圈是空间地理信息。数字高程模型（DEM）、河网水系、土地利用、土壤类型、植被覆盖，以及卫星遥感反演的水体范围、土壤湿度等产品。外圈数据不追求高频，但追求“精准的空间基准”。地形是水动力计算的根本输入，如果DEM的精度和现势性不行，后面算出来的淹没范围就没什么参考价值。

三个圈层的数据在数字孪生底座里要完成统一时空化处理，也就是全部转换到同一套坐标系和时间基准下。水利行业目前主流用2000国家大地坐标系（CGCS2000），高程基准用1985国家高程基准。新建系统还好说，麻烦的是老站点的数据——很多早期遥测站点用的是54北京坐标系和56黄海高程，差几厘米到几十厘米，做精细淹没分析时这个误差必须处理掉。

2.2 模型平台：水文模型、水动力模型、调度模型怎么配合

模型平台是数字孪生水利系统里最核心、也最难做好的部分。它不是运行一个模型，而是让多个模型按照业务流程协同工作。

降雨产流环节用分布式水文模型。以降雨为输入，通过下垫面特征（地形、土壤、植被）和各水文单元的产汇流参数，算出每个子流域的流量过程。比较常用的有SWAT、HEC-HMS，国内还有不少单位基于新安江模型做了分布式扩展。这个环节的关键在于率定——不是装上模型就能跑，要用历史洪水过程反复校准参数，直到模型能复现出真实的流量过程线。

河道演进环节用水动力模型。以水文模型的输出作为上边界条件，结合河道断面的地形资料、糙率参数、水利工程的调度约束，求解圣维南方程组，得到各断面的水位、流量过程。行业里常用的是HEC-RAS、MIKE系列、以及开源方案里江河模型和OpenTELEMAC-Macarte联合使用。水动力模型计算量大，做实时预报时往往需要降维处理——要么用一维模型代替二维三维，要么预先算好不同量级洪水的淹没场景库，实时用查表方式快速响应。

工程调度环节用调度模型。以水动力模型的预报结果为基础，在防洪、兴利、生态、发电等多目标之间寻找平衡，输出推荐的出库流量、闸门操作方案。调度模型可以是基于规则驱动的专家系统，也可以引入优化算法找最优解，但实际项目里我倾向于先做规则驱动，因为调度规程是主管部门认可的合规依据，优化算法算出来最优解未必能过审批这一关。

三个模型串联起来，才能形成“降雨-洪水-漫滩-调度”的完整计算链。数字孪生系统的价值集中体现在这一层：过去调度人员看的是几条河段的监测曲线，现在看到的是整条流域在未来几天的完整演化过程。

2.3 孪生引擎选型：Unity、UE还是自研，关键参数怎么比

孪生引擎是承载三维场景和交互功能的底座，选型直接影响开发效率、场景性能和后续扩展。我接触过不少项目，用Unity做水利数字孪生的占多数，UE4/UE5做大体量场景的也在变多。两者怎么选，主要看四个维度。

第一是场景规模和数据精度。UE在大地形、高逼真度渲染上有明显优势，Nanite虚拟化几何技术能直接处理上亿三角面的高模，配合Lumen全局光照效果很好，适合做流域级大场景。Unity这边地形系统相对轻量，小范围工程场景（一个枢纽、一座大坝）效率很高，加载速度和内存控制更省心。

第二是团队技术栈。Unity的C#开发上手门槛低，人才储备大，项目进度容易控制。UE的C++蓝图体系功能强但复杂度高，团队里需要至少一两个引擎底层熟手。小团队做快速交付，Unity往往是更稳妥的选择。

第三是数据对接能力。水利数字孪生离不开GIS数据：地形切片、倾斜摄影、影像贴图、空间分析结果都要在场景里表现。Unity有比较成熟的GIS插件生态（比如Mapbox、SkylineGlobe for Unity），UE在GIS领域主要靠第三方插件实现，整体成熟度略逊。

第四是业务功能复杂度。如果系统主要是监测展示加简单交互，Unity足够。如果要加复杂物理模拟、海量粒子效果、或者做高保真度的虚拟仿真实训，UE更有优势。

下面这个表是我做选型时的对比基准：

我们曾经做过对比测试，同一片流域范围，用UE加载高精度地形，启动时间比Unity多将近一倍，但水面反射、植被风动等视觉效果明显更好。做面向公众展示的系统用UE合适，做日常调度业务系统还是Unity更务实。另外有些项目需要把三维场景嵌入已有的Web业务平台，这时候还要兼顾Web渲染方案，比如用CesiumJS做轻量场景，把Unity或UE的场景通过视频流推送到Web端。

2.4 确定性预报与方案预演，如何串成业务闭环

架构设计得再好，落地到业务里也要看两条主线跑不跑得通：一条是确定性预报，一条是方案预演。

确定性预报就是基于实时监测数据，让模型算出“大概率会发生什么”。这一环的关键词是“自动”。雨量数据到了，模型就自动起算，算完自动更新预报结果，调度人员打开系统看到的永远是当前工况下最新的来水预测。要撑起这个“自动”，需要一套任务编排调度框架，把数据接入、模型计算、结果入库、场景更新这些环节串成流水线。

方案预演则是回答“如果这么做会怎样”。调度人员输入一个出库流量方案，系统立刻算出来下游断面的水位变化过程、淹没范围、影响人口。这环节对计算性能的要求很高，因为用户点的每一步操作都要在几秒到几十秒内返回结果。实操中最常用的做法是预计算加插值：把典型调度方案提前算好存入场景库，实时操作时在场景库里做快速匹配，必要时才触发实时重算。

确定性预报和方案预演连接在一起，就形成了完整的调度决策闭环：监测数据驱动预报，预报结果叠加方案预演效果，调度人员对比多个方案的后果后确定最终方案，系统再联动闸控执行。数字孪生在这个闭环里起到的是“数字实验室”的作用——把调度决策从“经验判断”升级为“预演验证”。

3. 实操过程：从数据接入到业务功能上线的完整流程

3.1 第一步：确定对象边界和数据清单

数字孪生不是一上来就建模，而是先做需求边界划定。这个“范围”如果不清，项目十有八九会失控。

比如做一个水库的数字孪生，至少要明确四个层面的范围：空间范围（上游控制流域面积、库区、下游影响河道）、工程范围（大坝、溢洪道、泄洪洞、电站等建筑物）、业务范围（防洪调度、兴利调度、大坝安全监测、闸门控制）、数据范围（哪些数据源能接、哪些还缺、哪些精度不够）。

我建议在项目启动阶段用一张《数据资源清单》把这事定下来。表格里至少包含：数据类别、数据源名称、责任单位、当前可用性、数据频率、数据传输方式、数据精度、是否满足建模要求。有一说一，这个清单填完，项目的工作量估算基本就准了，风险点也浮出水面了。

有些项目开发阶段才发现某个关键雨量站的数据根本接不出来，只能临时找替代方案，工期和预算全被拖垮。数据清单的意义就是提前把这些雷排掉。

3.2 第二步：数据治理与三套坐标系对齐

数据接入系统之后，第一件要做的就是数据治理。水利数据的历史包袱很重，同一个测站可能在不同系统里有不同的编码，同一个数据项在数据库里的单位可能是米也可能是厘米。这些不一致必须在数据底座的入口层解决，方式是在源头就做标准化。

我们通常的做法是建一张主数据字典：所有监测项按统一编码命名，站点的经纬度统一转换到CGCS2000，水位高程统一到1985国家高程基准，时间字段统一到北京时间并标注时区。这样一套字典建好之后，整个系统从上到下就只用这一套“语言”交流。

三套坐标系对齐是个实操感很强的问题。三维场景用的地理坐标系、监测数据引用的独立高程系统、工程图纸里的施工坐标，三套体系经常并存于一个项目。做场景搭建时，必须先把工程建筑物的CAD图纸在空间上准确定位到DEM地形上，否则就会出现建好的大坝飘在河面上、闸门和水尺错位的低级事故。这个过程没有太多捷径，就是逐个建筑物核对坐标转换参数，然后人工在场景里目验。

水位-库容曲线是水库类数字孪生项目里最关键的基础数据。它由库区地形计算得出：每给定一个库水位，查出对应的库容。实际工作中我们常遇到的情况是，设计阶段的曲线和实测地形反演的曲线对不上。我的建议是以实测地形为准重新计算。这个数据的误差直接影响调洪演算结果，属于“源头错、全链错”的高风险数据。重新计算的方法很简单：用GIS工具把设计水位以下的DEM地形抽出来，按库区范围逐层统计分析不同水位高程下的面积体积，累加出整条水位-库容曲线，再和设计手册里的曲线对比验证。别嫌麻烦，这步做好，后面专家评审的时候你能少挨很多骂。

3.3 第三步：流域建模与场景搭建的关键参数

几何建模环节，最关键的不是“像不像”，而是“准不准”和“算得快不快”。

地形场景的搭建，第一步是把DEM数据导入引擎。拿到手的数据如果是栅格格式，要检查分辨率和坐标系，范围不够的要补充数据源。地形导入后设置垂直拉伸系数，让高差变化足够明显，同时避免过度夸大导致视觉失真。水利场景里常见的是河流水面与地形之间的衔接缝隙，处理方法是统一水面高度数据源，让水面严格贴合监测点位的高程值。

三维模型方面，大坝、闸门、泵站这些核心建筑物建议用BIM数据直接导入。如果BIM模型精度太高导致场景卡顿，需要做减面处理。我们实际项目中为了性能平衡，会在主视角区域保留高精度模型，远处用简模拼接。植被、建筑、道路等环境要素没必要手工摆放，用程序化生成配合真实地理数据约束，效率会高很多。

水位仿真这一块的水面效果，引擎自带的物理材质系统可以处理。关键是要给水面一个动态变化的外部驱动——从数据接口实时拿到水位值，驱动水面模型的透明度、折射和波动参数。不同水位下的河岸浸没范围，要配合地形高程实时做顶点偏移，才有真实的涨落水效果。

3.4 第四步：模型配置、参数率定与系统集成

模型平台的建设是硬骨头。以常用的一维水动力模型为例，按以下步骤配置。

构建河道断面数据。从实测大断面资料提取每个断面的位置、河底高程、左右岸堤顶高程、糙率初值。断面间距可以按变化程度调整——地形变化剧烈的地方断面加密，平顺段适当放宽。断面数据的质量直接决定模型底线。

设置边界条件。上边界输入上游来流过程，下边界设置为水位-流量关系或实际控制断面水位。对于入库洪水预报，上边界直接耦合水文模型的出口断面流量。支流汇入的地方要注意对齐数据时序。

率定泥沙糙率。这一步没法绕开人工经验。拿几场历史洪水数据，调整河道糙率和局部阻力参数，让模型复现的水位过程线与实测吻合。率定目标通常是使水位过程线的峰值误差不超过0.2米，峰现时间误差不超过半小时。

实时预报系统的接口联调和模型滚动更新是落地的关键。水位、流量数据每5分钟到达一次，模型按小时滚动更新一次，每次更新要能自动完成数据装载、边界更新、模型重算、结果归档。这层自动化的稳定性，是项目交付后运维部门最看重的点。

系统集成是数字孪生平台项目的主要工期消耗点。三维引擎、模型计算服务、数据库、消息中间件、Web业务门户要全部连通。这里我建议在架构上把模型计算和三维场景解耦，模型服务单独部署成微服务，通过消息队列向场景端推送计算结果。三维场景主要承担展示和交互，模型计算不因场景卡顿而阻塞。

3.5 第五步：业务功能开发与部署，重点在预警与预案

水利数字孪生系统的业务功能，大致可以分为监测展示、预报预警、调度预演、应急推演、日常管理五类。

监测展示是最容易出效果的部分，数字大屏、三维沙盘、领导驾驶舱都是这类。值得强调的是，展示功能不能只有视觉冲击力，数据必须实时联动真实，否则就是个空壳。预报预警功能要把模型计算结果和预警指标结合起来，指标超限就自动在场景中高亮风险区域、弹窗提示并推送责任人。调度预演功能让调度员在三维场景里调整闸门开度，实时查看库水位和下游水位的响应。应急推演功能设置不同量级的洪水场景，模拟溃坝、漫堤、分洪等极端工况，输出淹没范围和影响人口统计结果。

在这些功能里，异常工况下的场景表现最考验开发功力。比如模拟溃坝洪水，需要在场景里实时渲染洪水波传播过程，配合水动力模型的计算结果，动态更新淹没范围。我们做这类功能时，需要将模型输出的淹没栅格数据实时映射成三维场景中的漫滩水体，通过材质变化和顶点动画来表现洪水推进的势能感。数字孪生项目坍塌往往是场景做得极其华丽、模型算得极其专业，但两者互不联系——模型结果没有驱动场景变化，场景里的水只是动画循环，跟物理世界毫无关系。这类“假孪生”才是项目交付时最容易被打回票的硬伤。

部署环节建议采用双活架构。中心机房承载模型计算和数据库，边缘节点部署于工程现场，负责数据采集与轻量场景渲染。网络中断时边缘节点能够独立运行基础业务，数据恢复后再回传中心做补录。水利现场通信条件千差万别，有些坝区到了汛期通信信道紧张，没有边缘自洽能力，系统就会成为摆设。

4. 常见问题与排查技巧实录

4.1 问题一：三维场景与监测数据对不上

这是最常见的问题，表现是：监测数据显示当前水位是720.5米，三维场景里的水位模型却明显不在对应高度。

排查步骤：

1. 核对坐标基准。监测数据用的高程基准是否与场景一致，常见的坑是56黄海高程与85国家高程混用，两者存在约0.1米的系统差。
2. 检查监测点位关联。确认水位数值关联到正确的断面和模型对象，点位编码映射配错的情况非常频繁。
3. 检查引擎垂直拉伸系数。场景为了视觉效果会放大高度比例，如果拉伸系数设置成1.5倍，水位高度也会被连带放大。
4. 确认数据链路延迟。实时数据从遥测站到场景端如果经过多级转发，可能有一两分钟的延迟，在水位快速变化时会产生明显偏差。

实际项目中，最终原因多半是系统菜单的水位比例设置被改了。维护人员在优化视角时调了垂直拉伸，从0.8改成1.8，结果水位全部“涨”了一倍多。这种事情不成文但真实存在——场景参数必须锁定，不能给业务维护人员开放权限。

4.2 问题二：雨量站数据缺失导致预报结果失真

分布式水文模型对雨量输入极度敏感。一次流域性降雨过程，上游某个雨量站若停止上报数据，模型的产流计算就会低报甚至漏报。

我遇到过这样一个真实场景：主雨带的一小时强降雨刷屏，模型却报出下游洪峰流量远低于实测值。检查下来发现，是上游3个关键雨量站通讯模块故障，数据滞留在了遥测终端里。问题不出在模型，而出在数据链路。此后我们的系统增加了“数据完整性守卫”模块：一旦发现参与计算的关键站点数据超出上报时限，立即标记数据不可信，并触发备用数据源或插值补充，同时给值班人员推送告警，让人工介入判断。

4.3 问题三：模型参数率定“拟合了历史，跑不赢未来”

历史洪水率定出来的模型，在下一次洪水来临时往往并不完全吻合。原因不复杂：流域下垫面会变化，河道糙率在植被生长、淤积、冲刷作用下也是动态的；气候变化让降雨时空分布特征也在悄悄改变。把模型参数固化一成不变，预报结果必然偏差。

解决思路是让模型参数“滚动更新”。每次洪峰过后，把实测数据并入率定样本，用最新样本重新校准关键参数。同时为不同量级洪水准备多套参数方案——大洪水时河道糙率被冲刷变小，参数和小洪水是不同的。我们在生产系统里就配置了三套参数档位，按当前来水规模自动选择，预报精度明显提升。

4.4 问题四：二维调度图与三维沙盘数据不一致

水利业务日常依赖二维GIS调度图，上面有实时水情、雨情、工情标签，调度人员习惯了这套平面化表达。三维沙盘出来以后，经常出现两边数据对不上：二维图显示蓄水量1亿方，三维场景显示8500万方。原因往往是两个系统的数据源没有打通——二维图读取的是业务数据库的实时表，三维系统读取的是历史记录表或模拟推演结果，两者相差了天然的时间差。

统一数据出口是解决办法。所有图表、场景、报表只允许从一个数据服务读取当前时刻全量数据，数据更新统一通过消息推送，保证各个展示端的数据版本一致。调度人员看到二维和三维数据打架，信任感流失了再想找回来就很难。

4.5 常见问题速查表

4.6 补充一个容易被忽略的小坑：系统时钟同步

水利数字孪生系统里涉及的监测设备、模型服务、数据库分布在不同节点，时钟如果不一致，数据时序就乱了。曾经遇到过遥测站时间漂移，上报的雨量数据比标准时间慢了15分钟，模型按时间戳去算产流，雨洪过程怎么都对不上，排查了整整一个工作日。排查手段是把同一断面不同来源的数据时间戳拉出来对比，发现差了一个固定的时间偏置。之后所有接入的设备和服务器一律做NTP时钟同步，并在数据接入层增加时间偏置校验，凡超过30秒的时间误差全部标记告警。

5. 我的一些真实体会

做水利数字孪生项目，表面上是技术活，实际上三分技术、七分认知。有几个体会写出来，给后来者参考。

第一，数字孪生项目别从可视化切入，要从业务场景切入。很多项目汇报起来是“我们做了一个大的三维场景”，听起来气势恢宏，但问一句“调度人员日常依赖它做什么”，答不上来。靠谱的路径是先找业务痛点——防汛值班最怕什么、调度决策最纠结什么、预案编制最耗时的是什么——再决定用数字孪生技术如何解决。先有用再好看，顺序不能反。我参与过的项目里，领导检查时最常问的最逼问的问题就是“数据准不准、能算什么、推广有什么变化”，这而问题的回答，拼的是业务逻辑和数据底座，不是渲染效果。

第二，数字孪生项目要持续运营，而不是交付即止。模型要滚动率定、数据引擎要持续接入新数据源、场景要随工程改造而更新、规则要随调度规程修订而调整。这些没有专门的运维团队长期跟进，系统衰退的速度会远超想象。建议在一开始就把运营费用和团队编制纳入规划，而不是只做“一次性建设”预算。

第三，数字孪生的边界要克制。不是流域里所有东西都要建到孪生体里，不是所有业务都要推倒重来，也不是所有决策都交给模型来做。数字孪生的定位应该是“参谋部”，给决策者提供更多、更准、更直观的判断支撑，最终拍板的是人，这个边界守得住，系统才能获得信任。数字孪生技术底座也在不断进化，因为工作关系我也接触到更多行业场景的拓展应用，包括工程训练、以及工控类小型场景的虚实联动等，思路和水利其实是相通的——把同一套数据驱动、模型推演、实时交互的方法论，适配到不同的业务对象上。先把水利这一个行业做透做强，这套方法论自然能外溢到更多领域。