中国校园放学治理体系白皮书

网页版本不是 226 页 PDF 的逐页复刻，而是围绕核心章节、关键方法和主要表格形成的在线导读，便于搜索、定位和快速判断这份白皮书是否值得继续阅读。原始 PDF 保留更完整的论述、版式与阅读节奏，是本白皮书的正式完整版本。

PDF 无需输入打开密码，允许阅读、传播、复制和打印；通过所有者密码限制修改、页面重组和表单变更。PDF 权限属于文档级保护，最终执行效果仍取决于阅读器是否遵守权限。

这份白皮书先解释放学为什么难，再把拥堵、安全交接、状态流转、异常处置和数据责任放进同一治理框架；随后讨论可视化系统怎样连接现场，以及学校怎样通过试点和同口径指标验证效果。

研究脉络属于本白皮书的内容导读，不代表未来每一份白皮书都会采用相同结构。

放学是学校每天都要完成的一次高密度协同。真正需要治理的不是单一通知，也不是一块大屏，而是学生状态、教师操作、家长到达、校门放行、异常处置和事后复盘之间能否形成一致、可执行、可追溯的闭环。

放学持续时间短，却同时集中安全、秩序、沟通、交通和服务体验等多类压力。学校通常已经拥有广播、微信群、门岗、班主任经验和若干设备，但这些资源如果没有统一状态和责任边界，仍会在高峰、雨天、临时调课、多校门或代接场景中失去同步。

本白皮书把校园放学治理拆成四个层次：第一层看清真实问题，第二层建立校内流程，第三层用数字系统连接状态和记录，第四层再讨论校门交通、区域协同与多校区管理。这个顺序可以避免把所有问题都归结为“缺少一个系统”，也避免把系统能力夸大为能够替代道路、制度和现场岗位。

全文使用三类证据：法律政策和权威指引用于确定责任与边界；可复用方法用于帮助学校诊断和试点；比例、效果和案例结果必须附带样本、地点、时间、测量口径和来源。没有这些条件的数字只能作为待验证假设。

放学难，不是因为某一个岗位没有努力，而是因为多个角色在相同的短时间窗口内处理不同目标。

对班主任而言，核心任务是确认本班学生状态并安全完成交接；对门岗而言，重点是校门秩序、人员识别和通道控制；对家长而言，最关心孩子什么时候出来、在哪里等待以及临时变化是否可信；对学校管理者而言，还需要知道过程是否按规则执行、异常是否处理、问题能否复盘。

这些目标并不天然一致。家长为了减少不确定性会提前到达，提前到达又会增加校门等待密度；教师为了安全可能放慢交接，但缺少状态同步时，门岗和家长会不断询问；学校为了提高效率可能扩大批次，但道路和等候区未必能够承受。放学治理需要在安全、效率、秩序和体验之间作出可解释的平衡。

因此，学校不能只统计“几点放完”，还应观察峰值持续时间、长尾等待、身份核验、迟接照护、通知有效性、冲突点和岗位负担。只有把这些维度放在同一张流程图里，才能判断问题究竟来自规则、空间、信息还是执行。

“车多”是表象。时间集中、空间冲突、信息不同步和异常无闭环，才是更稳定的诊断框架。

典型校门同时包含步行学生与家长、非机动车接送、自行车离校、私家车接送以及公交或地铁换乘。不同流线的速度、停留时间、空间需求和风险不同，却常常共用同一出口、同一等候区和同一放学窗口。

时间集中会让瞬时需求超过校门和道路承载；空间冲突会让等候、交接、通行、停车和掉头互相侵占；信息不同步会让家长提前到达并延长停留；异常无闭环会使迟接、代接、通知失败和设备故障转化为现场争议。四类成因可能同时存在，但主次顺序因学校而异。

诊断时不应直接套用其他学校的接送比例或改善数字。学校应在日常、雨天、活动日和临时道路变化等条件下，记录批次时间、峰值人数、等待时间、冲突位置和异常事件，再决定使用错峰、分区、远端接驳、信息同步或现场协同等措施。

一个方案不能只追求更快放完，还要同时回答安全、确定性、秩序、协同、可追溯和可恢复。

安全目标要求学生交接、人员通行、校门秩序和异常处置不因追求速度而降低标准。确定性目标要求各角色知道当前发生什么、下一步做什么、何时再次更新。秩序目标关注人车流线、等待区域和批次是否稳定。

协同目标要求教师、门岗、家长和管理人员使用一致状态，而不是在多个群聊和口头指令之间来回确认。可追溯目标要求关键操作、通知和异常能够事后查询。可恢复目标则要求断网、停电、设备故障、极端天气或人员缺岗时仍有安全降级流程。

