基于人脸识别的签到考勤APP设计与实现全解析

最近这段时间来问我毕设选题意见的学弟学妹不少，"基于人脸识别的签到考勤APP的设计与实现"这个题目出现的频率特别高。它确实是个好题目：贴近日常场景、技术栈能有深度、答辩时有故事可讲，而且不管是JAVA还是Python路线都能接得住。但别急着把它当成普通管理系统来做——真把这个项目从头到尾做完的人基本都有同感：界面和CRUD只是皮，身份认证才是骨，最花时间的部分其实是"如何让人脸识别在真实环境里稳定生效"。

这篇文章我打算完完整整地把这个题目的技术链条拆开讲一遍，从需求分析、技术选型，到人脸识别的核心链路、数据库和接口设计，再到真实环境中踩过的坑和论文写法。适合准备拿这个题做毕设的在校生，也适合想在公司内部快速搭一套考勤系统、但又不想直接买现成硬件的开发者。内容会比较长，但每一步都是我实际做过的路子，可以直接跟着往下走。

1. 这题不简单：人脸识别签到APP的需求边界到底在哪

其实看到题目的时候，大部分人的第一反应是"这不就是个带人脸识别的打卡系统吗"，然后就开始写用户表、写考勤表。我不建议这么干，因为需求没理清楚就动工，后面大概率会反复改表结构。先花两三天把需求边界划清楚，比多敲一万行业务代码都值。

1.1 表面是考勤工具，本质是身份认证系统

签到考勤的痛点，用过传统指纹机的人都懂：指纹磨破皮了识别不出来、天冷干燥也识别不出来，高峰期一群人在机器前面排队，一边搓手指一边看表。后来有的公司换成IC卡，又冒出代打卡的问题——一个人拿五张卡，全勤纪录全靠人情操作。课堂点名更不用说，大学教室里一百多号人，老师一节课喊完名字半小时就过去了。

人脸识别天然适合这个场景，核心原因是它的非接触性和不可替代性。用户只需要站在手机摄像头前，不需要接触任何设备，识别过程又快又自然，而且配合活体检测后，照片和视频基本挡不住它。但这也决定了这个项目的重心不在"考勤记录"这些常规功能上，而在身份认证的可靠性。

所以做需求分析时，我建议把整个系统当成一个身份认证平台来规划，考勤只是它的第一个应用场景。用户注册、人脸录入、特征管理、身份校验、活体检测这些底子打好了，后面要扩展签到之外的场景，比如门禁、课堂专注度分析、会议签到，都是顺理成章的事。这样想，系统设计的格局就不一样了。

1.2 把需求写成真正的需求文档：别漏掉非功能要求

很多毕设的需求分析章节写得很空,就是"学生可以注册登录、教师可以管理课程、系统可以记录考勤",这哪叫需求分析,这叫功能介绍。真正动手前,要把角色、功能、约束条件逐条列清楚。

最核心的两个角色是这样的:

• 普通用户（学生/员工）：注册登录、人脸录入（支持重新录入）、在线签到/签退、查看个人考勤记录、提交请假申请。
• 管理员（教师/HR）：用户管理、课程/部门管理、考勤规则配置（签到时间窗口、迟到判定标准）、考勤统计与导出、异常记录人工处理（补卡、申诉）。

功能需求其实好列，容易漏的是非功能需求。我自己总结下来有这几条是必须提前想清楚的：

1. 识别速度：单次签到的端到端耗时最好控制在1秒内，超过2秒用户体感就很差了。
2. 识别准确率：正确接受率至少要95%以上，误识别率要低到可以接受，否则会出现"我明明站在镜头前却打不上卡"的尴尬。
3. 防作弊能力：必须能识别出照片、视频这类静态/动态攻击，这就是活体检测存在的意义。
4. 环境适应性：教室和办公室的光线条件差异巨大，逆光、暗光、侧光都要能处理。
5. 并发处理：上课前5分钟往往是签到高峰期，上百人同时打开APP，后端能不能扛住。

这些需求里任何一条没考虑到，到测试阶段都会被放大成灾难。我记得第一次现场测试时，教室靠窗那排逆光严重，识别率一度掉到六成以下，后面专门做了图像预处理才压住这个问题。需求阶段多操一份心，后面就少熬一次夜。

