这两年课堂考勤一直是个很有意思的需求。我接到的这个项目名字有点长基于百度AI的课堂人脸识别学生选课考勤签到APP的小程序。拆开看其实就三件事选课、考勤、人脸识别把这三件事装进一个小程序里用百度AI的人脸识别来确认“来上课的这个人确实是选了这门课的学生”。项目做完之后我最大的感受是原来考勤这件事真的可以又快又稳还能顺手解决代签、漏签、人工统计一堆老问题。这篇文章会把整个项目的方案选型、核心链路、完整实操过程和踩坑记录都写出来。不管你是准备给学校做一套考勤工具还是单纯想研究小程序怎么接百度AI人脸识别应该都能从中拿到可以直接用的东西。1. 这个项目到底要干什么先想清楚方案再动手1.1 课堂考勤的三个老大难做这个项目之前我特意去旁听了几节大课。课堂考勤的痛点比我想象的明显一百多人的阶梯教室点名至少要花两三分钟老师念名字学生喊到底下还有帮忙答到的“热心同学”统计出来到底谁来了谁没来又得靠课代表课后整理错误率高得离谱。刷卡考勤倒是快但代刷现象很难避免一张校园卡可以在宿舍和教室之间来回传递。扫码签到稍微好一点可学生把二维码截图发到群里人在宿舍也能签上。传统方式的共同问题是考勤记录和“真正到场的人”之间缺乏一个无法伪造的绑定关系。人脸识别天然适合这个场景。每个人的脸是唯一的不容易被复制也不需要像指纹那样专门采集学生走到教室掏出手机拍一下系统就能认出你是谁顺便把你选的课、上课时间、签到情况全部关联起来。这就是这个项目的核心价值把“选课信息、出勤情况、身份验证”三块数据通过人脸识别串成一条完整的证据链。1.2 为什么选百度AI而不是自己训练模型这里要说明一下方案选型的逻辑。最早我确实纠结过要不要自己训练一个轻量人脸识别模型毕竟现在开源模型不少部署在小程序服务端好像也不复杂。但认真评估之后放弃了。人脸识别不只是“认出你是谁”这一步还涉及人脸检测、人脸对齐、特征提取、特征比对、活体检测以及对抗照片和视频翻拍的能力。自己训练一个能用的模型需要大量标注数据、GPU训练环境和持续的迭代时间对于一个小程序考勤工具来说成本太高了。百度智能云的人脸识别服务能把这一整套都封装成API人脸检测、人脸比对、人脸搜索、活体检测按调用量付费而且精度和安全性经过了大规模场景验证。我只需要把学生照片注册到人脸库签到时调一次搜索接口就能拿到“这个人是谁、相似度多少分、是不是活体”的完整结论。这相当于把最难的算法部分外包出去让我把精力集中在业务逻辑上也就是选课、考勤记录、学生端体验和数据报表。对绝大多数业务型项目来说这是一个更合理的选择。1.3 整体方案小程序端、云函数、百度AI三层结构整个项目的架构可以分成三层。最上面是微信小程序端负责选课列表展示、课程签到页面、拍照上传、结果反馈中间层是微信云开发里的云函数负责转发请求、保存考勤记录、维护课程和选课关系最底层是百度AI人脸识别服务负责接收图片、做人脸检测和身份比对返回识别分数。这里有个关键设计小程序端不能直接拿API Key去调百度AI接口因为密钥放在小程序前端代码里就等于公开了任何人通过抓包都能看到。我把所有请求都封装到云函数里小程序端只调用云函数百度AI的API Key和Secret Key只存在于云端环境变量中。这样做一举两得一是密钥安全有保障二是云函数天然是HTTPS服务端环境能解决小程序前端跨域调外部接口的麻烦。2. 人脸识别核心链路拆解注册、活体、搜索、回写2.1 第一步把人脸“注册”进人脸库识别的前提是库里有你的人脸。这个项目里学生第一次使用签到时候会进入一个“人脸注册”流程输入学号、姓名、选择当前学期选课然后正对摄像头拍一张清晰的照片这张照片会被交给百度AI做人脸检测和特征提取存到指定的Group人脸库里。百度AI的人脸库是按Group管理的一个Group就是一个独立的人脸集合可以在同一个账号下创建多个Group。这个项目建议按学期分Group比如“2025_spring_students”。这样做的好处是如果下个学期学生重新选课签到搜索时只在自己学期的Group里比对能有效减少候选人数识别速度和准确性都会提升。如果全校学生混在一个库里比对候选基数变大误识别概率也会变高。注册这一步还要注意一个细节提交照片前建议先检测照片质量。百度AI的人脸检测接口能返回角度、清晰度、遮挡情况等质量信息注册前检测一次不合格就提示学生重拍。我在项目里把检测标准和注册流程绑定检测接口分数低于阈值就让用户换张照片这种做法能避免很多后续识别问题。2.2 签到时的识别链路从拍照到拿到姓名签到的完整链路是这样的。学生在某门课的签到页面点击“开始签到”小程序打开摄像头拍一张正脸照把图片转为base64字符串通过云函数发给百度AI人脸搜索接口。百度AI返回一个结果列表包含匹配到的人脸对应的userId、相似度得分和活体检测状态。业务层拿到结果后先看活体是否通过再看相似度是否超过设定阈值两个条件都满足就认定签到成功把本次签到记录写入数据库。这里我特别强调一下为什么活体检测必须开。考勤项目面临的首要作弊手段就是照片和视频翻拍学生拍一张同学的照片对着镜头或者直接拿手机屏幕里的动态视频去扫如果系统不做活体检测这些全都拦不住。百度AI的活体检测能分析图片中的人脸是否为现场真实人脸对屏幕翻拍、纸质照片打印这类攻击有明显的拦截能力。实际测试下来开启NORMAL等级的活体控制后拿翻拍照片直接试的通过率很低基本都能识别为伪造。数据回写也很重要。签到成功后云函数会把三组数据写入数据库签到记录表里新增一条记录包含学生学号、课程编号、签到时间和识别分数学生的个人签到状态被标记为“已签到”课程的应到人数、实到人数、缺勤名单等统计信息同步更新。这样老师端在课程详情页里看到的就是实时刷新数据不用再手动统计。2.3 阈值设置识别精度和误判率的平衡点人脸识别接口返回的score是一个相似度得分这个分数代表当前人脸和库中目标人脸的匹配程度。分数越高是同一个人的概率越大。百度AI官方给出的推荐阈值是80分但在课堂考勤场景里我会建议把默认阈值设置得更高一点比如85分。为什么考勤最怕的是“甲走到教室机器把他认成了乙”这比“没认出来”麻烦得多。没认出来可以重新拍一次认错了考勤记录就是错的后面说都说不清。85分是我测试下来比较舒服的平衡点正常光线、正常角度下本人识别分数普遍在90分以上通过没问题而长得相似但非本人的匹配分数通常落在75到82之间85的阈值能把大部分误识拦在外面。当然不同班级人数会带来差异小班课可以把阈值稍微降到82大班课建议直接拉到88宁可有时候要重拍也不要认错人。3. 手把手实操记录从创建应用到第一次跑通3.1 申请百度智能云应用拿到密钥开始上手之前先准备好百度智能云账号。登录控制台进入人脸识别产品页面创建一个应用。创建后你会拿到两个关键凭证API Key和Secret Key。这两个东西后面调用接口鉴权都要用到务必妥善保存。我把它们放到了云函数的环境变量里没有写死在代码中这样即使代码仓库泄露密钥也不会暴露。百度AI的鉴权方式是先换token再调接口。用API Key和Secret Key请求token接口拿到一个access_token后续的人脸注册、搜索、检测接口都带着这个token去调用。token有有效期默认是30天所以不能每次调用都重新获取需要在代码里做缓存。这里给出一个云函数里获取并缓存token的示例代码我使用的是Node.js运行时和axios请求库const cloud require(wx-server-sdk) const axios require(axios) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const API_KEY process.env.BAIDU_API_KEY const SECRET_KEY process.env.BAIDU_SECRET_KEY let tokenCache { value: , expireAt: 0 } async function getAccessToken() { const now Date.now() if (tokenCache.value tokenCache.expireAt now) { return tokenCache.value } const url https://aip.baidubce.com/oauth/2.0/token const params { grant_type: client_credentials, client_id: API_KEY, client_secret: SECRET_KEY } const res await axios.get(url, { params }) tokenCache.value res.data.access_token // 提前60秒过期避免刚好在过期边界上请求失败 tokenCache.expireAt now res.data.expires_in * 1000 - 60 * 1000 return tokenCache.value } exports.main async (event) { return { token: await getAccessToken() } }这段代码把token缓存在云函数的全局变量里只要云函数实例不销毁同一个实例内的连续调用都直接用缓存token明显减少鉴权请求次数。有个细节值得注意expires_in的单位是秒需要乘以1000转成毫秒再和Date.now()比较否则会出现“token明明没过期却被反复刷新”的bug。3.2 云函数封装把百度AI的API包成业务接口token搞定之后就开始封装核心业务接口。这个项目的云函数需要提供四个功能人脸注册、人脸签到、查询签到记录、查询课程与选课信息。为了代码结构清晰我拆成了多个云函数文件而不是一个大函数处理所有逻辑。人脸搜索是签到流程的核心我直接给出云函数里的完整实现const cloud require(wx-server-sdk) const axios require(axios) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const GROUP_ID spring_2025_students exports.main async (event) { const { imageBase64, courseId, openid } event // 1. 先查当前用户对应的学号 const userRes await db.collection(users).where({ openid }).get() if (!userRes.data.length) { return { success: false, msg: 用户不存在 } } const student userRes.data[0] // 2. 调百度AI人脸搜索 const token await getAccessToken() const searchUrl https://aip.baidubce.com/rest/2.0/face/v3/search const searchRes await axios.post(searchUrl, { headers: { Content-Type: application/json }, params: { access_token: token }, data: { image: imageBase64, image_type: BASE64, group_id_list: GROUP_ID, user_id: student.studentId, quality_control: NORMAL, liveness_control: NORMAL } }) // 3. 处理识别结果 const result searchRes.data.result if (!result || !result.user_list || result.user_list.length 0) { return { success: false, msg: 未识别到人脸请正对镜头重拍 } } const topMatch result.user_list[0] const score topMatch.score const threshold 85 // 可根据班级规模调整 if (score threshold) { return { success: false, msg: 相似度过低(${Math.round(score)}分)请重新拍摄, score } } // 4. 检查是否已经签到防重复签到 const dupRes await db.collection(attendance) .where({ courseId, studentId: student.studentId }) .get() if (dupRes.data.length) { return { success: false, msg: 你已完成签到请勿重复操作 } } // 5. 写入签到记录 await db.collection(attendance).add({ data: { courseId, studentId: student.studentId, name: student.name, checkTime: Date.now(), score: Math.round(score) } }) return { success: true, msg: 签到成功, score: Math.round(score) } }这里有几个设计要点。我是先用openid去数据库查学号再把这批信息带给百度AI这样学生不需要每次都输入学号。签到前做了一个查重逻辑防止同一个人在同一门课里重复签到这是考勤系统的基本要求。识别结果里我不仅返回了成功信息还把识别分数带了出来学生可以看到自己的签到得分相当于给了个反馈用户心里也踏实。3.3 小程序端核心代码选课列表、拍照签到、结果反馈小程序前端用的是原生开发配合微信云开发。页面结构不复杂核心就三个首页选课列表、课程签到页、个人中心签到记录。选课列表页在onLoad时请求云函数拉取当前学生的选课数据按周次和节次排出近期的课程卡片。每张卡片上显示课程名、上课时间、教室位置和签到状态。签到状态用颜色区分已签到的显示灰色标签。签到页是整个交互体验的重头戏。我用了微信的wx.chooseMedia接口打开相机这个接口在真机上的唤起速度比旧的chooseImage更稳定。拍照后先压缩图片再转base64避免图片过大导致云函数请求超时。压缩我用的是官方推荐的方式先拿到临时文件路径再用wx.compressImage压缩质量到80%最后读取为base64字符串。前端签到调用的核心代码片段如下async takePhotoAndCheckIn(courseId) { const res await wx.chooseMedia({ count: 1, mediaType: [image], sourceType: [camera], captureDevice: front // 强制前置摄像头方便自拍 }) const tempFilePath res.tempFiles[0].tempFilePath // 压缩图片 const compressRes await new Promise((resolve, reject) { wx.compressImage({ src: tempFilePath, quality: 80, success: resolve, fail: reject }) }) // 读取为base64 const fileRes await new Promise((resolve, reject) { wx.getFileSystemManager().readFile({ filePath: compressRes.tempFilePath, encoding: base64, success: resolve, fail: reject }) }) wx.showLoading({ title: 正在进行人脸识别 }) try { const result await wx.cloud.callFunction({ name: faceCheckIn, data: { imageBase64: fileRes.data, courseId } }) wx.hideLoading() const r result.result if (r.success) { wx.showToast({ title: 签到成功 相似度${r.score}, icon: success }) } else { wx.showToast({ title: r.msg, icon: none }) } } catch (e) { wx.hideLoading() wx.showToast({ title: 识别服务异常请稍后重试, icon: none }) } }这个前端流程给用户的感觉就是“拍一下出结果”操作成本几乎为零。我自己在真机测试时从打开相机到看到签到结果最快的一次大约五秒钟。识别时间主要花在图片上传百度AI接口的过程中云函数转发带来的额外延迟很小整体响应速度能接受。3.4 选课逻辑怎么融入考勤流程一开始我只做了签到功能后来发现不行学生签到了但系统不知道他选的什么课签到记录和课程对应不上。于是我把选课流程加进了注册环节。学生在首次使用小程序时进入注册页面在线选择自己的课程。这个项目里的选课列表是模拟数据真实落地时可以对接学校教务系统。注册时绑定课程的好处是签到页面只会展示当前学生的选课列表每节课对应的签到入口清清楚楚不会出现“不知道去哪门课签到”的问题。老师在管理端能看到的是每个课程的出勤报表应到人数、实到人数、缺勤名单。这些数据全部由签到逻辑实时计算不需要人工干预。这也是这个项目比普通小程序考勤更有价值的地方它不仅做了身份验证还顺便把选课数据和考勤数据整合成了完整的数据链。4. 上线前必须解决的问题实测踩坑与排查记录4.1 活体检测误判照片翻拍拦住了吗活体检测是考勤项目最容易出问题的环节我花了大量时间测这一个点。拿到第一版的时候我用手机屏幕翻拍了照片去测识别结果里有不少能通过活体检测的情况。排查后发现问题不在百度AI的算法而在我的请求参数里liveness_control设的是NONE。百度AI的活体控制参数有三个档位默认是NONE需要手动调成NORMAL或HIGH。调成NORMAL之后用屏幕翻拍照片的测试基本都被拦截下来。我还测过用视频动态翻拍的方式NORMAL档位下也有部分通过的情况但把活体控制提到HIGH之后误判率明显下降。不过档位也不是越高越好。HIGH档位对拍摄环境要求更高光线暗一点就容易拒检导致正常签到的通过率下降。我的建议是课堂场景用NORMAL就够教室环境普遍光线良好NORMAL既保证速度又具备基本的安全防护。如果是对安全要求极高的场景再去考虑HIGH。4.2 光线和角度导致的识别失败这是一个真实使用中避不开的问题。有学生坐在靠窗的位置逆光拍了张照片识别分数只有六十多分签到直接失败。也有学生习惯侧脸自拍角度太大导致特征提取不全。这些情况都不是系统bug而是输入图片质量不达标。我的应对方案是双管齐下一是注册环节就做好质量把关注册用的照片必须正脸、光线充足、无遮挡二是签到失败时给清晰的提示不是简单说“签到失败”而是告诉用户“光线太暗请换个位置重试”或者“请正对镜头拍摄”。小程序端还加了一个简单的图片预览让学生拍完能看到自己的照片上传前自己先把关。另外我在百度AI请求里开了quality_control参数。这个参数会做图片质量预检如果图片本身模糊、光线异常或者遮挡严重会直接返回质量不合格不会进入特征比对流程。虽然会多一次检查但能拦截掉大量低质量图片整体识别成功率反而提高了。4.3 access_token过期和并发请求的问题token的管理是接入百度AI时最容易被忽略的细节。项目刚开始测试时只有我一个人调用token缓存逻辑没暴露问题。后来几个同学一起测云函数被调用了十几次突然报出无效token的错误。排查后发现是我缓存逻辑里的一个低级失误多个并发请求同时进来时它们都发现缓存中没有token于是同时去请求新token后拿到token的请求会把前一个覆盖导致一部分请求带着被覆盖前的旧token去调用百度接口自然就报鉴权失败。解决方案是加一个promise缓存锁在token还没返回前后续请求都等待同一个请求完成。想省事的做法是让token过期时间适当放宽并在请求失败时自动重试一次重新获取token这样即使发生并发也能自愈。4.4 隐私与合规人脸数据怎么存、怎么告知做校园场景的项目数据隐私是一道绕不过去的线。学生人脸照片属于敏感个人信息采集前必须明确告知。我在注册页加了一套完整的授权协议说明人脸照片仅用于课堂签到身份验证不会用于其他用途。百度AI方面传入的图片会经过加密传输识别完成后百度侧按规定会暂时保留数据用于安全审计但业务方可以在控制台配置数据保留策略这一点需要和学校的信息化部门确认清楚。还有一个容易被忽略的合规点注册人像照片的权限问题。这个项目可以让教务系统管理员批量导入学生照片也可以让学生自己用小程序拍照注册。从合规风险的角度我更推荐学生自己拍照授权的方式因为照片的来源是学生本人主动操作授权链路更清晰。批量导入的照片来源如果不明确后续容易出合规纠纷。4.5 常见问题速查表整理一下我在开发和测试过程中遇到的高频问题按症状、原因和解决办法列出来方便复现项目时快速定位症状可能原因解决办法返回“用户不存在”openid未在users集合中注册检查用户注册流程确认注册时正确写入学号与openid相似度分数普遍偏低注册照与签到照光线差异过大注册时强制使用正脸、充足光线照片签到提示对准镜头活体检测失败率极高liveness_control参数为NONE或环境光线暗调整参数为NORMAL避开背光环境部分图片上传超时base64体积过大上传前压缩图片质量控制在80%左右token报无效并发请求覆盖token缓存使用promise锁失败时强制刷新token重试识别结果显示库中人员匹配混乱group内注册人数过多且阈值偏低按学期拆分group适当提高阈值到85以上这些问题的共同规律是大部分都是接口参数配置和调用逻辑问题算法本身没有出过错。这也验证了选型百度AI是值得的我只需要把业务层和参数细节处理好就能获得稳定可靠的识别能力。5. 做完这个项目之后的几点体会这个项目做完我对“业务系统成熟AI能力”的组合方式有了更具体的理解。很多人会惯性觉得人脸识别是高科技非要自己训练模型才算厉害但实际上把成熟API用好把业务逻辑设计对才是项目落地成功的关键。百度AI在这里扮演的角色更像一个“识别人脸能力”的基础服务真正决定体验好坏的是前端的交互、阈值的调校、数据的联动这些细节。如果后续还想扩展我会优先考虑两个方向。第一个是把老师端管理界面做成管理后台小程序或网页增加导出Excel报表、批量导入课程课表、考勤异常提醒这些能力让整个考勤系统更完整。第二个是接入学生旷课次数预警当某名学生缺勤次数达到一定数量时自动向辅导员发送提醒。这些都能在现有架构上无缝扩展因为底层的选课关系、签到记录、人脸库已经全部打通了。最后再分享一个体验优化小技巧。签到页面在识别成功后可以展示一个打勾动画和“准时到达”的文案让学生有一个明确的完成感。这个小细节看着不起眼但实际使用率会明显提升学生更愿意主动配合系统而不是觉得被管着。毕竟考勤工具最终是给人用的体验顺了数据自然就准了。 
长河君 · 2026/10/17 7:18:25 · 阅读 1.2k 基于百度AI的小程序课堂人脸识别考勤系统实操指南
这两年课堂考勤一直是个很有意思的需求。我接到的这个项目名字有点长基于百度AI的课堂人脸识别学生选课考勤签到APP的小程序。拆开看其实就三件事选课、考勤、人脸识别把这三件事装进一个小程序里用百度AI的人脸识别来确认“来上课的这个人确实是选了这门课的学生”。项目做完之后我最大的感受是原来考勤这件事真的可以又快又稳还能顺手解决代签、漏签、人工统计一堆老问题。这篇文章会把整个项目的方案选型、核心链路、完整实操过程和踩坑记录都写出来。不管你是准备给学校做一套考勤工具还是单纯想研究小程序怎么接百度AI人脸识别应该都能从中拿到可以直接用的东西。1. 这个项目到底要干什么先想清楚方案再动手1.1 课堂考勤的三个老大难做这个项目之前我特意去旁听了几节大课。课堂考勤的痛点比我想象的明显一百多人的阶梯教室点名至少要花两三分钟老师念名字学生喊到底下还有帮忙答到的“热心同学”统计出来到底谁来了谁没来又得靠课代表课后整理错误率高得离谱。刷卡考勤倒是快但代刷现象很难避免一张校园卡可以在宿舍和教室之间来回传递。扫码签到稍微好一点可学生把二维码截图发到群里人在宿舍也能签上。传统方式的共同问题是考勤记录和“真正到场的人”之间缺乏一个无法伪造的绑定关系。人脸识别天然适合这个场景。每个人的脸是唯一的不容易被复制也不需要像指纹那样专门采集学生走到教室掏出手机拍一下系统就能认出你是谁顺便把你选的课、上课时间、签到情况全部关联起来。这就是这个项目的核心价值把“选课信息、出勤情况、身份验证”三块数据通过人脸识别串成一条完整的证据链。1.2 为什么选百度AI而不是自己训练模型这里要说明一下方案选型的逻辑。最早我确实纠结过要不要自己训练一个轻量人脸识别模型毕竟现在开源模型不少部署在小程序服务端好像也不复杂。但认真评估之后放弃了。人脸识别不只是“认出你是谁”这一步还涉及人脸检测、人脸对齐、特征提取、特征比对、活体检测以及对抗照片和视频翻拍的能力。自己训练一个能用的模型需要大量标注数据、GPU训练环境和持续的迭代时间对于一个小程序考勤工具来说成本太高了。百度智能云的人脸识别服务能把这一整套都封装成API人脸检测、人脸比对、人脸搜索、活体检测按调用量付费而且精度和安全性经过了大规模场景验证。我只需要把学生照片注册到人脸库签到时调一次搜索接口就能拿到“这个人是谁、相似度多少分、是不是活体”的完整结论。这相当于把最难的算法部分外包出去让我把精力集中在业务逻辑上也就是选课、考勤记录、学生端体验和数据报表。对绝大多数业务型项目来说这是一个更合理的选择。1.3 整体方案小程序端、云函数、百度AI三层结构整个项目的架构可以分成三层。最上面是微信小程序端负责选课列表展示、课程签到页面、拍照上传、结果反馈中间层是微信云开发里的云函数负责转发请求、保存考勤记录、维护课程和选课关系最底层是百度AI人脸识别服务负责接收图片、做人脸检测和身份比对返回识别分数。这里有个关键设计小程序端不能直接拿API Key去调百度AI接口因为密钥放在小程序前端代码里就等于公开了任何人通过抓包都能看到。我把所有请求都封装到云函数里小程序端只调用云函数百度AI的API Key和Secret Key只存在于云端环境变量中。这样做一举两得一是密钥安全有保障二是云函数天然是HTTPS服务端环境能解决小程序前端跨域调外部接口的麻烦。2. 人脸识别核心链路拆解注册、活体、搜索、回写2.1 第一步把人脸“注册”进人脸库识别的前提是库里有你的人脸。这个项目里学生第一次使用签到时候会进入一个“人脸注册”流程输入学号、姓名、选择当前学期选课然后正对摄像头拍一张清晰的照片这张照片会被交给百度AI做人脸检测和特征提取存到指定的Group人脸库里。百度AI的人脸库是按Group管理的一个Group就是一个独立的人脸集合可以在同一个账号下创建多个Group。这个项目建议按学期分Group比如“2025_spring_students”。这样做的好处是如果下个学期学生重新选课签到搜索时只在自己学期的Group里比对能有效减少候选人数识别速度和准确性都会提升。如果全校学生混在一个库里比对候选基数变大误识别概率也会变高。注册这一步还要注意一个细节提交照片前建议先检测照片质量。百度AI的人脸检测接口能返回角度、清晰度、遮挡情况等质量信息注册前检测一次不合格就提示学生重拍。我在项目里把检测标准和注册流程绑定检测接口分数低于阈值就让用户换张照片这种做法能避免很多后续识别问题。2.2 签到时的识别链路从拍照到拿到姓名签到的完整链路是这样的。学生在某门课的签到页面点击“开始签到”小程序打开摄像头拍一张正脸照把图片转为base64字符串通过云函数发给百度AI人脸搜索接口。百度AI返回一个结果列表包含匹配到的人脸对应的userId、相似度得分和活体检测状态。业务层拿到结果后先看活体是否通过再看相似度是否超过设定阈值两个条件都满足就认定签到成功把本次签到记录写入数据库。这里我特别强调一下为什么活体检测必须开。考勤项目面临的首要作弊手段就是照片和视频翻拍学生拍一张同学的照片对着镜头或者直接拿手机屏幕里的动态视频去扫如果系统不做活体检测这些全都拦不住。百度AI的活体检测能分析图片中的人脸是否为现场真实人脸对屏幕翻拍、纸质照片打印这类攻击有明显的拦截能力。实际测试下来开启NORMAL等级的活体控制后拿翻拍照片直接试的通过率很低基本都能识别为伪造。数据回写也很重要。签到成功后云函数会把三组数据写入数据库签到记录表里新增一条记录包含学生学号、课程编号、签到时间和识别分数学生的个人签到状态被标记为“已签到”课程的应到人数、实到人数、缺勤名单等统计信息同步更新。这样老师端在课程详情页里看到的就是实时刷新数据不用再手动统计。2.3 阈值设置识别精度和误判率的平衡点人脸识别接口返回的score是一个相似度得分这个分数代表当前人脸和库中目标人脸的匹配程度。分数越高是同一个人的概率越大。百度AI官方给出的推荐阈值是80分但在课堂考勤场景里我会建议把默认阈值设置得更高一点比如85分。为什么考勤最怕的是“甲走到教室机器把他认成了乙”这比“没认出来”麻烦得多。没认出来可以重新拍一次认错了考勤记录就是错的后面说都说不清。85分是我测试下来比较舒服的平衡点正常光线、正常角度下本人识别分数普遍在90分以上通过没问题而长得相似但非本人的匹配分数通常落在75到82之间85的阈值能把大部分误识拦在外面。当然不同班级人数会带来差异小班课可以把阈值稍微降到82大班课建议直接拉到88宁可有时候要重拍也不要认错人。3. 手把手实操记录从创建应用到第一次跑通3.1 申请百度智能云应用拿到密钥开始上手之前先准备好百度智能云账号。登录控制台进入人脸识别产品页面创建一个应用。创建后你会拿到两个关键凭证API Key和Secret Key。这两个东西后面调用接口鉴权都要用到务必妥善保存。我把它们放到了云函数的环境变量里没有写死在代码中这样即使代码仓库泄露密钥也不会暴露。百度AI的鉴权方式是先换token再调接口。用API Key和Secret Key请求token接口拿到一个access_token后续的人脸注册、搜索、检测接口都带着这个token去调用。token有有效期默认是30天所以不能每次调用都重新获取需要在代码里做缓存。这里给出一个云函数里获取并缓存token的示例代码我使用的是Node.js运行时和axios请求库const cloud require(wx-server-sdk) const axios require(axios) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const API_KEY process.env.BAIDU_API_KEY const SECRET_KEY process.env.BAIDU_SECRET_KEY let tokenCache { value: , expireAt: 0 } async function getAccessToken() { const now Date.now() if (tokenCache.value tokenCache.expireAt now) { return tokenCache.value } const url https://aip.baidubce.com/oauth/2.0/token const params { grant_type: client_credentials, client_id: API_KEY, client_secret: SECRET_KEY } const res await axios.get(url, { params }) tokenCache.value res.data.access_token // 提前60秒过期避免刚好在过期边界上请求失败 tokenCache.expireAt now res.data.expires_in * 1000 - 60 * 1000 return tokenCache.value } exports.main async (event) { return { token: await getAccessToken() } }这段代码把token缓存在云函数的全局变量里只要云函数实例不销毁同一个实例内的连续调用都直接用缓存token明显减少鉴权请求次数。有个细节值得注意expires_in的单位是秒需要乘以1000转成毫秒再和Date.now()比较否则会出现“token明明没过期却被反复刷新”的bug。3.2 云函数封装把百度AI的API包成业务接口token搞定之后就开始封装核心业务接口。这个项目的云函数需要提供四个功能人脸注册、人脸签到、查询签到记录、查询课程与选课信息。为了代码结构清晰我拆成了多个云函数文件而不是一个大函数处理所有逻辑。人脸搜索是签到流程的核心我直接给出云函数里的完整实现const cloud require(wx-server-sdk) const axios require(axios) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const GROUP_ID spring_2025_students exports.main async (event) { const { imageBase64, courseId, openid } event // 1. 先查当前用户对应的学号 const userRes await db.collection(users).where({ openid }).get() if (!userRes.data.length) { return { success: false, msg: 用户不存在 } } const student userRes.data[0] // 2. 调百度AI人脸搜索 const token await getAccessToken() const searchUrl https://aip.baidubce.com/rest/2.0/face/v3/search const searchRes await axios.post(searchUrl, { headers: { Content-Type: application/json }, params: { access_token: token }, data: { image: imageBase64, image_type: BASE64, group_id_list: GROUP_ID, user_id: student.studentId, quality_control: NORMAL, liveness_control: NORMAL } }) // 3. 处理识别结果 const result searchRes.data.result if (!result || !result.user_list || result.user_list.length 0) { return { success: false, msg: 未识别到人脸请正对镜头重拍 } } const topMatch result.user_list[0] const score topMatch.score const threshold 85 // 可根据班级规模调整 if (score threshold) { return { success: false, msg: 相似度过低(${Math.round(score)}分)请重新拍摄, score } } // 4. 检查是否已经签到防重复签到 const dupRes await db.collection(attendance) .where({ courseId, studentId: student.studentId }) .get() if (dupRes.data.length) { return { success: false, msg: 你已完成签到请勿重复操作 } } // 5. 写入签到记录 await db.collection(attendance).add({ data: { courseId, studentId: student.studentId, name: student.name, checkTime: Date.now(), score: Math.round(score) } }) return { success: true, msg: 签到成功, score: Math.round(score) } }这里有几个设计要点。我是先用openid去数据库查学号再把这批信息带给百度AI这样学生不需要每次都输入学号。签到前做了一个查重逻辑防止同一个人在同一门课里重复签到这是考勤系统的基本要求。识别结果里我不仅返回了成功信息还把识别分数带了出来学生可以看到自己的签到得分相当于给了个反馈用户心里也踏实。3.3 小程序端核心代码选课列表、拍照签到、结果反馈小程序前端用的是原生开发配合微信云开发。页面结构不复杂核心就三个首页选课列表、课程签到页、个人中心签到记录。选课列表页在onLoad时请求云函数拉取当前学生的选课数据按周次和节次排出近期的课程卡片。每张卡片上显示课程名、上课时间、教室位置和签到状态。签到状态用颜色区分已签到的显示灰色标签。签到页是整个交互体验的重头戏。我用了微信的wx.chooseMedia接口打开相机这个接口在真机上的唤起速度比旧的chooseImage更稳定。拍照后先压缩图片再转base64避免图片过大导致云函数请求超时。压缩我用的是官方推荐的方式先拿到临时文件路径再用wx.compressImage压缩质量到80%最后读取为base64字符串。前端签到调用的核心代码片段如下async takePhotoAndCheckIn(courseId) { const res await wx.chooseMedia({ count: 1, mediaType: [image], sourceType: [camera], captureDevice: front // 强制前置摄像头方便自拍 }) const tempFilePath res.tempFiles[0].tempFilePath // 压缩图片 const compressRes await new Promise((resolve, reject) { wx.compressImage({ src: tempFilePath, quality: 80, success: resolve, fail: reject }) }) // 读取为base64 const fileRes await new Promise((resolve, reject) { wx.getFileSystemManager().readFile({ filePath: compressRes.tempFilePath, encoding: base64, success: resolve, fail: reject }) }) wx.showLoading({ title: 正在进行人脸识别 }) try { const result await wx.cloud.callFunction({ name: faceCheckIn, data: { imageBase64: fileRes.data, courseId } }) wx.hideLoading() const r result.result if (r.success) { wx.showToast({ title: 签到成功 相似度${r.score}, icon: success }) } else { wx.showToast({ title: r.msg, icon: none }) } } catch (e) { wx.hideLoading() wx.showToast({ title: 识别服务异常请稍后重试, icon: none }) } }这个前端流程给用户的感觉就是“拍一下出结果”操作成本几乎为零。我自己在真机测试时从打开相机到看到签到结果最快的一次大约五秒钟。识别时间主要花在图片上传百度AI接口的过程中云函数转发带来的额外延迟很小整体响应速度能接受。3.4 选课逻辑怎么融入考勤流程一开始我只做了签到功能后来发现不行学生签到了但系统不知道他选的什么课签到记录和课程对应不上。于是我把选课流程加进了注册环节。学生在首次使用小程序时进入注册页面在线选择自己的课程。这个项目里的选课列表是模拟数据真实落地时可以对接学校教务系统。注册时绑定课程的好处是签到页面只会展示当前学生的选课列表每节课对应的签到入口清清楚楚不会出现“不知道去哪门课签到”的问题。老师在管理端能看到的是每个课程的出勤报表应到人数、实到人数、缺勤名单。这些数据全部由签到逻辑实时计算不需要人工干预。这也是这个项目比普通小程序考勤更有价值的地方它不仅做了身份验证还顺便把选课数据和考勤数据整合成了完整的数据链。4. 上线前必须解决的问题实测踩坑与排查记录4.1 活体检测误判照片翻拍拦住了吗活体检测是考勤项目最容易出问题的环节我花了大量时间测这一个点。拿到第一版的时候我用手机屏幕翻拍了照片去测识别结果里有不少能通过活体检测的情况。排查后发现问题不在百度AI的算法而在我的请求参数里liveness_control设的是NONE。百度AI的活体控制参数有三个档位默认是NONE需要手动调成NORMAL或HIGH。调成NORMAL之后用屏幕翻拍照片的测试基本都被拦截下来。我还测过用视频动态翻拍的方式NORMAL档位下也有部分通过的情况但把活体控制提到HIGH之后误判率明显下降。不过档位也不是越高越好。HIGH档位对拍摄环境要求更高光线暗一点就容易拒检导致正常签到的通过率下降。我的建议是课堂场景用NORMAL就够教室环境普遍光线良好NORMAL既保证速度又具备基本的安全防护。如果是对安全要求极高的场景再去考虑HIGH。4.2 光线和角度导致的识别失败这是一个真实使用中避不开的问题。有学生坐在靠窗的位置逆光拍了张照片识别分数只有六十多分签到直接失败。也有学生习惯侧脸自拍角度太大导致特征提取不全。这些情况都不是系统bug而是输入图片质量不达标。我的应对方案是双管齐下一是注册环节就做好质量把关注册用的照片必须正脸、光线充足、无遮挡二是签到失败时给清晰的提示不是简单说“签到失败”而是告诉用户“光线太暗请换个位置重试”或者“请正对镜头拍摄”。小程序端还加了一个简单的图片预览让学生拍完能看到自己的照片上传前自己先把关。另外我在百度AI请求里开了quality_control参数。这个参数会做图片质量预检如果图片本身模糊、光线异常或者遮挡严重会直接返回质量不合格不会进入特征比对流程。虽然会多一次检查但能拦截掉大量低质量图片整体识别成功率反而提高了。4.3 access_token过期和并发请求的问题token的管理是接入百度AI时最容易被忽略的细节。项目刚开始测试时只有我一个人调用token缓存逻辑没暴露问题。后来几个同学一起测云函数被调用了十几次突然报出无效token的错误。排查后发现是我缓存逻辑里的一个低级失误多个并发请求同时进来时它们都发现缓存中没有token于是同时去请求新token后拿到token的请求会把前一个覆盖导致一部分请求带着被覆盖前的旧token去调用百度接口自然就报鉴权失败。解决方案是加一个promise缓存锁在token还没返回前后续请求都等待同一个请求完成。想省事的做法是让token过期时间适当放宽并在请求失败时自动重试一次重新获取token这样即使发生并发也能自愈。4.4 隐私与合规人脸数据怎么存、怎么告知做校园场景的项目数据隐私是一道绕不过去的线。学生人脸照片属于敏感个人信息采集前必须明确告知。我在注册页加了一套完整的授权协议说明人脸照片仅用于课堂签到身份验证不会用于其他用途。百度AI方面传入的图片会经过加密传输识别完成后百度侧按规定会暂时保留数据用于安全审计但业务方可以在控制台配置数据保留策略这一点需要和学校的信息化部门确认清楚。还有一个容易被忽略的合规点注册人像照片的权限问题。这个项目可以让教务系统管理员批量导入学生照片也可以让学生自己用小程序拍照注册。从合规风险的角度我更推荐学生自己拍照授权的方式因为照片的来源是学生本人主动操作授权链路更清晰。批量导入的照片来源如果不明确后续容易出合规纠纷。4.5 常见问题速查表整理一下我在开发和测试过程中遇到的高频问题按症状、原因和解决办法列出来方便复现项目时快速定位症状可能原因解决办法返回“用户不存在”openid未在users集合中注册检查用户注册流程确认注册时正确写入学号与openid相似度分数普遍偏低注册照与签到照光线差异过大注册时强制使用正脸、充足光线照片签到提示对准镜头活体检测失败率极高liveness_control参数为NONE或环境光线暗调整参数为NORMAL避开背光环境部分图片上传超时base64体积过大上传前压缩图片质量控制在80%左右token报无效并发请求覆盖token缓存使用promise锁失败时强制刷新token重试识别结果显示库中人员匹配混乱group内注册人数过多且阈值偏低按学期拆分group适当提高阈值到85以上这些问题的共同规律是大部分都是接口参数配置和调用逻辑问题算法本身没有出过错。这也验证了选型百度AI是值得的我只需要把业务层和参数细节处理好就能获得稳定可靠的识别能力。5. 做完这个项目之后的几点体会这个项目做完我对“业务系统成熟AI能力”的组合方式有了更具体的理解。很多人会惯性觉得人脸识别是高科技非要自己训练模型才算厉害但实际上把成熟API用好把业务逻辑设计对才是项目落地成功的关键。百度AI在这里扮演的角色更像一个“识别人脸能力”的基础服务真正决定体验好坏的是前端的交互、阈值的调校、数据的联动这些细节。如果后续还想扩展我会优先考虑两个方向。第一个是把老师端管理界面做成管理后台小程序或网页增加导出Excel报表、批量导入课程课表、考勤异常提醒这些能力让整个考勤系统更完整。第二个是接入学生旷课次数预警当某名学生缺勤次数达到一定数量时自动向辅导员发送提醒。这些都能在现有架构上无缝扩展因为底层的选课关系、签到记录、人脸库已经全部打通了。最后再分享一个体验优化小技巧。签到页面在识别成功后可以展示一个打勾动画和“准时到达”的文案让学生有一个明确的完成感。这个小细节看着不起眼但实际使用率会明显提升学生更愿意主动配合系统而不是觉得被管着。毕竟考勤工具最终是给人用的体验顺了数据自然就准了。