六项目标之间可能发生冲突。例如加强核验可能增加平均交接时间，减少等待可能需要增加批次或岗位。学校应预先确定安全底线和权衡规则，避免把某一个效率指标变成唯一考核目标。

可视化放学系统是一套状态和流程系统，大屏、小程序、刷卡或闸机只是不同入口与终端。

系统从触发开始：教师、平板、刷卡、校牌或闸机产生事件；随后进行身份和权限校验，读取学校、年级、班级、批次、留堂和通知规则；符合条件后进入状态流转，并生成通知、显示、播报、回刷和日志记录。

可视化的意义不是把更多信息展示在屏幕上，而是让不同角色看到与自身职责一致的状态。教师需要知道班级和学生是否可以放行，门岗需要知道通道和异常，家长需要知道进度和接送要求，管理者需要看到全校节奏和事后记录。

系统必须明确边界：它可以支持状态同步、规则执行和过程留痕，但不能替代道路改造、现场专业判断、行政执法、监护责任和学校安全制度。涉及身份、位置、车辆或图像时，还必须遵循个人信息保护要求。

只有把“未放学、可交接、放学中、已离校、迟接、留堂和异常”定义清楚，多端协同才不会互相覆盖。

传统现场常用“放了”“没放”“家长来了”等自然语言表达状态，但不同岗位对这些词的理解可能不同。系统需要把状态、进入条件、允许动作、退出条件和责任岗位写成可执行规则。

班级状态和学生状态应分开。班级进入放学中，并不等于每名学生已经离校；学生完成刷卡或闸机事件，也不一定等于已经与授权接送人完成交接。系统设计应保留班级、学生、接送和通行之间的层次。

所有关键变化都应生成事件，包括触发人、触发端、时间、前后状态、规则结果和异常原因。撤销、回刷和人工修正不能直接覆盖历史记录，而应形成新的事件，才能支持复盘。

权限设计的核心不是功能菜单，而是谁能在什么范围、什么条件下改变什么状态。

教师通常只应操作自己负责的班级或学生；年级管理人员可以处理跨班批次和异常；门岗应看到与通行相关的状态，但不需要访问全部家庭信息；学校管理员负责配置规则、账号和审计；集团或教育管理视角优先使用汇总和脱敏数据。

高风险操作应设置更严格条件，例如撤销已离校、人工修改身份、批量改变状态、导出敏感数据或改变通知规则。系统可以通过二次确认、双人复核、操作原因和审计提醒降低误操作风险。

权限还应考虑临时代岗和人员变动。账号不应长期共用；临时权限需要明确有效期和范围；离岗后及时停用；日志应能关联到具体责任岗位。

通知不是越多越好。不同终端应围绕同一事件链，向不同角色提供必要信息。

家长通知应区分提示、行动和异常三种类型。提示类用于告知进度，行动类明确何时到达、在哪里等待和需要完成什么确认，异常类说明学生当前状态、学校正在做什么以及何时再次更新。

大屏适合展示班级、年级、通道和批次等公共状态，不应展示不必要的学生身份或家庭信息。语音播报应与屏幕状态一致，并控制模板、次数和优先级，避免多个来源重复播报。

通知系统必须记录应发送、已发送、送达、失败、重试和人工补救。不能只记录“点击发送”。当外部消息服务不可用时，学校应有站内提示、电话、广播或纸质名单等替代方式。

低年级接送必须形成授权、核验、当面交接、异常照护和记录闭环。

《中小学幼儿园安全管理办法》要求小学、幼儿园建立低年级学生、幼儿上下学接送交接制度，不得将晚离学校的低年级学生、幼儿交与无关人员。这意味着“家长认识”“孩子说认识”或一张转发截图都不应单独替代有效授权和必要复核。

临时代接应由监护人从学校认可的可信渠道发起，明确代接人、学生、有效时间和授权范围；信息不一致时，通过预留联系方式复核，而不是使用代接人现场提供的新号码。无法消除疑点时应停止放行并升级。

迟接学生应进入指定安全区域，由明确岗位继续照护。学校按预留顺序联系监护人与备用联系人，持续失联或出现风险时向值班负责人和学校管理层升级，并依制度联系属地有关部门。完成交接后记录实际接送人、时间和处理结果。

预警信号只是输入。学校还要判断学生位置、校舍、道路、接送能力和通信条件。

暴雨、雷电、台风、暴雪、道路结冰和高温会同时改变道路、校门、公共交通、家长到达和校内设施条件。学校应核对属地教育、气象、应急和交通部门的正式信息，再执行属地规定的停课、调整时间、安全留校或有序离校措施。

