一、先看业务链：岗位不是终点，工资闭环才是

传统管理容易把岗位、申请、工时和工资分散在不同表格中，学生无法及时了解处理进度，管理者也难以核对数据。本系统通过业务主键和用户信息将各阶段串联，使一条岗位申请能够继续追踪到工时和工资。

二、系统目标：透明、可追踪、可核对

• 岗位信息统一发布，减少重复询问和信息不对称。
• 申请过程保留审核状态与审核回复，学生可以随时查看结果。
• 工时按日期记录并由管理员审核，避免口头统计造成误差。
• 工资由工时和工时单价计算，保留发薪日期和工资详情。
• 提醒通知覆盖申请、工时和工资节点，降低遗漏。

三、双角色协作模型

学生用户主要负责岗位浏览、岗位申请、工时填报、工资查看和通知接收；管理员负责岗位维护、申请审核、工时审核、工资发放、公告与权限管理。系统通过角色菜单和数据条件控制两类用户的操作范围。

学生端强调操作简洁和进度可见，管理端强调批量查询、审核和统计。两者并不是独立模块，而是围绕同一批业务数据协同工作。

四、三层架构与功能地图

系统采用表现层、业务逻辑层和数据访问层的三层结构。表现层负责页面展示和输入，业务层处理岗位人数、申请审核、工时计算等规则，数据访问层负责MySQL数据读写。分层后，岗位申请规则或工资计算方式发生变化时，不需要大面积修改页面代码。

图1 系统总体架构图

图2 系统功能结构图

五、岗位发布：从后台录入到前台展示

管理员填写部门名称、岗位名称、工作地点、工资待遇、工作时间、人数需求和工作内容。提交时，系统检查必填项、人数范围及岗位状态，保存成功后在前台展示。岗位下架后不再接受新申请，但历史申请数据仍应保留。

图3 岗位信息发布流程图

六、岗位申请：审核结果必须可追踪

学生在岗位详情页提交申请材料、申请内容和日期。后台审核时写入审核状态与审核回复，学生个人中心展示最新结果。为了避免重复申请，可按“学生ID+岗位ID+有效状态”进行唯一性校验，或限制同一岗位的申请次数。

图4 岗位申请流程图

七、工时填报与工资计算如何衔接

申请通过后，学生才能进入工时填报。工时数据包含岗位、学生、记录日期、工时数和备注，管理员审核通过后才能计入工资。工资记录可根据审核后的总工时与工时单价计算合计金额，并保存发薪日期和说明。

八、数据库模型：围绕学生与岗位建立业务关系

系统核心实体包括学生用户、岗位信息、申请信息、工时填报、工资信息和提醒通知。申请信息承担承上启下作用：向前关联岗位，向后关联工时与工资。

图5 系统总体E-R图

• 岗位信息记录工作条件、待遇和人数需求。
• 申请信息保存学生材料、审核状态与回复。
• 工时填报记录工作量，并保留审核结果。
• 工资信息保存总工时、单价、合计金额和发薪日期。
• 提醒通知关联学生和业务来源，支持统一消息展示。

九、系统界面展示

图6 岗位信息界面

图7 岗位申请界面

图8 申请信息管理界面

图9 工时填报审核界面

图10 工资信息添加界面

十、异常场景与数据一致性

• 岗位人数已满时，应阻止新的申请或进入候补状态。
• 未审核通过的申请不能提交工时。
• 同一学生同一天同一岗位的工时记录需要防重复。
• 工资生成后若工时被退回，应重新计算并记录调整原因。
• 删除岗位时应采用逻辑删除，避免破坏历史申请和工资记录。

十一、测试结论与扩展方向

系统测试应覆盖注册登录、岗位检索、重复申请、申请审核、工时填报、工时退回、工资计算、通知查看和权限越界等场景。通过正常与异常用例组合，可以验证业务链是否完整。

后续可增加岗位推荐、用工部门账号、电子签字、工时批量导入、工资报表导出和统计看板。若接入统一身份认证，还可以减少学生重复注册并提高账号可信度。