光交箱智能锁的平台功能和APP功能怎么分：一张验收分工表

验收时最常见的返工，是拿投标文件里的平台功能清单去逐条点 APP。平台上有“开锁权限审批”，APP 上没有对应的审批页面，验收记录就记成了不合格项；反过来，APP 上的“现场巡检记录”在 PC 端找不到入口，又被记成缺失功能。这两份清单原本就是两张不同的表，只是被同一个项目一起买了下来。

光交箱智能锁这套系统由智能光交箱锁、低功耗多功能控制器、APP 和监控管理平台组成。设备与运营核心数据中心之间通过 NB-IoT 通信（见 光交箱智能锁产品页）。设备负责执行，平台负责决策和留痕，APP 负责现场动作和回传。功能清单的归属基本沿这条线切：谁做决定、谁在电脑前看全局，归平台；谁在现场、要被授权、要拍照和记录，归 APP。

平台侧：管全局与管权限的十一项

产品页技术参数里，平台功能列了十一项：日志管理、用户管理、报警管理、操作日志记录、门柜状态监测、开锁权限审批、门柜列表信息展示、工单统计派发、短信推送、门柜地点信息地图展示，以及日志信息过滤与导出。

按用途排一下，平台在项目里承担三类工作。

第一类是建人和建规则。用户管理决定谁能登录、属于哪个班组；开锁权限审批决定一次开锁申请批不批、批多久。这两项平台独有，APP 侧只有“申请”和“批复相关事项”，规则本身不在 APP 上。门柜列表信息展示和门柜状态监测是同一套资产底账的两个面：一页看清单，一页看状态。

第二类是看见并留下证据。报警管理把异常事件收进列表，日志管理和操作日志记录把谁在什么时候做了什么写下来，日志过滤与导出让这些记录能按时间、按柜、按人拉出来交给审计或运维复盘。同一个案例里，平台侧承担的正是用户管理、权限审批、工单派发和日志记录（见 偏远地区运维案例），与功能清单对得上。

第三类是对外发出。工单统计派发是平台把活派出去，并统计派出多少、完成多少；短信推送和门柜地点信息地图展示同样是平台侧输出，一个把信息推到人手上，一个把柜体摆在地图上给人看。

短信推送在验收里容易被放大。清单写的是平台具备短信推送能力，但没有写哪些告警触发短信、发给谁、是否每个项目都开通。换句话说，短信推送功能存在，不等于所有告警都会发短信；按这个标准去验，几乎必然对不上。更稳的做法是在技术协议里写明触发条件、接收人名单和通道费用由谁承担，再按这份约定验。

APP 侧：到了现场才用得上的功能

APP 功能列得更长，待办事项汇总之后依次是设备异常一览、设备告警一览、设备告警处理、工单派发处理、批复相关事项、箱体定位导航、实时开锁权限申请、预约开锁权限申请、扫码开锁、流程节点一键催促、设备安装施工日志、现场巡检记录、设备搜索过滤、箱体详细信息查看、拍照上传施工现场至平台，以及按权限变化展示的页面内容。

最后一项“定制化页面内容”不是普通功能，是一项约束：权限不同，展示的页面功能不同。同一份清单在不同账号上截图结果不一样，运维班组、代维班组、临时到场人员看到的菜单可能完全不同。把所有功能对着一个账号点一遍，本身就是错误的验收方法。

这十七项可以按“人在现场做什么”拆成几个时段。进门之前，打开 APP 先看待办汇总，知道今天要去哪几个柜；用设备搜索过滤在几百个点位里筛出目标；用箱体定位导航把车开到点位边上；用箱体详细信息确认编号和上次作业记录。要进柜时，提交实时开锁权限申请，或提前提交预约开锁权限申请，批准后用扫码开锁；流程卡在某个环节，用流程节点一键催促推一下。

进柜之后，用设备告警一览和设备异常一览看这个点位报过什么，用设备告警处理逐条处置；需要回复的事项在批复相关事项里写意见；施工或巡检过程写进设备安装施工日志和现场巡检记录；做完把照片上传到平台。工单派发处理在现场意味着领单、到场确认、完成回填这一串动作。

