宿舍报修为什么总卡在“谁来修”Spring Boot 智能工单系统把分配、处理、评分、申诉做成闭环真正的“智能工单”不一定靠 AI先把状态、责任人和争议处理机制设计清楚就已经能解决大量校园报修问题。Spring Boot宿舍报修小程序智能工单申诉仲裁宿舍报修最常见的痛点不是“学生不会提交问题”而是提交之后不知道谁负责、维修到哪一步、出了争议找谁。这个系统把报修工单拆成多个可追踪阶段学生提交、后台分配、部门处理、结果通知、用户评分如果处理结果存在争议还可以进入申诉、协商甚至仲裁流程。它的核心价值是把原本散落在群聊和电话里的沟通变成结构化工单。项目速览系统形态小程序用户端 Web 管理端核心角色学生用户、后勤部门、管理员工单主线报修 → 分配 → 处理 → 通知 → 评分争议机制申诉 → 协商 → 仲裁工单阶段 01学生先把问题描述完整小程序端的报修表单包含工单号、紧急程度、报修日期、上传图片和问题描述。相比只填“宿舍坏了”这种结构化字段能够让后勤人员更快判断问题级别也便于系统后续按紧急程度和时间排序。图片证据还能减少“描述不清”的反复沟通。小程序报修工单填写界面工单阶段 02工单不是提交完就结束而是进入分配报修详情中可以看到工单状态、分配时间、部门类型和具体后勤部门。也就是说系统把“谁来修”作为独立环节处理而不是让学生自己寻找维修人员。管理员可以根据工单内容和部门类型进行派单让责任归属更清晰。工单分配与处理详情工单阶段 03处理过程要有进度、凭证和结果工单处理列表会展示学生姓名、工单号、紧急程度、报修日期和上传图片并提供详情、申诉、评分、支付等操作。处理详情中还能保存维修图片、处理信息、处理进度和处理时长。把过程证据留在工单里后续无论评价还是争议处理都能基于同一份记录进行判断。后台工单处理列表工单阶段 04学生端能看到状态也能评价或申诉移动端的工单处理列表不仅展示分配部门和工单状态还直接提供详情、申诉、评分入口。这样做能明显减少“维修人员说处理完了但学生觉得没修好”的信息差。对于服务型系统用户反馈不能只放在一个意见箱里而应该和具体工单绑定。学生端工单处理与评价入口工单阶段 05争议处理是这个项目最有辨识度的部分系统中单独设置了申诉信息、协商信息和仲裁信息模块。处理详情可以看到申诉原因、协商内容、回复信息、补偿方案以及是否同意等字段。这样的设计意味着报修系统不只处理“正常工单”还考虑了异常场景和服务纠纷这也是它比普通报修 CRUD 更完整的地方。申诉与协商信息详情工单生命周期五个阶段如何串起来智能工单生命周期图从流程上看系统先把学生的描述转成标准工单再将工单分配给对应后勤部门处理完成后进入通知和评价。如果结果有争议则进入申诉、协商或仲裁。这里的“智能”更多体现在规则化分配、状态驱动和多节点协同而不是简单给页面贴一个 AI 标签。数据库关系为什么分配、处理、评分要拆成不同实体如果把所有字段都堆在一张“报修表”里后期很难记录多次分配、多次处理或多次申诉。更合理的做法是以报修工单为中心分别关联分配信息、后勤部门、处理记录、评分和申诉记录。这样既能保留历史也方便根据不同状态做权限控制。核心 E-R 关系图测试重点别只测“能不能提交”●不同紧急程度的工单是否能正常保存和查询●分配部门后学生端能否看到最新状态●处理完成后评分和申诉入口是否按规则开放●同一工单的分配、处理、申诉记录能否相互追溯●管理员、后勤部门和学生看到的操作权限是否不同结尾报修系统的价值是把责任和状态说清楚这类项目最能体现业务系统设计能力的地方不是界面做得多漂亮而是能不能回答三个问题现在工单在哪个阶段下一步由谁处理出现争议后怎么继续这个项目把这三件事都落到了具体模块和数据记录上因此很适合作为 Spring Boot 小程序的流程型案例。源码免费领取需要本项目源码、数据库文件或部署说明可在公众号后台回复「宿舍报修」获取。