2. 技术选型的逻辑：Java打底、Python做人脸、算法服务独立部署

毕设技术选型有一条隐性规则：技术栈要能支撑你写出论文，而不是写完代码就没事了。用人脸识别签到这个题目，最稳妥的组合是Java Spring Boot做业务后端，Python做算法服务，中间通过网络接口通信。为什么这么选，理由得说明白。

2.1 双语言架构的真实理由

市面上人脸识别相关的成熟库，绝大多数是Python生态的。OpenCV、Dlib、Face_recognition、InsightFace，官方文档和社区案例都以Python为主，用起来最省事。而业务系统这边，Spring Boot依然是国内中小型项目的绝对主流，网上关于用户认证、权限管理、定时任务、导出报表的资料一搜一大把，答辩的时候也更容易讲清楚。

有人会问，我能不能用Python全家桶把后端也写了？可以，但题目是"APP的设计与实现"，APP的后端接口用Spring Boot实现，在论文的"相关技术介绍"和"系统实现"两章里都能写出东西来。相反，如果纯用Python写后端，业务模块和算法模块混在一起，代码结构容易乱，答辩时评委问"你的工程结构是怎么分层的"会有点难答。

那能不能纯Java做人脸识别？能做，Java有OpenCV的绑定，也能调用深度学习框架导出的模型，但问题在于：(1) 模型转换和预训练模型获取的路径比Python曲折得多；(2) 你需要处理大量图像数组操作，代码写起来又长又绕；(3) 社区方案少，遇到问题很难搜到现成答案。所以我的建议是：Java负责业务，Python负责脸，中间用HTTP接口通信，各干各擅长的事。

2.2 人脸识别方案选型：别一上来就调云API

人脸识别这块，选型直接决定你后面开发体验和论文深度。我按从简单到复杂排个序：

如果是毕设，我建议优先在Face_recognition和InsightFace之间选。前者封装的API非常友好，几行代码就能完成人脸编码和比对，适合时间紧凑、把重心放在业务系统的同学；后者是深度学习方案，精度高，但环境配置和模型推理要花更多时间，适合想把算法部分写出深度、甚至对比多种模型的同学。

云端API我反而不推荐作为主体方案，因为论文里"系统实现"一章会很难写，你总不能写"我调用了百度的一个接口，然后它返回了结果"。但可以作为对比方案写进论文，用来佐证你的方案在离线环境下的优势。

2.3 算法服务化：Flask包一层HTTP接口

确定了算法用Python之后，最直观的问题就是Java怎么调用Python。有的同学写Jython、有的用ProcessBuilder去启动Python脚本，这两种我都试过，维护性都很差。正确做法是把人脸识别算法封装成一个独立的算法微服务，用Flask或FastAPI起一个HTTP接口，Java后端通过HTTP调用。

这样做有三个好处：一是Java和Python进程完全解耦，Python服务挂了不影响主业务处理；二是算法可以单独部署在带GPU的机器上，业务服务器不受影响；三是以后想换算法模型，只要保证接口输入输出不变，内部随便改。

我在项目里定义了这样两个核心接口：

# app.py - Flask算法服务 from flask import Flask, request, jsonify import face_recognition import numpy as np app = Flask(__name__) @app.route("/face/register", methods=["POST"]) def face_register(): # 接收图片，提取特征向量，返回给调用方存储 file = request.files["image"] image = face_recognition.load_image_file(file) encodings = face_recognition.face_encodings(image) if len(encodings) == 0: return jsonify({"code": 400, "msg": "未检测到人脸"}) return jsonify({"code": 200, "feature": encodings[0].tolist()}) @app.route("/face/verify", methods=["POST"]) def face_verify(): # 接收当前拍摄的人脸特征，与目标特征比对 data = request.get_json() target = np.array(data["target_feature"]) candidates = np.array(data["candidate_features"]) # 库里候选特征列表 distances = np.linalg.norm(candidates - target, axis=1) min_idx = int(np.argmin(distances)) min_dist = float(distances[min_idx]) threshold = data.get("threshold", 0.55) if min_dist < threshold: return jsonify({"code": 200, "matched": True, "distance": min_dist}) return jsonify({"code": 200, "matched": False, "distance": min_dist}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5001)

