第18章 痛点、瓶颈与根因

本章导读

上一章给出的是评估框架与现状判断，本章要做的是把这些判断拆到机制层面：每一个痛点，究竟是哪一条流程、哪一个预算科目、哪一项职责安排造成的。只描述现象而不追问机制，讨论就会停在“重视不够、人才不足、投入不足”这三句正确的废话上。本章的方法是：对每一个痛点追问三个问题——它在什么条件下必然出现，为什么当事人做出这个选择是理性的，改变哪一个变量才能让它不再出现；凡是答不出第三问的，就不是真痛点，只是抱怨。八类痛点（数据、标准、模型、系统、组织与人才、投入与效益、安全与合规、技术与工程）逐一拆解后，得到三个结论：痛点几乎都不是知识或技术问题，而是激励与流程问题；痛点分布不均衡，改进应当抓接口而不是抓单项；制度、机制、能力三层中，能力层的投入最容易做也最容易失效。最后一个提醒：痛点的描述很容易变成自我安慰——归因于“客观条件”就可以不做改变，而多数约束之内的选择空间比通常以为的要大。

学习目标

读完本章，你应当能够：

• 用“三问”方法把痛点拆到机制层面，并判断一个问题是否属于真痛点；
• 解释“底数衰减”为什么是数据生产没有挂在必经流程上的结果，而非采集技术不足；
• 说明没有对象标识规则时，空间融合会在哪一步失败，并写出最小标识规则的组成；
• 论证“模型不可信”的根因是缺少验证义务，而非算法落后，并写出建立验证义务的两项条件；
• 解释系统烟囱式建设的激励来源，说明为什么“系统”成了预算的唯一容器；
• 区分制度、机制、能力三层的改进难度与收益，指出为什么能力层投入最容易失效。

上一章给出的是评估框架与现状判断，本章要做的是把这些判断拆到机制层面：每一个痛点，究竟是哪一条流程、哪一个预算科目、哪一项职责安排造成的。只描述现象而不追问机制，讨论就会停在“重视不够、人才不足、投入不足”这三句正确的废话上。需要先声明本章的方法：对每一个痛点，都追问三个问题——它在什么条件下必然出现，为什么当事人做出这个选择是理性的，改变哪一个变量才能让它不再出现。凡是答不出第三问的，就不是真痛点，只是抱怨。

18.1 数据之痛

判断先行：数据问题的本质不是“没有数据”，而是“没有对同一件事的一致记法”。过去五年数据总量增长极快，可用的判断并没有同比增长，根本原因在于多数数据是“为汇报生产的”，而不是“为决策生产的”。这两类数据的生产函数完全不同。

18.1.1 底数：数据生产没有挂在必经流程上

第一次全国自然灾害综合风险普查是一次质量很高的调查：形成 11 号公报，建立 48 项调查类与 61 项评估与区划类技术规范，形成覆盖上千个指标的数据共享清单，并统一了普查底图与高分辨率卫星影像（国务院普查办，2024-05）。它能达到这个质量，恰恰因为它把四件事同时做齐了：统一底图、统一规范、统一培训、统一质控。这四件事在日常业务中通常是缺位的，而缺位的结果不是“数据差一点”，而是“数据无法比较”。

问题出在普查结束之后。普查是一个项目，项目有起点和终点；结题之后，数据生产就停止了。而现实世界每天都在产生新的房屋、新的道路、新的切坡建房、新的隐患点。只要数据生产不挂在行政许可（规划许可、施工许可、竣工验收）、日常巡查、事件复盘这些必经流程上，底数就一定会衰减，而且衰减速度与建设速度正相关。这不是“重视程度”的问题，是生产函数的问题。补数据的正确方式是改造流程——让每一次审批、每一次巡查、每一次复盘都自动产生一条可入库的记录——而不是再组织一次普查；再普查一次能得到一份新的高质量基线，但三年后仍会面对同一个问题。

18.1.2 精度：不同精度的东西被放在一起计算

实景三维中国已经形成 5 米、10 米格网等系列产品覆盖全国陆地国土，1:1 万数据覆盖 70% 陆地国土（自然资源部，2025-12）。这是三个不同精度的层次，各自适用不同尺度的分析。问题在于，当它们被放进同一个工程、同一张图、同一次叠加分析时，精度标签往往在流转中丢失了：数据被重采样、被格式转换、被裁切拼接，而元数据没有跟着走。后果是把误差当成了差异。用 10 米格网的地形去判断一条冲沟的汇流路径，得到的结论可能完全错误，而图面看上去毫无异常；更麻烦的是这类错误无法被“看图”发现，只能被“查元数据”发现。一条可执行的规则是：没有精度标签的图层不得进入定量分析，只能用于示意。这条规则成本极低，但需要有人在数据入库环节执行。

