想着写这个主题的时候，我最先想到的是我前几年带着一个团队做一个区级的教育信息化团队做数据盘点。教研员提了个不算过分的要求：想看一份"全区中小学生体质健康"的汇总。听起来就是一张表的事。真干起来才知道，体测成绩躺在体育局的专项系统里，身高体重在每年的体检数据库，家庭结构在民政的低保台账，课后运动时长又在学校的延时服务记录里。四个系统、三种网络环境、两个归口单位，最后我们花了整整三周才把这条数据拼出来。

那次之后我有点较真：问题到底出在哪？后来想明白，不是缺技术，是两件最朴素的事没做好——数据怎么采得上来，采上来之后又怎么让人知道"我们有什么、在哪、谁能用"。也就是今天想聊的教育数据采集，和数据目录。

一、教育数据采集，远不是装个同步工具那么简单

说起教育大数据，很多人第一反应是"量大"。其实杨现民在几次报告里反复强调过，教育大数据之"大"，不是数量大，是价值大。国务院 2015 年《促进大数据发展行动纲要》对大数据本身的界定倒是很实在：容量大、类型多、存取速度快、应用价值高。那份文件里"共享"提了 59 次、"开放"36 次，说明上头早就认准了——数据是要流动的生产要素，不是锁在硬盘里的资产。

但教育数据的采集，比其他行业麻烦得多。你在电商平台买东西，行为轨迹天然就被记下来了；可一个学生在课堂上走神了几秒钟、在社团活动里扮演了什么角色，这些"自然状态"下的数据，传统手段基本采不到，采到的也往往是抽样、刻意、非自然的。杨现民把它叫"持续性、自然状态、全面"的采集，还要跨界、多源，能预测预警。这比"埋个点"难不是一个量级。

（一）教育数据长什么样：六个层次

按来源和范围，教育大数据可以分成六类。这套分法有意思的地方在于，它既是采集的范围，也是后面做目录时的组织维度。个体是最细的颗粒，往上每合并一层，管理的半径就扩大一圈。

（二）采集不是"有数据就行"，技术体系有四梁八柱

杨现民团队梳理过一套采集技术体系，分 4 大类、13 种常见技术，从传感器、日志、问卷到系统对接、网络爬虫、可穿戴设备都有。往后还会更多，眼动追踪、语音交互、体感交互都在路上。

但技术多不代表能乱采。他提的几点注意事项，我越做越觉得实在：提前规划设计、边界要清晰、保持连续性和规范性、粒度尽可能小、符合伦理。尤其是"粒度尽可能小"——很多项目一上来就汇总成月报，等到要做学情预警时，才发现最底层的那一条行为记录早被抹平了，想补救都补不回来。

（三）真到了多源异构的现场，坑比想象中密

理论归理论，落到工程上，我更想讲一个真实的踩坑案例。某教育集团六个校区，海淀、朝阳、西城、东城、丰台、通州，各自一套 MySQL 实例，存着学员、课程、成绩。要把它们统一采进数据仓库，团队第一版方案是直连六个源库做 ETL——结果上线第一天，朝阳校区赶上选课高峰，连接超时，整个采集任务卡死在那一步，后边四个校区一个没采。

后来又试过 UNION ALL 一把梭，六个校区的数十万行合成一张临时表，RDS 磁盘直接告警。连接信息还硬编码在代码里，密码一变就得改代码重新部署，运维差点提刀来见。

最后定下来的架构，说复杂也不复杂：临时库解耦 + 分校区采集 + 配置外置。每个校区独立写一张临时表，互不干扰；采集用 try-catch 包住，一个校区挂了只记进失败列表，不拖垮全局；连接配置挪到 .env 里。

这件事给我的触动是：多源采集真正的难点从来不是技术多高深，是架构得给容错留地方。一个源挂了，不能让全网陪葬。

二、从一堆库表字段到能用的"数据目录"

采上来只是一堆 raw 数据。真正让数据"被找到、被看懂、被信任"，靠的是目录。

（一）元数据是起点，但光有元数据不够

通俗讲，元数据就是"数据库设计文档里写的那点东西"——有哪些库、哪些表、哪些字段、字段中文名叫什么。通过数据平台的定时采集，把各业务系统的元数据进行上下合并，就得到"数据资源目录"。

但资源目录有个硬伤：它只告诉你"有什么"，不告诉你"归谁管、重不重要、能不能对外"。一张 student 表，到底属于教务还是学工？里面哪个字段是个人信息？这些管理属性，资源目录里是空的。

（二）把"资源目录"养成"资产目录"，要做三件事

我见过一份做得比较扎实的资产目录，它的形成过程可以拆成三步：

• 剔除行：把废弃表、备份表、冗余表清掉。别不信，实际做下来，接近一半的表是没用的。
• 补充列：给每张表补上三类属性——业务属性（它是什么、归哪个业务）、技术属性（存哪、怎么取）、管理属性（归哪个部门、安全分级是什么）。后一类越来越重要，直接连着数据安全和分类分级。
• 内容完善：很多系统上线时字段中文名没填全，得一条条补。我们甚至给研发提了要求：以后每次发版涉及字段增改，必须先把数据信息补全才批上线，不然永远在填坑。

（三）目录得"分层"，也得"看人下菜"

一份好目录不能摊成一张大宽表。它要有层次，也要针对不同对象给不同视图：给管理者看全集团数据家底的大屏，给研发和业务的查询地图，给上级主管单位的正式 Word 版目录。同一个底，多种面孔。

三、目录不能只管"有什么"，还得管"谁能看"

这是很容易被忽略、却最容易出事的一环。

（一）先分类分级，再谈共享

