做过门禁项目交付的朋友应该都有这种体验项目上线那天甲方代表、物业经理、保安队长全站在单元门口围着人脸识别门禁机轮流刷脸。大家看一个过一个嘴上都说“不错不错”可真到项目验收签字的时候问题就来了——白天强光下识别不了晚上灯光暗一点刷不开戴眼镜的同事反复被拒存储的通行记录还有漏报……最后验收拖了半个月集成商天天在现场调还得被甲方指着鼻子问“你们这东西到底行不行”。我在安防集成这块做了十来年鸿蒙生态起来之后跟着做了好几个基于鸿蒙设备的人脸识别门禁项目。说实话这类项目最大的难点不在“把功能做出来”而在“如何系统地证明它真的好用”。很多集成商朋友习惯用“现场演示没问题”来替代验收评测这个思路在中小项目上偶尔能蒙混过关但在正式项目里尤其涉及鸿蒙这类相对新的技术栈没有一份专业的评测清单验收时基本就是拿自己的工期和口碑去赌。这篇东西就当是我给自己沉淀的一份验收与性能评估作业。我把这几年在鸿蒙人脸识别门禁项目上跑过的评测流程、指标设计、现场测试方法、问题排查思路整理成一份可复用的清单分享给同样在做集成交付的同行。不管你是项目负责人、技术工程师还是需要给甲方写验收报告的人都可以直接拿这套思路去套用。1. 项目验收之前先把交付边界和评测思路理顺1.1 鸿蒙人脸门禁的系统组成一个典型鸿蒙人脸识别门禁项目交付范围不是一台门禁机那么简单。从用户视角看是“刷脸开门”从集成商视角看至少包含四个层次前端设备层人脸识别终端鸿蒙系统、门禁控制器/电锁/闸机、补光灯、电源模块。系统软件层承载在鸿蒙设备上的门禁App或元服务负责人脸采集、特征提取、比对决策后台的人脸库管理、通行记录、权限管理平台。网络链路层局域网连接前后端、对外接口、断网续传机制、时钟同步。安装工艺层安装高度、角度、遮阳罩、防雨防水、线路接地、UPS续航。这四个层次任何一个环节出问题最终都会被甲方归纳成一句“人脸门禁不好用”。所以验收评测不能只看终端刷脸必须从“完整开门链路”的角度去测。1.2 评测不是“刷脸试一下”而是链路体检刚开始带项目时我也偷懒过觉得设备能刷开就行。直到有一次交付现场演示时一切正常第二天一早物业经理打电话说“门禁疯了人脸识别一直转圈”。后来查了半天是交换机网络环路导致终端到平台的心跳超时终端一直处于“离线重连”状态。这种问题靠刷脸演示是永远测不出来的。所以我后来在项目验收时固定一套思路把整个系统当成一条链路来测从“人员注册—前端采集—特征提取—比对—开门指令—闸机动作—记录回传—平台展示”全流程逐段打点计时任何一段异常都能快速定位。这个思路贯穿我后面的整套评测清单。1.3 验收对象与范围划分还没开始动设备之前先把验收范围写清楚避免扯皮。我通常会在验收启动会上跟甲方确认以下问题验收范围是仅前端人脸终端还是包含后端平台、网络改造、安装工艺验收人员基线以甲方指定的实际使用人员为准包含老人、小孩、戴眼镜/口罩人群还是测试组临时拉人性能指标基线识别率、误识率、拒识率、平均识别时延等指标分别按多少为合格线特殊场景要求夜间、室外逆光、上下班高峰多人连续通行等是否必须满足验收环境是否允许在交付现场实际环境测而不是单独搭一套完美环境这五条在验收报告里最好白纸黑字写清楚。特别是第一条和第三条很多集成商就是在这上面吃了哑巴亏——甲方验收时临时把指标加码你又没留书面依据只能自己认。2. 集成商专业评测清单指标体系怎么建这一章是核心我把评测指标整理成一张完整表然后逐个解释“为什么这样定”“怎么测”“容易在哪里虚高”。2.1 与识别核心算法相关的指标先列指标指标说明常见合格线测试方法识别率准确率正确识别并开门的比例≥98%常规场景有效测试次数中成功识别次数占比误识率FAR非本人被识别为本人≤0.1%1:1/≤0.01%1:N用非注册人员测试统计误通过比例拒识率FRR本人未被识别≤2%常规场景/≤1%高端项目用注册人员测试统计被拒比例识别时延从人脸出现在采集区到开门指令发出≤500ms本地1s内含平台联动从日志/平台取时间戳计算1:N库容单台设备支持的人脸底库上限依招标要求常见1千~5万向设备灌入目标数量特征库后测试这里最容易翻车的是“识别率”这个概念。有些供应商宣称“识别率99.9%”其实就是在自己公司搭的实验室环境、固定灯光、固定机位、固定角度用几十个人的照片反复测试得出的。真实门禁现场的复杂度远高于实验室。所以验收时必须强调“环境随机性”和“人员多样性”这两条写进评测方案里厂商就不好糊弄了。2.2 与鸿蒙端侧运行相关的性能指标鸿蒙设备端侧的运行质量直接影响识别体验和稳定性。这部分我通常重点看四项CPU/内存占用连续运行不少于72小时通过鸿蒙设备上的调试工具或者后台监控看系统资源曲线重点看是否存在内存爬坡内存泄漏的典型信号。冷启动与热启动时延从设备上电到进入刷脸界面能正常工作的耗时冷启动通常在几秒到十几秒热启动从休眠唤醒应在1秒左右。长时间连续运行稳定性连续不重启运行7×24小时统计是否出现死机、卡死、重启、识别模块服务异常退出。功耗与散热室外或半户外场景长期高温环境下是否因过热降频导致识别卡顿室内机也要看功耗是否在供电可承受范围内。这里有一个比较实用的小技巧用鸿蒙系统自带的“设备调试”能力或者通过hdc工具定期抓取进程列表和内存快照。如果看到某个服务进程的内存占用持续增长、且GC之后仍然不回落那大概率有内存泄漏。这个在我做过的项目里有两台设备在评测第60小时左右就暴露出来了要不是提前做了72小时压力测试交付后用户迟早会碰见“越用越卡”。2.3 网络、平台与安全性指标前端识别只是一部分门禁系统是联网的网络和平台层面也要纳入评测断网续传前端与平台断网后本地是否继续正常工作恢复网络后通行记录是否完整上传不丢记录。开门指令下发平台远程开门指令至前端执行的时延通常≤2s。心跳与在线率设备在线率运行周期内在线的比例不低于99.5%心跳周期检出异常。数据安全人脸特征值在端侧和平台侧的存储是否加密是否具备防导出、防篡改能力日志中是否对身份证号、人脸照片等敏感信息脱敏。权限管理平台侧是否具备分级权限操作日志是否可审计。数据安全这关在集成项目里常常被忽略。甲方一旦是园区、写字楼、学校这类对隐私敏感的场所评测不提前过一遍等被第三方审计出来就麻烦了。我一般会主动在验收清单里加一项“人脸特征数据明文导出检查”——检查通过平台或终端能否把人员库数据整体导出。能导出且无加密的话直接列为不合格项。2.4 交付体验类指标除去硬指标还得看日常使用的体验这类指标看似主观但能提前规避大量售后投诉易用性普通用户是否无需培训即可完成人脸注册和刷脸通行老人、小孩使用是否顺畅。异常引导识别失败时是否有清晰的语音/界面提示录入不合格照片时是否有明确反馈。批量注册效率从Excel导入人员信息到批量下发到终端单条平均耗时500人的项目能否在半天内完成配置。维护便利性故障告警是否及时、日志是否可导出、远程升级是否可行。3. 现场实操六类典型场景测试方法有了指标体系接下来就是真刀真枪在现场跑测试。下面是我的实操流程直接照着做就行。3.1 环境搭建与准备测试前先把现场环境完整搞出来测试花名册至少10人覆盖不同年龄、肤质、是否戴眼镜、是否习惯戴口罩其中至少包含2位“困难用户”老人或强逆光时容易识别失败的人。人员分两类注册人员录入系统、未注册人员用于测误识率。测试工具秒表或手机秒表测试记录表拍照/录像设备记录异常画面光照度计可选用于记录现场照度。设备状态确认终端、平台、门禁控制器全部正常运行时间同步准确人员库已正确下发。3.2 光照、角度、遮挡识别测试这是最核心的现场测试内容按控制变量的原则一组一组来。我常用的测试矩阵如下场景测试人数每人测试次数测试要求正常光照室内/阴天1010正对设备距离0.5~1.5米逆光1010人背对窗口或强光源暗光傍晚/夜间1010关闭或调暗环境灯强光直射1010阳光或射灯直射设备戴眼镜含眼镜人员10记录镜片反光影响佩戴口罩1010视甲方需求可不测侧脸30度1010左右侧各5次距离1米距离0.5米/2米105超近和超远距离每个场景记录通过次数、被拒次数、平均耗时、错误类型如报“请靠近屏幕”“照片质量差”“未注册”等。这样统计出来就能看出设备在哪些场景下偏弱。测完之后我会特别关注两个数据一是逆光场景下的拒识率如果明显偏高就需要调整补光或者开启宽动态二是暗光场景下的识别准确率夜间门禁是业主最常反馈的问题。3.3 活体检测与防攻击测试人脸门禁最怕的就是用照片、视频、3D面具开锁。验收时必须做防攻击测试照片攻击用注册人员的清晰正面照片A4打印或手机屏幕对准设备视频攻击用注册人员的短视频在设备前播放3D面具/头模攻击可选预算充足的甲方可以加测静态眨眼/动作指令活体检查设备是否具备动作指令防止简单的翻拍攻击。判定标准很简单上述攻击手段均不能开门且设备应有明确的告警记录或语音提示。这个环节不需要太多次每种攻击方式重复5次左右即可但一定要做。如果设备不具备活体检测能力哪怕算法识别率再高我也不会签字验收——这是底线风险。3.4 1:N大库容与并发热度测试人脸底库越大单次比对的耗时和误识风险都越高这是人脸识别的基本规律。所以1:N大库容测试很重要。实际操作上先向终端灌入目标数量的底库比如1000、5000、10000人用测试人员逐一到设备前刷脸记录时延是否明显上升。再模拟早晚高峰安排多名测试人员连续排队通行看设备是否出现漏识别、排队拥堵、开门指令丢失。检查系统对重复识别、同一人短时间多次进出的策略是否正常。有一种做法是“直接把库灌满测一下”但这样会把设备日常运行拖慢实际效果反而失真。我更推荐在招标要求人数的基础上额外加20%作为冗余测试更贴近真实项目扩容需求。如果设备在加库后识别时延明显超出承诺值或者出现掉线就要让供应商解释并调优。3.5 长时间稳定性与断网恢复测试这块前面提过我再补充操作细节。连续运行测试通常安排在功能测试完成后设备保持通电每天固定时间用测试人员刷脸一次连续72小时以上。观察以下几点是否出现设备重启、死机、识别服务崩溃通行记录是否连续有无某时间段记录缺失设备内存、CPU趋势是否健康固件日志/系统日志中有无异常报错。断网恢复测试的做法把设备从局域网断开模拟光缆故障或交换机断电。测三点断网瞬间设备能否正常开门断网期间通行记录是否本地保存不丢恢复网络后记录是否自动补传无需人工干预。我碰到过一个有意思的情况设备断网后本地开门没问题但恢复网络后补传数据时因为平台端时间戳校验严格把断网期间的所有记录都拒绝了。这种问题不测根本发现不了。4. 常见问题与排查技巧实录评测过程中总会遇见各种奇怪问题。这里整理一份我反复踩过的坑和排查思路。4.1 识别“虚高”的四种来源测试角度太单一厂商演示时永远让测试人员正对摄像头实际使用时侧脸、低头、仰头占比不低。解决评测方案里固定侧脸与俯仰角度测试。库容太小只有几十个人的底库识别速度和准确率当然好。解决按目标库容冗余量灌库后再测。有效样本太少试了20次全通过就敢说“99%准确率”样本量不足统计意义不大。建议每个场景至少100次有效测试。阈值调得很松为了“刷脸必开”把相似度阈值调到很低误识风险飙升。这说明不是设备好而是把安全换成了体验。评测时需要同时考察FAR和FRR不能只看“能不能开”。4.2 鸿蒙设备调试与日志抓取鸿蒙设备出问题第一个动作是抓日志。用DevEco Studio连接设备或者用hdc命令行工具抓取hiloghdc shell hilog -r // 清空日志 hdc shell hilog -b crash | grep com.xxx.face // 抓取应用崩溃日志 hdc file recv /data/log/xxx . // 拉取设备端日志目录实际排查中我见过最多的问题集中在三类应用/服务崩溃重启通常是内存不足或算法库在特定分辨率下异常可从crash log看到具体堆栈。网络连接断开从hilog里搜“connect timeout”“socket close”等关键字能快速判断是平台地址不可达还是终端长时间空闲被服务器断开。特征库同步失败HAP包升级后把底库清空了或者人员库信息未同步到新版本数据目录导致刷脸提示“未注册”。4.3 多人通行、误开门、漏记录的排查这类问题要按链路拆分去查。我常用的排查顺序开门正常但平台无记录优先查网络上传、平台接口日志。可以在平台侧查该设备的上报时间戳如果设备侧有记录但平台没有多半是断网补传或接口鉴权问题。平台有记录但门不开优先查门禁控制器确认控制信号是否发出、电锁供电和接线是否正常。有一种常见情况是开门指令已到达但控制器联动逻辑没有配置成“有效脉冲”导致锁只响不动作。同一人连续刷脸被部分识别多为光线变化、面部状态变化、设备缓存问题可从识别日志看返回的相似度分数如果分数忽高忽低就要查补光和图像质量。4.4 验收报告里的关键表述验收报告的表述很讲究既要客观也要给后续维护留出合理空间。我习惯在报告里采用三级结论合格所有必测项通过或一般缺陷项不影响系统正常运行有条件通过存在非致命缺陷但供应商已在约定时间内给出整改计划可先通过验收、后闭环整改不合格存在重大功能缺失、安全隐患或核心指标不达标需要供应商整改后重新测试。写数据时注意异常样本要标注原因。比如“拒识5次其中2次为测试人员未按规则遮挡面部属于无效样本”这样避免被甲方或供应商各执一词时说不清。5. 验收之后交付落地与性能优化的经验心得5.1 阈值与补光参数的基准调整评测数据出来后通常会发现设备默认参数不一定适合现场。我一般会基于评测结果做一轮调整识别阈值如果FRR偏高用户总被拒先轻微下调阈值例如从0.80调到0.78但不能低于供应商建议的安全下限否则FAR会上升。调完后重新跑一遍关键场景测试验证。补光策略逆光场景表现差优先考虑开启宽动态或提高补光亮度而不是单纯依赖算法。识别距离与安装高度根据现场动线调整设备安装高度标准是摄像头与普通人身高差距不要太大一般在离地1.4~1.5米让设备“平视”人脸而不是俯视。5.2 硬件选型与安装工艺的避坑评测过程中我也踩过选型和安装的坑。比如市面上有些一体机、识别模块像TA1088这类设备是比较常见的型号在库容、接口开放度上差异很大。选型时除了看参数表一定要确认三点是否支持阈值可调是否提供日志和调试接口是否支持离线本地库。安装工艺上人脸门禁最怕两件事一是大面积逆光环境没有遮阳罩二是夜间缺少红外补光。这两点在正式项目里是高频售后问题验收时一定要纳入现场核查项。5.3 把评测清单沉淀成后续项目的标尺评测清单不是一次性工具。我自己是每做一个项目就更新一版清单把现场新遇到的问题和对应排查方法补进去。比如早期清单里没有“断网补传时间戳”这项吃过亏之后补进去现在每个项目都跑。时间长了这份清单就成了团队内部的“验收标尺”新人带着做项目也不容易漏项。最后说点个人感受。做集成项目这么多年我越来越觉得验收不是走形式更不是跟甲方“斗智斗勇”而是在交付前替自己和客户把雷排掉。人脸识别门禁这种天天被人用的系统一次误识、一次拒识、一次漏记录都会被真实用户直接感受到。宁可验收期多花三天把问题清单跑透也不要等交付后花三个月去现场救火。希望这份评测清单对正在做鸿蒙人脸识别门禁项目的同行有点帮助也欢迎大家在实际项目中补充更好的测试思路。