18.1.3 时效：更新链条上没有触发点

更新的现实机制是“专项驱动”：有专项经费就更新，没有就等。而专项的立项取决于预算周期和注意力分配，两者都与数据的实际衰减速度无关。可行的做法是设置强制触发点，把更新从“要不要做”变成“什么时候必须做”。三个最有效的触发点是：事件后强制回填（每次灾害处置的核查结果必须入库）、审批后强制同步（竣工验收数据同步到空间库）、年度变更调查对接（利用已有的国土变更调查成果批量更新）。这三个触发点的共同特征是它们本来就存在，只需要增加一个“入库”动作，边际成本很低。

18.1.4 基准与拓扑：两类“看起来对”的错误

坐标基准与高程基准的代际差异会造成两种表象：两套图叠不上，或者叠上了但不重合。前者容易被发现，后者最危险——图上看起来是对的，实际存在系统性偏移，而偏移量恰好与该地区的地形复杂度相关。拓扑缺陷更隐蔽：道路断头、水系不连通、行政区划飞地、面自相交，这些缺陷在视觉上几乎不可见，但会让网络分析直接失效——可达性算出来偏大、最优路径算不出来、汇流分析在中途断掉。普查和实景三维提供了很好的几何底子，但拓扑检查通常被当作“数据处理的附属工作”跳过，因为它不产生新的图层，也不出现在验收清单里。

18.1.5 孤岛：不是技术不通，是责任没有分清

数据共享的技术障碍在多数地区已经基本消除，剩下的障碍是责任分配。当一份数据被共享出去、被用于一个错误结论、造成了后果，责任如何划分？在没有明确规则的情况下，数据持有方的最优策略是不共享，或者只共享经过高度概括的版本。这是理性的，不是保守的。破解的办法不是再建一个共享平台，而是给出三件事：用途限定（这份数据只能用于什么）、有限免责（在约定用途内使用不追究提供方责任）、全程留痕（谁在什么时候取用了什么）。这三件事都是制度设计，不需要新技术。

表18-1 数据缺陷的类型、表现与对分析的影响

边界提示：数据治理最容易被做成“大而全”的工程，试图一次性把数据做全。正确的顺序是按业务动作倒推需要什么数据：先明确“下一次事件中要做哪几个判断”，再确定支撑这几个判断需要哪些图层、什么精度、多久更新一次。反过来做，一定得到一个庞大而没人用的数据库。

18.2 标准之痛

判断先行：标准不缺，缺的是“可执行的编码与口径”。应急管理信息化领域已集中制定发布百余项技术标准（应急管理部），供给是充足的。落地卡在三处：对象没有统一编码、统计没有统一口径、标准没有配套验收手段。

18.2.1 编码：没有主数据，所有融合都是字符串匹配

同一栋建筑，在住建的房屋普查库、应急的承灾体库、自然资源的不动产库里有三个不同的标识；同一处地质灾害隐患点，在普查库和专业部门的监测库里有两种编号体系。当需要把三套数据合起来看时，实际执行的是名称加地址的模糊匹配。这种匹配的成功率看起来不低，但错配率通常没有被统计，而错配在应急场景中的后果是不对称的：漏配导致对象漏管，错配导致资源投错地方，两者都比“没有数据”更难发现。

根因不在技术，在于编码规则由各系统建设时自定，而跨系统的主数据管理职能没有明确归属。可操作的起点是先定“对象标识规则”而不是先建数据库：规定新增对象的赋码责任方是谁、在哪个环节赋码、已有对象如何建立映射。这份规则可以只有几页纸，但它决定了后续所有融合的成本。

18.2.2 口径：两套统计口径不能混用

2025 年全国自然灾害造成 6703.37 万人次受灾、死亡失踪 763 人、直接经济损失 2416.17 亿元（国家防灾减灾救灾委员会办公室、应急管理部，2026-01）；同年各类生产安全事故 19884 起、死亡 18261 人，重大事故 9 起、较大事故 357 起（应急管理部，2026-01）。这是两套完全不同的统计体系，致因链条、责任主体、可干预环节都不同。

混用的后果不是数字错了，而是结论反向。如果把两者简单相加做“总伤亡”，会得到“自然灾害比生产安全事故更安全”的错误印象；如果混在同一张趋势图里，会出现“总体持平”这类掩盖结构的伪结论。同样，单次灾害的损失（如定日地震直接经济损失 89.45 亿元）与年度总量（2416.17 亿元）不能相加，也不能用单次占比去推断年度结构。技术上能做的不多，但有一件事必须做：把“口径”作为数据模型里的一等属性，任何汇总操作必须先声明口径，且不同口径的数据不得在同一视图中自动合并。这条规则如果写进系统而不是写进文件，能避免大量错误。

