SCHOOL PRACTICE

福建省龙岩市某公办幼儿园指挥版与闸机协同实践

老师发布班级放学后,已授权家长刷脸入园接领并携幼刷脸出园,通行记录与 9:00 到园统计进入同一复核链路。

案例速览

先看项目事实,再进入完整实施记录

这里集中呈现判断相似场景所需的基本事实;正文继续说明建设起点、方案取舍、实施过程、异常处理和复盘边界。

学校类型
福建省龙岩市公办幼儿园
主要操作
9:00 到园统计
协同范围
指挥版、闸机接口对接、接送关系与人脸资料
异常兜底
班级尚未放学、接送关系异常
公开方式
匿名实施记录
01 / 学校背景与场景

福建省龙岩市某公办幼儿园指挥版与闸机协同实践:先理解学校现场与建设起点

项目最终使用场景为福建省龙岩市一所公办幼儿园。幼儿园接送需要先由老师确认班级进入放学状态,再允许已授权家长进入校内接领幼儿,避免家长过早进入校园。

青鸽系统已维护学生、班级、监护关系及项目所需身份资料。项目在校方确认处理依据、授权范围、保存期限和设备接口后,按最小必要原则同步与接送关系关联的必要人脸资料,并回传有效通行事件。

班级放学由老师通过指挥版操作;校门 LED 与语音播报同步展示放学状态。对应班级放学后,已授权家长才可刷脸入园,接到幼儿后再次刷脸出园,形成接送与通行记录。

02 / 改造前的具体问题

先说明原有流程中真正需要解决的断点

接送关系与人脸资料对齐

学生、班级、监护关系与闸机设备侧人员编号需要一一对应;必要人脸资料只在校方授权和项目必要范围内处理。

家长进出方向可信

闸机事件需要区分家长入园和带幼儿出园,并处理重复识别、方向不明、设备离线和补传事件,避免把一次接送重复计数。

9:00 到园统计

每天 9:00 后按班级汇总应到与实到;应到基数需要结合当日学籍名单、请假和临时调整,实到人数来自有效进校事件。

班级与接送两层协同

指挥版回答哪个班级已允许接领,闸机回答哪位家长何时入园、何时带幼儿出园,两类事件不能混成同一个状态。

03 / 方案设计与流程

围绕学校原有管理方式组织系统流程

老师通过指挥版确认班级进入放学状态,同一次操作同步更新校门 LED 并触发语音播报;家长在校门外等待时即可查看和听取当前放学状态。

只有对应班级已由老师放学后,系统才向已授权家长开放刷脸入园权限;家长接到幼儿后再次刷脸出园,系统关联记录家长、幼儿、班级、方向、时间和设备。

到园统计以每天 9:00 为观察节点,按班级展示应到、实到、未到及待核人数;放学接送链路则把班级状态、家长入园和带幼儿出园分别留痕,供学校存档复核。

04 / 实施步骤与岗位

明确谁来操作、如何上线以及怎样逐步校准

确认接送流程

先确认老师通过指挥版发布班级放学,再允许对应家长刷脸入园;接到幼儿后由家长再次刷脸出园。

建立接送映射

核对学生、班级、授权家长、接送关系与闸机设备编号,并明确必要人脸资料的同步、更新和停用规则。

配置通行权限

把班级放学状态作为家长入园前置条件,分别记录家长入园和带幼儿出园事件,并配置去重、离线补传与异常状态。

定义统计口径

确定 9:00 后的应到基数、有效进校事件、请假与迟到处理方式,再按班级形成应到/实到统计。

上线验证

上线前使用真实但受控的测试名单完成 LED、语音播报、放学前拒绝入园、放学后家长入园、带幼儿出园、重复识别和后台复核验证。

05 / 通知与状态链路

一次操作如何传递到现场展示、播报与相关终端

9:00 到园统计

系统按校方确认的学生、班级、请假和有效进校事件,形成各班应到、实到、未到及待核统计。

