智慧社区综合服务小程序(人脸识别、AI问答、Echarts图形化分析)

智慧社区综合服务小程序：人脸门禁为什么要先绑房屋，AI 问答又为什么先把提问落库

关键词：Spring Boot · Vue 3 · uni-app · 人脸识别（百度 AI）· DeepSeek 智能问答 · ECharts 图形化分析 · 房屋绑定审批 · 物业缴费与余额 · 工单流转

一、写在前面

住过老小区的人应该都有体会：想给家里装个门禁卡，得跑一趟物业；物业群里发通知说"今晚停水"，消息被刷屏顶到看不见；报修一台坏了的电梯，打电话过去说不清是哪栋哪单元，师傅上门还要再问一遍。物业那边也有物业的难处------住户信息散在几个 Excel 里，谁家有几辆车、住几口人，只有管这片的老员工记得住。

这些事都不算大，但堆在一起就很真实：信息是有的，只是没有一个地方同时装得下住户、房屋、车辆、访客、缴费这些东西，更没法让它们互相关联。做毕设时我选了这个场景，目标不是把纸表搬进小程序，而是让"这个人是这栋这户的住户"这件事成为系统里可以被校验的前提。

所以整个系统是围绕房屋这个中心来组织的：住户绑房屋、人脸绑房屋、车辆绑房屋、缴费按房屋生成、访客访问的是某套房屋。下面把架构、两类角色和十块核心实现拆开讲，重点说三件事：人脸照片为什么必须先和房屋绑上才能用 、AI 问答为什么先把提问落库再调模型 、批量生成缴费记录怎么避免重复生成。这几块是答辩时最容易被追问的地方。

二、系统概述与技术选型

系统采用前后端分离的 B/S 架构，由微信小程序端和物业管理后台组成，以用户、房屋、住户与家庭成员、人脸信息、车辆与车辆进出记录、访客登记、缴费记录与余额变动、报修工单、社区活动与报名、社区公告、消息通知、意见反馈、AI 会话与消息、AI 知识库为主要业务数据。

层级	主要技术与职责
小程序端	uni-app、Vue 3、ColorUI；提供首页入口、门禁识别与录入、报修投诉、社区活动、物业缴费、访客预约、停车记录、AI 智能助手与个人中心
管理后台	Vue 3、Element Plus、Vite、Vue Router、Pinia、Axios、ECharts；提供房屋、住户、人脸、访客、车辆、缴费、活动、公告、反馈与统计看板的维护界面
服务端	Java 17、Spring Boot、MyBatis-Plus、MySQL；提供 REST 接口、分页查询、业务校验、定时任务与文件处理能力，并统一处理登录态与角色权限
智能与外部服务	百度人脸识别 API（人脸检测与比对）、DeepSeek 大模型 API（多轮对话）；人脸比对结果与 AI 会话消息均落库，便于回溯
数据库	MySQL 5.7/8.0，Navicat 管理，共 22 张业务表

关于技术选型有两点说明：小程序端用 uni-app 是因为它一套代码可以同时出微信小程序和 H5，答辩时演示方便、后期扩展也方便；管理后台用 Vue 3 + Element Plus，是因为后台页面以表格、表单、图表为主，组件库直接覆盖大部分场景，能把精力放在业务逻辑上。

三、两类角色，两块工作区

系统定义用户（住户）和物业管理员两类账号：

用户：账号密码或微信授权登录，维护个人信息与家庭成员，申请房屋绑定并在多套房屋间切换，录入人脸与车辆信息，预约访客，查看与缴纳物业费、账户充值，提交报修投诉并评价，浏览与报名社区活动，查看公告与消息通知，通过 AI 智能助手在线咨询
物业管理员：管理用户、房屋与住户信息，审批房屋绑定、人脸信息、车辆申请与访客登记，批量生成缴费记录与查看缴费统计，分派维修工单，发布社区活动与公告，回复意见反馈，维护 AI 知识库，查看报修、活动、车辆、缴费四个维度的统计看板

登录支持账号密码和微信小程序 OpenId 两种方式，服务端校验通过后签发令牌，令牌中写入用户 ID 与角色。前端通过路由守卫区分两端入口，但数据范围的控制放在服务端：接口需要的当前用户直接取自令牌解析结果，而不是由前端传参指定，前端藏菜单只是体验优化，不是权限控制。

四、核心功能与实现