Java这边用RestTemplate或者OpenFeign调用就行，业务层不需要关心人脸怎么算出来的，拿结果直接用。这个架构跑起来之后，整个系统就清晰了：Android端拍照或上传图片 -> Java业务服务处理签到流程 -> 需要比对时调Python算法服务 -> 结果写回数据库。

3. 核心链路拆解：从摄像头一帧图像到签到成功

现在到了整个项目最核心的部分——人脸识别链路。网上很多人把这部分当成一个黑盒，封装好了直接用，但论文里和答辩时都需要你讲清楚每一步在做什么。把链路拆开看，其实就是一个固定的四步流程：人脸检测、人脸对齐、特征提取、特征比对。

3.1 四步走：检测、对齐、提取、比对

这四步我分别解释一下，同时会带上代码思路。

人脸检测是第一步，解决的问题是"画面里人脸在哪里"。传统做法是Haar级联，速度快但准确率一般，大角度和暗光下容易漏检。深度学习方案里有MTCNN、RetinaFace这些，效果明显更好。Face_recognition库底层用的就是HOG特征配合线性分类器，在正面人脸场景下表现已经够用。

人脸对齐解决的是"人脸姿态不统一"的问题。同样是正脸，有人稍微歪头，有人仰头，特征提取前要把人脸校正到标准位置。方法是先定位眼睛、鼻子、嘴角这些关键点，然后做仿射变换，把人脸统一到一个标准尺寸和角度。这一步直接决定特征提取的稳定性。

特征提取是把对齐后的人脸图像转换成一个固定维度的向量。传统方法提色彩、纹理特征就完事了，深度学习模型则是通过训练好的卷积神经网络把人脸映射到一个向量空间，同一个人的不同照片在这个空间里距离很近，不同人的距离较远。Face_recognition库默认生成128维特征向量，InsightFace的ArcFace模型通常生成512维向量。

特征比对是在特征空间里算距离。常用的是欧氏距离或余弦相似度，距离小于阈值就判定为同一个人。整个流程核心代码是这样的：

def recognize(frame, known_encodings, known_ids, tolerance=0.55): face_locations = face_recognition.face_locations(frame) face_encodings = face_recognition.face_encodings(frame, face_locations) for encoding in face_encodings: distances = face_recognition.face_distance(known_encodings, encoding) min_idx = int(np.argmin(distances)) if distances[min_idx] <= tolerance: return known_ids[min_idx], float(distances[min_idx]) return None, None

注意这个tolerance参数不是随便定的，后面我会专门讲怎么调。

3.2 人脸录入阶段的细节：一张脸照片远远不够

签到能不能成功，一半的功劳在注册阶段。我见过不少项目注册时让用户拍一张正脸就完事了，结果首次签到就失败——因为用户是侧着身子站的，手机举的角度也不一样，光线更是完全不同。

正确做法是多角度、多帧采集。录入时让用户按照屏幕提示完成几个动作：正对镜头、轻微左转、轻微右转、抬头、低头，每个姿势采集一到两帧，全部提特征后存成多条特征记录。签到比对时，拿当前画面特征跟这个用户的全部特征挨个比，只要有一条记录匹配成功就算通过。

另外录入照片的质量检测也值得做进去。两件事：一是模糊检测，可以用Laplacian算子的方差来判断，方差低于某个阈值就提示重新拍；二是人脸完整度，确保脸没有超出画面边界。这两行代码在论文里虽然不起眼，但能体现你对"真实环境可靠性"的思考。

3.3 识别阈值怎么定：不是拍脑袋决定的

阈值定得太严，用户稍微换个角度就识别失败；阈值定得太松，相似脸会误判成同一个人。好的做法是拿一批测试数据画出阈值和误判率的关系，再选一个平衡点。

我当时准备了大概一百个人的照片集，另外还有同一人的不同角度、不同光线下的照片，用这批数据做了个简单测试表：

建议把阈值做成配置项，放到配置中心或数据库里，线上发现问题可以动态调整，而不是每次改代码重新部署。这个设计细节答辩时说出来很加分。

3.4 活体检测：挡住照片和视频攻击

