# 人脸识别考勤怎么落地？从摄像头到小程序的完整技术选型

> 工厂企业想做刷脸考勤，摄像头怎么接、人脸数据放哪、迟到早退怎么判定？本文给出 RTSP 接入 + 本地人脸比对 + 小程序前端的完整技术方案与成本估算。

「厂里 300 多人，打卡机代打严重，能不能改成刷脸？」这是我们最近接到最多的一类需求。技术上完全可行，但方案怎么选，直接决定成本、准确率和合规风险。

## 先明确三个决策点

**第一，人脸数据存在哪。** 这是最关键的一条。如果把员工人脸上传到第三方云平台，涉及个人信息保护合规问题，员工也容易抵触。更稳妥的做法是把人脸库放在企业自己的服务器上，比对在本地完成，只有考勤结果（工号、时间、是否迟到）往外传。

**第二，用哪套人脸模型。** 主流选择是 InsightFace（精度高、模型体积适中）和 dlib（部署简单、资源占用低）。做 1:N 的员工识别，InsightFace 的 ArcFace 系列在国内场景下表现更稳，一般要求底库照片质量过关。

**第三，摄像头能不能用。** 大部分工厂已有海康、大华的 RTSP 摄像头，可以直接复用，不必重新布线。但要注意分辨率——低于 1080P 的枪机在 3 米外抓拍人脸，误识率会明显上升。

## 完整链路

整条链路是这样的：

1. **取流**：后端通过 RTSP 拉取摄像头视频流（FFmpeg / OpenCV）
2. **转码**：转成 HLS 或 WebRTC，让手机端能实时预览
3. **抓拍**：小程序端预览画面，员工点击抓拍，或后端按帧自动抓拍
4. **检测与对齐**：人脸检测、关键点对齐、质量过滤（模糊/侧脸直接丢弃）
5. **特征比对**：提取 512 维特征向量，在本地底库中做 1:N 检索
6. **业务判定**：命中员工工号 → 记录时间 → 按考勤规则判断迟到/早退
7. **结果输出**：考勤报表、异常提醒、月度统计导出

微信小程序这一层有个实际限制要提前知道：**小程序不能直接播放 RTSP**，必须先由后端转码。另外小程序如果用了云开发，在 Web 端是无法使用 `wx.cloud` 的，需要改成 `app.callFunction()` 调用云函数。

## 成本大致构成

- **硬件**：复用现有摄像头则接近零成本；新增 1080P 摄像头按需采购
- **服务器**：本地一台带独显或强 CPU 的机器即可支撑几十路比对；纯 CPU 推理需要评估并发
- **软件**：取流转码 + 人脸比对 + 考勤规则 + 小程序前端 + 管理后台
- **合规**：员工知情同意书模板、数据留存期限设定

对比传统打卡机，刷脸考勤的初期投入略高，但省掉了代打漏洞和每月核对工时的隐性成本。以 300 人规模测算，人力核对的效率提升通常在半年内就能覆盖投入。

## 几个容易踩的坑

**底库照片不规范。** 用员工自拍的侧脸、戴帽子照片入库，识别率必然差。建议现场统一采集，每人 1–3 张正脸照片。

**光照条件。** 厂区门口的逆光会让抓拍质量骤降。要么加装补光灯，要么把摄像头装在内侧顺光位置。

**网络抖动。** RTSP 取流对网络稳定性敏感，建议摄像头与服务器走内网有线，不要跨公网。

**误识率与阈值。** 阈值调太高会「认不出」，调太低会「认错人」。上线初期建议保留人工复核入口，用真实数据调两周再把阈值固化。

---

如果你正在评估刷脸考勤方案，可以把现场摄像头型号、点位数量和员工规模告诉我们，我们给出具体的可行性与工期判断。