1. 为什么门禁验收不能只在白天按下"开门"就算过
先说一个我自己的教训。前年我在华南某园区做一个人脸识别门禁项目，设备端基于鸿蒙系统，一共部署了8台人脸识别门禁一体机，管理服务器一台，底库约1200人。供应商演示那天阳光明媚，现场测试怎么刷怎么过，甲方负责人当场签字验收。结果第二周开始陆续接到投诉：下午三点以后，西侧大门三台设备频繁识别超时，有个员工在门口站了快20秒才开门。后来一查，问题很简单——那几台设备安装朝向正西偏南，下午低角度阳光直射镜头，形成逆光，识别率急剧下降。而验收当天是上午，光线条件刚好全在设备的舒适区。
这件事让我彻底改变了对"门禁验收"的态度。早些年我参与过的门禁验收，很多就是"刷个脸、开个门、签个字"三步走，设备能反应过来就算通过。但人脸识别门禁压根不是"能开门"就完事的系统，它既涉及识别算法性能，又涉及光学环境适配，还涉及系统平台的稳定性与运维能力。尤其是在设备端跑鸿蒙系统的项目里，分布式协同、多设备管理、系统升级这些额外维度，让验收的复杂度比传统门禁高出一大截。
集成商在这个环节里往往同时背着三副担子：对甲方，你是技术顾问，要替用户把关键指标把关；对设备厂商，你是项目承接方，要确认设备是否符合采购约定的功能与性能；对自己，你还要评估后续两年的运维成本，避免在质保期内被一个个"隐性问题"反复拖下水。这三个身份叠加在一起，就决定了你不能再靠感觉验收，必须有一套能落到纸面上的专业评测清单。
这套清单的核心逻辑，是把验收拆成三个层次。第一层是功能验收：该有的功能有没有，比如远程开门、记录查询、报警联动；第二层是性能验收：指标是不是达到合同要求，比如识别速度、错误接受率、活体检测成功率；第三层是体验验收：在真实环境、真实人群、真实光照条件下，设备能不能稳定、流畅、无感地服务。很多时候前两层都能过，崩就崩在第三层。后面的内容，我按照这套逻辑展开。
2. 验收前的资料与基线：把"测什么"和"怎么判"先钉死
在插上第一台设备电源之前，先把验收的边界条件确定清楚。这个阶段做得越细，后期扯皮越少。我建议至少留出半天到一天时间专门做验收准备，别一进场就急着开机测。
2.1 必须审核的技术文档清单
验收不是只对着机器说话，文档审核往往能提前暴露大部分坑。这里列几个我每次必查的文档类别：
| 文档类型 | 审核重点 | 常见问题 |
|---|---|---|
| 需求规格说明书 | 功能范围、性能指标是否与合同条款一致 | 合同写"识别速度≤1秒"，文档却写成"平均响应2秒以内" |
| 系统设计文档 | 系统架构图、接口协议、数据流向说明 | 实机接口与文档描述不一致，后续联调才发现 |
| 算法性能报告 | 设备厂商声称的FRR/FAR、识别速度、底库容量 | 报告没有标注测试环境和样本构成，参考价值有限 |
| 设备规格书 | 摄像头分辨率、补光灯功率、防护等级、工作温度范围 | 实机参数缩水，防护等级标着IP65实际没有防水胶圈 |
| 部署文档 | 网络规划、VLAN划分、服务器配置、时间同步方案 | 漏掉访客网络与办公网络的隔离要求 |
| 运维手册 | 日志采集方式、系统升级流程、故障恢复步骤 | 升级流程过于抽象，没有回滚方案 |
审核这些文档时，我的习惯是拿合同条款做基准，逐项比对，不放过任何一处数字偏差。比如合同里写了"设备应支持断网离线识别"，那就要确认算法性能报告、系统设计文档、运维手册三个地方都对离线识别场景有明确说明，缺一个都要让厂商补。
2.2 基线环境确认与样本库准备
这一步决定测试结果是否公平、可复现。先确认几件事：网络拓扑是否与部署文档一致，交换机VLAN配置是否正确，服务器时间是否通过NTP同步，设备供电是否稳定。特别提醒一下时间同步，人脸识别门禁的通行记录如果要作为安防证据，时间戳对不上就是大问题。我遇到过两台设备相差4分钟，记录导出来跟监控录像完全对不上，最后只能靠人工推断。
样本库的准备工作更不能偷懒。测试样本应该覆盖目标使用人群的真实构成。比如那个园区项目里员工年龄跨度很大，我要求测试样本至少200人，年龄段从20岁到65岁都要有，同时涵盖戴眼镜、不戴眼镜、戴口罩、戴帽子、女性长发、男性寸头等常见情况。样本太少或者太单一，测出来的指标根本说明不了问题。
2.3 测试工具与人员分工
工具清单如下：照度计、卷尺、秒表（或者直接用设备日志里的时间戳）、测试用手机两台（分别负责录制视频和拍摄照片用于活体攻击测试）、笔记本电脑一台（用于抓取设备日志和网络报文）、一个装有串口/SSH客户端的U盘启动环境。如果设备支持鸿蒙的hdc调试工具，最好准备一个配置好的调试环境，后面抓日志能省不少事。
现场人员分工要形成三方在场机制：甲方代表见证，负责确认测试过程公平；乙方工程师负责操作设备、调整参数；你作为集成商负责记录数据和评判结果。每一轮测试开始前，三方先口头确认测试项目、测试方法、判定标准，避免测完之后再争论"当时是不是这么测的"。测试记录本一带三份，现场签字确认，后面写验收报告直接引用。
3. 人脸识别核心指标的量化测法与判定标准
这一章是整个验收报告的技术核心。人脸识别的性能指标不能停留在厂商提供的宣传页面，必须采用能在现场复现的方法来验证。
3.1 识别率与错误率：FRR、FAR、EER这样测才严谨
先解释三个术语，后续表格和判定都依赖它们。FRR是错误拒绝率，简单说就是已经注册过的员工，去刷脸却被系统拒绝的概率，这个指标直接影响日常使用体验。FAR是错误接受率，指的是没有注册过的人，去刷脸却被系统放行的概率，这个指标直接关系到安防等级。EER是等错误率，就是FRR和FAR相等时的值，通常用来描述算法整体性能，数值越低越好。
实际测法是这样的。FRR测试：让200名已注册员工每人完成10次正常面部识别尝试，一共2000次，统计被拒绝的次数，被拒绝次数除以2000就是FRR。FAR测试：选取50名未注册人员，每人尝试识别10次，再加上50次使用已注册人员照片打印成图片的模拟攻击，统计放行次数除以总尝试次数，就是FAR。我测量的这个园区项目参考合同标准：FRR≤1%，FAR≤0.001%。按这个标准，2000次FRR测试最多允许20次拒绝；FAR测试500次一次都不能放行。
提示：现场测试时要注意区分"识别失败"和"未检测到人脸"是两回事。很多设备在光线不良时会提示"请正视摄像头"，这种属于检测阶段就没抓住人脸；真正的识别失败是人脸已经清晰框出来了，比对环节却判断为不匹配。验收记录里最好把这两种情况分开统计，否则后续定位问题会很痛苦。
3.2 识别速度与通行效率
识别速度建议定义为：人脸出现在设备识别区域内开始，到设备发出开门指令为止的耗时。这个定义排除了门锁机械开锁时间和闸机摆臂动作时间，纯粹考核设备端+算法端的能力。
测量方法不复杂：在设备日志里找到每笔通行记录的"人脸检测开始时间"和"比对完成时间"，两者相减即为识别耗时。如果设备日志粒度不够，可以用高帧率录像拍摄一台带屏幕显示时间戳的参考时钟来辅助计算。现在的门禁一体机普遍要求识别速度≤1秒，实际测试中大多数中高端设备在理想条件下能做到200到500毫秒。但要注意底库规模的影响，底库从100人扩展到5000人，比对时间通常会有明显增长。所以验收时必须在真实底库规模下测试，不能拿一个只有几十条记录的测试底库来凑数。
通行效率则要结合硬件形态来看。闸机式门禁受限于闸机摆臂速度，纯粹看设备的识别吞吐量意义不大。但如果设备是自动门模式或者高度集成化的门禁终端，可以用模拟高峰的方式测试：安排20个人排成一队连续刷脸，统计1分钟内成功通过人数。这个数字通常要求不低于每分钟25到30人，否则早晚高峰期就会出现排队积压。
3.3 活体检测：照片、视频、面具攻击测试
很多人验收时忽略活体检测，觉得门禁是给内部员工用的，不会有人拿照片来搞事情。这个想法在真实安防场景里非常危险。我见过不止一次员工的照片被发到内部群里，只要打印出来往镜头前一放，没有活体检测的设备当场直接开门。
活体攻击测试按以下顺序做。第一轮：A4纸彩色打印5张已注册员工的正面照片，每张照片在设备前停留约3秒尝试识别，每个样本做10次，共50次，记录放行次数。第二轮：用手机拍摄已注册员工的正面录像，播放该视频对着设备镜头，同样做10次，共50次，记录放行次数。第三轮（条件允许时）：用3D打印面具或者高仿真硅胶面具测试，这个成本较高，视项目预算决定是否执行。
判定标准参考：照片攻击和视频攻击的拦截成功率应≥99%，也就是50次攻击中最多允许1次漏判，最好是0次。如果设备在活体检测上失守，属于一级不合格项，必须整改后复测。这个标准直接写进验收报告，避免后续扯皮。
4. 鸿蒙平台在门禁场景的专项评估清单
既然项目标题把"鸿蒙"放在了最前面，那说明这套门禁系统不是普通的嵌入式Linux设备，而是运行在鸿蒙生态下的智能终端。对这一类设备，验收的关注点不能只停留在识别算法本身，必须把操作系统平台层面的能力也纳入评测范围。
4.1 分布式协同能力验收
鸿蒙最核心的卖点是分布式能力。放在门禁场景里，常见的落地形式包括：手机碰一碰开门、访客临时授权在多个门禁之间流转、管理员通过平板远程查看和管理所有设备状态。验收时至少要测三件事：设备发现与连接建立是否顺畅，跨设备指令延迟是否能接受，断连后能否快速自动恢复。
具体测法：准备一台支持鸿蒙生态的手机，首次配对时记录从扫描到建立连接的时间，一般应该在几秒级别；随后连续执行10次远程开门指令，记录每次从手机端发出指令到门锁动作的时间间隔；再连续执行20次断连重连，观察设备是否需要人工干预才能重新注册。这里要说一个容易踩的坑：很多设备宣传支持分布式组网，但实际现场有几十台设备同时在线时，设备间的广播流量可能把无线AP打拥塞。验收时必须把项目实际规划的设备数量压力跑一遍，不要只在两台设备联调时测试。
4.2 系统稳定性与长时间运行表现
这一项建议做一个72小时连续运行压力测试。场景是这样的：设备上电后不做重启，安排人员每隔一定时间进行识别操作，同时用日志工具持续采集设备进程的CPU占用、内存占用和系统温度数据。
我通常在验收前准备一个简单的采集脚本，放进后台跑着：
# 通过hdc连接鸿蒙设备，持续抓取系统性能数据到本地文件 hdc shell hilog -r hdc shell "cat /proc/meminfo | grep MemAvailable" >> device_mem_$(date +%Y%m%d).csv while true; do hdc shell "top -b -n 1 | head -20" >> device_cpu_$(date +%Y%m%d).csv sleep 10 done这个脚本不复杂，但能帮助判断两件事：一是长时间运行后内存占用是否持续增长，如果曲线一路向上不回落，说明存在内存泄漏，这在门禁设备上属于严重问题；二是CPU占用是否出现周期性尖峰，尖峰可能对应后台任务调度异常，会导致识别响应突然变慢。72小时内如果出现任何一次系统无响应、死机、自动重启，都应该列为不合格项，要求厂商排查后复测。
4.3 运维与升级能力
门禁设备不像手机，一用就是好几年，后期系统升级和故障排障能力比一时的新功能重要得多。验收时要重点验证：设备是否有清晰可用的系统日志，日志能不能远程采集；系统升级流程是否完整，是否支持版本回滚；设备配置的备份与恢复是否方便。
现场我一般会要求厂商演示一次完整的系统升级流程，从打包升级包、推送、执行、重启到版本核验。特别要求厂商在升级过程中人为中断一次，看看设备能不能自动回退到上一个正常版本。这个测试很关键，我见过某项目升级到一半设备变砖，只能返厂刷机，几十台设备挨个拆下来寄回去，直接导致项目延期两周。升级能力验证通过后再确认日志命令能用，能捞出人脸识别模块的运行日志即可，相关命令各设备有差异，按实际产品手册执行。
5. 场景化测试：光线、姿态、人流与环境的真实演练
前面几章的测试方法偏向实验室化，都是在相对受控的条件下测量。但门禁设备的实际使用环境千变万化，尤其是户外安装不到位的情况下，同一台设备在周末和周三的表现可能完全不同。这一章讲的是怎么把真实场景搬进验收流程。
5.1 光线条件矩阵测试
人脸识别最怕的就是光线变化。这个矩阵测试最少要跑四轮：晴朗白天顺光、晴朗白天逆光、傍晚弱光、夜间无光（依赖补光灯）。如果设备装在室内，还要加测室内正常照明、室内弱光和室内无光。每一轮测试之前，用照度计记录现场的真实照度值，测试完成之后把照度和识别结果对应起来。
重点关注逆光情况。门禁设备安装时，摄像头的朝向会决定它面对的光源方向。如果安装位置正对下午的太阳，逆光会让人的面部处在阴影中，识别率断崖式下降。测试方法是：安排10名已注册人员站在距设备0.5米、1米、1.5米三个距离点，分别在上述四种光照条件下各完成5次识别，统计每组条件下的成功率。任何一组条件出现连续两次错误拒绝，就要记录并排查原因。
5.2 人群与姿态覆盖度
人脸识别算法对不同人群的适配能力差别很大。小孩脸部特征发育不完全，部分算法识别率会偏低；老年人脸部皱纹多，也会影响特征提取；戴眼镜人员会面临镜片反光；戴口罩则直接遮挡了嘴巴区域，依赖全脸特征的旧算法基本失效。
测试时不要只安排年轻员工去"配合测试"，尽量凑齐以下类别：60岁以上老人、14岁以下儿童、戴眼镜者、戴口罩者、戴帽子者、长发遮挡脸部者、浓妆者。每人完成至少10次识别。如果合同里约定了支持口罩识别，就把戴口罩作为必测项，单独统计。姿态方面，让测试人员分别以正脸、左右转头约15度、上下俯仰约15度、边走边刷四种状态测试。这一步的核心目的是确认设备在"真实使用姿势"下依然可靠，而不是要求每个用户都得规规矩矩正对摄像头。
5.3 压力测试与早晚高峰演练
压力测试要回答一个很实际的问题：早高峰20个人同时过闸机，会不会造成长时间排队。方法是在现场模拟20到30人的连续通过场景，所有人排成一队依次刷脸通行，记录每个人从进入识别区到闸机打开的间隔时间，计算平均耗时和最长耗时。
同时要观察管理平台的表现：8台门禁设备同时上传通行记录，管理服务器CPU占用是否飙升，数据库写入是否有明显延迟，查询记录时页面响应是否卡顿。如果项目规模更大（比如整个园区几十台设备、底库上万条），就要考虑让厂商提供压力测试报告，或者安排小规模并发测试，再结合数据评估服务器性能拐点。
6. 集成商最容易漏掉的六个细节
正文前面测的都是"看得见"的部分，这一章专门说那些容易被忽略、但会在质保期内反复折腾你的细节。
6.1 断电恢复与电源波动
门禁设备装在外面，供电环境不像机房那么理想。验收时要主动做断电测试：设备正常运行中直接断开电源，观察数据是否丢失；恢复供电后设备是否能自动启动，服务是否自动拉起，是否需要人工按复位键。用稳压器制造几组瞬时电压波动，观察设备是否会误重启或进入保护状态。很多设备正常使用没问题，一遇到供电不稳就反复重启，每次重启还要几十秒，对用户体验影响很大。
6.2 网络异常下的降级表现
人脸识别门禁最好的工作模式当然是联网运行，记录实时上传、权限实时下发。但网络不可能保证100%稳定。验收时要做断网测试：断开设备网线，用已注册员工测试本地识别开锁是否仍可用，再用未注册人员测试是否会被拒绝；恢复网络后查看离线期间产生的通行记录是否自动补传到管理平台，时间戳和事件顺序是否完整。这一项不过关的话，后期只要网络抖动，大门就可能瘫痪，或者漏掉通行记录。
6.3 通行记录完整性与数据同步
核对通行记录是一个细活。测试期间让每名测试人员按预定顺序在不同门禁点刷卡/刷脸，生成一批已知记录。测试结束后从管理平台导出记录清单，与真实通行事件逐条比对，重点检查三项：记录总数是否一致，时间戳是否准确，关联的人脸照片缩略图是否清晰可辨。如果记录数量和实际发生次数对不上，或者照片模糊到无法辨认身份，这个系统作为安防设备的价值就要打个问号。
6.4 户外环境与硬件耐久性
设备装在户外，就要考虑防水防尘、高低温、紫外线老化。验收时可以要求厂商提供设备防护等级证书，同时现场做一次模拟淋雨测试（用喷壶对着设备正面喷水），观察屏幕和摄像头区域是否进水起雾。高温暴晒测试要挑一个晴天午后，让设备在太阳下直晒至少2小时，观察屏幕是否变暗、摄像头画面是否出现过曝、识别功能是否仍然正常。低温环境如果现场条件有限，可以结合厂商提供的产品环境测试报告做书面审查，但最好在设备规格书里明确工作温度范围，并留出余量。
6.5 设备发热与持续运行温漂
这个细节很少有人查，但很影响长期稳定。人脸识别门禁一体机内部有处理器、补光灯、屏幕，长时间运行发热量不小。在72小时压力测试期间，用手持红外测温枪测一下设备外壳温度，如果超过50摄氏度要注意散热是否够；同时注意观察摄像头画面是否出现热噪声——画面看起来像蒙了一层"雪花"，尤其在夜间补光灯开启时更明显。有些设备刚开机识别率很高，运行几个小时后画面逐渐变毛，这就是温漂问题，原理是摄像头传感器温度升高后噪点增加，算法提取特征的质量下降。
6.6 隐私合规与数据安全
人脸数据属于敏感个人信息，合规性不可忽视。验收时不能只看功能，必须确认：人脸特征数据是存储在设备本地、管理服务器本地，还是上传到了云端；存储时是否加密；是否有明确的数据保留期限和删除机制；管理平台的账号权限是否区分了管理员、操作员、审计员；日志里能不能看到谁在什么时间查了谁的通行记录。如果厂商的人脸数据漫无目的地传到云端，这个项目从合规角度就有硬伤，集成商有责任把这个问题提出来。
7. 验收报告编写与争议处理经验
所有测试做完，最后要形成一份经得起复核的验收报告。报告写得潦草，前面的工作等于白做。
7.1 报告应包含的要素
一份完整的验收报告，至少要包含以下内容：项目概况与验收依据、测试环境描述（网络拓扑、设备列表、软件版本、底库规模）、测试工具清单、测试项目与测试方法、原始测试数据汇总、指标判定结果、问题项清单及整改建议、遗留事项和复测计划。数据汇总部分建议用表格呈现，每一项都附上合同约定值、实测值、是否符合结论。原始记录跟测试照片作为附件存档。
7.2 分歧判定与复测机制
验收现场出现分歧是常事，最常见的争论是"我测出来的数据跟厂家标称不一致"。处理机制要在验收开始前就约定好：如果任一方对测试结果有异议，可以申请复测；复测时必须使用同样的测试方案、同样的样本库、同样的现场环境；如果复测结果仍与首次差异明显，则引入第三方检测或返厂检测作为仲裁手段。注意，复测不能无限期进行，要在报告中约定复测次数上限和最终期限，否则项目会拖到没有尽头。
7.3 验收通过后的交接与质保衔接
验收报告签了字，不等于集成商的工作就结束了。交付物清单要逐项核对：设备出厂合格证、使用说明书、运维手册、管理平台账号和密码（由管理员保管）、备品备件、调试工具软件安装包。培训记录也要留档，至少完成一次面向甲方运维人员的系统操作培训，内容包括日常操作、常见故障处理、升级流程、数据备份方式。质保期从验收通过之日起算，这个时间节点要在报告里明确写出来，避免供应商说"质保从发货日起算"。
最后分享一个私人习惯：每次验收我都会把当天的测试录像按照场景分文件夹保存，逆光、弱光、活体攻击、压力测试各一个文件夹，按时间排序。这个习惯后来救了我好几次，项目出问题的时候翻出验收当天的录像一对照，是环境变了还是设备老化了，一眼就能判断，不用跟厂商和甲方陷入各说各话的僵局。这个习惯从早年那个"只测了上午就签字"的项目开始养成，至今没断过。
