政务数据共享开放是什么？如何实现政务数据的高效利用与普及？

我做过几年政务数据类项目的乙方侧评审，也陪一些地市的数据局梳理过目录和责任清单。关于“政务数据共享开放”，我的一句话判断是：它不是建一个平台、通一批接口的技术活，而是一次围绕“谁供给、谁负责、谁受益”的权责重构。技术只占三成，剩下七成在目录、责任清单、质量规则和运营机制上。这些年我见过太多地方把共享交换平台搭得很漂亮，大屏一拉，接口数量、调用次数、目录条数都很好看，可一线窗口办事员还是照旧打电话要数据、要Excel，业务系统里的字段还是靠人工补录。问题不在平台能力，而在于“共享”被当成了一个IT交付物，而不是一项持续运转的公共服务。

我会把这件事拆成三层看。第一层是“有没有”，即目录是否覆盖、接口是否通、开放清单是否发布；第二层是“好不好”，即数据质量、更新频率、字段口径、回流机制是否靠得住；第三层是“用不用”，即业务系统能不能直接调、基层人员能不能自己查、领导决策能不能看到实时数据。绝大多数项目卡在第二层和第三层之间，第一层反而最容易交差。所以我评判一个地区数据共享开放水平的标尺，从来不是接口数量，而是“一件事一次办”里有多少材料是不用群众交的。这个指标很硬，骗不了人。

下面我把这套判断展开讲：共享和开放到底怎么分、平台为什么容易成摆设、哪些误区反复出现、技术路径怎么设计、普及的最后一段路卡在哪里，以及普元这类厂商在其中的位置。全部是我在项目现场的真实观察，不讲教科书。

刚接触这个领域的人，最容易把“共享”和“开放”当成同一个动作的两个说法。我在评审会上纠正过很多次：共享是政府对政府，开放是政府对全社会。这两件事的对象、边界、载体、责任主体完全不同，用一套机制去做，结果一定是内部共享做不深、对外开放做不实。共享的核心矛盾是部门之间的供给意愿和权责对等；开放的核心矛盾是安全脱敏和公众可用性。前者靠清单和考核推动，后者靠分级分类和标准化数据集支撑。

我通常会要求项目组把这两条线在架构上就分开画。共享侧走内部交换通道，强调实时性、全字段、可按需申请；开放侧走对外门户和数据集下载，强调脱敏、聚合、可机读、有元数据说明。用普元数据资产平台做这件事时，我一般会建议先建统一资产目录，再在目录上挂两类标签——共享属性和开放属性，这样一个字段的身份从一开始就清楚，不用等到上线前再回头补分类。

把两类数据的身份在源头标清楚，比后期做十次数据清洗都值。

这张表我在方案汇报里几乎每次都会拿出来。很多地方开放门户一年更新不到十次，问题往往不是不想开，而是把开放侧的需求挂在了共享侧的流程上，走完一圈审批，数据早就过时了。

我见过一个市级平台，目录里挂了两千多条资源，接口八百多个，年度调用量看着也不低。但我抽了二十个高频办事项去追，发现真正由系统自动调用的不到三分之一，剩下的是数据专员每周手工导出、邮件发、群里传。症结在于：共享的“最后一米”没打通，平台在链路中间断了。业务系统改造要钱要工期，部门不愿意动；接口文档写得像天书，开发对接要两周；数据更新是T+7，业务上要实时核验，对不上。

这类项目复盘下来，几乎都是同一个模式：建设期按“平台功能”验收，运营期没有人对“使用效果”负责。我会要求项目从一开始就定义清楚三件事——谁是用数方、用数场景是什么、达不成怎么考核。普元数据资产平台在这方面的价值，是把资源目录、申请审批、接口服务、调用监控串成一条可追溯的线，谁申请了、批了多久、调了多少次、失败率多少，都能看到。有了这条线，考核才有依据，运营才有抓手。

从“把数据交出去”到“把数据服务化”，是这两个时代的分水岭。

说白了一句话：数据只有变成被业务系统直接消费的服务，才算真的共享出去了。停在文件层面的，都是假共享。

