企业官网建设流程全解析

1. 为什么“信创+鸿蒙+人脸门禁”这三个词放在一起会让人头疼

先说个我最近的真实感受。前两年做安防项目，人脸识别门禁的选型逻辑特别简单：预算多少、识别率多少、能不能接现有平台，基本上这三个问题聊完就能定。但这两年信创要求一下来，事情变得复杂了——不是设备性能不行，而是整个技术栈的“国产化适配”成了一个绕不开的考核项。

尤其最近接触的几个政企园区项目，甲方上来就直接问：你们能不能做纯国产化的人脸门禁方案？操作系统能用鸿蒙吗？后端服务器是不是信创的？数据库也要信创的吧？一连串问题问下来，你会发现传统那套“安卓主板 + 海康/大华SDK + Windows服务端”的老路子已经走不通了。

先说清楚一个概念，信创不是指某一个具体产品，而是一整套从底层芯片到操作系统、数据库、中间件、上层应用全面国产化的技术生态。而人脸识别门禁恰恰是安防领域里对“芯片算力、系统稳定性、算法精度、数据安全”四件事都要求极高的场景。现在要在鸿蒙系统上做门禁，还要满足信创要求，难点就集中在这几个维度：

• 硬件层面：主控SoC必须是国产或可替代方案，比如瑞芯微、海思、君正等，且要能跑OpenHarmony或HarmonyOS的适配版本。
• 系统层面：鸿蒙系统本身的版本选择、裁剪定制、驱动适配，尤其是摄像头、补光灯、读卡器、门锁控制器这些外设的HDF驱动开发。
• 算法层面：人脸检测、特征提取、活体检测、人脸比对这些模型能不能在端侧跑得动，能不能降低对云端算力的依赖。
• 数据层面：人脸特征属于敏感个人信息，采集、存储、传输、比对全链路的加密和权限管理怎么做，等保、个保法的合规要求怎么落实。
• 工程落地层面：老旧门禁点位怎么改造？现在还在用Windows的服务器要不要全换？运维团队会不会维护鸿蒙设备？

这篇文章我就围绕这五个层面，把我实际调研和项目推进中踩过的坑、验证过的方案、觉得靠谱的路径，完整地拆一遍。不管你是甲方信息科的负责人，还是做安防集成的厂商，或者想切入信创门禁赛道的个人开发者，这篇文章应该都能给你一个比较清晰的判断框架。

2. 需求拆解：信创门禁项目的真实核心是什么

2.1 “信创”不是换一块主板那么简单

我见过不少项目方的第一反应是：信创不就是把安卓换掉，用鸿蒙或者麒麟系统重新编译一遍APP吗？这个理解偏差挺大的。

以门禁这个场景来说，一台传统的人脸识别门禁终端，内部跑的是Android系统（大多数厂商基于安卓二次开发），底层依赖的是高通/联发科的SoC，人脸算法用的可能是商汤、旷视的SDK，门禁控制逻辑通过韦根协议或者RS485对接门锁控制器，后端管理平台部署在Windows Server + SQL Server上，客户端用C#或者Web方式访问。

而信创版本的门禁，整套链路都得变：

• 终端操作系统从Android变成OpenHarmony或者基于OpenHarmony的行业发行版。
• 主控芯片从高通/联发科切换为瑞芯微、海思、全志等国产SoC。
• 算法SDK需要适配鸿蒙的Native层接口，或者干脆用开源模型自研。
• 后端服务要跑在麒麟、统信UOS等信创操作系统上。
• 数据库要换成达梦、人大金仓、openGauss这些。这里我不是说每一家门禁厂商都已经做到了这一步，而是说“信创门禁”验收的时候，甲方会按这个标准来查。

所以真实的项目痛点是：不是某个单点技术上不了，而是整个技术链路的每一项选择都得“可解释、可兜底、可替换”。

2.2 人脸门禁在这个背景下的特殊难点

人脸识别门禁和手机人脸解锁有一个很大的不同：手机人脸解锁失败了我可以用指纹、密码兜底，但门禁是人要进出的，识别失败可能就意味着这个人被挡在门外，或者要通过保安手动放行，这对体验和效率的影响非常直接。

再加上门禁场景的光照极其不可控——逆光、暗光、侧脸、戴口罩、戴帽子，甚至大太阳底下半边脸在阴影里，都是常见情况。我一直觉得，人脸门禁真正考验的不是算法在公开数据集上的99%准确率，而是复杂环境下能不能保持稳定。

