为什么做
学校已有面向教职工的人事系统和面向学生的教务系统，但后勤服务、物业、外包合作人员与教职工家属等中长期驻校人员，一直缺少统一的源头管理系统。他们的信息需要进入饭卡、网络与门禁等校内服务，原有数据链路却没有一个清晰的责任起点。
这个项目要补上这块空白：办事大厅负责申请与审批，本系统承接审批结果，管理人员档案、工号、有效期和部门权限，再通过受控的数据接口供学校数据中台取用。
我负责的部分
我承担了项目从问题定义到可验收系统的主线工作：
- 与业务老师、办事大厅技术方和数据中台持续确认需求，梳理人员信息在学校系统之间的流向；
- 划定系统边界，明确本系统负责“审批完成后的源头管理”，不重复建设审批、饭卡、上网、门禁或人脸系统；
- 把口头需求整理成可执行的业务规则，包括人员类别、工号编码、在职与离职状态、到期与续期、三级账号和多部门授权；
- 设计办事大厅增量取数方案，用动态字段映射、幂等键与水位线处理表单变化、重复记录和失败重试；
- 主导 FastAPI、Vue 3、MySQL 与 Docker Compose 的全栈实现，并组织分阶段开发、独立审查和回归验证；
- 编写功能演示、部署、运维和学校联调交接文档，把生产环境仍需协调的事项明确留给对应责任方。
系统实现
- 支持办事大厅定时取数与管理员手动录入，自动分配第三方人员工号；
- 覆盖查询、编辑、续期、离职、到期提醒与非破坏性对账等人员生命周期；
- 提供三级角色和多部门授权，数据范围由后端强制执行，不只依赖前端隐藏按钮；
- 提供范围化工作台、组合查询、Excel 导出、系统日志与告警确认；
- 通过独立只读 MySQL View 向数据中台提供人员数据，并把业务表与外部读取权限隔离；
- 使用数据库迁移、自动化测试、冒烟测试与可重复的 Docker 环境支持交付和复核。
当前进度
Mock 版本已完成自动化技术验收和人工页面验收。当前系统包含 31 个后端接口和 14 个前端业务页面；最终后端测试记录为 160 项通过、2 项按条件跳过。
真实办事大厅、数据中台和学校生产网络尚未完成联合联调。项目目前等待正式凭据、网络通道、域名、备份与运行责任人等外部条件，因此不能把现阶段描述为“已经上线”。
这段经历
这是我第一次从零主导学校内部信息系统。最难的部分并不是写出某个页面，而是先回答“谁提供数据、谁能修改、谁负责消费、失败后由谁处理”。如果这些责任没有被说清楚，代码越快，后期返工反而越多。
这段经历也让我更重视边界和交接。一个系统只有在业务规则、权限、异常处理、部署方式和未决事项都能被下一位接手者理解时，才算真正接近可交付。