商用自动门营业、送货、保洁与闭店：场景需求和切换交接怎么核对

一张表先写清谁在什么时段通行

同一处门在一天里可能服务不同的人和任务。场景表先记录使用者、通行方向、路线和负责人员，再写预期动作。不要先挑一个听起来合适的模式名称，再让现场人员猜它具体意味着什么。

营业时需要确认顾客和员工怎样触发开门，相关检测范围与实际路径是否对应。送货时还要考虑推车、货物和人员能否在约定路线内通行。停留需求应依据实际任务和设备资料确定，不在文章中给所有项目统一的时间数值。

保洁期间不是按一下保持开启就结束

保洁可能涉及地面、轨道附近和门体周边，应由责任人员按现场要求安排隔离、设备状态和替代通行。不能让作业人员在运行缝隙中寻找清洁位置，也不能通过取消保护功能来避免开关动作。

结束作业后，谁检查现场、谁确认需要恢复的功能、谁通知使用方，应事先明确。界面显示某个状态，只能说明设备给出了相应提示，不能代替对实际动作和现场条件的核查。

闭店要把外侧进入和内侧离开分开说

闭店后是否允许外侧触发、员工从内侧如何通行、锁控动作与权限如何对应，是不同问题。不能只说“锁门”，便认为每一种路径都已明确。具体方案需要对应设备、控制逻辑和项目要求确认。

涉及疏散、消防或其他特殊用途时，由相应责任单位核对。网页不提供统一锁控方案，不把外侧停止感应等同于所有方向都停止通行，也不把失电状态与营业模式混在一起。

谁切换，谁确认，谁接管异常

交班时记录当前场景、实际状态、临时安排和未解决问题。临时设置还应明确结束条件及恢复责任，避免第二天开店时继续保留前一晚的安排。

如果出现指令发出但结果不符，应记录请求来源、显示状态与实际观察，而不是反复切换直到看似正常。后续处理按准确设备说明进行，需要专业人员参与时保留现场原状态和记录。

从需求变成采购和验收内容

采购阶段请供方逐项答复哪些场景可实现、依赖哪些配置、存在哪些限制，以及怎样验证。不能从其他品牌公开功能推定本站每个型号都支持同样逻辑。

交付时按已确认的场景验证相关功能，记录实际条件和结果。没有执行的项目不勾选合格，缺少外部配合的项目单列待验证。详细触发分类、门体场景输入与锁控资料分别由现有文章承接，本稿不重复写成通用控制器说明。

四种使用场景，不用同一行自动开门概括

场景表先写希望实现的结果，再让供方说明支持条件。它不是通用控制器菜单，也不要求设备必须出现相同名称。不同型号的选项、输入和权限定义可能不同，应按准确文件映射。

共同要求可以引用同一份文件，但每个门位的例外应独立记录。店铺正门、员工通道和送货口即使外观相同，使用目标也可能不同，不能因为采购了相同机组就直接复制全部场景结论。

假设情形：保洁结束后，为什么不能只看门还开着

以下是说明记录方法的假设情形，不是本企业工程案例。某门位在保洁期间采用了经确认的临时安排，作业结束后门扇仍处于开启状态。仅凭这个位置，无法确定它是在等待触发、处于保持请求，还是尚未完成恢复。

交接时应记录现场已完成什么、临时请求是否撤销、当前配置及实际结果，再由责任人按确认方案安排恢复。不能让接班人员仅凭门的位置猜测模式，更不能要求其尝试无依据的接线或屏蔽保护。

若恢复条件尚未齐备，就保持清晰的未完成记录及现场安排，由责任方接管，而不是为了结束保洁任务把全部状态勾成正常。此例不说明任何型号的默认动作，具体执行按项目与设备文件确认。

场景表与验收记录分别留存

场景表记录需求、支持依据、配置前提和责任分工；验收记录写实际执行了什么、在什么条件下、观察到什么结果。需求写进表里，不代表已验证；设备界面显示某个名称，也不代表现场全部路径已覆盖。

下载空表按门位和场景填写，不预设时长、型号、锁控方式或合格结果。临时任务需要时可新增一行，写明结束与恢复条件；无法验证的内容保留原因和后续责任，不用一个总勾代替。

进一步确认触发方式可看开门方式选型；完整场景输入看使用需求；锁控部分看电锁与释放条件。本页只组织一天内不同任务的切换与交接，不提供控制器操作或通用电气方案。