光有特征比对，挡不住别人拿一张你正面照片去签到。于是就有了活体检测。常见的方案有几类：

• 动作指令活体：后端随机下发"眨眨眼""张张嘴""向左摇头"指令，用户照做，通过关键点位置变化判断是否真人。优点是普通手机摄像头就能实现，成本低，缺点是用户配合成本略高。
• 红外活体：利用红外摄像头下皮肤和非皮肤材质的反光差异来区分真人脸和照片。精度高，但需要特定硬件。
• 深度学习活体：用模型直接判断当前画面是真人还是照片/屏幕，对硬件要求低，但需要足够训练数据。

毕设场景下，我最推荐动作指令活体，因为它逻辑不复杂、论文里容易写清楚，而且视角效果好——用户看着是在和APP互动，不是傻傻站那扫脸。具体实现就是在录入和签到时加一个"动作验证"步骤：APP弹出指令时开始录像，等用户完成动作后抽取关键帧送算法服务，算法检测到眨眼或摇头动作就返回通过。

4. 业务落地：数据库表设计、接口约定与防重复签到

算法链路通了大半，但别忘了这毕竟是个考勤APP，业务功能得撑起来。数据库设计和接口设计的好坏，直接影响开发的顺畅程度和论文的系统设计章节。

4.1 三张核心表：用户、人脸特征、考勤记录

我项目里最主要的表有用户表、人脸特征表、考勤记录表，另外还有课程/部门、请假、考勤规则等相关表，篇幅关系我先把三张核心表的结构写出来。

用户表负责基础账号信息和角色区分：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, real_name VARCHAR(50) NOT NULL, role TINYINT DEFAULT 0 COMMENT '0-普通用户 1-管理员', dept_id BIGINT COMMENT '部门或班级ID', status TINYINT DEFAULT 1 COMMENT '1-正常 0-禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) );

人脸特征表单独抽出来，而不是把特征向量直接塞用户表，原因是一个人可以有多条特征记录，而且特征数据本身是一个长度很大的数组，放用户表会拖慢常规查询：

CREATE TABLE face_feature ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, feature TEXT NOT NULL COMMENT '128维或512维特征向量，JSON数组', feature_type TINYINT DEFAULT 0 COMMENT '0-普通 1-活体采集', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_id (user_id) );

考勤记录表是业务核心，设计时要注意唯一约束，否则代码层面漏判一条数据就会产生重复签到：

CREATE TABLE attendance_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, course_id BIGINT, check_date DATE NOT NULL, check_in_time DATETIME, check_out_time DATETIME, status TINYINT DEFAULT 1 COMMENT '1-正常 2-迟到 3-早退 4-缺勤 5-请假', UNIQUE KEY uk_user_date (user_id, check_date) );

UK_KEY uk_user_date这个约束很重要，它保证了同一天同一用户只能有一条考勤记录，这是防重复签到的最后一道保险。

4.2 核心接口怎么约：Token鉴权与业务请求流

APP和后端之间我用RESTful接口通信，核心接口大概有这些。注意看，人脸识别服务只负责"生成特征"和"验证特征"，不参与考勤业务流程，这样职责边界很清楚。

签到接口的完整调用链是：APP拍照上传 -> Java接口收到图片 -> 转给Python算法服务提特征 -> 算法服务返回特征向量 -> Java再调比对接口（或者直接传一个候选用户ID只跟这个人比）-> 比对通过后写考勤记录。为了减少算法服务调用次数，我的做法是先按当前时间确定要签到的课程，再只把该课程下所有已录脸用户的特征作为候选集，这样比对范围通常只有几十到几百人，速度非常快。

接口请求时带上JWT Token，登录后拿到Token，刷脸签到前先验Token，后面所有接口都走同一套鉴权逻辑。

4.3 防止同一个人短时间重复打卡

这是一个在普通管理系统里不会遇到的问题，但在考勤系统里必须处理。场景是：用户在8:59签了一次到，发现签错了（或者又退出去重新进了一次），9:00又签一次，结果库里出现两条记录。而且上课高峰期并发大，代码里先查再插会有竞态问题。

我的处理方案是双保险：