4.1 房屋是中心：住户、人脸、车辆、缴费为什么都挂在房屋上

系统的数据模型以房屋为核心节点：一个用户可以绑定多套房屋（自住、父母家、出租房），一套房屋下可以有多个住户（家庭成员），人脸信息、车辆信息、缴费记录都关联到具体的房屋，访客预约访问的也是某套房屋。

这么做有两个直接好处。第一，权限判断有了统一口径 ：小程序里切换"激活房屋"之后，门禁通行、车辆进出、待缴明细都只针对当前这套房屋，"我能不能开这个门"不用每次重新推理，看人脸记录挂在哪套房屋下就够了。第二，缴费和统计有了天然的归属：物业费按房屋生成、按房屋统计，住户换了但房子没变，历史缴费记录不会跟着人走。

房屋绑定采取申请---审批的方式：用户在小程序提交房屋绑定申请，物业管理员审核通过后才完成认证。这一步不能省------房屋绑定的背后是门禁通行、车辆放行、缴费记账三项实际权利，如果任人自填就相当于把这些权利交出去了。

4.2 人脸门禁：照片为什么必须先和房屋绑上

人脸门禁是本系统集成度最高的一块，链路分五步：

用户在小程序上传人脸照片，填写姓名、手机号等信息，选择要关联的房屋提交
物业管理员在后台审核这条人脸记录，通过后启用，不通过则保持禁用
用户在小程序端拍照通行，前端把照片传给服务端，服务端调用百度人脸识别 API与库里已启用的照片做比对
比对返回相似度分数，服务端按预设阈值判定是否放行
无论放行与否，都写入一条通行记录（时间、关联房屋、结果）

两个设计取舍值得展开说。

第一，人脸不是"用户的一个属性"，而是"住户在某套房屋下的一张通行凭证"。 如果把人脸照片直接存到用户表，一个用户只能有一张脸、只能进一套房子，多房屋场景立刻失效；更麻烦的是禁用就变成了"把用户的脸删掉"，而人脸记录一旦删除，之前基于它产生的通行记录就失去了关联对象，历史查不清。按记录授权、按状态禁用，撤销的是通行权，留下的是记录。

第二，库里存相似度分数，而不是只存"是否通行"。 如果只落一个布尔值，将来阈值要调高调低，历史记录就无法按新标准重新判断，只能全部作废重采。存分数意味着历史记录是可复盘的------运营发现某段时间误放行偏多，把阈值往上调，重新筛一遍历史分数就能看到影响面有多大。

4.3 AI 智能助手：知识库加进来，提问先落库

AI 智能助手面向住户，回答物业缴费、报修流程、门禁办理这类问题，支持多轮对话 和多会话管理：用户可以同时留着几个会话（一个问缴费、一个问报修），会话列表里能看到标题和时间，点进去继续聊。

调用链路上有三个细节：

第一，先把用户提问落库，再调用模型。 反过来做的话，模型请求失败或超时，用户界面上出现了一条自己发出的消息，历史会话里却查不到------这类"看得到、查不到"的消息最难排查。

第二，回答在流式输出结束后整体落库，不存流式碎片。 边生成边存会留下半截话，用户下次翻历史看到一句断掉的回答，会以为是系统坏了。

第三，管理员维护的 AI 知识库会作为参考内容喂给模型。 后台可以按分类录入知识条目并设置关键词，用户提问命中相关内容时，这部分内容一并作为上下文传给模型，让回答落在本小区的实际规则上，而不是泛泛而谈。知识库条目本身是独立数据，物业改了收费标准，改一条知识条目就行，不需要重新训练或改代码。

4.4 物业缴费：批量生成怎么避免重复，余额和流水的关系

缴费流程按"生成---缴纳---记录"三段设计：

物业管理员按周期为房屋批量生成缴费记录，每条记录保存房屋、费用类型、金额、所属周期、缴费状态与截止日期
用户在待缴明细里看到本户应缴费用，选择缴费方式完成缴费，状态更新为已缴
用户可以先给账户充值，系统记录充值金额与余额变动明细（充值、缴费扣款、余额快照）

批量生成有一个必须处理的边界：同一套房屋、同一个费用周期只能有一条缴费记录。生成逻辑先按"房屋 + 周期"查重再插入，否则管理员手滑点两次"生成本季度费用"，住户那边就会出现两条一模一样的待缴单，交了一条还剩一条，最后只能人工删。

