第13章 痛点诊断

本章导读

本章是第六篇的入口：它承接第12章对底线的讨论，把问题从“怎么建”换成“建成了为什么还是不好用”，并为第14章的成熟度评估提供问题清单。全章先立方法论——公开的痛点清单之所以不可用，是因为表述层级不齐、归因指向外部、清单又不随建设阶段调整；再把七类痛点按“现象—机理—根因—可解性”逐一拆开，最后在 13.9 节收敛为三类根因。最容易误读之处是把“可解性”读成难度排序：工程问题靠投入，制度问题靠规则，阶段性问题靠等待，三条路径不能互相替代。读完应能对任意一类痛点给出可检验的判断——它是否可被某一方独立改变。

学习目标

读完本章，你应当能够：

• 复述 13.1 节给出的三条理由，说明一份公开的“痛点清单”为何既解释一切又指导不了任何改进；
• 用“现象—机理—根因—可解性”四步，为 13.2 至 13.8 节的任一类痛点写出一份拆解，并标注它属于工程问题、制度问题还是阶段性问题；
• 对照表13-1 的七行，说出“数据之痛”“机制之痛”“标准之痛”三类痛点的根因为何重合；
• 用 13.4 节浙江“审查核对设为专项规划报批前置条件”的设计，解释“把外部要求转化为内部流程”的含义；
• 判断 13.5 节所述数据模型升级的最佳时机，并说明为何运行期迁移的代价会超过重建；
• 针对 13.9 节的三类根因各提一条可落地的过程性指标，并指出该指标由谁采集。

13.1 为什么痛点清单大多是假的

在进入具体分析之前，需要先说明一个方法论问题。公开可见的“痛点清单”绝大多数是不可用的，原因有三。

第一，痛点的表述层级不齐。“数据不共享”“标准不统一”“人才不足”这类表述，既是痛点也是万能理由，几乎可以解释任何失败，因此也无法指导任何改进。真正的痛点必须有边界：在什么条件下出现、影响多大、谁受影响最深。

第二，痛点的归因普遍指向外部。系统建设方倾向归因于业务部门不配合，业务部门倾向归因于系统不好用，主管部门倾向归因于地方不重视。归因一旦确定，改进动作就停止了。有效诊断必须找到“可被某一方独立改变”的环节。

第三，痛点会随建设阶段漂移。在数据整合阶段最痛的是底数不清，在平台上线阶段最痛的是性能与易用性，在场景推广阶段最痛的是规则冲突。用一份静态清单覆盖全过程，必然失焦。

本章的组织方式因此做了调整：每一类痛点都按“现象—机理—根因—可解性”四步写，其中“可解性”是判断该痛点属于“工程问题”“制度问题”还是“阶段性问题”，因为这三类问题的解决路径完全不同。工程问题靠投入，制度问题靠规则，阶段性问题靠等待。

13.2 数据之痛

现象。 三类表现最普遍：一是图层很多但不敢用，某一层的数据在甲地准确、在乙地失真；二是数据更新滞后于管理动作，业务已经办完，图上还没有痕迹；三是同一对象有多份数据，彼此不一致且无法判断哪份为准。

机理。 造成这三类现象的技术原因不同。图层不敢用的根因是质量不可度量——数据有精度指标，但没有“可用性”指标。一份 1:2000 的地类图斑在平原区完全够用，在山区可能因为影像判读误差而系统偏倚，但系统不会告诉你哪里不可信。更新滞后的根因是更新触发机制与业务链脱钩：如果数据更新依赖年度调查，那么任何在两次调查之间的管理动作都不会留在图上。多份数据不一致的根因是缺少唯一标识：同一块地在调查库、规划库、登记库里各有一个 ID，三个 ID 之间没有稳定的映射关系，于是每次比对都要靠空间位置去猜。

根因。 再往下追一层，数据之痛的共同根因是数据责任没有落到具体岗位。谁负责更新、更新到什么程度算合格、不更新有什么后果，这三个问题在多数单位没有明确答案。没有责任人，就没有更新；没有验收标准，就没有质量。

可解性。 属于工程问题与制度问题的混合。技术上可以通过质量元数据（每个图层的精度、来源、时点、可信度）与唯一标识体系显著改善；制度上必须把更新责任写进业务流程——例如规定“任何审批事项办结后 N 个工作日内必须回写空间痕迹”。

