简介基于深度学习的人脸识别考勤系统完整源码与配套文档面向计算机相关专业学生可用于毕业设计、课程设计、期末大作业或项目实战练习。系统主要涵盖人脸检测、特征提取与考勤记录等环节代码结构清晰附带手册和部署说明便于初学者快速上手并二次开发。资源压缩包共2000个文件整体约82.26MB以Python源码文件为主辅以说明文档、前端样式与交互脚本覆盖算法实现、界面展示和项目说明书等不同层面目录结构清晰便于按需查阅。目前已有178人学习该项目经导师指导并通过评审获得99分代码完整、可复现性强适合作为高分毕设的参考模板。借助源码、文档与可视化图表读者可清晰理解人脸识别考勤系统的设计与实现流程亦可在此基础上扩展打卡、日志等功能。1. 人脸识别考勤系统难的不是模型是让模型乖乖上班做一个人脸识别考勤系统听起来是深度学习的活真正动手才发现难点不在把人脸认出是谁而在把「认出是谁」变成一条不会出错的考勤记录。博主当时做这个方向也踩了不少坑——模型在测试集上准确率能到99%一到办公室门口逆光、侧脸、戴口罩立刻翻车。这个项目标题里有两块硬货一是基于深度学习的识别推理二是考勤系统的业务闭环后者才是毕业设计拿高分的关键因为答辩老师一定会追着问迟到怎么算、缺卡怎么判、相似的人怎么办。这套系统适合两类人一类是计算机相关专业做毕业设计手里有源码但不知道怎么讲清楚原理另一类是已经上班的工程师想在公司内部快速搭一套低成本的面部打卡方案。它能解决的核心问题就一句话——用摄像头替代刷卡机把人脸特征变成打卡凭证同时把考勤原始记录算成可汇报的统计结果。接下来我从模型选型、特征提取、业务表设计、常见翻车点到验证方法一层层讲透。2. 选型与原理为什么毕设里都绕不开 ArcFace 这一套2.1 从深度学习的四个环节看考勤系统的建模边界人脸识别考勤系统按深度学习的标准流程拆一共四个环节人脸检测、人脸对齐、特征提取、特征比对。很多新手上来就想训练一个 CNN 分类器把每个员工当一类去训练这是最容易走偏的路后面专门说。先看四个环节里哪些能用现成模型哪些要自己写逻辑。人脸检测负责从摄像头画面里把人脸框出来常见方案是 RetinaFace 和 SCRFD这两种模型在遮挡、小脸上的表现比老一代 MTCNN 好不少。人脸对齐是把检测到的人脸眼睛、鼻子、嘴巴校正到标准位置因为同一个人的脸在不同角度下像素分布完全不一样不对齐直接提特征相似度会掉得很离谱。特征提取是核心把对齐后的 112x112 人脸图变成一串固定长度的向量业内主流是 ArcFace输出 512 维特征。特征比对就简单了算两个人脸向量的余弦相似度超过阈值就认为是同一个人。在这个项目里你要清楚自己的建模边界深度学习模型只负责前三步最后一步比对逻辑和考勤规则是自己写 Python 代码完成的。很多源码里把这四步全部封装在一个类里对外只暴露一个recognize(image) - employee_id方法你改业务的时候会非常痛苦后面讲怎么拆。2.2 本地跑通的依赖安装与模型文件准备不管手里拿到的是哪份源码先确认依赖能不能在当前 Python 版本下跑通。常见做法是要求 Python 3.8 到 3.10 之间太新的版本反而容易出兼容性问题。依赖项里最重的两个是 PyTorch 和 insightface如果只做推理不做训练PyTorch 装 CPU 版就够了训练集三千张以内 CPU 训练也不是不能忍。# 创建虚拟环境避免把系统 Python 搞乱 conda create -n face_attendance python3.9 conda activate face_attendance # 安装 CPU 版 PyTorch注意不要默认装 CUDA 版否则没显卡会报错 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 安装 insightface 和 opencv这两个是人脸检测和特征提取的主力 pip install insightface opencv-python numpy # 安装数据库驱动和 Web 框架按源码实际情况选 pip install flask pymysql这里要说明一下insightface这个包安装后在第一次运行时会自动下载模型文件到用户目录下的~/.insightface/models/buffalo_l里面包含检测模型和识别模型。如果源码里自带模型文件优先用自带的因为自动下载经常因为网络原因中断而且不同版本的 insightface 对模型文件格式的兼容性不完全一样。模型就绪后写一段最简代码验证环境能用 OpenCV 读取摄像头画面并且能跑通检测再往下走。2.3 最小可用的特征提取代码与参数说明把四个环节串起来的最小代码段长这样。这个函数是我在实际项目里反复用到的核心片段也是源码里最常见的封装方式值得逐行读。import insightface import cv2 import numpy as np # 初始化人脸分析器providers 里的参数在无 GPU 机器上必须改成 CPUExecutionProvider face_app insightface.app.FaceAnalysis(namebuffalo_l, providers[CPUExecutionProvider]) face_app.prepare(ctx_id0, det_size(640, 640)) def extract_feature(image_path): # 读取图片BGR 格式注意 OpenCV 读进来是 BGR 不是 RGB img cv2.imread(image_path) # 检测并提取人脸特征在同一张图里出现多张人脸时 faces 会返回多个结果 faces face_app.get(img) if len(faces) 0: return None, None # 默认取第一张人脸考勤场景下镜头前通常只有一个人 face faces[0] # 关键一步normed_embedding 是已经做过 L2 归一化的 512 维特征向量 embedding face.normed_embedding # 同时返回检测框坐标方便后续在画面里画框和判断人脸大小 bbox face.bbox.astype(int).tolist() return embedding, bbox # 测试提取库底图和待识别图的特征 emb_database, _ extract_feature(employee_001.jpg) emb_query, _ extract_feature(camera_capture.jpg) # 余弦相似度计算因为特征已经归一化直接用点积即可 similarity np.dot(emb_database, emb_query) print(fsim{similarity:.4f})这里有两个参数值得注意。det_size(640, 640)是检测分辨率调成(320, 320)会漏掉远距离的小脸调成(1280, 1280)会大幅拖慢推理速度办公室摄像头到人脸距离两米左右用 640 是平衡点。face.normed_embedding拿到的是已经归一化好的向量有些旧代码写的是face.embedding那个需要自己再做一次归一化否则算出来的相似度会集中在 0.99 到 1.0根本没法设阈值这也是个很容易被忽略的坑。2.4 为什么不用 Facenet又为什么不直接训练 CNN 分类器很多教程里会提到 Facenet 和 CosFace但毕设源码里出现频率最高的是 ArcFace原因是它把「类间距离拉大、类内距离缩小」这个目标做得很直接。ArcFace 在分类层之前的夹角边界上加了 margin 惩罚让模型学到的特征天生就适合做余弦比对而 Facenet 用的是三元组损失训练时要反复挖三元组调试成本高不少。在考勤这种数据量不大、类别数固定就是几百号员工的封闭场景里ArcFace 微调的成本和效果都是最可控的。直接训练 CNN 分类器的问题是模型根本不会泛化。假设公司有 50 个人分类器最后一层是 50 个输出节点训练时每个人必须有足够多且角度多样的照片否则学到的全是「这个 ID 对应的照片背景」而不是「这个人的人脸」。新员工入职还得重新训练整个模型这完全违背了考勤系统的增量需求。用 ArcFace 特征库的方案新员工只需要采集两张照片生成特征向量插进数据库模型本身不用动这个优势在答辩时一定要讲清楚。特征库方案对比可以直接用这个表说明方案类别扩展光照鲁棒性训练门槛毕设推荐度CNN 分类器每次加人需重训较差需要大量采集不推荐Facenet加人只需提特征较好三元组难调一般ArcFace加人只需提特征好上手快推荐3. 把「识别」变成「考勤」数据流、表结构与打卡判定核心3.1 考勤系统的数据流和员工库建库设计识别做得再漂亮最终要落到数据库里才有意义。考勤系统的数据流可以画成一条直线摄像头采集 → 人脸检测对齐 → 特征提取 → 跟员工特征库比对 → 命中则插入打卡记录 → 按规则汇总日考勤。这个链条上最容易出问题的是中间三段因为特征比对涉及阈值选多少打卡插入涉及同一人一秒内重复识别要不要去重这都属于工程决策。员工特征库的设计建议用 MySQL 单表解决表结构不要搞得太复杂毕设阶段两张表足够员工表和考勤记录表再加一张视图或者统计查询处理上下班。员工表里存工号、姓名、部门、人脸特征。人脸特征是一个 512 维的 float 向量在 MySQL 里不能用 JSON 字符串硬存建议用 BLOB 类型存二进制Python 端用pickle序列化后再写入读出时再反序列化。这个方案比存 512 个字段的浮点列好得多读写都干净。-- 员工表核心字段就这些别加太多冗余列 CREATE TABLE employee ( emp_id VARCHAR(16) PRIMARY KEY, emp_name VARCHAR(32) NOT NULL, dept VARCHAR(32), face_feature BLOB COMMENT 512维特征pickle序列化后写入, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 打卡记录表每条记录代表一次识别成功后的原始打卡 CREATE TABLE attendance_record ( id INT AUTO_INCREMENT PRIMARY KEY, emp_id VARCHAR(16) NOT NULL, punch_time DATETIME NOT NULL, similarity FLOAT COMMENT 识别时的相似度分数方便复盘阈值, device_id VARCHAR(16) DEFAULT cam01, KEY idx_emp_time (emp_id, punch_time) );建表之后要做一个关键操作给员工批量录入底图。常见做法是建一个register_employee.py脚本循环读取photos/目录下的工号.jpg文件提取特征写入数据库。这里建议在脚本里加一步「质量检查」比如检测不到人脸的直接跳过并打日志特征提取成功但相似度跟库里已有员工超过 0.8 的也要告警防止重复注册。这步在文档说明里写清楚答辩时是个亮点。3.2 打卡判定的核心逻辑人脸比对加业务过滤实时摄像头识别不能每帧都触发数据库写入否则两秒内能刷出几十条记录。常见做法是维护一个「冷却时间」同一员工在五到十秒内只允许写入一次具体值根据办公场景的人流量调节人多的部门调到三秒人少的办公室调到十秒也没问题。import time import numpy as np import pymysql # 全局缓存上一次记录打卡的时间避免同一人连续触发写入 last_punch_time {} def recognize_for_attendance(frame, cursor, threshold0.5, cooldown5.0): faces face_app.get(frame) if len(faces) 0: return None for face in faces: embedding face.normed_embedding # 从数据库拉取全部员工特征实际项目中可以缓存到内存避免每秒查询数据库 cursor.execute(SELECT emp_id, face_feature FROM employee) best_id, best_score None, -1.0 for emp_id, feat_blob in cursor.fetchall(): feat pickle.loads(feat_blob) # 从 BLOB 还原出 512 维向量 score np.dot(embedding, feat) # 归一化后的余弦相似度 if score best_score: best_score, best_id score, emp_id if best_score threshold: now time.time() # 冷却期内跳过重复打卡不报错 if last_punch_time.get(best_id, 0) cooldown now: last_punch_time[best_id] now cursor.execute( INSERT INTO attendance_record (emp_id, punch_time, similarity) VALUES (%s, %s, %s), (best_id, datetime.now(), best_score) ) return best_id, best_score return None, None这段代码的逻辑是先用当前帧里检测到的每张人脸去库里比对拿到最高分和对应员工 ID然后过两个门槛第一个是相似度阈值低于阈值直接不认第二个是冷却时间防重复。参数threshold0.5不是乱写的ArcFace 特征分布里同一人不同照片的相似度通常在 0.55 到 0.8 之间不同人的相似度集中在 0.1 到 0.4 之间0.5 是个比较保守的分界点。但每批训练出来的模型分布略有差异运行后要按实际数据微调后面验证章节会写具体统计方法。这个模块在源码里通常会做得更复杂有的加了多线程抓帧、有的加了消息队列但核心永远是这一段比对、过阈值、防重。把这段逻辑吃透任何版本的源码拿过来都能改得动。3.3 考勤汇总迟到、早退和缺卡的判定边界打卡记录只是原始数据考勤系统要输出的是「这个月谁迟到几次」所以必须有汇总规则。最常见的规则是上班时间设为 09:00下班时间 18:00一天内最早一条记录是上班卡最晚一条是下班卡。上午打卡时间晚于 09:00 算迟到早于 09:00 算正常下班卡早于 18:00 算早退全天没有打卡记录算缺卡。这套逻辑看起来简单但边界条件非常多比如加班到第二天凌晨、请假半天、一个人一天打了四张卡都需要说明。-- 日考勤汇总查询每天取最早和最晚打卡记录再用 CASE WHEN 判定状态 SELECT a.emp_id, DATE(a.punch_time) AS work_day, MIN(a.punch_time) AS first_punch, MAX(a.punch_time) AS last_punch, CASE WHEN DATE_FORMAT(MIN(a.punch_time), %H:%i) 09:00 THEN 迟到 WHEN MIN(a.punch_time) IS NULL THEN 缺卡 ELSE 正常 END AS morning_status, CASE WHEN MAX(a.punch_time) IS NULL THEN 缺卡 WHEN DATE_FORMAT(MAX(a.punch_time), %H:%i) 18:00 THEN 早退 WHEN TIMESTAMPDIFF(HOUR, MIN(a.punch_time), MAX(a.punch_time)) 8 THEN 工时不足 ELSE 正常 END AS evening_status FROM attendance_record a JOIN employee e ON a.emp_id e.emp_id GROUP BY a.emp_id, DATE(a.punch_time);这条 SQL 里最容易被忽略的是TIMESTAMPDIFF(HOUR, MIN(punch_time), MAX(punch_time)) 8这个判断它处理的是「打了卡但工作时间不足」的情况比如上午十点半才来、下午三点就走了这种情况在简单的迟到判定里会被漏掉。很多毕设源码里没有这一句答辩时候被老师问一句就露馅。还有DATE_FORMAT比较字符串时间戳的方式依赖 MySQL 的时间字段精度如果punch_time是DATETIME类型没问题如果错用VARCHAR就会出排序错乱。这些问题写文档说明时要特意强调。3.4 从门禁机到本地摄像头设备对接的取舍有些毕设要求对接现成人脸识别门禁机而不是自己用 USB 摄像头这时候会涉及设备 SDK 或者局域网协议对接。常见做法是先用抓包工具看门禁机上报的数据结构因为市面上绝大多数人脸门禁机都有 HTTP 或私有 TCP 上报接口每次识别成功后会向服务端推送一条包含人员 ID、时间戳、设备编号的 JSON 消息。用 Python 的Flask写一个回调接口接收上报再写入刚才的attendance_record表就完成了对接。这条路比自己写摄像头识别省事很多因为设备端已经做了深度学习推理但坑在于每家门禁机的协议不统一有些需要先注册设备、有些需要加密签名。如果你拿到的源码已经实现了门禁机对接那文档说明里一定要写清楚协议格式比如消息体长什么样、字段含义是什么。如果是自己用摄像头就要接受本地推理的算力限制CPU 推理单帧 640x640 检测加特征提取耗时大概在 80 到 150 毫秒之间加上 OpenCV 读帧和业务逻辑能做到每秒三到五帧的稳定处理。打卡场景不追求 30 帧实时这个速度够用。4. 避坑毕设人脸考勤最常见的 5 个翻车点4.1 现象换角度、换光线就认不出人训练集里全是正脸照片测试时人稍微低头或者背光相似度直接掉到 0.3 以下打卡频繁失败。原因是对齐环节依赖人脸关键点极端角度下关键点定位不准输入给特征提取网络的图就歪了。解决方法是每个员工至少录入三张照片一张正脸、一张左右各偏转 30 度、一张戴着日常眼镜的。录入后单独跑验证脚本把摄像头现拍的照片跟库存特征算相似度低于 0.45 就重新采集。这套做法能让光照变化影响小很多因为特征空间对同一人的不同姿态还是有聚类性的。4.2 现象双胞胎和相似脸互相误识别两个人长得太像相似度能到 0.6 以上超过阈值就刷成对方。这个问题不能靠调高阈值解决因为调高到 0.7 之后本人稍微换个角度就过不了。真正有用的做法是把「动态抓拍验证」加进打卡流程第一帧识别候选人是 A 或者 B第二帧让用户稍微转头如果连续三帧的最高分对应的都是同一个人且分数差大于 0.08才确认身份。或者用二次校验识别成功后要求输入工号后四位这对考勤系统的体验影响不大但能从根本上杜绝相似脸误判。答辩时把这个当成系统的抗误识别设计讲很加分。4.3 现象打卡成功但考勤汇总对不上号插入记录成功但日汇总里这个人显示缺卡。排查下来发现是员工 ID 编码不一致录入员工时用EMP001打卡时人脸识别返回的是内部编号1001SQL JOIN 不上。还有一种是打卡时间存的是本地时间但考勤统计服务器时区不同造成上下班判断偏移一小时。解决方法是在识别写入阶段统一转换成Asia/Shanghai时区数据库连接串里也加上serverTimezoneAsia/Shanghai。时间数据一旦混入多种时区后续所有统计都是错的这是个必须提前定死的规范。4.4 现象程序跑起来画面很卡识别延迟越来越大摄像头预览流畅但人脸框出来之后要过一两秒才能显示结果。原因多半是识别比对循环里没有缓存员工特征每帧都重新查库、反序列化、算 512 维向量点积数据库查询一来一去的开销全算进推理延迟里。解决办法是程序启动时把员工表里的特征全部加载到内存字典里员工档案变更时手动触发一次缓存刷新识别循环只跟内存比对。实测同样一组员工内存比对比查库快一个数量级延迟从八百毫秒降到一百毫秒以内。4.5 现象源码能跑但文档说明里的架构图画得跟代码不一致这是毕设里最常见的「隐性翻车」代码是深度学习模型文档里却写成了简单的图像模板匹配答辩老师细问两句就站不住。原因是很多人拿到的源码文档是另一份项目的拼凑版没有跟着代码走一遍。解决方法是逐模块核对文档里的调用链从main.py启动到摄像头采集再到数据库写入每个步骤都要跟代码对应上。建议画一张时序图放在文档开头把其中最关键的一段识别代码直接贴进文档正文并加注释这样答辩时不仅讲得清楚还能展现你自己确实读过源码。文档里被问得最频繁的四个点是模型怎么选的、阈值怎么定的、误识率多少、新增员工要不要重训把这几项写成独立的「设计决策说明」章节比什么都管用。5. 成熟度验证与进阶把系统推进到「能答辩、能演示」的标准验证一个考勤系统靠不靠谱不是在摄像头前打一次卡看有没有记录而是做一次批量回测。常见做法是把摄像头固定在公司门口录一段三十分钟的视频然后跑离线脚本把视频逐帧抽出来做识别再跟真实打卡记录比对算出「识别率」和「误报率」两个指标。这两个数字写进文档说明里整个系统的可信度立刻不一样。# 离线回测脚本从历史视频里抽帧统计识别率和误报率 import cv2 from pathlib import Path video_path test_record.avi cap cv2.VideoCapture(video_path) total_frames 0 matched 0 false_alarm 0 # 提前准备一份人工标注的 GT 列表格式为 (帧号, 员工ID) ground_truth load_ground_truth(test_gt.csv) while True: ret, frame cap.read() if not ret: break # 每 5 帧取一次识别业务场景不需要每帧都判定 if total_frames % 5 ! 0: total_frames 1 continue emp_id, score recognize_for_attendance(frame, cursor, threshold0.5) gt_id ground_truth.get(total_frames) if emp_id and emp_id gt_id: matched 1 elif emp_id is None and gt_id is not None: false_alarm 1 # 应该识别成功但漏掉了 total_frames 1 cap.release() print(f识别率{matched / max(len(ground_truth), 1):.2%}) print(f漏检率{false_alarm / max(len(ground_truth), 1):.2%})这段脚本跑一遍你就知道真实场景里自己的系统处在什么水平。识别率在 95% 以上算好用区间90% 到 95% 能演示低于 90% 就必须回头调阈值和数据采集了。进阶方向里最值得做的是活体检测因为纸质照片和手机屏幕能轻松骗过普通摄像头模型用simple-onnx-liveness这类开源方案在识别前加一步判断是真脸还是屏幕成本不高但效果显著。其他方向比如把打卡结果实时推送到企业微信、按部门导出月度考勤报表都属于「加个接口就有亮点」的模块优先级排在活体检测之后。日常开发工作流我也是踩了坑才总结出来的先批量采集底图和测试图再跑批量提取特征入库最后才调阈值和冷却时间这跟许多人「先跑起来再补数据」的习惯刚好相反——数据没准备好任何调参都是黑匣子里的玄学。如果你的源码里文档跟代码对不上宁可花时间自己读代码理一条主线也不要带着错误的架构图去答辩那是给老师送分题。这套方案做下来也许不会让你的考勤系统变成什么惊艳产品但至少每一步你都能说出为什么这么选、踩过什么坑希望帮到你。本文还有配套的精品资源点击获取
简介基于深度学习的人脸识别考勤系统完整源码与配套文档面向计算机相关专业学生可用于毕业设计、课程设计、期末大作业或项目实战练习。系统主要涵盖人脸检测、特征提取与考勤记录等环节代码结构清晰附带手册和部署说明便于初学者快速上手并二次开发。资源压缩包共2000个文件整体约82.26MB以Python源码文件为主辅以说明文档、前端样式与交互脚本覆盖算法实现、界面展示和项目说明书等不同层面目录结构清晰便于按需查阅。目前已有178人学习该项目经导师指导并通过评审获得99分代码完整、可复现性强适合作为高分毕设的参考模板。借助源码、文档与可视化图表读者可清晰理解人脸识别考勤系统的设计与实现流程亦可在此基础上扩展打卡、日志等功能。1. 人脸识别考勤系统难的不是模型是让模型乖乖上班做一个人脸识别考勤系统听起来是深度学习的活真正动手才发现难点不在把人脸认出是谁而在把「认出是谁」变成一条不会出错的考勤记录。博主当时做这个方向也踩了不少坑——模型在测试集上准确率能到99%一到办公室门口逆光、侧脸、戴口罩立刻翻车。这个项目标题里有两块硬货一是基于深度学习的识别推理二是考勤系统的业务闭环后者才是毕业设计拿高分的关键因为答辩老师一定会追着问迟到怎么算、缺卡怎么判、相似的人怎么办。这套系统适合两类人一类是计算机相关专业做毕业设计手里有源码但不知道怎么讲清楚原理另一类是已经上班的工程师想在公司内部快速搭一套低成本的面部打卡方案。它能解决的核心问题就一句话——用摄像头替代刷卡机把人脸特征变成打卡凭证同时把考勤原始记录算成可汇报的统计结果。接下来我从模型选型、特征提取、业务表设计、常见翻车点到验证方法一层层讲透。2. 选型与原理为什么毕设里都绕不开 ArcFace 这一套2.1 从深度学习的四个环节看考勤系统的建模边界人脸识别考勤系统按深度学习的标准流程拆一共四个环节人脸检测、人脸对齐、特征提取、特征比对。很多新手上来就想训练一个 CNN 分类器把每个员工当一类去训练这是最容易走偏的路后面专门说。先看四个环节里哪些能用现成模型哪些要自己写逻辑。人脸检测负责从摄像头画面里把人脸框出来常见方案是 RetinaFace 和 SCRFD这两种模型在遮挡、小脸上的表现比老一代 MTCNN 好不少。人脸对齐是把检测到的人脸眼睛、鼻子、嘴巴校正到标准位置因为同一个人的脸在不同角度下像素分布完全不一样不对齐直接提特征相似度会掉得很离谱。特征提取是核心把对齐后的 112x112 人脸图变成一串固定长度的向量业内主流是 ArcFace输出 512 维特征。特征比对就简单了算两个人脸向量的余弦相似度超过阈值就认为是同一个人。在这个项目里你要清楚自己的建模边界深度学习模型只负责前三步最后一步比对逻辑和考勤规则是自己写 Python 代码完成的。很多源码里把这四步全部封装在一个类里对外只暴露一个recognize(image) - employee_id方法你改业务的时候会非常痛苦后面讲怎么拆。2.2 本地跑通的依赖安装与模型文件准备不管手里拿到的是哪份源码先确认依赖能不能在当前 Python 版本下跑通。常见做法是要求 Python 3.8 到 3.10 之间太新的版本反而容易出兼容性问题。依赖项里最重的两个是 PyTorch 和 insightface如果只做推理不做训练PyTorch 装 CPU 版就够了训练集三千张以内 CPU 训练也不是不能忍。# 创建虚拟环境避免把系统 Python 搞乱 conda create -n face_attendance python3.9 conda activate face_attendance # 安装 CPU 版 PyTorch注意不要默认装 CUDA 版否则没显卡会报错 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 安装 insightface 和 opencv这两个是人脸检测和特征提取的主力 pip install insightface opencv-python numpy # 安装数据库驱动和 Web 框架按源码实际情况选 pip install flask pymysql这里要说明一下insightface这个包安装后在第一次运行时会自动下载模型文件到用户目录下的~/.insightface/models/buffalo_l里面包含检测模型和识别模型。如果源码里自带模型文件优先用自带的因为自动下载经常因为网络原因中断而且不同版本的 insightface 对模型文件格式的兼容性不完全一样。模型就绪后写一段最简代码验证环境能用 OpenCV 读取摄像头画面并且能跑通检测再往下走。2.3 最小可用的特征提取代码与参数说明把四个环节串起来的最小代码段长这样。这个函数是我在实际项目里反复用到的核心片段也是源码里最常见的封装方式值得逐行读。import insightface import cv2 import numpy as np # 初始化人脸分析器providers 里的参数在无 GPU 机器上必须改成 CPUExecutionProvider face_app insightface.app.FaceAnalysis(namebuffalo_l, providers[CPUExecutionProvider]) face_app.prepare(ctx_id0, det_size(640, 640)) def extract_feature(image_path): # 读取图片BGR 格式注意 OpenCV 读进来是 BGR 不是 RGB img cv2.imread(image_path) # 检测并提取人脸特征在同一张图里出现多张人脸时 faces 会返回多个结果 faces face_app.get(img) if len(faces) 0: return None, None # 默认取第一张人脸考勤场景下镜头前通常只有一个人 face faces[0] # 关键一步normed_embedding 是已经做过 L2 归一化的 512 维特征向量 embedding face.normed_embedding # 同时返回检测框坐标方便后续在画面里画框和判断人脸大小 bbox face.bbox.astype(int).tolist() return embedding, bbox # 测试提取库底图和待识别图的特征 emb_database, _ extract_feature(employee_001.jpg) emb_query, _ extract_feature(camera_capture.jpg) # 余弦相似度计算因为特征已经归一化直接用点积即可 similarity np.dot(emb_database, emb_query) print(fsim{similarity:.4f})这里有两个参数值得注意。det_size(640, 640)是检测分辨率调成(320, 320)会漏掉远距离的小脸调成(1280, 1280)会大幅拖慢推理速度办公室摄像头到人脸距离两米左右用 640 是平衡点。face.normed_embedding拿到的是已经归一化好的向量有些旧代码写的是face.embedding那个需要自己再做一次归一化否则算出来的相似度会集中在 0.99 到 1.0根本没法设阈值这也是个很容易被忽略的坑。2.4 为什么不用 Facenet又为什么不直接训练 CNN 分类器很多教程里会提到 Facenet 和 CosFace但毕设源码里出现频率最高的是 ArcFace原因是它把「类间距离拉大、类内距离缩小」这个目标做得很直接。ArcFace 在分类层之前的夹角边界上加了 margin 惩罚让模型学到的特征天生就适合做余弦比对而 Facenet 用的是三元组损失训练时要反复挖三元组调试成本高不少。在考勤这种数据量不大、类别数固定就是几百号员工的封闭场景里ArcFace 微调的成本和效果都是最可控的。直接训练 CNN 分类器的问题是模型根本不会泛化。假设公司有 50 个人分类器最后一层是 50 个输出节点训练时每个人必须有足够多且角度多样的照片否则学到的全是「这个 ID 对应的照片背景」而不是「这个人的人脸」。新员工入职还得重新训练整个模型这完全违背了考勤系统的增量需求。用 ArcFace 特征库的方案新员工只需要采集两张照片生成特征向量插进数据库模型本身不用动这个优势在答辩时一定要讲清楚。特征库方案对比可以直接用这个表说明方案类别扩展光照鲁棒性训练门槛毕设推荐度CNN 分类器每次加人需重训较差需要大量采集不推荐Facenet加人只需提特征较好三元组难调一般ArcFace加人只需提特征好上手快推荐3. 把「识别」变成「考勤」数据流、表结构与打卡判定核心3.1 考勤系统的数据流和员工库建库设计识别做得再漂亮最终要落到数据库里才有意义。考勤系统的数据流可以画成一条直线摄像头采集 → 人脸检测对齐 → 特征提取 → 跟员工特征库比对 → 命中则插入打卡记录 → 按规则汇总日考勤。这个链条上最容易出问题的是中间三段因为特征比对涉及阈值选多少打卡插入涉及同一人一秒内重复识别要不要去重这都属于工程决策。员工特征库的设计建议用 MySQL 单表解决表结构不要搞得太复杂毕设阶段两张表足够员工表和考勤记录表再加一张视图或者统计查询处理上下班。员工表里存工号、姓名、部门、人脸特征。人脸特征是一个 512 维的 float 向量在 MySQL 里不能用 JSON 字符串硬存建议用 BLOB 类型存二进制Python 端用pickle序列化后再写入读出时再反序列化。这个方案比存 512 个字段的浮点列好得多读写都干净。-- 员工表核心字段就这些别加太多冗余列 CREATE TABLE employee ( emp_id VARCHAR(16) PRIMARY KEY, emp_name VARCHAR(32) NOT NULL, dept VARCHAR(32), face_feature BLOB COMMENT 512维特征pickle序列化后写入, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 打卡记录表每条记录代表一次识别成功后的原始打卡 CREATE TABLE attendance_record ( id INT AUTO_INCREMENT PRIMARY KEY, emp_id VARCHAR(16) NOT NULL, punch_time DATETIME NOT NULL, similarity FLOAT COMMENT 识别时的相似度分数方便复盘阈值, device_id VARCHAR(16) DEFAULT cam01, KEY idx_emp_time (emp_id, punch_time) );建表之后要做一个关键操作给员工批量录入底图。常见做法是建一个register_employee.py脚本循环读取photos/目录下的工号.jpg文件提取特征写入数据库。这里建议在脚本里加一步「质量检查」比如检测不到人脸的直接跳过并打日志特征提取成功但相似度跟库里已有员工超过 0.8 的也要告警防止重复注册。这步在文档说明里写清楚答辩时是个亮点。3.2 打卡判定的核心逻辑人脸比对加业务过滤实时摄像头识别不能每帧都触发数据库写入否则两秒内能刷出几十条记录。常见做法是维护一个「冷却时间」同一员工在五到十秒内只允许写入一次具体值根据办公场景的人流量调节人多的部门调到三秒人少的办公室调到十秒也没问题。import time import numpy as np import pymysql # 全局缓存上一次记录打卡的时间避免同一人连续触发写入 last_punch_time {} def recognize_for_attendance(frame, cursor, threshold0.5, cooldown5.0): faces face_app.get(frame) if len(faces) 0: return None for face in faces: embedding face.normed_embedding # 从数据库拉取全部员工特征实际项目中可以缓存到内存避免每秒查询数据库 cursor.execute(SELECT emp_id, face_feature FROM employee) best_id, best_score None, -1.0 for emp_id, feat_blob in cursor.fetchall(): feat pickle.loads(feat_blob) # 从 BLOB 还原出 512 维向量 score np.dot(embedding, feat) # 归一化后的余弦相似度 if score best_score: best_score, best_id score, emp_id if best_score threshold: now time.time() # 冷却期内跳过重复打卡不报错 if last_punch_time.get(best_id, 0) cooldown now: last_punch_time[best_id] now cursor.execute( INSERT INTO attendance_record (emp_id, punch_time, similarity) VALUES (%s, %s, %s), (best_id, datetime.now(), best_score) ) return best_id, best_score return None, None这段代码的逻辑是先用当前帧里检测到的每张人脸去库里比对拿到最高分和对应员工 ID然后过两个门槛第一个是相似度阈值低于阈值直接不认第二个是冷却时间防重复。参数threshold0.5不是乱写的ArcFace 特征分布里同一人不同照片的相似度通常在 0.55 到 0.8 之间不同人的相似度集中在 0.1 到 0.4 之间0.5 是个比较保守的分界点。但每批训练出来的模型分布略有差异运行后要按实际数据微调后面验证章节会写具体统计方法。这个模块在源码里通常会做得更复杂有的加了多线程抓帧、有的加了消息队列但核心永远是这一段比对、过阈值、防重。把这段逻辑吃透任何版本的源码拿过来都能改得动。3.3 考勤汇总迟到、早退和缺卡的判定边界打卡记录只是原始数据考勤系统要输出的是「这个月谁迟到几次」所以必须有汇总规则。最常见的规则是上班时间设为 09:00下班时间 18:00一天内最早一条记录是上班卡最晚一条是下班卡。上午打卡时间晚于 09:00 算迟到早于 09:00 算正常下班卡早于 18:00 算早退全天没有打卡记录算缺卡。这套逻辑看起来简单但边界条件非常多比如加班到第二天凌晨、请假半天、一个人一天打了四张卡都需要说明。-- 日考勤汇总查询每天取最早和最晚打卡记录再用 CASE WHEN 判定状态 SELECT a.emp_id, DATE(a.punch_time) AS work_day, MIN(a.punch_time) AS first_punch, MAX(a.punch_time) AS last_punch, CASE WHEN DATE_FORMAT(MIN(a.punch_time), %H:%i) 09:00 THEN 迟到 WHEN MIN(a.punch_time) IS NULL THEN 缺卡 ELSE 正常 END AS morning_status, CASE WHEN MAX(a.punch_time) IS NULL THEN 缺卡 WHEN DATE_FORMAT(MAX(a.punch_time), %H:%i) 18:00 THEN 早退 WHEN TIMESTAMPDIFF(HOUR, MIN(a.punch_time), MAX(a.punch_time)) 8 THEN 工时不足 ELSE 正常 END AS evening_status FROM attendance_record a JOIN employee e ON a.emp_id e.emp_id GROUP BY a.emp_id, DATE(a.punch_time);这条 SQL 里最容易被忽略的是TIMESTAMPDIFF(HOUR, MIN(punch_time), MAX(punch_time)) 8这个判断它处理的是「打了卡但工作时间不足」的情况比如上午十点半才来、下午三点就走了这种情况在简单的迟到判定里会被漏掉。很多毕设源码里没有这一句答辩时候被老师问一句就露馅。还有DATE_FORMAT比较字符串时间戳的方式依赖 MySQL 的时间字段精度如果punch_time是DATETIME类型没问题如果错用VARCHAR就会出排序错乱。这些问题写文档说明时要特意强调。3.4 从门禁机到本地摄像头设备对接的取舍有些毕设要求对接现成人脸识别门禁机而不是自己用 USB 摄像头这时候会涉及设备 SDK 或者局域网协议对接。常见做法是先用抓包工具看门禁机上报的数据结构因为市面上绝大多数人脸门禁机都有 HTTP 或私有 TCP 上报接口每次识别成功后会向服务端推送一条包含人员 ID、时间戳、设备编号的 JSON 消息。用 Python 的Flask写一个回调接口接收上报再写入刚才的attendance_record表就完成了对接。这条路比自己写摄像头识别省事很多因为设备端已经做了深度学习推理但坑在于每家门禁机的协议不统一有些需要先注册设备、有些需要加密签名。如果你拿到的源码已经实现了门禁机对接那文档说明里一定要写清楚协议格式比如消息体长什么样、字段含义是什么。如果是自己用摄像头就要接受本地推理的算力限制CPU 推理单帧 640x640 检测加特征提取耗时大概在 80 到 150 毫秒之间加上 OpenCV 读帧和业务逻辑能做到每秒三到五帧的稳定处理。打卡场景不追求 30 帧实时这个速度够用。4. 避坑毕设人脸考勤最常见的 5 个翻车点4.1 现象换角度、换光线就认不出人训练集里全是正脸照片测试时人稍微低头或者背光相似度直接掉到 0.3 以下打卡频繁失败。原因是对齐环节依赖人脸关键点极端角度下关键点定位不准输入给特征提取网络的图就歪了。解决方法是每个员工至少录入三张照片一张正脸、一张左右各偏转 30 度、一张戴着日常眼镜的。录入后单独跑验证脚本把摄像头现拍的照片跟库存特征算相似度低于 0.45 就重新采集。这套做法能让光照变化影响小很多因为特征空间对同一人的不同姿态还是有聚类性的。4.2 现象双胞胎和相似脸互相误识别两个人长得太像相似度能到 0.6 以上超过阈值就刷成对方。这个问题不能靠调高阈值解决因为调高到 0.7 之后本人稍微换个角度就过不了。真正有用的做法是把「动态抓拍验证」加进打卡流程第一帧识别候选人是 A 或者 B第二帧让用户稍微转头如果连续三帧的最高分对应的都是同一个人且分数差大于 0.08才确认身份。或者用二次校验识别成功后要求输入工号后四位这对考勤系统的体验影响不大但能从根本上杜绝相似脸误判。答辩时把这个当成系统的抗误识别设计讲很加分。4.3 现象打卡成功但考勤汇总对不上号插入记录成功但日汇总里这个人显示缺卡。排查下来发现是员工 ID 编码不一致录入员工时用EMP001打卡时人脸识别返回的是内部编号1001SQL JOIN 不上。还有一种是打卡时间存的是本地时间但考勤统计服务器时区不同造成上下班判断偏移一小时。解决方法是在识别写入阶段统一转换成Asia/Shanghai时区数据库连接串里也加上serverTimezoneAsia/Shanghai。时间数据一旦混入多种时区后续所有统计都是错的这是个必须提前定死的规范。4.4 现象程序跑起来画面很卡识别延迟越来越大摄像头预览流畅但人脸框出来之后要过一两秒才能显示结果。原因多半是识别比对循环里没有缓存员工特征每帧都重新查库、反序列化、算 512 维向量点积数据库查询一来一去的开销全算进推理延迟里。解决办法是程序启动时把员工表里的特征全部加载到内存字典里员工档案变更时手动触发一次缓存刷新识别循环只跟内存比对。实测同样一组员工内存比对比查库快一个数量级延迟从八百毫秒降到一百毫秒以内。4.5 现象源码能跑但文档说明里的架构图画得跟代码不一致这是毕设里最常见的「隐性翻车」代码是深度学习模型文档里却写成了简单的图像模板匹配答辩老师细问两句就站不住。原因是很多人拿到的源码文档是另一份项目的拼凑版没有跟着代码走一遍。解决方法是逐模块核对文档里的调用链从main.py启动到摄像头采集再到数据库写入每个步骤都要跟代码对应上。建议画一张时序图放在文档开头把其中最关键的一段识别代码直接贴进文档正文并加注释这样答辩时不仅讲得清楚还能展现你自己确实读过源码。文档里被问得最频繁的四个点是模型怎么选的、阈值怎么定的、误识率多少、新增员工要不要重训把这几项写成独立的「设计决策说明」章节比什么都管用。5. 成熟度验证与进阶把系统推进到「能答辩、能演示」的标准验证一个考勤系统靠不靠谱不是在摄像头前打一次卡看有没有记录而是做一次批量回测。常见做法是把摄像头固定在公司门口录一段三十分钟的视频然后跑离线脚本把视频逐帧抽出来做识别再跟真实打卡记录比对算出「识别率」和「误报率」两个指标。这两个数字写进文档说明里整个系统的可信度立刻不一样。# 离线回测脚本从历史视频里抽帧统计识别率和误报率 import cv2 from pathlib import Path video_path test_record.avi cap cv2.VideoCapture(video_path) total_frames 0 matched 0 false_alarm 0 # 提前准备一份人工标注的 GT 列表格式为 (帧号, 员工ID) ground_truth load_ground_truth(test_gt.csv) while True: ret, frame cap.read() if not ret: break # 每 5 帧取一次识别业务场景不需要每帧都判定 if total_frames % 5 ! 0: total_frames 1 continue emp_id, score recognize_for_attendance(frame, cursor, threshold0.5) gt_id ground_truth.get(total_frames) if emp_id and emp_id gt_id: matched 1 elif emp_id is None and gt_id is not None: false_alarm 1 # 应该识别成功但漏掉了 total_frames 1 cap.release() print(f识别率{matched / max(len(ground_truth), 1):.2%}) print(f漏检率{false_alarm / max(len(ground_truth), 1):.2%})这段脚本跑一遍你就知道真实场景里自己的系统处在什么水平。识别率在 95% 以上算好用区间90% 到 95% 能演示低于 90% 就必须回头调阈值和数据采集了。进阶方向里最值得做的是活体检测因为纸质照片和手机屏幕能轻松骗过普通摄像头模型用simple-onnx-liveness这类开源方案在识别前加一步判断是真脸还是屏幕成本不高但效果显著。其他方向比如把打卡结果实时推送到企业微信、按部门导出月度考勤报表都属于「加个接口就有亮点」的模块优先级排在活体检测之后。日常开发工作流我也是踩了坑才总结出来的先批量采集底图和测试图再跑批量提取特征入库最后才调阈值和冷却时间这跟许多人「先跑起来再补数据」的习惯刚好相反——数据没准备好任何调参都是黑匣子里的玄学。如果你的源码里文档跟代码对不上宁可花时间自己读代码理一条主线也不要带着错误的架构图去答辩那是给老师送分题。这套方案做下来也许不会让你的考勤系统变成什么惊艳产品但至少每一步你都能说出为什么这么选、踩过什么坑希望帮到你。本文还有配套的精品资源点击获取
