产品版本与部署方式

不是。小程序版是青鸽放学协同平台面向特定学校场景形成的常用方案入口，与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。

可以评估升级到指挥、刷卡、闸机或组合方案。升级前需要重新确认账号与数据结构、学校网络、已有设备接口、历史数据迁移和通知渠道，不能默认所有环境都能无改造升级。

适合幼儿园、小规模学校、快速试点和主要诉求是老师操作加家长通知的学校。

不是。闸机版是青鸽放学协同平台面向特定学校场景形成的常用方案入口，与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。

可以按学校规则配置，但闸机事件不能未经校验直接外发。系统需要确认学生身份、事件方向、有效时段和重复事件，再结合网络边界与通知渠道生成相应记录或消息。

不是。已有闸机、人脸识别或刷卡设备的学校，也可以评估事件接入和设备利旧方式。

不是。刷卡版是青鸽放学协同平台面向特定学校场景形成的常用方案入口，与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。

可以按部署方案评估。校牌出校事件需要先完成身份匹配和有效性校验，再根据学校通知规则、网络边界和已开通渠道生成通知；具体渠道和时效以实施方案为准。

可以。刷一下放学、刷两下留堂、刷三下完成只是示例，正式交付可按学校现场流程配置。

不是。刷卡版是产品能力入口，纯内网是部署方式。刷卡版可以做纯内网部署，但指挥版和闸机版也可以按学校条件评估纯内网。

不是。纯内网部署是青鸽放学协同平台面向特定学校场景形成的常用方案入口，与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。

最先确认网络边界、已有设备、是否需要家长外部通知、后台查询要求和学校运维条件。

两者都可以按学校条件评估纯内网部署。指挥版侧重平板调度、大屏和播报，闸机版侧重身份与通行事件；能否落地仍取决于服务器、网络、设备接口、通知出口和运维条件。

可以在产品支持范围内配置，例如操作身份、适用班级、有效时段和对应状态。具体刷卡次数、撤销与异常处理规则应先用学校真实流程验证，并写入实施方案。

不等于。纯内网通常指校内主流程和核心数据在校内运行；若还需要公众号、短信等外部通知，应单独设计受控出口、数据字段、失败降级和安全责任，并由学校确认网络边界。

不是。指挥版是青鸽放学协同平台面向特定学校场景形成的常用方案入口，与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。

可以按接口条件组合。平板指挥、老师刷卡、学生校牌和闸机事件需要先进入统一身份、权限与状态规则，再分别触发显示、通知和日志；设备兼容性应在实施前联调确认。

不必须。指挥版的核心是权限、批次和状态调度，大屏属于常见输出终端；学校可以根据校门组织、现有设备和现场沟通方式选择大屏、语音播报或其他显示组合。

不会用“永久保存”作为统一承诺。数据应按学校配置、业务需要、合同约定和适用规则设置留存范围，并通过权限、脱敏和审计控制使用。

不能默认承诺。设备协议、身份字段和现场网络差异较大，需要先核验供应商接口、事件方向和异常处理方式，再确定直接接入或增加适配层。

可以按学校已开通模块组合。公众号和短信可按现有配置触达家长；企业微信、钉钉、学校自有平台等通知端需先确认账号、接口、网络与消息规则。所有入口经过身份、权限和任务规则校验后进入同一状态链路。

不属于某个固定版本。统一 App 是平台的移动入口，家长、教师、校长和值班人员根据账号授权进入不同工作台；正式下载仍以签名、真机兼容和发布状态为准。

不是。它们是青鸽放学协同平台面向不同学校场景形成的常用方案入口，共享学校组织、角色权限、放学任务、状态同步和操作记录。

它们可以作为不同学校的入口和部署形态，但进入系统后应尽量共用同一套权限、配置、状态、通知和日志追溯逻辑。

青鸽放学覆盖放学触发、权限校验、学校配置、状态机、事件通知、大屏显示、语音播报、家长查看和后台追溯。具体能力会随学校版本、部署方式和权益配置组合。

这些名称已经对应学校熟悉的落地场景，也承接既有搜索与引用；现在将它们统一解释为同一协同平台的常用方案入口，而不是互不相通的独立系统。

建议先看学校是否需要纯内网、是否已有闸机或校牌设备、是否需要家长实时通知，再看大屏、语音播报和后台查询等扩展能力。

当前产品方案可按学校场景理解为指挥版、刷卡版、闸机版和小程序版；纯内网是部署方式，指挥版、刷卡版、闸机版都可以按学校网络和安全要求评估。

私有部署强调系统安装在学校、集团或指定的独立环境中，但该环境仍可能连接互联网；纯内网部署强调核心业务在没有外网时仍能运行。两者都需要明确服务器、数据库、账号、证书、备份、升级和远程支持责任；如果还要通过微信、公众号或短信通知家长，还需单独设计受控外联和最小数据字段。

指挥能力可根据项目条件采用手机 App、微信小程序、电脑网页端或 Windows 现场程序。具体采用哪种终端，要核对操作岗位、账号权限、网络环境、设备管理、安装签名、升级方式和离线降级；代码中存在某类客户端，不等于该终端已经在所有项目中完成同等发行和现场验收。

不一定。刷卡主体可以是班主任、值班人员、学生或学校认可的其他身份介质，取决于学校希望确认的是“班级开始放学”还是“某名学生形成离校事件”。实施前必须明确卡片归属、可操作范围、有效时段、重复与误刷规则、撤销方式和人工兜底，不能只按设备名称决定流程。

典型链路包括设备鉴权、事件唯一性判断、身份解析、学校与校门归属校验、进出方向和时间窗校验、任务与轮次匹配、状态转换、通知任务生成以及黑匣子留痕。任一环节失败都应记录原因并保留人工处置入口；闸机上报“通行成功”只能作为输入事实，不能直接覆盖学校放学任务的业务状态。

放学与离校协同方案把班级或学生状态操作，与学生个人实际出校事件连接到同一业务平台。第一阶段可由小程序、指挥端或教师操作卡触发班级放学、留堂或完成；第二阶段由闸机、人脸、学生卡或 UHF-RFID 确认学生实际出校，并按学校配置形成记录或通知。

班级放学通知说明班级或指定学生已经进入放学、留堂或完成阶段，不等于孩子已经走出校门；学生实际出校通知来自经过身份、方向、时段和重复事件校验的闸机、刷卡或人脸事件。学校可以按流程选择两级通知，也可以让部分事件只保留为后台记录。