学生尚未到校、正在校内和已经开始离校，对应的响应完全不同。在校学生需要有安全区域、岗位值守、逐班清点和家长更新；已经在途的学生不能被远程指挥冒险折返；家长无法安全到达时，应转入迟接照护，而不是降低身份核验标准。

通知必须回答发生了什么、依据什么决定、学生在哪里、是否需要立即到校、新的时间地点、何时再次更新和联系哪个岗位。断网或停电时使用电话树、广播、纸质名单和人工回报，恢复后再补录。

系统可以调节到达和放行节奏，但物理空间仍需要“一校一策”的道路与现场方案。

学校应先画出学生、家长、非机动车、机动车和公共交通的真实流线，标记等待、交接、通行、掉头、汇入和过街等冲突点。校门内外的责任主体不同，任何交通管制、执法或公共道路调整都需要由有权限的部门依法决定。

常见措施包括错峰、单向交通、远端停车、校门缓冲区、不同校门分流、即停即走和公共交通衔接。措施是否适用取决于道路宽度、过境交通、学校规模、年龄结构和周边资源，不能把其他学校的固定顺序或百分比直接复制。

数字系统可以记录批次、家长到达、通道状态和峰值变化，帮助学校与交管部门识别问题；但系统不能替代交通设施评估、现场勤务和道路容量。

区域协同不是建设一块大屏，而是明确谁发现、谁研判、谁处置、谁反馈。

学校先完成校内分批、交接、告知和异常处置；教育部门推动区域标准、试点协调和风险督导；公安交管依法负责道路组织、设施评估、高峰勤务和执法；属地及相关部门按职责参与环境秩序、施工和资源协调。

协同流程应从问题开始，而不是从数据集中开始。学校使用统一口径记录位置、时段、类型和影响，区分校内流程、道路组织、设施和环境问题，再交给有职责的主体。处置完成后记录措施、结果和复核时间，并回写学校规则。

区域平台优先使用汇总趋势、风险类别和脱敏事件。只有在目的明确、具有合法性基础并确有必要时，才处理学生、家长、车辆或图像明细。

青鸽放学已经能够在网络互通或允许外网访问的多校区环境中使用；尚未完整的是集团侧汇总统计与统一分析。

教育集团不需要等待一套全新的集团版才能开始。只要各校区能够访问同一服务，或者各校区内网之间已经互通，就可以按校区建立组织、账号、班级、批次和权限，分别运行放学流程。每个校区仍保留自己的校门、设备、通知和现场规则。

集团场景的关键不是把所有校区配置成完全相同，而是区分统一标准和校区差异。集团可以统一身份规范、核心状态、最低安全要求和审计字段；校区保留作息、校门、设备、接送方式和通知策略。

当前需要继续开发的是集团侧数据统计功能，包括跨校区趋势、异常分类、运行对比和汇总报表。现阶段可通过校区独立查询和必要的数据导出完成管理，但不应把集团统计描述为已经完整交付。

放学系统处理的是未成年人相关场景，数据设计必须从目的和必要性出发。

学生身份、监护关系、接送授权、到达时间、车辆、位置和图像一旦能够关联特定自然人，就属于个人信息处理范围。不满十四周岁未成年人的个人信息属于敏感个人信息，需要更严格的目的、必要性、告知同意和保护措施。

数据最小化不是少做安全，而是只收集完成具体目的所需的数据。身份核验可以保存匹配结果、执行岗位和时间，不等于长期保存完整证件影像；区域统计可以使用匿名化数量和趋势，不等于集中全部学生明细。

系统还应设置访问控制、日志、保存期限、删除机制、备份恢复和供应链管理。人脸、位置和公共场所图像采集需要单独评估必要性，不应作为所有学校的默认方案。

部署方式应由网络边界、家长触达、现有设备和运维能力共同决定。

强调校内数据闭环的学校可以选择纯内网或本地化部署，通过平板、刷卡、闸机、本地大屏和校内后台完成流程。需要向家长提供微信小程序或外部消息触达时，则需要相应网络和服务能力，不能把小程序描述为纯内网方案。

已有 LED 大屏、广播、闸机、校牌或刷卡设备时，应先评估接口、身份字段、事件输出、时钟同步、异常反馈和离线能力。利旧的目标是减少重复建设，但不能为了使用旧设备而牺牲流程完整和安全边界。

部署验收需要同时检查功能、网络、安全、备份、故障降级和运维责任。学校应知道系统不可用时如何继续安全放学，以及恢复后如何补录。

风险治理不是列出风险名称，而是明确触发条件、保护动作、升级岗位和完成标准。