校门等待提示

班级尚未放学时,家长在校门外通过 LED 和语音播报了解学校当前放学状态。

老师发布放学

老师通过指挥版确认本班进入放学状态,系统同步更新现场显示、播报与接送权限。

家长刷脸入园

只有对应班级已放学且家长身份与接送关系有效时,闸机才允许家长进入校内接领幼儿。

家长带幼儿出园

家长接到幼儿后再次刷脸出园,系统关联保存家长、幼儿、班级、方向、时间和设备记录。

学校复核

后台关联班级放学、家长入园、带幼儿出园、通知与异常结果,供学校存档、查询和争议复核。

06 / 异常处理方式

真实运行中如何处理临时变化和状态偏差

班级尚未放学

对应班级未由老师发布放学时,家长刷脸不获得入园权限,并继续通过 LED 和语音了解现场状态。

接送关系异常

家长身份未匹配、接送关系失效或必要资料不同步时,不自动放行,转由学校按制度人工核验。

重复与离线事件

使用事件标识、人员、设备、方向和时间窗口去重;离线补传保留原始发生时间与接收时间。

通知失败

通行记录与通知结果分别保存;通知失败不能抹掉已确认的进出校事件,并应提供重试或人工联系线索。

07 / 阶段结果与复盘

只呈现已经确认的变化,也保留后续改进边界

已确认采用指挥版与闸机协同:老师先发布班级放学,系统再允许对应家长刷脸入园,班级状态与家长通行保持不同业务层级。

已确认家长接到幼儿后需要再次刷脸出园,系统将家长、幼儿、班级与两次通行事件关联存档;9:00 到园统计仍按班级单独计算。

项目已于 2026 年 8 月 26 日完成上线部署,指挥版、LED 与语音播报、家长两次刷脸接送、班级到园统计和学校复核链路进入正式使用;运行表现以学校实际记录为准。

指挥版加闸机不是简单增加一台刷脸设备,而是把老师放学操作、LED 与语音提示、家长入园、带幼儿出园和学校复核拆成可追溯的不同事件。

幼儿及监护人的人脸资料属于敏感个人信息。类似项目必须先确认处理依据、告知或授权要求、最小必要字段、保存期限、传输安全、设备厂商责任和退出清理机制。

08 / 关联产品与能力

本案例实际使用或配套的产品能力

统一平台关系

本案例采用的操作端、LED 展示、语音播报、通知和操作记录进入同一学校任务与状态链路。

指挥版

由老师确认班级进入放学状态,并同步驱动现场提示和家长入园权限。

闸机接口对接

按已核验协议接收身份识别、进出方向、时间、设备和结果事件。

接送关系与人脸资料

在校方授权和最小必要范围内,处理学生、班级、授权家长、接送关系及必要人脸资料。

家长刷脸接送

班级放学后允许已授权家长刷脸入园,接到幼儿后再次刷脸出园并关联接送记录。

班级到园统计

9:00 后按学校口径统计各班应到、实到、未到和待核人数。

LED、语音、监护人通知与学校存档

校门 LED 和语音播报同步展示放学状态;按学校配置生成监护人通知,并关联保存班级操作、家长通行和通知结果供后续复核。

FAQ

常见问题

为什么必须先由老师发布班级放学,家长才能刷脸入园?

这是把班级放学状态与家长通行权限分开管理:老师先确认本班进入接送阶段,系统才向已授权且接送关系有效的家长开放入园,避免家长过早进入校园。

9:00 后的应到、实到人数怎样计算?

应到基数需结合当日班级名单、请假和临时调整;实到人数来自符合学校口径的有效进校事件。未匹配、重复或方向不明的事件进入待核,不直接计入实到。

家长人脸资料和通行记录需要怎样管理?

应由学校确认处理依据、授权范围、最小必要字段、保存期限和退出清理机制,并明确设备厂商与平台的责任边界;通行事件还应保留原始时间、方向、设备和异常结果供复核。