在信创+鸿蒙的双重约束下，这个难点会被进一步放大：

• 算法模型得能在端侧（通常也就2-4个TOPS的NPU算力）跑得动，不能动不动就调用云端接口，毕竟园区门口的网络可不一定稳。
• 活体检测在信创门禁上几乎是刚需，因为很多场景有防尾随、防照片开门的要求，而当前主流的红外+RGB双目方案，对底层驱动和系统调度的要求比单目高得多。
• 数据隐私合规，人脸照片和特征值能不能只存在设备本地或者园区私有化服务器上，不经过第三方云端，这直接影响方案架构。

2.3 以终为始：先明确项目边界再谈技术选型

我的习惯是，接到这类项目先写一份“需求确认清单”，把边界划定清楚再动手。因为信创项目里“范围蔓延”太常见了——本来只换终端，结果客户说要不后端也一起换了，数据库也换成新的，再后来发现旧的人脸照片库数据格式还不兼容新平台。

建议清单至少要包含这些项：

• 项目范围：是新建全套，还是利旧改造？如果利旧，旧门禁终端是什么品牌什么系统？能否支持替换？后端平台是否必须兼容旧设备？
• 部署模式：纯离线本地化部署，还是允许云端辅助？很多信创项目因为数据合规要求，直接要求全本地化。
• 终端数量：这直接影响硬件采购成本和管理平台架构，100台和10000台的方案完全不一样。
• 并发需求：上下班高峰期多少人同时过闸机？这决定人脸比对是本地1:1还是1:N，以及后台服务的并发能力。
• 算法精度要求：误识率（FAR）和拒识率（FRR）各容忍到什么水平？这决定了阈值怎么配。
• 合规要求：等保几级？要不要过密评？人脸数据保存多久？删除机制怎么做？

这张清单填完，项目的大致架构和技术路线基本就有数了。

3. 系统架构设计：信创门禁的完整技术链路

3.1 终端侧：鸿蒙系统 + 人脸识别模组的结合方式

终端侧是整个门禁系统最核心的部分，也是最容易出现“看起来能跑但不好用”问题的环节。鸿蒙系统在这块的优势主要体现在三点：

• 分布式能力可以天然支持多设备联动。比如门禁终端采集到人脸，可以把特征值同步到园区内的其他门禁点，实现“刷一次脸、全楼通”的效果。
• 统一开发框架可以一套代码适配多种设备形态，不管是壁挂式门禁机、立柱式闸机头还是桌面式访客机，都可以跑同一套鸿蒙应用。对厂商来说维护成本确实降下来了。
• 系统级的安全机制比安卓更严格，应用沙箱、权限管控、数据加密这些在底层就做了限制，对门禁这种涉及敏感数据的场景是加分项。

具体到实现方式，目前主流有两种：

第一种是纯鸿蒙原生方案。终端主控直接跑OpenHarmony，人脸采集、活体检测、比对识别全部在鸿蒙系统内完成，UI用ArkTS开发，底层算法通过Native C++接口或NPU加速库调用。这种方案最“根正苗红”，信创验收时最容易被认可，缺点是对开发团队要求高——既懂鸿蒙应用开发，又懂C++算法移植的人，市面上还真不多。

第二种是鸿蒙+Linux双系统方案。底层跑OpenHarmony的Linux内核，上层的人脸识别模块以独立进程方式运行，通过Binder或Socket和应用层通信。这种方案的好处是算法模块可以保持相对独立，不用跟ArkTS的UI框架深度耦合，缺点是系统复杂度上去了，调试问题会多一些。

从工程实践看，如果你们团队算法能力较强，建议直接走第一种——纯鸿蒙原生方案。现在OpenHarmony对NPU的支持已经逐渐成熟，RK3588等芯片的NPU在鸿蒙下的推理性能，跑一个小型化的人脸识别模型完全是够用的。但如果你是第一次做，建议先做一个最小可行性验证，拿一块RK3568或者RK3588的开发板，把系统烧录、摄像头出图、NPU推理跑通，再决定后面怎么做。

3.2 算法侧：端侧模型选型与自研的取舍

人脸识别算法的生态，其实已经很成熟了。如果不想从零开始训练模型，有几个开源方向可以快速打底：