1. 数据库层：靠uk_user_date唯一索引兜底，重复插入会直接报错，应用层捕获后返回友好提示。
2. 应用层：签到接口进入事务后先检查当天是否已有有效记录，有就直接返回"今日已签到"，没有才执行插入。

有同学会问要不要用Redis做分布式锁，其实考勤系统的并发量远没到需要分布式锁的程度，数据库唯一索引已经能解决99%的问题，加上代码逻辑判断就够了。分布式锁放在论文的"性能优化"部分提一嘴可以，但别为了秀技术而滥用。

5. 真实环境中踩过的坑：光线、口罩、相似脸与识别速度

这个项目最难的部分，不在功能开发，而在真实环境下的调试。算法模型在测试集上表现不错，一放到教室里就各种翻车。下面这几个坑都是我在实测中真实遇到的，按影响程度排序。

5.1 逆光和暗光：识别率从95%掉到60%的教训

第一次在教室实测，靠窗那排的学生反复签到失败，后来发现是逆光问题——窗外阳光太强，摄像头拍出来的人脸面部区域全是暗的，特征提取出来跟注册时差很多。后来单独测暗光环境，走廊灯光昏暗的地方，检测不到人脸的情况也频繁出现。

解决办法做了几个：

• 图像预处理：把图片转成灰度图后做直方图均衡化，增强暗部细节。这是OpenCV几行代码的事，但对识别率的提升立竿见影。
• 多帧采样取最优：连续取5帧画面，分别做人脸检测，选择人脸区域最清晰的一帧去提取特征。
• 前端提示：APP端检测到环境亮度过低时，主动提示"当前光线不足，请移步明亮处"，避免用户反复试错。

还有一个细节是注册照片和签到照片的光线差异性。注册时在室内灯光下拍，走廊灯光稍微不一样就容易失败。所以录入阶段我刻意在上传前同样做一遍预处理，让注册和签到的图片处在同一处理条件下，特征一致性会好很多。

5.2 口罩：绕不开的遮挡问题

这几年做考勤系统，口罩是绕不开的话题。口罩遮住鼻子和嘴巴之后，上半张脸的特征信息大量缺失，特征向量和注册时的差距会变大，识别率明显下降。尤其是冬天，用户戴着口罩来签到，总不能让人家在门口摘口罩吧。

我的处理思路是分模式的。系统增加一个"口罩模式"开关，用户选择开启后，算法比对的重点放到眼睛和额头区域。具体做法是先定位人脸关键点，把鼻子以下的区域做掩膜处理后，再提取特征。代码上看是用关键点坐标把下半张脸区域清零，然后喂给特征提取模型。这个方案不是100%准确，但相比直接拿全脸特征去比，在戴口罩场景下的正确接受率能提升不少。

如果业务上不允许戴口罩签到（比如某些需要核验完整面孔的场景），那么合理的设计是引导用户在临时摘口罩的瞬间完成活体检测，签到一次也就几秒钟，用户是能接受的。关键是系统要给出清晰的引导文案和足够的准备时间，别让人在摄像头前手忙脚乱。

5.3 双胞胎和相似脸：阈值要设得恰到好处

一开始我把阈值设得比较松，结果测试时一对双胞胎互相签到了对方的考勤。研究了下，两个人的特征向量距离确实非常接近，比一般人的距离小得多。当时第一反应是把阈值调严，但调严之后识别的失败率也跟着涨上去了，经常有同学要在镜头前调整半天角度才打得上卡。

最后的解决思路是这样的：阈值保持在一个合理的平衡点上，但对距离低于"极相似"区间的用户增加二次验证。就是说，如果某次比对的结果和目标用户的距离在0.30以内，正常通过；如果在0.30到0.55这个"可疑区间"，而且库里有其他用户特征距离也很近，就触发一次活体动作验证，确认是真人后再通过。这样既不牺牲普通用户的使用体验，又增加了相似脸的防护强度。

5.4 性能优化：从秒级到毫秒级的三个关键改动

最开始跑通全流程时，一次签到要1.5到2秒，响应慢得让人着急。后来做了三处改动，基本稳定在300毫秒左右。

第一处是底库特征常驻内存。一开始每次比对都从数据库读出候选用户的所有特征，再转成numpy数组，光IO和序列化就要花掉不少时间。后来在算法服务启动时就把底库特征加载进内存，比对时直接查内存，耗时直接降了一截。