18.2.3 落地：标准写了“应”，没写“谁验、怎么验”

多数技术标准的表述是“应符合……”，但没有配套的测试数据集与合格判定方法。于是标准在执行端退化成了“参考”，验收时无法判定是否符合。最短的改进路径是给每个关键标准配一个测试样例集与验收脚本。这件事在普查的技术规范体系上有很好的基础：48 项调查类规范、61 项评估与区划类规范本身就是高度可测试的对象，只要把它们转成“输入样例—期望输出—判定规则”的形式，标准就从文本变成了工具。

18.2.4 跨部门冲突：同一个空间对象有两套定义

河道管理范围与洪涝风险范围、生态保护红线与灾害高风险区、城市建设边界与地质灾害易发区，这些概念在不同部门的法规里各有定义，边界不重合是常态。冲突不解决，图上就会出现两套红线，业务人员不敢用，最终回到各自系统。关键判断是：这类冲突应当在规划编制阶段解决，而不是在系统集成阶段解决。集成阶段解决冲突的成本要高出一个量级，因为此时两边都已经有既成成果、有考核指标、有责任归属。真正有效的做法是在国土空间规划、流域规划编制的环节就把灾害风险边界作为约束条件纳入，而不是等两套图都做完再来“融合”。

表18-2 标准落地的五类断点及其可操作改进

边界提示：标准不是越多越好。需要区分两类标准：数据交换与接口类标准宜严、宜强制，因为它决定互操作；技术实现类标准宜宽、宜留白，因为过早固化会锁死演进。三维数据格式、模型接口、渲染管线这类领域，现在定得太细，三五年后就会成为包袱。

18.3 模型之痛

判断先行：模型的问题不是“算得对不对”，而是“能不能被相信、并在压力下被使用”。大量模型在技术指标上合格，在决策场合中却不被采纳，原因几乎都出在可追溯性与可解释性上，而不是精度上。

18.3.1 率定缺失与参数不可追溯

灾害模型的参数高度依赖本地条件：流域的糙率、土壤的下渗能力、坡体的岩土结构、城市的管网排水能力。这些参数的获取需要本地实测或历史事件反演，而历史事件数据恰恰是最缺的——这构成了一个循环：没有历史数据就没有率定，没有率定模型就不可信，不可信就不被使用，不使用就不产生新的验证数据。打破循环的起点不是提高模型精度，而是先建立“事件—数据”的采集习惯：每次事件处置过程中同步记录关键观测值，哪怕只有几个点。几个真实观测点对率定的价值，远高于再多的模型改进。

与此并列的另一个缺陷是参数不可追溯。很多淹没分析、扩散模拟在事后复盘时无法复现：不记得当时用的什么地形数据、什么边界条件、什么参数版本。这个缺陷的严重性常被低估——它意味着模型结论无法被审计，也就无法被用来界定责任；在一个需要界定责任的场景中，不可审计的结论等于不可用。解决办法很朴素：模型运行必须留下可复现的记录，包括输入数据集版本、参数集版本、模型版本、运行时间。这在技术上只是工作量，在管理上需要一条规定。

18.3.2 算力与时间窗的错配

高精度的二维水动力模拟，一次完整计算可能需要数小时；而应急决策的时间窗常常以分钟到小时计。这不是算力不足的问题，是物理约束：网格越细、时间步长越小，计算量按超线性增长，靠堆算力解决不了。正确的解法是模型分级，而不是模型升级：用粗网格、简化方程的一维或简化二维模型在几分钟内圈定可能受影响的范围，再在这个范围内用精细模型做局部精算。两级模型的分工是“先知道大概在哪，再知道具体多深”。很多地方跳过第一级，直接追求高精度全域模拟，结果是在应急窗口内算不完，只能不用。

18.3.3 输出与业务动作之间缺一层“对象化”

模型输出的是水深栅格、流速场、浓度场；业务需要的是“哪几户需要转移、哪条路不能走、哪个安置点要启用”。中间需要一次转换：把栅格值转换为受影响对象清单。这一层转换既不属于模型开发，也不属于前端展示，通常处于“没人负责”的状态，于是被跳过。跳过这一层的直接后果是：模型很先进，指挥员看到的仍是一张彩色图，图上好看但说不出该做什么。

2023 年海河流域性特大洪水防御中，基于特大暴雨预报与普查成果快速研判洪水量级、识别防洪工程风险隐患、研判兰沟洼蓄滞洪区分洪情景（国务院普查办，2024-05），这个案例之所以有效，恰恰是因为完成了从“水情”到“工程风险与分洪情景”的对象化转换。

18.3.4 验证缺失：模型停在演示态