三个重叠区：同一件事，两侧各做一段

工单

工单是清单里唯一两侧都出现的大项。平台写的是“工单统计派发”，APP 写的是“工单派发处理”。这不是重复登记，而是同一张工单在不同阶段由不同角色动手。派单、改派、统计完成率是平台上调度岗的动作；领单、到场、作业、回填和上传是 APP 上现场人员的动作。把“APP 能派单”当成必检项，等于要求现场人员握有调度权；把“平台能回填现场照片”当成必检项，等于要求坐在办公室的人替现场拍照。

告警

告警同样两侧都有：平台的报警管理负责收集、分派、留档；APP 的设备告警一览和设备告警处理负责在现场看到并处置。判断依据还是动作在哪一侧。查历史、看趋势、决定派谁去，在平台；到柜前看这条告警、确认现场情况、处理完上传结果，在 APP。案例中撬锁、撬门、水淹等异常是实时告警并推送到管理人员手机端的（见 同上案例），接收端和处置端可以分开配置，验收也不能只验一侧。

地图与导航

这一组最容易被当成一个功能。平台的“门柜地点信息地图展示”是在办公室屏幕上把全部柜体铺在地图上，看分布、看密度、看哪个片区告警集中；APP 的“箱体定位导航”是从当前位置算出一条到某个具体柜体的路线。前者面向区域，后者面向单个点位。同出版商的地埋光交箱和智能井盖两套平台也是这个分工：GIS 地图在平台上，手机 APP 负责定位导航到指定设备，并能通过 PC 网管平台或手机 APP 远程开盖（见 智能地埋光交箱与 智能井盖产品页）。验收时按这个分工分别验：平台验地图上的点位完整率和状态标注，APP 验导航能否到达目标柜体。

验收怎么分：平台验规则与留痕，APP 验现场动作

清单切开之后，验收方法也随之分开。审批、授权、日志导出这类结果补不回来，验收当天才想起来考勤，前面几个月的记录不会凭空长出来。平台侧应当在系统上线时就提取样本，验收时核对同一批样本是否还在、是否完整。

平台侧的验收从三组材料入手。第一组是用户与角色：找出实际参与本项目的账号清单，核对每个账号的角色是否与职责相符，再抽一个代维班组账号登录，看它在平台上能看到哪些柜、能审哪些申请。第二组是审批流程：完整跑一次真实流程，从提交申请到批复到开锁到日志出现记录，每一步截图附进验收记录；再试一次越权申请，看系统是否拒绝。第三组是报表导出：选定一个时间范围、一个区域，导出日志和工单统计，核对条数与页面显示是否一致，导出的文件能否直接交给业主审计。

APP 侧的验收更像现场开工。第一组是现场上传：挑一个有代表性的柜，走完打卡、申请、开锁、作业、拍照、回填，确认照片出现在平台端的对应记录里，而不只是留在手机上。第二组是扫码：在信号正常的点位试一次扫码开锁，再到信号较弱的点位试一次，看是否按项目约定的兜底方式（例如蓝牙或现场申请）可用。第三组是导航与待办：从驻地导航到一个此前没去过的柜，确认导航到正确点位，且到达后待办中出现该点位的任务。

平台侧的权限粒度值得在合同里多管一层。同一产品家族的智能 OCC 平台已按区域和业务分别设置用户权限（见 智能 OCC 产品页），说明区域和业务是两个可用的分权维度。光交箱智能锁平台并未列出具体权限粒度，验收用户与角色时应向供应商索取一份角色权限矩阵，按矩阵逐格核对，而不是只看账号能不能登录。

按 GB 51171-2016《通信线路工程验收规范》，通信线路工程施工结束后，施工方向建设单位提交完工报告与竣工资料，由建设单位组织设计、监理和施工各方进行竣工验收。初验阶段抽查安装工艺，复测主要技术指标，并对工程资料做全面检查评议（见 该规范第 14.2 节条文）。智能锁的平台与 APP 功能验收并不落在光缆指标里，但这条流程给了一个可借鉴的次序：功能清单、账号、截图与导出记录都属于“资料”，应与工艺和现场动作的检查并列，而不是各自零散地对。