第二处是减少比对范围。前面提过，根据当前时间和课程信息，只取该课程的学生特征作为候选集，而不是拿着全量几千人的底库算距离。这次优化把比对的计算量从十万次降到几百次。

第三处是接入FAISS做向量检索。如果底库真的到了几万人级别，线性扫描就有点吃力了，这时可以用FAISS建立索引做近似最近邻搜索，毫秒级返回topK结果。我在论文里把这部分作为性能对比数据写了进去，答辩时评委很感兴趣。

另外Android端也有一点技巧：摄像头用CameraX而不是Camera2，前者生命周期管理更简单，内存分配更友好；每次签到拍完照片及时回收Bitmap，避免App内存持续上涨导致卡顿甚至OOM。

6. 从代码到毕业设计论文：毕设文档的写法参考

代码写完只是完成了项目的一半，对一个毕设题目来说，论文才是最终呈现形式。很多同学代码能力很强，一写文档就头疼，这里我给一个可以直接参考的骨架。

6.1 目录怎么设计最稳

以"基于人脸识别的签到考勤APP的设计与实现"这个题目，比较稳妥的目录结构是这样的：

• 第一章 绪论：研究背景与意义、国内外研究现状、论文结构安排
• 第二章 相关技术介绍：Java/Spring Boot、Python、OpenCV、人脸识别相关算法
• 第三章 系统分析：可行性分析、需求分析、用例图+用例描述
• 第四章 系统设计：总体架构设计、功能模块设计、数据库设计、接口设计
• 第五章 系统实现：环境搭建、核心模块实现（重点写人脸识别模块和签到模块）、界面展示
• 第六章 系统测试：测试环境、功能测试用例、性能测试结果与分析
• 第七章 总结与展望：项目完成情况总结、不足之处与后续改进方向

这套结构的优点是逻辑顺：先讲为什么做，再讲用什么做，再讲怎么做，然后讲做成什么样，最后讲还能怎么做更好。评委按目录就能把你的工作看明白。

6.2 摘要和技术描述这样写不踩雷

摘要最容易犯的毛病是写得像功能列表。给你一个参考框架：

针对传统考勤方式存在的代打卡、识别率不稳定、高峰期排队等问题，设计并实现了一款基于人脸识别的签到考勤APP。系统采用Spring Boot搭建后端服务，Android端负责用户交互与人脸图像采集，Python算法服务完成人脸检测、特征提取与身份比对。文章详细阐述了人脸识别技术在考勤场景中的应用流程，包括人脸录入、活体检测、特征匹配以及异常考勤处理等核心环节。测试结果表明，系统在常规室内环境下能够高效、准确地完成签到任务，具备较好的实际应用价值。

注意这里有一个容易被破防的点：研究方法和技术原理必须写实。把"人脸检测-人脸对齐-特征提取-特征比对"四步流程写成你能讲明白的原理，而不是一句"通过深度学习模型识别人脸"就带过。评委一旦追问"特征向量怎么生成的""距离阈值怎么确定的"，你得能回答上来。

6.3 测试用例与性能数据的组织方式

测试章节有没有说服力，直接影响论文质量。功能测试要覆盖核心流程，格式清晰即可。

性能测试建议给出真实测试数据。比如不同人脸底库规模下的识别耗时对比，或者不同阈值下的准确率对比。这些数据不需要多华丽，但必须看起来是"做过实验的人"才能写出来的。我当时就把内存底库和数据库直查对比了一下，再附上一张耗时折线图，这部分工作量不大，却是论文里最扎实的实证支撑。

最后再分享一个个人的体会：这类身份识别项目，做完之后最能沉淀下来的能力，不是调包调参，而是工程调试经验——你知道光线不对该怎么办，知道相似脸怎么兜底，知道性能瓶颈通常出现在哪一层。如果后续想在这个题目上继续加分，可以扩展考勤大数据分析模块，比如缺勤趋势可视化、课堂专注度分析、异常考勤预警，或者把Android端改成微信小程序，让校园场景下不用额外装APP。这些扩展方向跟原题贴合得很自然，答辩时也有得聊。