绝大多数模型在建成后从未被系统性验证。没有验证记录，就没有人敢把它用于真实决策；不用于真实决策，就永远得不到验证。这是一条自我强化的停滞路径。打破它的办法是把它变成制度：每次事件后强制做“模型回溯”，把模拟结果与实测结果对比并存档。同时确立一条管理规则——没有验证记录的模型只能用于内部参考和培训，不得作为对外决策依据。这条规则看起来严苛，实际上是在保护模型开发者：一旦有了验证记录，模型才可能被真正使用。

表18-3 模型五类失效的可观测信号与干预方式

边界提示：不是所有场景都需要物理模型。相当一部分应急决策只需要“叠加加规则”：把隐患点、降雨预报、人口分布叠在一起，按预设规则判断风险等级，效果往往优于复杂的物理模拟，且可解释性更强。把简单问题模型化，是另一种形式的资源浪费。

18.4 系统之痛

判断先行：烟囱式建设不是认识问题，是“预算年度加项目制”的必然产物。只要预算必须形成项目、项目必须交付系统，烟囱就会持续产生。批评“部门本位主义”解决不了这个问题，因为它描述的是结果而不是原因。

18.4.1 系统为什么会不断新建

在现行的预算体制下，信息化投入必须落到具体项目上，项目必须有明确的交付物，而“系统”是最容易被识别、被验收、被展示的交付物。于是系统成了预算的容器：有钱就要有项目，有项目就要有系统。与此形成对照的是，集成、对接、数据治理这些工作没有独立的预算科目：它们不产生新的系统，也不产生可展示的成果，因此只能挤占运维经费或建设项目的剩余额度。这就是为什么几乎所有地方的集成工作都排在最后、做得最浅。理解这一点很重要——新建系统的部门并不是不知道重复投资，而是在现有规则下，新建是唯一能把预算变成成果的路径。改变行为必须先改变科目设置。

18.4.2 重复投资的具体形态与集成的脆弱性

重复投资最常发生在四类能力上：底图、三维模型、视频汇聚、账号体系。这四类能力的共同点是“通用性强、专业属性弱”，因此每个部门都有理由自建一套，也都能找到自建的必要性论证。一个可测量的指标是“同一能力在辖区内的独立实例数”：底图有三套、视频汇聚平台有四套、账号体系有五套，这些数字本身就能说明问题，而且比投资额更容易统计，也更难被辩解。

集成的脆弱性则来自组织安排：接口对接没有独立预算、没有独立工期，通常由承建单位在项目尾期“顺手做”。结果是接口能通，但脆弱——一方升级接口就断，断了之后没人负责修，因为原项目的质保期已过。这类问题的表现是“集成做过了但用不了”；它的成本不在建设期显现，而在事件中显现，需要跨系统取数时才发现取不到。

18.4.3 体验：事件中要开多个系统

这是最刺眼也最容易被掩盖的失败形态。指挥员在事件中需要打开多个系统、记住多套账号、在不同界面间搬运数据，最后的选择往往回到即时通信群加纸质图。系统还在，投资还在，但人在关键时刻不用它。验收环节几乎无法发现这个问题，因为验收测试的是“功能是否可用”，而不是“在压力下是否会被使用”。唯一有效的检验方式是实战演练中的观察：看指挥员在演练时实际打开了什么。

18.4.4 运维：重建轻养的机制原因

建设有专项资金、有明确的政绩可见度、有开工和竣工的时间节点；运维是经常性支出，没有节点、没有仪式感，在财政收紧时最先被压减。数字孪生水利在“十四五”期间全面完成 94 项数字孪生流域建设先行先试任务，并推进 14 个省级水网先导区、49 处数字孪生灌区、230 个数字孪生农村供水工程，启动 12 座智能大坝、32 处数字孪生调水工程、98 处数字孪生蓄滞洪区（水利部）。这个体量说明建设能力已经具备。接下来的真问题不是再建多少，而是如何让这些已建成果在五年后仍然可用——模型要重新率定、数据要更新、软件要升级、人员要交接。这部分工作没有专项，也没有考核。

表18-4 系统层痛点的表现与机制根因

边界提示：不是所有系统都该合并。“一个平台包打天下”同样会失败，因为专业系统的深度需求与通用平台的标准化取向天然冲突。正确的目标是“一个入口加多个专业内核”：入口统一、账号统一、底图统一，专业计算仍然由专业系统承担，通过服务调用而非界面整合来连接。

18.5 组织与人才之痛

判断先行：人才问题的实质不是“人少”，而是“岗位不存在”。在一个没有对应编制的组织里，再多的培训也不会产出复合型能力，因为能力没有承载它的位置。

18.5.1 复合型岗位在编制上不存在