关键判断：数据治理的成败，不在于清洗了多少数据，而在于是否建立了“业务动作触发数据更新”的闭环。凡是依靠专项治理行动来更新数据的地区，治理结束后数据必然重新滞后；凡是把更新嵌入审批、登记、执法流程的地区，数据会自然保持现势。这是区分“治过”与“治住”的唯一标准。

13.3 标准之痛

现象。 最典型的表现是同一块地在不同系统里地类不同。耕地与林地的认定冲突是公开讨论最多的例子：一块山坡地，按种植现状可能被认定为耕地，按林木郁闭度可能被认定为林地，两套认定标准各有依据，都有相应的补贴与考核政策附着其上。冲突一旦发生，基层无法自行裁决。

机理。 标准冲突的本质不是技术错误，而是分类目的不同。土地利用分类服务于用途管制与耕地保护，森林资源分类服务于林业管理与生态考核，两者的分类维度并不完全重合（一个重现状用途，一个重植被属性）。当两套分类都被赋予法律效力时，冲突就必然出现，且无法通过“提高数据质量”消除。

根因。 根因在于缺少跨体系的裁决规则。技术标准解决“怎么分类”，但不解决“两个分类冲突时以谁为准”。这一层必须由制度给出答案。2026 年部领导在答记者问时提到，重庆、浙江等地“着力在解决耕地林地认定标准不一样、空间矛盾等方面做了大量工作，有效化解了相关矛盾，同时统筹优化了耕地保护和国土绿化的空间布局”——这句话的关键词是“化解”与“统筹优化”，说明实践中采取的不是简单的二选一，而是在具体地块上做实质性调整。

可解性。 属于制度问题。技术可以提供冲突识别的能力（自动发现同一空间的多重认定），但裁决权必须在制度层。可操作的方向有三：一是建立“一地一认定”的裁决流程，明确裁决主体与依据；二是对历史遗留冲突设定过渡期与处理规则；三是在新增数据入库环节增加冲突校验，防止增量冲突。

另一个常被忽略的标准问题是标准供给的结构性缺口。目前“一张图”没有总体国家标准，GB/T 39972—2021 只覆盖规划侧系统，而平台侧的国家标准仍在研（计划号 20243578-T-466，尚未发布），基础地理实体数据规范在编且无标准号。这意味着大量在建项目实际上是在“无标可依”的状态下自定规则，未来标准出台后必然面临改造。这不是任何一方的过失，而是标准制修订周期与工程进度之间的客观张力。

13.4 机制之痛

现象。 三种形态：一是数据能看不能用，其他部门要看数据必须先提申请、走流程，时效性无法满足业务；二是跨部门审批仍在各自的系统里完成，只是在最后环节把结果汇总到“一张图”展示；三是出了问题找不到责任主体，因为流程跨了多个系统。

机理。 机制之痛的技术表现是“集成度不足”，但真实原因是权责与数据权限不匹配。数据由 A 部门生产，B 部门使用，出错的后果由 B 承担，A 没有动力保证质量。这种不对称在任何一个多部门数据体系中都存在，只是“一张图”把它放大到了全域尺度。

根因。 根因是考核对象与数据责任主体错位。“一张图”建设的考核对象通常是自然资源主管部门，但数据的生产责任分散在农业、林业、水利、生态环境等多个部门。被考核者无法直接约束数据生产者，只能靠协调。协调的成本很高，效果不稳定。

可解性。 属于典型的制度问题，且难度最高。可行的路径是把数据质量纳入数据生产部门的考核，或者通过制度安排把数据责任部分转移——例如浙江的做法，把“规划‘一张图’”审查核对设为专项规划报批的前置条件，未通过原则上不得报批。这一设计的巧妙之处在于：它不要求规划编制部门“配合”数据工作，而是让数据成为报批的必要条件，从而把外部要求转化为内部流程。

13.5 技术之痛

现象。 具体而可测：大数据量下图层的加载与叠加分析响应慢；二维与三维割裂，同一栋楼在二维图上是一个面、在三维模型里是一个体，两者无法关联；跨库查询结果不一致，同一个统计口径在两个系统给出两个数。

机理。 性能问题的根源多在架构而非硬件。2026 年部公开的总体框架采用“物理分散、逻辑一体、互联互通”的分布式数据管理模式，这一模式在数据治理上是正确的（避免集中带来的权责与安全风险），但在性能上把瓶颈从数据库转移到了服务聚合层：一次跨区域的空间查询可能要穿透多个节点的服务，任何一跳延迟都会累积。解决方向不是加大单机配置，而是服务编排优化、结果缓存与预计算。