放学风险可以分为身份与交接、人员与交通、信息与协同、设备与数据、天气与外部条件五类。每类风险都需要预防、检测、处置、恢复和复盘，而不是只写一条应急联系电话。

异常处理应有状态和时限。例如通知失败后自动重试并转人工补救；身份不一致时停止放行并由指定岗位复核；设备故障时启用人工流程；极端天气时进入保护状态并逐人确认。

学校还应定期演练高风险但低频的场景。演练要记录是否按预案完成、是否出现新的风险、岗位是否清楚、替代通信是否有效，并据此更新规则。

试点要先定义问题、范围、基线、指标和停止条件，再用同口径数据判断效果。

一个合格试点应说明对象、问题、措施、周期和判断方式。例如“东校门一至三年级，验证批次调整和状态通知能否减少长尾等待与冲突”，比“全校上线智慧系统看看效果”更容易评估。

核心指标包括等待时间中位数和高分位数、峰值持续时间、异常闭环率、通知有效率、冲突事件率、岗位处理时长和安全降级成功率。基线与试点必须使用相同起止时点、位置和记录方式。

天气、活动、道路施工、班级变化、临时增加岗位和设备故障都可能影响结果。报告应同时呈现改善、无变化、恶化和无法判断的项目，并预先写明错误放行、严重状态不一致、隐私问题或降级不可用等停止条件。

实施不应从安装设备开始，而应从真实流程、角色和边界开始。

第一步是需求访谈和现场观察，确认学校类型、学生规模、校门、作息、接送方式、现有设备、网络边界和异常流程。第二步把真实流程画成状态、角色和事件图，明确哪些问题由系统处理，哪些依赖制度、空间或外部部门。

配置和联调阶段准备组织、账号、班级、学生、批次、通知、显示、播报和设备接口，并使用真实但受控的场景测试撤销、留堂、迟接、代接、通知失败和故障降级。培训应按角色进行，而不是一次性讲解全部功能。

试运行期间设置现场支持和每日复盘，问题按安全、规则、配置、设备、网络和使用习惯分类。正式上线不等于项目结束，学校还需要月度或学期复盘、账号清理、规则更新和应急演练。

采购应要求供应商用学校真实流程演示，并把能力边界、数据责任和故障降级写进验收。

学校应先确认需要解决的问题，再比较产品。只看大屏效果、功能数量或报价，容易忽略权限、异常、日志、部署和长期运维。演示最好使用学校真实的一次放学：谁发起、谁有权限、批次如何变化、家长如何收到通知、异常如何处理、事后能否查询。

合同和验收应区分标准能力、项目配置、接口适配、定制开发和研发方向。尚未完成的集团统计、自驾接送等能力应明确状态，不能以模糊语言当作已交付。

持续服务包括账号和权限维护、规则变更、设备接口、通知渠道、数据备份、故障响应、培训和复盘。学校应能够导出或查看必要的审计记录，并掌握系统不可用时的安全流程。

来源不是装饰。每一个效果数字都应能回答样本、地点、时间、口径和原始链接。

权威媒体和政府公开信息可以证明政策、事件和地方实践，但不能自动证明某个产品在所有学校都有效。产品案例应说明学校条件、实施范围、上线能力、测量周期和数据来源，并得到可公开授权。

效果数据应同时呈现原始数量和比例。例如异常闭环率提高，需要同时说明异常总数、闭环数、时限定义和缺失数据。等待时间应报告中位数、高分位数和样本量，而不只给平均数。

网页引用应链接到直接支持该结论的页面，PDF 应列出完整标题、发布机构和链接。对于需要本校验证的方法建议，应明确标注为建议、评估框架或试点假设，避免被误读为既成事实。

好的放学治理不是让所有学校使用同一种方案，而是让每所学校能够看清问题、明确责任、验证措施并持续复盘。

学校可以从一个校门、一个年级、一个高频异常或一次雨天放学开始。先建立可解释的状态和责任，再选择通知、大屏、刷卡、闸机、小程序或内网部署等技术组合。

青鸽放学关注的是把校内放学状态、协同动作和过程记录连接起来。对于校门道路、行政执法、公共交通和区域资源问题，系统只能提供信息与协同支持，仍需要学校和有权限的部门共同治理。

当学校能够用同一套口径回答“发生了什么、谁在处理、是否完成、效果如何、下次怎样改进”，放学才真正从依赖个人经验的现场工作，转变为可持续的治理能力。

引用用于确认学校安全、交通治理、个人信息保护、极端天气和试点评估的责任与方法边界。为保持正文阅读连贯，网页仅在章节末尾提供轻量来源入口。