会 GIS 的人通常在地理信息、规划、测绘类事业单位；懂应急业务的人在指挥中心、业务司局、救援队伍。两者之间缺少一个编制上的交集岗位——既懂空间分析又懂处置流程，且被明确授权在事件中产出空间产品。没有岗位，就没有职业通道；没有通道，就留不住既懂两边的人；留不住人，就只能外包；外包团队不懂业务语境，产出的是图层而不是判断。这是一条闭环的退化路径，靠培训无法打断。

可行的干预是设岗，而不是培训。培训是给已有岗位增加技能，设岗是创造需求。具体做法是：在指挥或规划职能中明确设置“空间分析”职责，写入岗位说明，并在演练中检验其是否真的出场。这个动作不需要新增编制，只需要重新定义现有岗位的职责清单。

18.5.2 部门壁垒的结构性来源

应急管理部门承担综合协调职责，而绝大多数致灾与承灾数据掌握在水利、气象、自然资源、住建等专业部门手中。协调权与数据持有权分离，这是法定分工的结果，不是态度问题。国家、省、市、县四级应急信息共享网络已经构建（应急管理部，2025-07），它解决的是“通道”：数据能不能过来；它不能解决“动力”：数据持有方为什么要持续供给、供过来的数据为什么要保证质量。动力问题只能靠制度安排解决——把数据供给纳入对方的工作职责与考核，或者给出明确的免责与补偿机制。

18.5.3 事件中“谁出图”没有规定

多数预案里写明了谁负责指挥、谁负责转移、谁负责物资，但很少写明“态势图由谁在什么节点产出、经谁审核、发给谁”。于是事件中临时指定，事后无人负责更新，下一次事件重新来过。这是一个成本极低、收益很高的补丁：在预案中增加一节，明确空间产品的产出责任、时限、审核人与分发范围。它不需要任何技术投入，却能显著提升事件中的信息效率。

18.5.4 考核指标决定了行为

考核建成率，就建新系统；考核登录率，就刷活跃度；考核闭环率，就可能出现虚假回填。任何单一指标都会被博弈，这是管理常识。相对稳健的做法是把考核的重心放在“事件复盘抽查”上：随机抽取真实事件，核对系统在其中的实际出场时刻与作用。这种考核无法通过临时准备应对，因为它要求的是历史事实。成本较高，但它是唯一难以伪造的一类指标。

表18-5 组织层断点的表现、根因与低成本的干预动作

边界提示：设岗与考核都是慢变量，通常需要一到两个任期才能见效。在此期间，更现实的策略是把关键能力“产品化”——把分析方法固化成模板、把模板固化成工具、把工具固化成流程，使能力不依赖于具体某个人。产品化不能替代设岗，但它能在人员流动中保住底线能力。

18.6 投入与效益之痛

判断先行：应急 GIS 的投入产出关系之所以难讲清楚，是因为它的主要效益是“未发生的损失”。这类效益在财务上不可见，在政治上不可展示，因此在预算竞争中天然处于劣势。

18.6.1 周期错配：效益在“没出事”时体现

预算的松紧与事件强相关：出了事，追加投入容易获批；连续几年平稳，投入就被视为可以压缩。这形成了一种周期性摆动——灾后突击建设、平时闲置、下次灾害再建。每一轮建设都从零开始，因为上一轮的成果已经因为缺乏运维而失真。这个循环的根子是评价周期与效益周期的错配：政治周期以年计，防灾效益以十年计。破解的办法不是讲道理，而是把效益转化成可年度观测的中间指标，例如预警提前量、转移组织的耗时、跨部门调取的耗时。这些指标每年都能测，且与最终的减灾效果方向一致。

18.6.2 量化困难与替代指标

避免的损失难以货币化，这是普遍难题。可行的替代指标有三类：预警提前量（从预警发出到影响到达的时间）、转移覆盖（在影响到达前完成转移的对象比例）、暴露人口变化（同一强度事件下受影响人口的变化）。需要明确一条纪律：2025 年全国自然灾害直接经济损失 2416.17 亿元、死亡失踪 763 人（国家防灾减灾救灾委员会办公室、应急管理部，2026-01），这组数字可以作为“不投入的代价”的量级参照，但绝不能用来推算投入产出比。任何“避免百分之几的损失即等于多少亿元收益”的算法，都是把相关性当因果性，会在专业审查中被推翻。

18.6.3 重建轻用与采购方式错位

验收看功能清单，不看使用记录，这是“重建轻用”最直接的制度原因。一个系统只要功能齐全、演示流畅，就能通过验收；至于它在过去一年中被真实业务调用了多少次，通常不在验收范围内。把使用记录纳入验收并不复杂：要求提供过去若干个月的真实调用日志与业务方清单，并抽查若干条核对。这会显著改变承建方的行为，因为功能可以堆，使用不能堆。