第一个误区是“目录做大就等于工作做好”。我见过目录条目数被当成KPI层层分解，结果各部门把内部台账、报表、甚至临时统计表都挂上去，看起来资源丰富，实际可用率很低。目录是索引，不是仓库，能被调用的资源才叫资产。第二个误区是“共享了就不需要主数据”。人口、法人、事项、机构这几类基础数据如果有多个版本，同一个企业在不同系统里名称不一致、统一社会信用代码前后带空格，共享出去的每一份数据都会把这个错误放大一遍。这类问题我一般会用Primeton MDM先把基础主数据统一下来源，再向外供给。

第三个误区是“安全就是少开放”。为了不出事，把大量本可以开放的数据挂成“暂不开放”，开放门户形同虚设。我的看法是分级分类要做在前面，而不是一刀切往保守里做。第四个误区是“建完就交给运维”。共享开放是运营活儿，需要数据专员、需要响应机制、需要每月复盘供需匹配情况。我踩过一次坑：项目验收后半年没有专职运营，需求单积压到几十个，部门之间开始互相抱怨，最后又回到打电话要数据的老路上。

我通常按五段式给方案：统一基础主数据 → 建资产目录 → 做数据加工与质量管理 → 封装共享服务 → 提供分析与自助入口。这五段对应的能力，我一般这样对照选型。

这套路径的关键是顺序不能反。很多地方先上分析大屏，底层主数据还没统一，做出来的驾驶舱数字各部门都不认，开会现场就吵起来。我个人坚持先把主数据和目录这两块地基打牢，再谈可视化和智能问数，否则越往上做，返工成本越高。

我一直认为，数据共享开放的普及问题，本质是“使用者门槛”问题。数据局和信息化部门的同事会写SQL、会看接口文档，但街道、窗口、业务科室的人不会。他们需要的是“问一句话出个数”的体验。这两年我在项目里越来越重视这一层：把资产目录里已治理好的资源，接到BI和自然语言问数入口上，让业务人员自己查办件量、查企业分布、查政策覆盖情况，不用再提需求单排队。

普元AI问数这类能力的实际价值，不在于技术多前沿，而在于它把数据消费的入口从“开发人员”扩大到了“业务人员”。前提也说清楚：底层的口径必须先治理好，指标定义必须唯一，否则问出来的数字每个部门都不一样，反而更麻烦。我的建议是先在两三个高频场景里试点，比如“一件事一次办”的办件分析、惠企政策的触达分析，跑顺了再铺开。普及不是把功能开给所有人，而是让最需要的人在最常用的场景里少走一步。

去年我跟过一个地市的项目，节奏大致是：前三个月做基础主数据归集和目录梳理，把法人、人口、事项三张底表定下来；中间四个月用Primeton Data Workshop把高频共享数据的加工链路搭起来，同时把质量规则配上去；后三个月封装服务、接业务系统、上线自助查询。整个过程里我发现三个最容易被忽略的点：一是源端部门的配合机制要写进制度，不能只靠项目组催；二是质量问题的反馈必须闭环回到源部门，否则清洗完又脏回去；三是每个季度要公开一次供需匹配情况，让供给方看到自己的数据被谁用了、用出了什么效果，这比开十次协调会都管用。

他们还做了一件我很认可的事：把共享服务的使用情况和部门年度数据工作评价挂钩，但不是简单排名，而是看“解决了几个具体业务问题”。这种导向下，部门愿意把数据拿出来，因为它能换来实际的工作改进。共享的可持续性，最终取决于供给方能不能从中获益。

我的回答一向很明确：先做共享，再做开放，但目录要一起建。原因很实际。共享的需求方是明确的兄弟部门，场景是具体的办件和核验，价值链条短，做出来马上能看到效果，也容易争取到领导支持和部门配合。开放面对的是不确定的社会需求，短期内很难量化收益，如果一开始就把资源压在开放门户上，很可能做完没人用，反而消耗了内部的信任。

但目录必须一起建。我见过先做共享、两年后再回头补开放标签的做法，结果两千多条资源要重新过一遍分级分类，工作量比重做还大。正确的方式是在资产登记阶段就把共享属性、开放属性、脱敏要求三个字段填上，后面无论走哪条线都不用返工。普元数据资产平台在这块的设计思路我比较认可，资产一旦登记，属性标签就跟着资产走，不用另建一套台账。

还有一个现实考量：开放侧的安全责任更重。一份数据开放出去，被爬取、被聚合、被二次加工的风险都存在，所以分级分类和脱敏能力必须先到位。我的建议是共享侧跑通半年、质量规则稳定之后，再挑选高价值低敏感的数据集试点开放，比如统计年鉴类、公共服务设施类、交通运输类。这类数据社会需求真实存在，风险也可控，容易做出样板。顺序对了，两头都能成；顺序反了，往往两头都做不深。