二三维割裂的根源是对象模型不统一。二维用图层组织，三维用模型组织，两者的最小单元不同。部里提出的以地理实体码为纽带关联实景三维与行业专题数据，正是试图在标识层打通。

跨库不一致的根源是统计口径的时点差异。两个系统各自的更新节拍不同，同一时点查询得到的其实是不同时点的快照。解决需要引入统一的时点参数与版本管理。

根因。 技术之痛的共同根因是缺乏统一的时空数据模型。多数系统沿用了“图层+属性表”的传统模型，而“一张图”需要的是“空间对象+时相+关系”的模型。模型不改，性能与一致性都会持续出问题。

可解性。 属于工程问题，但周期长。短期可通过架构优化缓解，中长期必须做数据模型升级。需要提醒的是，数据模型升级的代价极高，一旦系统上线运行多年，迁移成本会超过重建。因此这项工作的最佳时机是新建或大改，而不是运行期。

13.6 组织与人才之痛

现象。 县级最明显：有系统但没人会用；会用的人一旦调走，能力就断档；培训做了很多轮，回到岗位还是用老办法。

机理。 这不是培训强度不足，而是岗位设计与系统能力不匹配。如果系统要求使用者理解坐标系、图层、拓扑，那么绝大多数基层人员无法胜任；如果系统把这些复杂性封装掉，只暴露业务语言（这块地能不能建、属于哪类），则可用的概率大幅提升。换言之，人才之痛的很大一部分其实是产品设计问题。

根因。 根因是复合型人才的培养周期长于系统建设周期。一个既懂自然资源业务又懂空间数据的骨干，通常需要三到五年培养，而一套系统的建设周期往往只有一年。指望系统上线时人才同步到位，在时间上就不成立。可行的替代方案是降低系统的专业门槛，同时保留专业人员的深度操作入口——即所谓的“双通道设计”。

可解性。 阶段性问题与工程问题的混合。产品侧的改进可以显著缓解，人才培养只能靠时间积累。

13.7 投入产出之痛

现象。 建设投入可以算清，效益无法量化。汇报时常用“效率提升”“材料减少”作证，但这些指标往往只覆盖了最显著的场景，无法反映整体。

机理。 效益难量化有三个技术原因：一是“一张图”的产出主要是避免损失而非创造收益，避免的损失不体现在任何账目上；二是效益分散在多个部门，没有单一主体有动力统计；三是效益有时间滞后，数据治理的收益往往在两三年后才显现。

根因。 根因是评价体系与建设目标不匹配。如果建设目标是“业务协同”，评价体系就应当度量协同程度，而不是度量系统功能数量。现实中的评价体系往往偏向可计数的工程指标。

可解性。 属于制度问题。第十四章提出的成熟度评估模型，正是为这类评价提供一种可操作的替代方案。

需要补充一个产业侧的观察，它从另一个角度印证了投入产出的压力。据中国地理信息产业协会口径，2025 年产业总产值 9005 亿元、同比增长 5.9%，从业单位 26.9 万家、单位数增速 11.1%。单位数增速高于产值增速，意味着单机构平均营收在下降。官方“十五五”期间年均产业总产值突破万亿元的目标，隐含增速约 2%—3%，低于当期增速。这组数据说明行业整体处于“增量放缓、主体增多”的状态，项目制供给模式的利润空间在收窄。对“一张图”这类大型工程而言，这意味着承建方的持续投入能力会受到约束——这本身就是一个需要在规划阶段考虑的风险。

13.8 合规与安全之痛

现象。 三种具体摩擦：一是同一个数据要给不同对象提供不同版本，工作量大且容易出错；二是审图周期与业务时效冲突，动态生成的地图服务几乎无法逐幅送审；三是脱密处理后的数据在内部使用时精度不足，影响判读。

机理。 合规之痛的本质是“一套数据、多种用途、不同密级”的结构性矛盾。同一份高精度数据，对内管理需要完整精度，对外服务需要脱密版本，公开发布需要审图。如果只有一套数据，就无法同时满足；如果做多套，就产生一致性维护的成本。

根因。 根因是缺少按用途分层的产品体系。2026 年部里提出“完成现有基础测绘成果的公众版加工编制，研制多类型多尺度多功能公众版测绘成果”，以及“建立‘一张图’地理底图联动更新机制，统筹推进‘一张图’地理底图与天地图融合更新”，正是试图建立“一套数据、多种产品”的体系。这个方向如果落地，合规摩擦会显著下降。