采购方式则决定了能力的形态。按软硬件清单采购，得到的是产品清单，而不是能力；清单式采购的隐含假设是“能力等于功能之和”，而实际能力取决于功能之间的衔接与人的使用。服务化采购（按事件保障付费、按调用量付费、按运维响应时限付费）更接近真实需求，因为它把供应商的利益与“持续可用”绑定。但它有明确边界：涉及涉密数据处理、需要长期驻场、需要深度定制的部分，不适合完全服务化。合理的结构是“核心能力自建、通用能力服务化、峰值能力弹性采购”。

表18-6 投入产出失衡的五种形态与矫正手段

边界提示：强调效益不等于要求每个项目都自证回报。应急能力建设中有相当一部分属于“底线能力”，它的价值在于极端情况下的可用性，无法用日常使用率衡量。对这类能力，正确的评价方式是压力测试与演练结果，而不是调用量。把底线能力按使用率考核，反而会诱导它去追逐日常业务，削弱其应急属性。

18.7 安全与合规之痛

判断先行：合规与时效的矛盾是真实的，但多数情况下不是“制度太严”，而是“合规动作没有前置”。把审批、定级、审核这些动作从事件中挪到事件前，矛盾的大部分就消失了。

18.7.1 涉密与共享的结构性矛盾

涉密基础测绘成果的提供使用需要审批，审批已下放至省级、时限缩短至 10 个工作日，并有明确的销毁要求（自然资源部）。这已经是优化后的安排。但应急的时间尺度是小时级，与 10 个工作日的审批周期不在同一个量级上。矛盾的真实形态不是“要不要保密”，而是“事件发生时能不能立刻拿到”。解法是把授权前置：事前明确本单位在特定灾种、特定区域内可以使用的成果范围，一次性完成审批；事件中只做“取用”，事后做留痕核查。这需要事先做工作——明确需求范围、完成审批、建立取用登记——但在事件中节省的时间是决定性的。

18.7.2 分类分级的落地难点

地理信息数据分类分级工作要求重要数据目录的申报、审核与认定（自然资源部，2025-05）。落地时的难点在于：同一份数据在不同场景下的敏感度不同。一张包含燃气管网走向的图，平时是内部管理资料，在特定时期则可能成为高价值的目标信息。按“数据集”分级难以处理这种差异，更可行的是按“场景加要素组合”分级：同一数据集在不同使用场景、不同要素组合下适用不同的管控要求。这种做法的管理复杂度更高，但更贴近实际，也能避免“一刀切导致全部不能用”。

18.7.3 公开地图出图的合规摩擦

地图管理条例确立了地图审核制度，公开地图内容表示规范于 2025 年 1 月发布并实施、有效期 5 年（自然资源部，2025-01）。应急场景下，新闻发布会、指挥大厅大屏、对外通报都可能需要出图，而审核需要时间。最有效的缓冲机制是预置：事前完成一批标准底图模板与符号库的审核，事件中出图只做“叠加”，不改变底图要素与表示方式。这样一来，需要审核的是新增的专题表达，而不是整张图。这个做法在很多地方已经实践，但缺少制度化，往往依赖个别人员的经验。

18.7.4 等保成本与供应链替代

网络安全法于 2025 年 10 月 28 日修改通过、2026 年 1 月 1 日施行（全国人大常委会，2025-10），网络运行安全与数据安全义务进一步明确。对应急地理信息平台而言，这意味着等级保护测评、密码应用改造、日志审计、应急预案演练都成为持续性支出。对小市县而言，这是一项硬约束：不投入就过不了测评，过不了测评就可能被限制运行。合理的应对不是削减，而是集约——由省级统一建设安全能力（如统一的密码服务、统一的日志审计、统一的安全运营中心），市县按需调用，避免每个县重复建设一套安全设施。

供应链层面，GIS 内核、空间数据库、三维引擎的国产化替代在持续推进，替代期的典型问题是性能差距与生态差距：插件少、文档少、人才少。更棘手的是替换窗口与业务连续性的冲突——系统不能停，替换又不能不影响。可行的路径是双轨并行加兼容层：新系统优先采用国产内核，老系统通过兼容层维持运行，逐步迁移而非一次性切换。这需要提前规划，因为兼容层本身也是成本。

表18-7 合规约束与应急时效的冲突点及缓冲机制

边界提示：合规不是“多加审批”，而是“把审批前置”。反过来，也不能把“应急”当作豁免合规的理由。一次违规可能导致平台停摆、成果被收回，其代价远大于一次事件的响应延误。正确的平衡是：常态下把合规做足，非常态下用足已经取得的授权。