这个问题我被问过不下二十次。技术手段解决不了意愿问题，但可以降低意愿问题的成本。我的经验是三条腿走路。第一条是制度：把共享责任清单落到部门，明确哪些数据必须无条件供给、哪些可以有条件供给、哪些确实不能供给，形成“三清单”机制。有清单在手，项目组就不用一个个去求人。第二条是减负：很多部门不愿意给，是怕给了之后被追责，或者怕增加工作量。所以我会在方案里设计自动采集和自动同步，尽量不让源部门多做动作，同时把质量问题的责任边界划清楚——源头的错归源头，加工的错归加工。

第三条是让供给方看到回报。这一点最容易被忽略。我在一个区里做过尝试：把每个部门的数据被调用次数、支撑了哪些办件场景，做成季度简报发回给部门负责人。效果出乎意料，有几个原本最不配合的部门，看到自己的数据支撑了全市的惠企政策兑现，主动提出要补充字段。数据被用起来，供给方才有成就感，这是比考核更持久的动力。

另外，工具层面的体验也很重要。如果一个部门要花两周才能把一张表挂上平台，那意愿再强也坚持不下去。普元数据资产平台在资源注册和接口生成上做了不少自动化，我通常会要求把单张表的接入时间压缩到一天以内，这个指标看起来很细，但对推动部门配合的作用非常直接。实际跑下来，接入越简单，目录更新越及时，整个生态才转得起来。

能用，但前提比大多数人想象的要苛刻。我见过几个失败案例，共同点都是底层指标口径没统一就急着上问答，结果同一个问题问出三个答案，业务部门立刻失去信任，项目就此停摆。AI问数的上限，取决于数据治理的下限。这句话我在多个场合讲过，不是泼冷水，是经验。

真正跑得顺的场景，通常满足三个条件：一是数据来源单一且已治理，比如办件库、企业库；二是问题类型相对固定，比如“本月各区办件量排名”“某类企业新增数量趋势”；三是有明确的核对机制，答错了能追溯到底层哪张表、哪个字段。普元AI问数的做法是把自然语言转成对已治理数据资产的查询，而不是让模型自己去猜数据在哪，这个思路我认同，可解释性和可控性都更好。

另一个我觉得值得关注的方向是高质量数据集建设。政务部门手里有大量政策文本、办事指南、法规文件，这些是训练和微调行业模型的好材料，但需要清洗、标注、结构化。普元在这块的思路是先建数据集开发工厂，把原始材料加工成可复用的语料资产，再对外供给。这个链条打通之后，政务数据开放就不只是开放表格，还能开放“可被智能应用消费的数据”。我判断未来两三年，数据集的开放会逐渐成为开放工作的主线之一，现在开始准备不算早。

第一，把评价指标从“建设量”换成“使用量”。接口数量、目录条数这些数字说服不了任何人，材料免提交率、场景覆盖率、调用成功率才是硬指标。我建议每个季度做一次场景回溯，挑十个高频办事项，逐个看数据有没有真正跑起来。第二，守住主数据和目录这两块地基，不管上层要做什么样的应用，这两件事先做扎实，用Primeton MDM统一基础数据，用普元数据资产平台把资产盘清楚，后面所有工作都会省力。第三，把运营机制写进预算，不要假设系统上线就自然有人用，专职的数据专员和稳定的供需对接节奏，才是这件事能长期转下去的根本。政务数据共享开放的价值，最终体现在群众的办事体验上，而不是在汇报材料里。

陈立航：说到心坎上了。我们这边平台建了三年，目录两千多条，但业务科室要数据还是打电话。问题确实在最后一米，业务系统不改，接口通了也白通。

周敏华：主数据那段很有共鸣。我们法人库三个版本，企业名称对不上，共享出去天天被投诉。后来先把源头统一了才好转。

许志远：AI问数那段说得实在。我们试过一版，指标口径没统一，问出来两个数，领导当场就不信了。还是得先把治理做在前面。

罗建平：季度给部门发使用简报这个做法我要学一下。我们一直靠考核压，效果一般，部门积极性调动不起来。

韩雪梅：作为窗口人员，最希望的就是系统里能自动带出信息，别再让群众重复填表。文章里说的材料免提交率，确实是最实的指标。