宝山区教育局出过一份《教育重要数据识别规则和重要数据目录管理办法（试行）》，思路很清晰：按数据的价值、内容敏感程度、影响范围和分发范围，把教育数据分成核心数据、重要数据、一般数据、公共数据、个人信息、教育教学数据，再做敏感级别划分。

识别原则也实在：聚焦安全影响、突出保护重点、衔接既有规定、定量定性结合、动态识别复评。简单说，重要不重要，不是拍脑袋，是按"一旦泄露会影响谁、影响多大"来判。

（二）共享的底线："共享为常态，不共享为例外"

目录管到这一步，就绕不开一个问题——数据给不给别人用。宝山的做法是三条：

宝山还强调"一次汇聚、充分共享"：各业务系统之间不得单独私拉数据对接，统一走区教育数据资源管理平台。这条我特别认同——多头对接看似快，实则每一根私拉线都是未来的数据责任死角。

四、目录建好之后，数据怎么真正流动起来

目录再漂亮，数据躺在里面不动，也是死的。

（一）教育为什么非做数据共享不可

市局、区县、学校各买过一套云平台，功能重叠，却互不认账——这是很多地方的真实写照。纵向上，市、区、校三级职能对应；横向上，基础教育处和信息化处各管一摊。数据权限层层加码，最后谁也调不动谁的库，"信息孤岛"就这么来的。

（二）共享系统长什么样

一套可用的教育数据共享系统，大致由"数据共享中心"和"个人工作台"两块组成。中心面向用数的人，提供目录查询、数据申请、审核、下载；工作台面向供数的人，做数据上报、管理、记录跟踪。所有共享走统一网关，带认证、日志、访问控制。

（三）流动起来之后，能解决什么真问题

举几个落地的例子：

• 学习动机分析。把学生课前预习、课堂互动、课后作业的数据聚合，再向民政、国土等部门要来家庭维度的数据，结合学习动机理论做多角分析，老师才第一次"看见"一个厌学孩子背后到底卡在哪。
• 学情预测。基础教育课程推进快，一个章节几周就过。共享更多数据后，系统能在学生掉队之前预警，而不是等期中考试砸了才叫家长。
• 贫困生助学金。这个例子我每次讲都觉得值。过去是让学生上台念申请稿，很多自尊心强的孩子宁可饿着也不举手。现在用住房、购车、父母工作、一卡通消费这些数据算一个贫困指数，悄悄把钱打到卡上。某个傍晚，一个刚上完体育课的孩子跑到食堂，发现卡里多了几百块——那种不动声色的好，正是数据该有的温度。

五、政策托底：《教育政务数据共享管理办法》划的硬杠杠

前面讲的目录、采集、共享，落到纸面上，现在有正式文件管着了。教育部 2026 年 2 月印发《教育政务数据共享管理办法》（教办〔2026〕1号），把"该共享的必须共享、谁提供谁负责、一切走平台"这些原则，用三十条条款钉成了硬要求。它管的是教育部门之间、以及教育部门和其他政府部门之间的政务数据共享。挑几条和前面直接相关的说。

（一）平台是"总枢纽"，线下私拉一律不行

第六条把数据共享平台定位为"总枢纽"，也是与国家政务大数据平台互联互通的总节点。所有共享的申请、审核、交换都得走平台。第十七条更直白：原则上不允许离线拷贝，确需拷贝的要报部网信办同意、点对点签收，一次拷贝 100 万条以上还得报部网信领导小组。这和前面宝山"一次汇聚、充分共享、不得私拉对接"是一脉相承的，只是从地方办法升成了部里红线。

（二）三类共享是法定分类，不是可选项

第十三条把共享属性分成无条件共享、有条件共享、不予共享三类，和宝山区那套口径一致。但办法更硬：第十五条明说，不得通过擅自增设条件来阻碍共享；列进"不予共享"的，必须有明确的法律、行政法规或国务院决定依据。换句话说，"不共享"得拿得出法律依据，不能凭习惯说不给就不给。前面第三节那张三类共享表，现在不是地方经验，是法定分类了。

（三）目录要"统一编制、动态更新"

第十一条、十二条：全国统一目录编制标准，由部网信办组织编制，目录里要含数据项、提供单位、数据格式、更新频率、共享属性、分类分级等；各部门编自己的目录，审核后发布。第十四条还给了硬时限——法律或职责一变，数源部门要在 10 个工作日内更新目录、报审，部网信办 2 个工作日内审完发布。这和我们做资产目录时"补充列、内容完善"是对得上的，只是多了法定节奏，不能想起来才动。

（四）申请和校核都卡着"天数"

第十六条到十八条把节奏写死了：无条件共享，数源部门 1 个工作日内答复；有条件共享，10 个工作日内审完，特殊情况可再延 10 个工作日。数源部门同意共享后，20 个工作日内必须共享出去。校核申请，10 个工作日内核实更正。退回不能"直接拒绝"，得一次性告诉对方补什么材料；不同意也得给明确理由。这些天数，是给"拖着不办"套上的缰绳。

（五）用数方有红线，提供方也不能说停就停

第十九条给需求部门划了线：严格按申请用途用，不能公开、不能转给第三方、不能擅自扩大范围或挪作他用；目的已实现、无法实现或不再必要的，要按要求处置，使用记录至少保存 5 年（二十一条）。数源部门这边，无正当理由也不得终止或变更已经提供的共享服务。两边都有责任，谁越界谁担责——二十七条、二十八条把数源部门和需求部门各自的违规情形和处分都列清楚了。

写到这，我其实有点拿不准。目录和采集这套方法论，技术上并不玄乎，真正卡人的，往往不是怎么建，而是建起来之后"谁提供、谁负责"这四个字怎么落。
跨部门的数据责任划分，比任何一张架构图都难画。
我们还在摸索，也只能继续摸索。