18.8 技术与工程之痛

判断先行：技术层面的多数失败不是算法不行，而是工程没做完。轻量化、离线化、降级方案这些“不出彩”的工作被系统性跳过，而它们恰恰决定了系统在极端条件下的可用性。

18.8.1 三维性能：好看不等于能用

300 余个地级以上城市完成了 LOD1.3 三维模型生产（自然资源部，2025-12），成果在桌面端演示时效果很好。但指挥大厅的多屏并发渲染、移动端的弱网加载、跨部门的并发访问，是完全不同的负载条件。未经轻量化处理的三维成果，在这些场景下往往打不开或卡顿。轻量化（层级简化、瓦片切分、纹理压缩、按需加载）是必需工序，不是优化项；它之所以经常被砍掉，是因为在验收清单上“看得见效果”的是模型精细度，而“看不见”的是加载性能。

18.8.2 海量数据与冷热分层缺失

影像、点云、时序监测数据的增长速度远快于预算增长。缺少冷热分层与生命周期管理的结果是：所有数据都放在高性能存储上，成本高企，然后在预算压力下开始删数据——通常删掉的正是需要长期保存的历史时序数据，而它恰恰是模型率定最需要的。可操作的做法是建立数据生命周期规则：明确哪些数据必须永久保存、哪些可以降级存储、哪些可以按规定销毁。这不是技术问题，是管理规则问题。

18.8.3 AI 可信：单一指标掩盖了漏报

有企业在公开场合披露，其森林火情智能识别产品的火情识别准确率提升至 95% 以上、上报时间从 1 小时缩短至 3 秒（企业发布口径，2025-12）。这类指标必须标注为企业口径，不能当作行业结论。更实质的问题是：准确率掩盖了漏报率与分布偏移。在火情识别这类场景中，漏报的代价远高于误报——漏报一次可能造成重大损失，误报的代价只是一次核实。而准确率这个指标对两类错误的惩罚是不对称的，且通常在特定季节、特定地域、特定传感器条件下的样本上测得，一旦分布偏移就会显著下降。可执行的管理规则是：AI 结果只作为“提示”，不作为“结论”；每一条 AI 提示都必须有人确认并留痕；漏报率必须单独统计并定期公布。这条规则会降低系统的“自动化观感”，但它是把 AI 真正用起来的前提。

18.8.4 边缘与“三断”，以及验收即停更

断网、断电、断路条件下，依赖云端的 GIS 完全失效。应对方案是离线包加边缘计算，但离线包的制作与更新是纯粹的工程活：需要预先划定范围、预先切瓦片、预先打包数据、预先测试。它不出彩、不进汇报材料，因此经常被推迟。判断一个系统是否真的具备应急属性，最省事的测试就是断网演练：拔掉网线，看还能不能出图、能不能查到对象、能不能生成转移清单。

工程实施层面，最常见的失败模式是“上线即验收、验收即停更”：系统在验收时功能齐全，之后因为没有运维预算、没有明确的责任人、没有持续的需求输入，逐渐失真。预防的方式是在合同与制度上设置“验收后义务”——质保期内的响应时限、数据更新的责任、每年的复检要求。这些条款在很多合同里是缺失的，或者有但没有执行记录。

表18-8 技术与工程风险的触发条件与缓解手段

边界提示：技术选型要看“最坏条件下的可用性”，而不是“最好条件下的效果”。演示环境里的流畅与实战环境里的可用，是两个不同的指标。任何技术方案在评审时都应当回答一个问题：在网络中断、电力中断、人员不足的最坏条件下，它还能提供什么。

18.9 根因分析：制度、机制与能力三层

判断先行：前述八类痛点不是八个独立问题，而是三层结构的显现。制度层决定了激励，机制层决定了流程，能力层决定了执行。只在能力层做投入，前两层不变，痛点必然复发。

18.9.1 制度层：三条硬约束

第一条是项目制预算：预算必须落到项目、项目必须交付系统，于是系统成为预算的唯一容器，集成与治理没有科目。这条约束直接生产了烟囱与重复投资。第二条是法定分工：综合协调职责与专业数据持有权分属不同部门，这是法律授权的结构，不是可以靠协调会解决的；它决定了跨部门共享必须靠制度安排（职责、免责、补偿），而不能靠技术平台。第三条是统计口径分立：自然灾害与生产安全事故是两套统计体系，各有其法定的责任主体与报送流程；它决定了空间分析必须始终带着口径标签，任何“总数”都是有条件的。

这三条约束都不是“错误”，它们在各自的目标上是合理的；痛点是它们在应急这个特定场景下相互作用的结果。因此改革的方向不是推翻约束，而是在约束内设计缓冲：给集成设科目、给共享设规则、给汇总设口径声明。

