干了七八年智慧城市和市政信息化项目我发现“智慧管网”这四个字甲方喊了很多年真正落地却没几个。要么被做成一块中看不中用的大屏要么被集成商堆了一堆传感器数据躺在系统里睡大觉。最近我在整理一套92页的智慧管网综合管理平台建设方案把里面那些能落地、能打动甲方、也能扛住实施周期考量的东西抽出来聊一聊。这套方案涉及管网的感知监测、GIS一张图、视频联动、应急指挥覆盖供水、排水、燃气、热力等多类管线对做智慧城市、智慧园区、市政数字化的朋友或者甲方信息化部门准备立项的朋友都有参考价值。这篇不整虚的直接说方案怎么设计、关键技术怎么选、踩过哪些坑。1. 智慧管网项目到底在解决什么问题1.1 管网管理的三大痛点看不见、连不上、算不清很多没接触过现场的人以为管网管理就是看几张图纸。实际上市政管网和园区管网的日常管理长期被三个问题折磨。第一个是“看不见”。地下管线都在地底下隐蔽性强老城区尤其严重。很多单位手里只有纸质竣工图还是几十年前的管位、埋深、材质、阀门位置全靠老师傅脑子里的记忆。我见过不少项目施工前挖探坑挖不到管线就按图施工结果一铲子下去把燃气管挖断了周边几万居民停气。这种事故几乎每年都有核心原因就是管线“看不见”。所以智慧管网平台第一个要解决的就是把地下的东西搬到“一张图”上让人能看见、能查。第二个是“连不上”。管网上的压力计、流量计、液位计、水质分析仪、气体探测器大多嵌在泵站、阀门井、检查井、调压站这些地方由不同厂家生产通讯协议五花八门。有的数据在PLC里有的在SCADA系统里有的干脆靠人工抄表一个月抄一次。数据分散在各处没有一个统一的平台汇总想分析漏损、预测爆管根本无从下手。这就是典型的“数据孤岛”。第三个是“算不清”。就算有了数据如果只是把数字显示在屏幕上那也只是从“看不见”变成“看得见”离“管得好”还差得远。真正的智慧管网要能干三件事一是对实时监测数据做异常判断比如压力骤降、流量突变它能报警二是结合历史数据和管网拓扑做分析比如哪一段管龄老、腐蚀严重应该优先改造三是在突发事件时能辅助决策比如爆管了告诉你要关哪些阀门、停水范围多大。这些能力靠人脑是算不过来的必须靠平台去算。1.2 方案的建设目标与覆盖范围这92页的PPT方案名义上叫“智慧管网综合管理平台”说白了就是建一个“管网数据中心 业务应用中心 指挥调度中心”三位一体的平台。整体建设目标可以拆成五句话统一物联感知接入统一数据标准治理统一业务应用协同统一展示门户入口统一运维管理体系。前三句话解决数据问题后两句话解决使用问题。很多项目只盯着第一句把钱都花在买传感器上后四句完全没做最后当然是失败。覆盖范围上根据不同业主单位的需求差异很大。一类是市政级的覆盖供水、排水、燃气、热力、电力、通信等地下管线涉及权属单位多协调难度大。另一类是园区、厂区、校区级的以供水、排水、工业管道为主管理相对集中更容易落地。方案里通常会把这两类场景都列出来让甲方对号入座。大多数情况下我更建议从园区或厂区级切入先做一个集中区域把业务流程跑通再往市政大网扩展不然一上来就摊大饼后期推进会非常痛苦。1.3 顶层设计一张网、一张图、一个平台这套方案的核心顶层设计就是“三个一”框架。“一张网”是指物联感知网。在关键节点布设压力、流量、液位、水质、气体浓度、井盖状态等传感器通过RTU、DTU、边缘网关等设备统一接入。这一层是基础点位布在哪、测什么、采多密直接决定了平台的数据质量。我的经验是全点位覆盖不现实优先布在“高风险、高价值、高故障率”的位置比如泵站进出口、管网交汇点、老旧管网段、易涝点等。“一张图”是指统一的GIS空间数据底座。所有管线、场站、设备、传感器、视频点位全部落到统一坐标系的地图上叠加地形图、影像图、规划图形成一张“管网全息图”。这张图不仅是展示用的更是后续空间分析、爆管分析、巡检路径规划的基础。“一个平台”是指综合管理平台本身。包含用户权限、数据接口、业务微服务、移动端APP等把监测预警、巡检养护、应急指挥、统计分析所有业务统一收口。这个平台不是简单地把各个子系统做链接而是要做数据层面的深度打通和业务流程的重构这是最考验设计功力的地方。2. 综合管理平台的总体架构与设计思路2.1 四层架构感知层、传输层、数据层、应用层方案里最常见的总体架构就是四层架构。虽然听起来有点老生常谈但在管网领域每层都有它自己的特殊讲究。感知层最容易被低估。很多人以为感知层就是买传感器实际上这里面的坑最密集。管网地下环境潮湿、易渗漏、无电源传感器必须考虑防水等级、电池寿命、信号穿透性。比如井盖下的水位计用NB-IoT传输一节电池撑两三年这叫合理如果你选了4G实时视频传输的方案电池撑不了一周方案直接报废。所以感知层的选型原则是数据频次够用就行功耗越低越好。传输层方面管网场景是混合组网。监测点位分散、量小、需要低功耗用NB-IoT、LoRa这类低功耗广域网泵站、污水处理厂等场站数据量大、有电源用光纤或者4G/5G专网视频监控数据量大、实时性要求高必须走专网或光纤不能跟NB-IoT混在一起。方案里要画出网络拓扑图明确哪个区域走哪条链路这是后期运维排障的依据。数据层是整个平台的心脏。管网数据分为空间数据、实时监测数据、业务数据三类。空间数据用空间数据库存管理管点、管段、阀门、泵站等几何信息和属性实时监测数据是时序数据频率高、量大建议单独使用时序数据库像TDengine、IoTDB这类性能比关系型数据库好一个数量级业务数据用传统关系型数据库比如巡检工单、故障记录、应急事件。这三类数据必须物理隔离、逻辑打通否则数据量一大查询性能就崩。应用层就是给不同角色用的业务系统。包括大屏展示系统、监测预警系统、巡检养护系统、应急指挥系统、移动端APP等。这一层要按用户角色做权限拆分不能一张大屏打天下。比如巡线员要的是“我今天的巡检路线和待处理问题”值班领导要的是“全市/全园区管网运行状态和告警汇总”两者界面完全不同。2.2 为什么必须选综合管理平台而不是一堆独立系统这一点我每次评审方案都会反复强调管网信息化最怕的不是没系统而是系统太多、互相不通。假设你给甲方分别上了“SCADA监测系统”“GIS管网系统”“巡检APP”“视频监控平台”每个都做得不错但它们数据不通、账号不通、业务不通。压力传感器报警了巡检员还要去另一个系统看定位视频还要再切一个平台确认现场指挥调度的效率反而更低。这就是典型的信息化改造带来的“数字负担”。综合管理平台的价值就是把这几个“烟囱”统一拔掉重新建成一个“大平层”。底层一个数据中台中层一套微服务上层按业务拆出多个应用模块。所有模块共用一套用户体系、一套地图底图、一套告警规则引擎、一套工单流转引擎。这样做的好处有三个第一是数据一次采集、多处复用。同一路液位计的数据既能驱动大屏展示也能触发告警还能写进巡检工单的现场记录不用每个系统各接一遍。第二是业务可以联动。举一个真实场景深夜某路段压力突然下降平台自动判断疑似爆管生成告警事件同时弹出该路段地下管线图自动调出半径200米内的视频监控画面并向值班人员手机推送任务。这种“监测-定位-视频-派单”的联动只有在一个统一平台里才能顺畅跑通。你要是在五个系统里手动切换等确认完现场水都淹了半条街了。第三是运维成本低。一套平台一个运维团队硬件、网络、数据库、应用全管如果上了七八套系统每套都要单独运维、单独升级、单独培训对甲方来说就是持续的“资金黑洞”。2.3 安防与视频监控子系统成熟平台直接对接更靠谱管网项目的视频监控需求不像安防项目那么花哨但同样刚需。泵站、污水处理厂、燃气调压站、易涝点、偷排偷倒高发区域都需要视频监控。这一块如果从零开始自研会非常痛苦因为涉及视频编码、流媒体转发、存储、AI识别等一大堆底层能力做得再多也不如专业厂商稳定。所以在实际方案里视频监控子系统我通常建议直接采用成熟的安防综合管理平台做底座比如海康的iSecure Center、ivms-8700这类或者大华、宇视的同类产品。这些平台具备设备接入、实时预览、录像回放、报警事件管理、门禁联动等完整能力而且有自己的生态和SDK/OpenAPI管网综合管理平台只需要按标准接口对接即可。对接时的关键点有三个。第一是协议要统一优先走GB/T 28181国标协议接入避免跟着某个厂商的私有协议绑定太深第二是报警联动要打通管网平台监测到液位超限、井盖位移、烟雾报警时要能自动调阅相关摄像头的实时画面或者触发云台预置位这个需要通过安防平台的OpenAPI做二次开发第三是视频点位要上图每个摄像机都要有经纬度坐标能在管网GIS地图上直接点选播放不能单独开一个视频系统切来切去。我见过有甲方非要平台厂商把视频模块也“自研”了结果画面延迟大、录像检索卡最后又灰溜溜地换回专业安防平台。这事怎么说呢专业的事交给专业的人平台方把精力放在管网业务逻辑上才容易出成绩。2.4 数据模型的逻辑与编码规范想做好管网平台数据模型必须提前设计清楚这是方案里最容易“图省事”随后“翻大车”的地方。管网数据建模核心要分清静态数据和动态数据。静态数据是管网本身的家底包括管点阀门、三通、弯头、检查井、设备井等、管段两点之间的管线、场站泵站、调压站、水厂等。每一个设施都要有唯一编码编码规则建议参照行业标准或地方标准比如“管线类型代码-行政区代码-道路代码-顺序号”加上权属单位、材质、管径、埋深、建设年代、状态等属性字段。动态数据是传感器实时上报的数值要按点位编码、测点类型、时间戳、数值来组织同时要保留质量标签比如“正常”“疑似异常”“离线补传”方便后续做数据清洗。还有一点容易被忽略就是坐标系不统一。不同来源的管线图纸有的用地方坐标系有的用GPS的WGS84坐标系有的用西安80、北京54如果不统一转换到CGCS2000国家大地坐标系在GIS图上所有数据都会错位哪怕错个一两米竣工测量和施工交底就全乱了。方案里一定要明确所有空间数据统一坐标系转换过程要记录原始坐标系和转换参数留痕可查。3. 核心功能模块拆解与实操要点3.1 二三维一体化GIS一张图GIS一张图是管网平台的门面也是几乎所有甲方最关注的部分。做得好方案汇报时直接加分做得不好一张图粗制滥造后面功能再强大也没人愿意用。一张图的核心不光是“画得好看”而是“查得快、算得准”。你要能把所有管线按供水、排水、燃气、热力等管种分色显示支持按照道路名称、权属单位、管径范围、埋深范围做条件查询定位点击任意管线或管点能弹出属性卡片看到管材、管径、埋深、建设年代、维护记录等信息。这是基础叫“看得见”。在此基础上还要叠加二三维联动二维图上选中管线三维场景同步定位支持横断面、纵断面剖切分析让运维人员直观看到管线的空间层次和相互间距。空间分析能力是一张图拉开档次的关键。管网专业里最经典的是爆管分析。当某处发生爆管系统要基于管线拓扑关系自动进行“关阀搜索”找出能够隔离故障段的最小阀门集合并模拟展示停水影响范围。这个功能在应急场景下价值极大。我接触过一个三线城市的自来水公司之前爆管抢修调度员靠记忆关阀门关了三个阀门还没把水断干净耽误了快一个小时。后来上了平台同样的位置爆管系统20秒给出阀门列表和影响范围抢修效率完全不是一个量级。做GIS一张图要注意数据质量。很多项目一开始管线数据不齐急着做展示结果是“带病上图”。为了赶工期有些管线位置是手工在地图上描上去的精度差得离谱。我的建议是GIS一张图宁可范围小一点、精度准一点也不要为了“全”而让地图上充满了不可信的线条。数据精度不达标后续所有空间分析都是空中楼阁。3.2 实时监测预警与SCADA数据接入管网的实时监测本质上是一套轻量级的SCADA系统。数据源头是分布在管网节点上的各种传感器、智能终端数据内容主要包含压力、流量、液位、水质余氯、浊度、pH值、可燃气体浓度、井盖状态等。平台要解决的核心问题是怎么把数据稳定地采上来并且及时准确地发出告警。数据接入这层厂商协议繁杂是最大的拦路虎。常规做法是引入一个统一的物联网接入层由边缘网关或者平台侧的协议解析插件去适配各类终端的私有协议对上提供统一的MQTT或HTTP接口。常见的电力行业协议有DL/T645水表行业有CJ/T188环保在线监测有HJ212工业现场设备多用Modbus RTU/TCP部分大型场站支持OPC UA。方案里要列一张协议适配清单明确哪些用标准协议哪些需要厂商提供SDK做定制开发。告警规则值得说两句。很多人以为告警就是“数值超过阈值就触发”太简单了。管网现场环境复杂压力波动、水流脉动都会造成毛刺数据直接按固定阈值一晚上能给你推几百条假告警最后大家把通知关掉真正的告警也看不见了。成熟的方案必须做“组合判断”和“延时确认”。比如“压力低于0.2MPa且持续30秒以上”才触发低压告警或者“流量突变超过20%且与压力趋势反向”才判定疑似爆管。用规则引擎把判断逻辑做进去把误报率压下来告警系统才有可靠性和公信力。告警产生之后要能自动生成工单、推送责任人并在GIS图上定位显示。同时告警要有分级一般分红、橙、黄三级不同级别对应不同的处置时限和上报路径。这样值班人员才能分清轻重缓急把精力放在真正要命的事件上。3.3 视频监控与环境感知联动视频监控不只用于安防在管网场景里它还是一个重要的“环境感知辅助手段”。大多数管网平台的视频能力来自对接成熟的安防综合管理平台比如前文提到的ivms-8700、iSecure Center等管网平台本身不重复造轮子但联动场景要设计好。最简单的联动是“告警-调视频”。监测数据触发告警后系统自动调取事件点附近摄像机的实时画面投到大屏或值班人员电脑上。比如污水管网某处液位持续上涨平台上一键弹出对应路口的监控画面值班人员不用到现场就能判断是不是有堵塞或者雨污混流。这里的实现逻辑是在GIS数据模型里把每个监测点与附近摄像机做空间关联告警时通过视频平台的OpenAPI按点位编码调流。再进阶一步是“AI事件联动”。现在成熟的安防平台都带智能分析能力比如在管网保护区识别挖掘机、重型车辆闯入在河道排口识别异常排放在井盖周边识别移动和破坏行为。这些AI事件一旦触发可以反向推送消息给管网平台让平台自动在GIS图上标记并生成现场检查工单。这样一来视频系统不只是“眼睛”还变成了“哨兵”能主动发现管网周边的风险行为。做联动设计时有几个坑要提醒第一摄像机点位和监测点位关联关系要提前建好不要等告警了才临时在地图上找探头第二视频存储和带宽要留余量如果所有监控都全天候高清录制存储成本会很高建议按“事件触发录像定时巡航录像”结合的方式第三视频平台和管网平台的时钟必须同步否则查录像和事件对不上时间戳这个在运维里很烦人。3.4 巡检养护工单闭环管理管网设备不是装上就完事了日常巡检养护才是细水长流的活儿。管网巡检的痛点也很典型巡没巡到位说不清发现问题靠电话上报处理结果没有跟踪问题容易不了了之。所以平台必须把巡检业务做成一个完整的闭环计划下发、现场打卡、问题上报、工单派发、处理反馈、复核销项。巡检计划方面管理员在系统里按管网等级和风险制定巡检路线、巡检周期。巡检员通过手机APP接收任务按路线实地巡查。打卡方式我建议用NFC/二维码结合GPS定位的方式既要证明“人到现场”又要防止用虚拟定位作弊。现在手机自带GPS但地下井室、泵站附近信号可能飘所以务必支持离线打卡网络恢复后再自动补传不然每次到地下车库或者信号屏蔽严重点位就罢工巡检员会骂娘的。发现问题后巡检员在APP上报隐患拍照上传描述具体情况。系统按隐患类型自动派单给对应的维修班组比如井盖破损派给设施维护组燃气泄漏报警派给管网抢修组。维修班组接单后去现场处理回传处理结果。最后由巡检员或系统审核复核确认问题解决后销项。整个过程在平台里留痕一件事件从发现到解决责任明确、时间线清晰。以后再有人问“这个井盖谁负责修、修到哪一步了”直接查工单就行不用来回打电话问。实际推进中最难的不是系统功能而是让一线巡检员真正习惯用APP。这里有个技巧巡检APP的界面一定要简单大按钮、少层级、离线优先不要做成一堆表单让工人填。项目经理去现场跟班走两天比在办公室里看一百页需求文档管用得多。3.5 应急指挥与模拟仿真突发事件处置能力是检验智慧管网平台价值的一块试金石。平台在应急场景下的角色是一个“信息汇聚和指挥调度中枢”。应急预案要数字化。把不同事故类型爆管、泄漏、污染、内涝等对应的处置流程、责任人、联系电话、应急资源抢修车、发电机、堵漏材料、防护装备提前录入系统。事件发生后负责人一键启动对应预案系统自动通知相关人员同时将事件定位、影响范围、周边视频、可用资源全部汇总到一张应急指挥大屏上。指挥人员在大屏上就能掌握全局通过短信、APP指令向不同小组下发任务处置过程全程记录事后可以复盘总结。更高阶的功能是水力模型仿真这个一般作为二期或分期建设内容。在管网GIS数据基础上构建供水或排水管网的水力模型利用实时监测数据做在线校正。它的价值体现在爆管事件发生后模型可以快速模拟不同关阀组合下的停水影响范围甚至预测恢复供水后的压力分布排水管网可以模拟不同降雨强度下的内涝风险和积水路段提前布防。不过水力模型的构建需要较完整的管网拓扑和准确的现场数据前期数据质量达不到的话模型结果并不可信所以方案里一定要有“数据积累期”的安排别指望一上来就建“数字孪生”这种大工程。4. 关键技术选型与部署落地经验4.1 数据接入协议与设备选型要点设备选型直接决定项目后期的稳定性和运维成本方案里要给出清晰的选型原则。地下管网监测设备优先考虑NB-IoT通讯。原因是地下井室信号穿透要求高NB-IoT比4G更能覆盖到井下而且功耗低电池供电可以支持2到3年。像液位计、井盖状态监测器、水质传感器这类低频率、小数据量的设备NB-IoT是首选。对于安装在泵站、调压站等有稳定电源的场所可以选4G/5G或光纤接入这样数据实时性和带宽更有保障。协议适配这块要留足够的预算。市面上的传感器厂家少说几十家每家都有私有协议。你不可能要求甲方把所有传感器换成同一品牌所以平台侧一定要有设备接入中间件或者边缘网关通过插件化方式适配不同协议。选型时优先选择网关设备已经预置了主流协议包的厂商能省很多事。还有一些隐蔽的选型问题供电和防护等级。室外的传感器设备供电是老大难能用电池的坚决不要拉电线能用太阳能的也要考虑连续阴雨天防护等级至少要IP68因为设备动不动要泡在水里。这些细节写进招标参数里能帮你筛掉一批不靠谱的小厂。4.2 平台部署架构与基础性能测算平台部署架构我建议采用“重点场站本地部署中心平台集中部署”的混合模式。重点泵站、污水厂等可以通过边缘网关做本地数据采集和联动控制避免中心网络中断时彻底失控中心平台则负责全量数据汇聚、存储、分析和业务应用。存储和性能要提前做推算不要等上线了才发现撑不住。以5000个监测点、5分钟上报一次为例平均每秒产生约16.7条记录每小时约6万条一天约144万条。如果峰值到1分钟上报一次每秒就有83条一天变成720万条。这样的数据量如果全部丢进MySQL一两年后查询就会明显变慢。所以时序数据一定要单独用时序数据库TDengine、IoTDB、InfluxDB都可以配上定期降采样策略——原始数据保留90天或者180天超过之后自动聚合为5分钟或1小时的平均值、最大值、最小值既能满足趋势分析又控制了存储成本。并发性能上一张图操作、告警查询、工单处理这类业务一般按同时在线100到200人、并发操作50人来规划服务器配置8核16G起步数据库独立一台时序库独立一台应用服务可以集群部署前端加一台负载均衡。这样的配置对大多数城市级或大型园区项目来说足够应对了。4.3 92页方案之外的隐藏成本实施、数据与协调这套方案PPT能讲清楚“平台是什么”但真正做项目的人都知道成本大头往往不在软件本身而在实施和协调。首先是管线物探和测绘费用。如果甲方现有的管线资料不完整、精度不够就必须在项目实施前期做管线探测这笔费用可能占整个项目预算的三分之一甚至更多而且周期长、受天气和现场条件影响大。方案里如果不提这一点后期预算执行时会非常被动。其次是数据治理的隐性工作量。把多来源、多格式、多坐标系的管线数据统一成一套标准的数据做拓扑检查、属性补全、坐标转换需要大量的人工整理这部分工作看不见摸不着却直接决定GIS平台能不能用。没有做过数据治理的人没法理解为什么要花那么多人月去“整理图纸”。再就是跨部门协调成本。市政管网涉及的权属单位非常多供水公司、燃气公司、热力公司、通信运营商每个单位都有自己的一套账。平台建设要获取他们的管线数据涉及保密和配合问题经常是开十次会都要不齐数据。我的建议是在立项阶段就让主管领导出面牵头把数据共享责任写进文件不要等项目启动了再扯皮。另外要多准备几个隐私脱敏和数据安全方案权属单位担心数据泄露是可以理解的你拿出可信的安全措施配合度会高很多。所以方案里一定要有分期建设路线图我通常建议分三期一期做平台基础框架和GIS一张图接入主要静态数据二期做实时监测网络和数据采集上线预警、巡检、工单等核心业务三期做应急指挥、水力模型、AI分析等智能化应用。这样既分散了预算压力也让每一期都能交付可用的成果避免大干快上最后烂尾。4.4 常见问题与排查技巧实录最后整理一份项目实施和运维过程中最常见的问题清单都是实测下来的经验。现象可能原因排查步骤传感器数据长时间不更新设备离线、电池耗尽、信号盲区先看设备在线状态再查NB-IoT网络信号最后到现场检查设备是否被淤泥淹没或损坏部分点位数据明显异常传感器漂移、零点漂移、网关毛刺调出历史曲线看突变点对比相邻点位数据数据异常持续半天以上建议现场校准告警频繁误报阈值不合理、告警规则太简单用“组合判断延时确认”按本周数据统计分析重新设置阈值GIS地图上管线位置偏移坐标系不统一、定位采集精度不足检查数据入库坐标系与原始竣工图做抽样叠加对比偏差大则重新采集视频预览卡顿或黑屏带宽不足、存储满、编码不兼容、设备离线先确认摄像机网络连通性再查流媒体服务器CPU/带宽占用最后检查存储磁盘状态巡检APP在井下无信号地下信号弱、运营商覆盖差启用离线打卡模式回地面后自动补传重要点位可加装信号中继器平台页面加载慢数据库未优化、大表无索引、图层请求量大检查慢SQL日志为常用查询字段加索引GIS图层按视野范围动态加载针对时区问题也提醒一下。很多物联设备的默认时区是UTC而平台是北京时间如果不做转换数据时间戳会对不上告警和录像对应关系全乱。解决方式是设备端统一配置北京时间平台侧再做一道校验最简单的方法是在数据接入层写一个统一的时区处理函数无论上游传来什么格式都按标准时间入库避免源头上各搞各的。还有一个老生常谈的坑就是网络隔离。很多甲方的内网和物联网是物理隔离的平台又需要和视频专网对接这中间怎么打通、用什么安全设备、是否需要跨网摆渡都要在方案设计阶段就确认清楚。我见过有项目因为网络安全评审没过导致物联网数据一直进不了中心平台拖着好几个月没法上线。这类架构问题提前和甲方信息部门、安全部门对齐比事后补救省心得多。我个人在项目里最深的体会是智慧管网平台的成功三分靠技术七分靠数据和业务协同。技术选型、架构设计、功能模块这些在92页方案里都能写清楚但真正决定项目成败的是前期能不能把数据底子摸清中期能不能让不同部门的人愿意用起来后期能不能持续运维、把数据喂活。做这类项目别总想着把功能堆得又多又炫先把一条管线的数据做准、一个巡检员的工单流转做顺、一次爆管事件的响应做快比什么都有说服力。最后再分享一个做方案汇报的小技巧不要只罗列平台功能要算账。算一下每年因为管网漏损、爆管停水、误挖事故造成的经济损失再对比平台建设投入把投资回报这本账摊给甲方看方案过审和立项通过的把握会大很多。