• FaceRecognition类开源项目：基于dlib或者ArcFace的思想，用Python或C++实现，虽然是传统的ResNet结构，但在门禁这种受控环境下精度已经够用。
• 商用SDK的信创适配版本：现在国内不少算法厂商都推出了适配鸿蒙/OpenHarmony的SDK，如果你的项目预算充足、时间紧张，直接用商用SDK是最省事的。
• 基于ONNX转换的模型部署：不管你是用PyTorch训练的还是开源社区下载的模型，只要导出成ONNX格式，在鸿蒙端侧通过ONNX Runtime或者自研推理引擎来部署，是一条比较通用的路径。

我的建议是：如果项目验收有“自主可控”的明确要求，算法模型尽量选择开源基座+自研微调路线。比如用ArcFace的预训练模型做人脸特征提取，用MobileFaceNet做轻量化，用CenterFace做检测，这套组合在门禁场景下经过调优，端侧单次识别可以做到200毫秒以内，完全满足通行体验。

实际项目中一定要做的是模型量化。端侧NPU的算力有限，FP32模型在RK3588上推理一张人脸可能要大几十毫秒，量化成INT8之后能提升2-3倍速度，精度损失通常在可接受范围。这一步一定要在项目初期就做，等到开发后期再优化性能就被动了。

3.3 数据链路：从摄像头到门锁的全流程安全设计

人脸门禁最怕的就是数据链路被人截胡或者篡改。我们把完整的数据流拆开来看：

1. 采集端：摄像头模组通过MIPI/USB接口接入SoC，实时视频流进入算法模块。这个环节要防止的是摄像头替换攻击，所以正规做法是在驱动层做摄像头ID校验，非白名单设备不出图。
2. 特征提取：在设备本地完成人脸检测、对齐、特征提取，生成特征向量（通常512维或256维的浮点数组）。这个环节注意不要在应用层直接传输原始人脸图片，尽量只上传特征值。
3. 比对识别：特征值和本地底库（或者远程底库）做比对。本地比对可以大大降低网络依赖，但底库容量有限（端侧存储一般几千到几万人）；远程比对灵活性高，但网络延迟和稳定性是个考验。
4. 控制指令：比对成功以后，门禁终端通过韦根、RS485或者网络继电器向门锁控制器发送开门指令。这个环节的关键是防重放攻击——不能让别人录一段开门指令的报文就能重复开门。
5. 日志记录：每一次开门事件（含抓拍照片、比对得分、人员ID、时间戳）要上传到管理平台存档。

安全设计上，有几个关键点：

• 通信加密：设备到管理平台之间必须走TLS加密通道，有条件甚至建议用国密算法（SM2/SM3/SM4）做双向认证。别觉得这是过度设计，信创项目验收时这是加分项。
• 特征值加密存储：设备本地的人脸底库不能明文存储，建议用SM4或AES-256加密，密钥由管理平台下发并定期轮换。
• 传输最小化：管理平台存储的应该是加密后的特征值而不是原始人脸照片，除非有政策要求必须留档原始照片。
• 数据销毁机制：员工离职、访客离开、项目终止时，对应的人脸数据要有明确的删除策略和操作留痕。

3.4 管理平台：信创服务器上的门禁系统怎么搭

门禁管理平台这一层，在信创项目里往往是最容易被忽略但工作量巨大的部分。

服务器的选型，在信创要求下基本就是麒麟（Kylin）和统信UOS二选一。CPU大概率是鲲鹏、飞腾或者海光系列。数据库和中间件的差距其实不大问题，真正的坑在后端应用开发。

如果你原来的平台是基于Windows + .NET写的，迁移到信创环境基本等于从零开发，因为.NET Core虽然在国产系统上能跑，但UI层、服务层的很多依赖库还得重新适配。更靠谱的路线是：

• 后端代码用Go或Java + Spring Boot重写。这两个技术栈在麒麟系统上有大量验证过的案例，踩坑成本低。
• 数据库优先考虑openGauss或达梦。门禁管理系统的数据量并不大（可能就几十万条开门记录），用达梦完全够用，关键是SQL语法要兼容，否则数据迁移的时候会疼。
• 前端用Web方式，浏览器通过HTTPS访问。注意信创终端上预装的浏览器一般是奇安信或红莲花浏览器，Chromium内核，常规的Vue/React应用都能跑，但要提前测试兼容性。

