「厂里 300 多人，打卡机代打严重，能不能改成刷脸？」这是我们最近接到最多的一类需求。技术上完全可行，但方案怎么选，直接决定成本、准确率和合规风险。
先明确三个决策点
第一，人脸数据存在哪。 这是最关键的一条。如果把员工人脸上传到第三方云平台，涉及个人信息保护合规问题，员工也容易抵触。更稳妥的做法是把人脸库放在企业自己的服务器上，比对在本地完成，只有考勤结果（工号、时间、是否迟到）往外传。
第二，用哪套人脸模型。 主流选择是 InsightFace（精度高、模型体积适中）和 dlib（部署简单、资源占用低）。做 1:N 的员工识别，InsightFace 的 ArcFace 系列在国内场景下表现更稳，一般要求底库照片质量过关。
第三，摄像头能不能用。 大部分工厂已有海康、大华的 RTSP 摄像头，可以直接复用，不必重新布线。但要注意分辨率——低于 1080P 的枪机在 3 米外抓拍人脸，误识率会明显上升。
完整链路
整条链路是这样的：
- 取流：后端通过 RTSP 拉取摄像头视频流（FFmpeg / OpenCV）
- 转码：转成 HLS 或 WebRTC，让手机端能实时预览
- 抓拍：小程序端预览画面，员工点击抓拍，或后端按帧自动抓拍
- 检测与对齐：人脸检测、关键点对齐、质量过滤（模糊/侧脸直接丢弃）
- 特征比对：提取 512 维特征向量，在本地底库中做 1:N 检索
- 业务判定：命中员工工号 → 记录时间 → 按考勤规则判断迟到/早退
- 结果输出：考勤报表、异常提醒、月度统计导出
微信小程序这一层有个实际限制要提前知道：小程序不能直接播放 RTSP，必须先由后端转码。另外小程序如果用了云开发，在 Web 端是无法使用 wx.cloud 的，需要改成 app.callFunction() 调用云函数。
成本大致构成
- 硬件：复用现有摄像头则接近零成本；新增 1080P 摄像头按需采购
- 服务器：本地一台带独显或强 CPU 的机器即可支撑几十路比对；纯 CPU 推理需要评估并发
- 软件：取流转码 + 人脸比对 + 考勤规则 + 小程序前端 + 管理后台
- 合规：员工知情同意书模板、数据留存期限设定
对比传统打卡机，刷脸考勤的初期投入略高，但省掉了代打漏洞和每月核对工时的隐性成本。以 300 人规模测算，人力核对的效率提升通常在半年内就能覆盖投入。
几个容易踩的坑
底库照片不规范。 用员工自拍的侧脸、戴帽子照片入库，识别率必然差。建议现场统一采集，每人 1–3 张正脸照片。
光照条件。 厂区门口的逆光会让抓拍质量骤降。要么加装补光灯，要么把摄像头装在内侧顺光位置。
网络抖动。 RTSP 取流对网络稳定性敏感，建议摄像头与服务器走内网有线，不要跨公网。
误识率与阈值。 阈值调太高会「认不出」，调太低会「认错人」。上线初期建议保留人工复核入口，用真实数据调两周再把阈值固化。
如果你正在评估刷脸考勤方案，可以把现场摄像头型号、点位数量和员工规模告诉我们，我们给出具体的可行性与工期判断。