可解性。 属于工程与制度的混合。技术上要解决多版本的一致性与联动更新，制度上要明确不同版本的使用边界与责任。

13.9 根因归纳

把上述七类痛点收敛，可以归纳出三个根因，它们分别对应三个不同的解法。

第一类根因：制度未与流程绑定。 数据更新责任、质量责任、裁决责任都没有落到具体流程节点上，导致所有责任最终都落到“协调”上。解法是把要求嵌入流程——例如“办结即回写”“未通过比对不得报批”。浙江的第二十条设计是这个方向的范例。

第二类根因：能力建设滞后于系统建设。 系统按理想状态设计，使用者按现实能力配置，两者之间的落差由培训填补，而培训填不满。解法是产品分层——把专业能力封装成业务语言，同时保留专业入口。

第三类根因：缺少可操作的度量。 无法度量就无法改进，也无法评价。解法是建立过程性指标而非结果性指标，例如“审批在图内闭环的比例”“数据更新的平均滞后天数”“冲突的自动发现率”。

表13-1 把七类痛点与三类根因对应起来，并标注可解性判断。

表13-1 七类痛点的机理与可解性判断

本章小结

本章没有采用罗列式写法，而是对每一类痛点做了四步拆解。这样做的好处是能区分“可以靠投入解决的”和“投入也解决不了的”——后者才是真正的风险。

从七类痛点的分析看，数据、标准、机制三类痛点的根因高度重合，都指向同一个问题：制度要求没有嵌入业务流程。这意味着它们不能通过加强数据治理来解决，只能通过改造流程来解决。技术类痛点的根因是缺少统一的时空数据模型，属于工程问题但周期长，最佳解决时机是新建或大改。组织与人才类痛点的相当一部分其实是产品设计问题，可以通过降低专业门槛显著缓解。投入产出与合规安全两类痛点，则需要新的度量方式与产品体系。

三类根因给出三个解法方向：把要求嵌入流程、把复杂性封装进产品、把评价从结果指标转向过程指标。这三件事都不在传统的信息化项目范围内，这也解释了为什么“一张图”在多数地区的推进速度慢于预期——它要求的能力超出了承建方与业主方习惯的能力边界。

最后需要说明一个容易被忽略的判断：痛点不是均匀分布的。在同一时刻，不同地区、不同层级、不同业务条线所处的痛点阶段完全不同。一个已完成底图统一的省份，其最痛的点可能已经从“数据不一致”转为“场景不闭环”；而一个刚开始建设的县，最痛的仍是“底数不清”。因此任何跨区域的统一方案，都必须保留分层适配的空间，否则会在解决旧痛点的同时制造新的痛点。

思考与练习

1. 13.1 节称痛点会随建设阶段漂移。请以 13.5 节的“性能与易用性”和 13.6 节的“有系统但没人会用”为例，说明一个刚完成底图统一的省份与一个刚开始建设的县，各自最痛的点为何不同，并判断这对跨区域统一方案意味着什么。
2. 对照表13-1 的七行，逐一核对每行“根因归类”与“可解性”两列是否自洽：哪些行标为“工程+制度”或“阶段+工程”，请说明为什么单一解法不够。
3. 辨析题：一种流行说法是“只要数据治理到位，标准与机制问题自然消解”。请用 13.3 节“分类目的不同”与 13.4 节“考核对象与数据责任主体错位”两处分析反驳它，并指出该说法在哪个具体环节上失效。
4. 13.7 节引用 2025 年产业总产值 9005 亿元、同比增长 5.9%，从业单位 26.9 万家、单位数增速 11.1%。请用这组数字说明“增量放缓、主体增多”对承建方持续投入能力的影响，并指出这一风险应在项目周期的哪个阶段被纳入考虑。
5. 动手题：从 13.2 至 13.8 节任选一类痛点，画一张四格图（现象、机理、根因、可解性），每格只写一句判断，并在根因格旁标注“可被哪一方独立改变”。完成后与表13-1 对应行比对，指出你的判断与该行的差异。
6. 13.9 节提出“缺少可操作的度量”这一根因。请为本地设计三条过程性指标，写明指标定义、采集方式与采集频次，并说明为何不采用“系统上线数量”这类结果指标。

接下来：本章把痛点拆到了根因，却还没有回答“改到什么程度才算改好”，第14章 成熟度评估模型 用五级五维的尺子接住这个问题——没有度量，痛点诊断只能停留在经验层面。