管理平台的核心功能，我建议不要过度设计，先把这几件事做扎实：人员库管理（录入、下发、注销人脸）、门禁权限配置（谁能过哪道门、什么时间段可以过）、通行记录查询（多条件检索、导出）、设备状态监控（在线率、离线告警、故障上报）、系统日志审计（管理员操作留痕，满足等保要求）。

4. 实施落地：从POC到批量部署的完整路径

4.1 用两周时间做一个“真机验证”POC

信创+鸿蒙门禁这种组合，光看PPT和数据表是判断不了项目能不能成的。我强烈建议在正式投标或者立项前，花一到两周做一个真机验证POC。

POC的范围不用大，但必须覆盖最核心的三条路径：

• 设备端：一块RK3588开发板（或者直接采购一台基于该芯片的门禁样机）+ OpenHarmony系统 + 一个入门级摄像头模组，验证系统能正常启动、摄像头能出图、基础的人脸检测能跑通。
• 算法端：用开源的人脸识别模型，在开发板上完成一次从摄像头抓拍到比对成功的完整流程，记录响应时间（目标端到端小于500ms）和识别率。
• 管理端：在一台麒麟V10服务器上部署一个最小可用的门禁管理服务，能完成人员信息录入、特征值下发、通行记录回传即可。

POC阶段最容易暴露的问题：摄像头驱动适配不完善（MIPI摄像头在某些主板上的驱动优先级有bug）、NPU算子不支持（模型里的某些层在NPU上没法加速，只能掉到CPU跑）、系统休眠唤醒异常（门禁设备长时间运行，这个很容易出问题）。提前发现这些问题，比投标后再解决要主动得多。

4.2 批量部署前必须完成的三项适配工作

第一批样机验证通过后，别急着大规模采购和施工，还有三项适配工作必须在批量部署前完成：

第一项是设备兼容性矩阵。同一个型号的门禁机，不同批次的摄像头模组、屏幕、读卡器模块都可能来自不同供应商。鸿蒙系统的驱动适配一定要覆盖所有可能出现的硬件组合。我有一次在项目中就遇到过，同一型号的设备，前一百台用的是国产摄像头，后面补货的那批换了另一家的模组，结果至少要重新刷一版固件才能正常出图。

第二项是人员底库的大规模导入测试。很多项目在POC阶段只用了几十个人的测试数据，一切正常。但实际部署的时候，动辄几千上万人的底库在导入过程中会遇到各种问题：照片格式不统一、重复人员检测、历史数据字段缺失、照片清晰度不够导致特征值质量低下。这些情况要提前准备好清洗方案。

第三项是权限策略的灰度方案。全园区一次切到新系统，如果出现大面积识别故障，进不了门，那就是事故。稳妥的做法是按楼栋或者按区域分批次切换，每次切换前做好旧系统到新系统的人员权限映射核对。

4.3 安装调试阶段最容易翻车的三个环节

门禁项目安装调试阶段的工作看着不难，但在信创环境下，翻车的点往往很出乎意料：

• 设备激活与License授权：有些鸿蒙设备的License授权机制跟传统安卓设备不一样，可能会出现激活失败、授权过期的情况。尤其是如果License服务器部署在内网，设备离线环境下能不能正常激活，必须提前验证。
• 网络策略配置：园区网一般都有防火墙策略，门禁设备需要的端口（HTTPS 443、设备管理端口、NTP时间同步端口等）如果没放通，设备会“上线即离线”。但这个在信创项目里经常发生，因为网络改造往往要按等保要求重新做分区分域。
• 时间同步问题：门禁日志的时间戳必须准确，否则事后追溯非常麻烦。鸿蒙设备默认的NTP服务器可能连不上政务网/园区网的NTP源，需要手动指定内网NTP地址。

这些都不是什么高深技术，但每个都能让项目多延期几天。

4.4 运维视角：长期稳定运行比上线更重要

门禁设备是7x24小时运行的，上线只是开始，长期的运维能力才是决定项目口碑的关键。

运维核心关注几个指标：设备在线率（目标99%以上）、识别成功率（目标98%以上）、故障平均修复时间（目标24小时以内）。这几个指标背后对应的是完善的告警平台和备件库。

信创设备有个比较现实的问题：硬件如果用的是国产新平台，运维团队对它的了解程度普遍不如传统安卓设备，出了问题排查起来更慢。所以建议在合同中明确要求厂商提供知识库和远程诊断工具，或者在设备上预留远程运维通道（当然要考虑安全）。