余额与流水的处理原则是：余额字段和余额变动明细在一次事务里同时更新，明细是账、余额是当前状态。 只更新余额不写明细，一旦对不上就无从查起；只写明细不更新余额，每次展示都要把全部流水加起来，随着时间推移越来越慢。充值、扣款、退回都各自产生一条明细，住户在个人中心能看到完整的余额变动记录。

4.5 报修投诉：工单四态流转与评价的关系

住户在小程序提交报修申请，选择报修类型、填写问题描述、上传现场照片。物业管理员看到后分派给具体的维修人员 ，工单按 待分派 → 处理中 → 已完成 → 已评价 流转，住户在完成后对服务做 1--5 分评价。

设计上有两点：分派是工单流转的起点 ，工单在待分派状态下没有责任人，任何"处理中"的操作都应该是分派之后才允许的，否则会出现一条没人负责却已经在处理的工单；只有已完成的工单才能被评价，评价之后状态不再回退，评分一旦落库就不能反复修改，否则某个服务的评价分数会随时间被刷成任意值，统计出来没有意义。

工单还保留了处理过程和照片，住户在详情里能看到"谁在处理、处理到哪一步"，减少"提交了没人管"的反复询问。管理员可以按状态、类型、时间查看报修统计。

4.6 访客管理：通行码和三态流转

住户在小程序预约访客，填写访客姓名、手机号、来访时间、来访事由等信息，系统自动生成通行码 ；物业管理员审核访客申请并留存登记记录，访客状态按 待审核 → 已通过 → 已注销 流转。

通行码由服务端在预约创建时生成，和这条访客记录绑定。三态里"已注销"是有实际含义的一步：访客离开或预约时间过了，记录状态流转到已注销，此时通行码失效，不能再用同一条记录反复进出。这样既保留了来访历史，又不会让一张旧的通行码长期有效。

4.7 车辆管理：登记、审批与陌生车辆识别

住户登记车辆信息并与所属房屋关联，物业管理员审批车辆申请。车辆进出时系统自动记录进出时间，库中不存在的车牌会被标识为陌生车辆，方便物业核对。

把车辆和房屋绑定，解决的是"这辆车是不是本小区住户的"这个问题。没有这层关联，系统只能判断"车牌在不在库里"，判断不出"这辆车归哪户"；有了关联，一辆车换了住户、或者一个住户登记多辆车，都能在数据上表达清楚，车辆统计也可以按房屋、按时间维度来算。

4.8 社区活动：状态交给系统算，而不是靠人工改

物业管理员发布社区活动时设置报名开始与结束时间、活动开始与结束时间、人数上限等参数，用户可以浏览活动并在线报名。活动状态由定时任务按时间自动更新（报名中、进行中、已结束等），管理员也支持编辑和取消活动。

这样做的原因是：状态如果靠人工手动改，活动一多必然有漏改的，住户会看到"已结束的活动还能报名"或者"正在进行的活动显示已结束"。时间参数一旦配置好，状态就是算出来的，不需要谁记得去改。管理员取消活动时，已报名记录一并处理，用户端能看到活动已取消的提示。管理员可以查看报名记录和活动统计分析。

4.9 社区公告与消息通知

公告支持设置标题、内容、类型、生效时间和置顶。生效时间决定了公告什么时候开始对住户可见，置顶则保证重要通知（比如停水、电梯维保）不会被日常信息顶下去。住户在小程序公告列表里按类型查看，进详情页看完整内容。

系统内的关键节点会产生消息通知（缴费提醒、工单状态变化、访客审核结果等），住户在小程序的提醒通知页集中查看，未读状态单独维护，避免让住户在一堆页面里翻自己错过了什么。

4.10 意见反馈与四维统计看板

住户可以在小程序提交意见反馈和建议，管理员在后台查看并回复，反馈状态分为待处理和已回复两类，回复内容落库留存。

管理端配有报修、活动、车辆、缴费四个维度的统计看板，用 ECharts 呈现。统计的数据来源是业务明细表按维度聚合实时计算，而不是维护一份单独的统计表------报表数字必须和明细能对上，如果另存一份统计结果，只要有一次写入没跟上，就会出现"看板说这个月收了 80 笔，缴费记录里只找得到 76 笔"的尴尬，而这种不一致很难自动发现。