具体执行时，一张几列的表就够用。每次验收按它填，签字时也按它签字。

这张记录表的用处是让验收异议可复现。同一个功能在另一个账号、另一个版本、另一个点位上表现不同，不必靠回忆解释，翻记录即可。

三栏表：功能、归属与验收动作

下面这张表按产品页的功能列举逐项拆开。归属一栏写“平台”或“APP”，两侧都有的写清各自那段动作。验收动作一栏写可观察、可归档的动作，不写“检查是否正常”这类无法判定的说法。

表格里有几行需要单独说明。告警一行跨了两侧：平台做汇总与分派，APP 做查看与处置，两者都验，但验的对象不同。拍照上传、设备安装施工日志、现场巡检记录三行都是同一类跨侧项：动作在 APP 采集，结果必须落在平台的对应柜体记录上，所以验收要在平台端打开来看，而不是只看手机上是否提交成功。这三项若只验 APP 端，闭环其实没走完，签认时应在验收记录里注明平台端的回查结果。定制化页面这一行的目标不是“功能存在”，而是“角色与菜单一致”，这正是权限不同、展示页面不同的含义。

功能列举不等于版本承诺

上面两份清单都是产品页上的功能列举，不是某个交付版本的配置单。同一款产品在不同版本、不同项目中，页面与字段会变化，清单也不能直接当合同附件。下面五件事没在技术协议里确认，验收时几乎都会产生争议。

一是清单对应的版本与部署方式。产品页的清单是通用列举，项目里可能只部署其中一部分，某些版本的入口位置也可能不同。验收依据应锁定为技术协议中列明的版本与配置，而不是一份网页截图。

二是短信推送的触发条件与接收人。清单只说明具备短信推送能力；哪些告警触发短信、发给哪几个号码、是否包含故障恢复通知、通信费用如何结算，都需要逐项写清。

三是参考标准是否仍现行。举个例子，YD/T 5160-2015《无线通信室内覆盖系统工程验收规范》于 2015 年 10 月 14 日发布、2016 年 1 月 1 日实施，在全国标准信息公共服务平台上已标注自 2026年9月1日起废止（见 标准信息页）。引用这类标准号作为验收依据时，要核对最新状态与替代标准，也要避免把室内覆盖系统的验收规范搬到户外光交箱上适用。

四是权限矩阵与验收账号。APP 页面随权限变化，验收开始前必须定好哪个账号测哪些功能、该角色应该看不到哪些菜单。没有矩阵，验收结论无法复现。

五是异常兜底路径与跨侧项的回查条件。信号弱的点位开锁按项目约定的方式是否可用，开锁失败如何处理，告警是否需要推送到平台与 APP 以外的通道，都要在协议里定清楚。拍照上传、施工日志、巡检记录这类 APP 采集、平台留痕的项，还应写明以平台端能调出同一记录作为通过条件，否则现场提交成功也可能拿不到可审计的证据。

问题分开之后，争议会少很多。平台侧最该验的是用户与角色、审批流程、报表导出。这三项都是管理动作，配置错了，后续的问责和审计都无从谈起。APP 侧最该验的是现场上传、扫码与导航、待办汇总，这三项都是现场动作，既影响作业效率，也决定平台里的数据是否真实。工单、告警、地图与导航这三处重叠区，按“谁做那一半动作”各验一半，两边都通过才算完整。

下一步值得做两件事：拿一份与项目对应的角色权限矩阵，把平台侧与 APP 侧的权限差异定下来；再拿当前技术协议的版本号与本页清单核对一遍，把不一致的项标出来。这两份材料齐了，三栏表才能作为验收依据填完。需要本项目平台与 APP 功能范围的正式条款，或需要与工程师核对某条功能在你们项目中的配置，可向销售工程师索取《正式技术规格确认单》，官方联系方式为 sales@hj-net.com。