另外，鸿蒙系统的OTA升级策略要想清楚。小版本迭代可以直接推送，大版本升级建议先在实验室验证一两周再推送，不要在业务高峰期做批量升级。

5. 安全合规：这部分躲不掉，千万别留到验收前

人脸识别门禁涉及的安全合规问题，多少有点“平时觉得烦、验收时一票否决”的性质。我见过不止一个项目，功能全部做好，最后倒在隐私合规评估上。

5.1 分级分类：你的人脸数据属于什么级别

根据相关法规和数据分类分级指南，人脸信息属于生物识别信息，在个人信息里属于敏感级别。存储和处理的任何一环出了问题，都可能面临严重的后果。

实操中的建议：

• 尽量不要在门禁设备本地存储原始人脸照片，只存特征值，且对特征值进行加密。
• 如果需要留档抓拍照片（比如防尾随追溯），建议只保留最近N天的记录（比如30天），过期自动清理。
• 不同区域的门禁数据最好做物理隔离。比如办公区、机房、档案室的数据不要全部放在同一个库里，权限控制也要分开。

5.2 等保合规：门禁系统在等保里怎么定位

人脸门禁系统如果承载了园区的人员通行管理功能，并且和整个园区的安防平台打通，通常会作为信息系统的安全保护对象参与到等保测评中。

等保2.0里和门禁系统直接相关的控制点主要是：身份鉴别（你用什么方式证明你是合法用户）、访问控制（谁能过哪道门）、安全审计（操作留痕、日志留存）、数据保密性（人脸特征值加密存储）。

和门禁项目方沟通时，建议直接向甲方确认几个问题：这个系统要不要单独过等保？边界定级是几级？测评时间点是什么时候？这直接决定你系统设计时要预留哪些安全功能（比如日志留存时间、双因素认证、密码策略等）。

5.3 国产密码算法：不是可选项，是基本要求

越来越多的信创项目明确要求使用国密算法，包括SSL证书，SM2签名、SM3摘要、SM4加解密都有。和人脸识别直接相关的场景是：

• 设备与服务器之间的通信加密：建议用SM4作为对称加密算法、SM2做密钥协商和签名。
• 人脸特征值存储加密：可以用SM4加密后存储。
• 日志完整性保护：用SM3做哈希链，防止日志被篡改。
• 设备身份认证：给每台设备预置SM2证书，服务器端校验设备身份，防止伪造设备接入平台。

国密算法这块，OpenHarmony底层是支持国密算法的，关键是要在应用层正确调用。建议在项目规划阶段就把国密相关需求明确到对接文档里，别最后再来适配。

6. 实战踩坑记录：几个真实场景的复盘

6.1 移植人脸算法到鸿蒙，SharedLibrary导致的崩溃

我们第一个POC版本是用C++写的人脸识别模块，以.so的方式集成到鸿蒙应用里。第一次联调就发现一个很诡异的问题：算法模块执行到一定流程后，App直接闪退，连崩溃日志都没有。

排查了两天，最后定位到是这个.so依赖了Boost库中的某些组件，而这套Boost库在编译时对线程模型和异常处理的假设与鸿蒙的运行时环境有冲突。解决办法是重新用鸿蒙SDK配套的交叉编译工具链编译算法模块，所有第三方依赖尽量静态链接，不要动态依赖系统库。

这个坑让我意识到，做鸿蒙端侧算法，编译环境和依赖管理是第一要务。建议从项目开始就建立一个统一的Docker交叉编译环境，所有算法相关依赖都放在里面构建，避免“在我电脑上能跑、到设备上就崩”这种经典问题。

6.2 摄像头出图正常但人脸检测完全不触发

还有一次，摄像头在Demo应用里预览正常，但切到人脸识别模块后发现检测完全触发不了。排查后确认不是算法问题，而是摄像头输出的图像格式和算法模型输入不匹配。

传统安卓摄像头默认输出通常是NV21或YV12格式，而鸿蒙相机框架在某些平台上输出的可能是RGBA8888。算法模型如果用的是YUV输入，就需要在中间加一层格式转换。这些细节在文档里往往不会写清楚，必须自己动手验证。

做图像类算法移植时，格式转换这个环节要提前做适配层，接收多种输入格式统一转换，能省很多事。

6.3 活体检测在强光下的误判率飙升