18.9.2 机制层：四个缺失

第一个缺失是主数据管理：没有跨系统的对象标识规则，所有融合都是字符串匹配。第二个缺失是更新触发：数据更新依赖专项，而不是依赖业务流程中的必经节点。第三个缺失是模型资产化：模型没有台账、没有率定记录、没有验证档案，因此不可审计、不可追责、不可信任。第四个缺失是使用侧考核：考核指向建成率，行为就指向新建。

这四个缺失的共同特征是：补上它们的成本并不高，但它们都不产生“可见成果”，因此在以可见成果为导向的评价体系中持续被推迟。

18.9.3 能力层：岗位、工具与流程的匹配度

能力层的真实问题不是人数，而是匹配度。基层需要的是“一屏能看懂、一句话能执行”的工具，供给的却是功能齐全的分析平台；需要的是转移名单与路线，供给的是图层与工具箱。这种错配的根源在于需求表达：基层没有能力把自己的需求翻译成技术语言，技术方也没有动力去基层蹲点观察。结果是双方都以为自己知道对方要什么。

18.9.4 杠杆点排序与一个反常识结论

如果只能做一件事，最高杠杆是把“使用”写进考核与预算科目，因为它改变的是激励，而激励决定所有其他行为。第二杠杆是主数据与对象标识，它是一次性投入、长期收益，且不依赖任何新技术。第三杠杆是模型资产化与事后验证，成本低，但对“信任”的边际改善最大。最低杠杆是再建一个平台——在现有能力已经相对充足的情况下，新建平台对整体水平的提升非常有限，却会进一步分散运维资源。

由此得到一个反常识的结论：多数痛点不能靠“更多投入”解决，只能靠“改变激励”。只要考核的是建成率，就一定会建成一批没人用的系统；只要运维没有科目，就一定会出现建成即停更；只要共享没有免责规则，就一定会出现数据接入但不更新。反过来说，这也意味着改进的空间很大：前文列出的多数干预动作——定对象标识规则、给接口纳入运维合同、在预案中写明出图责任、把使用日志纳入验收、预置合规授权——都不需要大额投资，只需要有人拍板并承担协调成本。真正的稀缺资源不是钱，是协调意愿。

表18-9 痛点、根因与杠杆点的对照

边界提示：根因分析容易滑向“制度决定论”，即认为在制度不变的前提下什么都做不了。这个判断过于悲观。前述多数干预动作都在现有制度框架内可行，只是需要有人承担协调成本。真正做不到的是“一次性解决”，可以做到的是“每年解决一两个接口问题”。

本章小结

本章把八类痛点逐一拆到机制层面，得到的第一个结论是：这些痛点几乎都不是知识问题或技术问题，而是激励与流程问题。底数衰减是因为数据生产没有挂在必经流程上；融合困难是因为没有对象标识规则；模型不可信是因为没有验证义务；系统烟囱是因为系统成了预算的唯一容器。每一条都能追溯到具体的制度安排，也都能在现有框架内找到成本不高的干预动作。

第二个结论是：痛点的分布不均衡，改进应当抓接口而不是抓单项。当前最值得优先处理的是三个接口——影像到判断、普查到更新、模型到转移决策。这三个接口打通之后，整体水平的提升会明显大于在任何单项能力上继续加码。相反，如果继续在每个单项上追求“更全更强”，得到的会是一批各自很强但互不相通的能力。

第三个结论是：制度、机制、能力三层中，能力层的投入最容易做也最容易失效。能力层的问题不是人少，而是岗位、工具与流程不匹配；解决方式不是培训更多人，而是把方法产品化、把职责写进岗位、把需求从基层倒推出来。这些动作都不需要大额投资，需要的是协调意愿和持续的推动。

最后一个提醒：痛点的描述很容易变成自我安慰——把它们归因于“客观条件”，就可以不做改变。本章刻意避免这种写法。多数约束是真实的，但约束之内的选择空间比通常以为的要大。真正的差别不在于有没有约束，而在于有没有人在约束内把一两件事做到底。

思考与练习

1. 选一个你亲历的“数据更新滞后”问题，用三问方法拆解，写出可改变的变量与干预动作。
2. 某市新建系统与既有系统数据对不上，写清“对不上”的具体形态（对象、编码、口径各一条）与修复顺序。
3. 为洪水淹没模型建立“验证义务”，请写出验证数据来源、频率、责任人与不合格处置。
4. 用预算与考核的角度解释烟囱式系统反复出现的原因，并给出两条制度性约束建议。
5. 把“影像到判断、普查到更新、模型到转移决策”三处接口各写一条成本最低的打通动作。
6. 为什么“培训更多人”不能解决能力层问题？请写出替代动作清单（至少三条）。