我们最初测试的活体检测方案是3D结构光（或者叫红外深度方案），在室内环境下效果很好，但是拿到室外或者光线复杂的半开放场景，强光干扰下误判率飙升，经常把真人识别成攻击。

排查下来发现主要是红外图像在强光下过曝，深度信息丢失严重。最后解决方案是增加图像质量检测前置模块，在采集到明显过曝或欠曝的帧时自动调节曝光参数并重新采集，同时增加可见光+红外的双模态融合判断。

这个经验是：活体检测不是“有这样一个功能”就可以了，必须根据部署环境的光照特点做针对性调优，尤其在门禁这种绝大多数设备在户外或者半户外环境的场景下。

6.4 底库从Windows平台迁移到信创平台时丢数据

最后一个典型的坑，管理平台从Windows + SQL Server迁移到麒麟 + openGauss时，人员照片和人脸特征值的字段格式完全对不上。SQL Server里的Image类型和openGauss的bytea类型转换后，部分历史数据读取异常，导致这些人的特征值在门禁端匹配不上。

解决方法是写了一个数据迁移程序，统一把照片转为二进制流、特征值转为Base64字符串重新入库，宁可多花一周做数据清洗，也不能迁完了才发现旧照片库没法用。

7. 给正准备做这类项目的你几点实在建议

结合前面的经验和踩过的坑，我最后梳理一份“从零开始做信创鸿蒙人脸门禁”的实操建议清单。这些建议不一定适合所有项目，但至少能帮你在前期避开80%的坑。

7.1 选型方面：算力、摄像头、系统版本怎么定

• 主控SoC优先选RK3588、RK3568或者海思HI3519系列。RK3588的NPU算力有6TOPS，在这个几个里面最强，同时跑检测、特征提取、比对是够用的，即使后续要加更多AI功能也留有余量。
• 摄像头模组选择上，优先选RGB+IR（红外）双目方案，对活体检测和夜间识别都有帮助。分辨率200万像素（1920x1080）就够用，再高只会增加算力消耗，不会带来识别率的明显提升。
• 系统版本建议基于OpenHarmony的行业发行版，不要自己从开源主线拉代码编译维护。OpenHarmony每年的LTS版本（比如4.x版本）已经比较稳定，而自己维护主线分支的运维成本会非常高。

7.2 团队配置：这类项目需要什么样的人

一个信创鸿蒙门禁项目，核心角色至少要有：嵌入式Linux系统工程师（搞驱动适配、系统裁剪、启动优化）、鸿蒙应用开发工程师（ArkTS/ArkUI，负责界面和业务逻辑）、算法工程师（模型转换、量化、推理优化）、后端开发工程师（管理平台开发、数据迁移）、项目经理（跟甲方对接、推进验收）。

如果团队规模有限，避开一个误区：不要指望一个懂安卓开发的工程师快速转鸿蒙开发就行。鸿蒙开发不只是语言层面（ArkTS代替Kotlin/Java），更涉及系统能力、分布式框架、驱动适配这些完全不同的知识体系，建议给团队预留至少一个月的学习和试错时间。

7.3 流程管理：POC、小批量、量产三阶段的节奏

• POC阶段（2-4周）：只做技术验证，确认系统能跑、方案可行，不建议在这个阶段追求功能和界面完整。
• 小批量阶段（4-8周）：10-20台设备部署在真实环境，跑通全业务流程（人员录入、通行、记录查询、权限管理），收集真实场景下的识别率数据。
• 量产阶段：提前确认备货周期、安装施工计划、网络改造方案，制定分批切换策略，把上线风险控制到最低。

整个周期，顺利的话3-4个月能完成一个小规模项目，不要指望一个月上线。

7.4 关于未来的一点观察

鸿蒙生态在行业端的渗透，这两年肉眼可见在加速。目前行业里做OpenHarmony适配的厂商越来越多，主控芯片、传感器、外设模块的驱动适配也慢慢完善起来了。但从实际项目角度看，真正好用的行业方案还不多，早期入局的人在踩坑的同时，也在积累别人没有的工程经验。

人脸识别门禁只是一个切入点，同样的技术底座可以延伸到访客管理、考勤、会议签到、智慧食堂、重点区域管控等更多场景。把这一套信创+鸿蒙的AIoT方案跑通了，后面能做的事情其实非常多。

如果你正准备启动这样一个项目，我的建议是从小做起，把第一个POC跑扎实。技术这条路没有捷径，把每一个细节抠到位，后面的事就是顺水推舟。