高速公路工程水土保持全过程管控系统

校企合作项目,从 0 到 1 主导产品方案与前端落地,审批效率提升 70%,数据错误率由 12% 降至 1%

+70%
审批效率提升
12%→1%
数据错误率下降
3-5天→数小时
审批时长压缩
12+
迭代优化功能点

一、项目背景

高速公路工程穿越山地丘陵等水土流失敏感区域,依据《水土保持法》须在工程全周期开展水土保持管控。传统模式下,建设、施工、监理、监测、验收等多方主体协同依赖线下手工记录与纸质流转,存在明显痛点:

1. 审批耗时长:水土项目材料需经多单位多岗位审批流转,线下多单位平均流转 3-5 天,影响项目进度。
2. 数据混乱:施工台账、监测数据、验收资料分散在各参与方 Excel 与纸质件中,版本不一、易丢失且管理混乱,数据错误率高达 12%。
3. 信息不对齐:各主体掌握的工程状态不同步,预警信息滞后,常在问题发生后才被发现。

项目目标:建设覆盖"方案—设计—施工—验收"全过程的水保管控系统,实现数据集中化、审批线上化、预警实时化,从源头降低水土流失风险与合规风险。

二、核心职责

作为项目组长兼产品、前端,统筹项目全生命周期,承担以下五项核心职责:

2.1 需求调研

深度参与企业员工访谈,覆盖建设、施工、监理、监测等多角色岗位,从一线真实工作流中提炼出审批慢、数据乱、信息不对齐三大核心痛点,并输出需求清单与业务流程图。

2.2 产品方案设计

设计系统整体功能架构,明确六大功能模块与数据流向;输出完整 PRD 文档,并使用 Figma 完成高保真原型,作为研发与评审基线。

高速公路工程水土保持全过程管控系统 系统架构图 中心数据库 方案 · 设计 · 施工 · 验收 项目管理模块 工程设计 设计单位编辑 工程施工 施工单位编辑 工程管理 建设/监理审核 工程验收 验收单位审批 实时预警 监测单位管理 建设单位 编制单位 设计单位 施工单位 监理单位 监测单位 验收单位 各角色根据权限查看/编辑对应功能模块 员工管理模块 用户账号 · 组织架构 · 角色分配 项目管理模块 项目配置 · 权限管理 · 添加成员 系统管理员 系统配置 · 日志审计

2.3 前端开发

基于 Vue2 + ElementUI 负责核心前端实现,主要包括:

  • 搭建基于角色的动态路由,实现八类用户差异化菜单与页面权限;
  • 配置 ECharts 可视化预警图表,实时展示施工指标与阈值对比;
  • 协调后端接口联动,主导前后端联调与数据契约定义。

2.4 测试优化

组织 2 轮 Beta 测试,收集 20+ 名员工真实反馈,迭代优化 12+ 功能点,涵盖表单交互、预警规则、权限边界等关键场景。

2.5 项目管理

统筹项目全生命周期管理,牵头对接企业部署上线;输出标准化使用手册,并负责员工赋能培训,保障系统顺利落地使用。

团队协作机制:项目启动前输出明确的里程碑计划;每周组织1次会议同步当前任务进度;遇到UI/前端/后端不一致时由我牵头拉对齐会并做决策。我的协作风格偏向'文档先行+快速闭环'——先写PRD定基线,再有风险小步快跑迭代,避免反复返工。

三、系统功能模块

系统围绕"数据—预警—协同"三条主线,划分为六大功能模块,覆盖水土保持从方案到验收的完整闭环(可点击左栏模块导航查看各模块说明与界面截图)。

中心数据库管控
统一纳管水土保持方案、工程设计、工程施工及专项验收数据,构建全流程数据底座。
实时预警系统
施工数据与控制中心指标实时对比,超出目标值自动预警并推送至责任主体。
文件上传模块
支持本地暂存与提交,路由后置守卫拦截未保存离开,防止数据丢失。
动态路由权限
八类用户(建设/施工/监理/监测/验收等)按角色动态加载路由与页面权限。
数据可视化
基于 ECharts 实时预警图表、趋势曲线与指标看板,多维呈现管控状态。
响应式适配
PC 端与小程序端双端兼容,支持施工现场移动巡查数据实时回传。

3.1 中心数据库管控

以中心数据库为底座,串联水土保持方案、工程设计、工程施工、专项验收四大阶段,实现各阶段数据可追溯、可对比,打破参与方之间的信息壁垒。

3.2 实时预警系统

系统将现场施工数据(如扰动面积、弃渣量、防护措施进度)与控制中心设定的目标阈值实时比对,一旦超出阈值即自动触发预警,按责任归属推送至对应岗位,将"事后补救"转为"事前干预"。

3.3 文件上传模块

针对施工现场网络不稳定场景,文件上传支持本地暂存,待网络恢复后一键提交。同时引入路由后置守卫,在用户未保存即试图离开时进行拦截确认,避免录入数据丢失。

3.4 动态路由权限

基于用户角色动态生成路由表,登录后根据后端返回的权限标识addRoutes动态挂载可访问页面,菜单与页面双重校验,详见第五章权限矩阵。

3.5 数据可视化

采用 ECharts 构建实时预警看板,包括阈值对比柱状图、趋势折线图、风险分布地图等,帮助管理者一屏掌握全局水保管控状态。

3.6 响应式适配

系统兼容 PC 端与小程序端,施工现场巡查人员可通过小程序实时上传照片与数据,回传中心数据库,实现"现场—中心"数据闭环。

四、技术选型与实现

基于校企合作 B 端场景对稳定性与开发效率的双重要求,技术栈选型如下:

层级 技术 选型理由
前端框架 Vue2 2023年项目启动时,Vue3生态对ElementPlus的部分B端组件支持仍不够稳定,Vue2+ElementUI对中小型B端项目是经过大量实战验证的成熟组合,团队熟练度高、风险低。
UI 组件库 ElementUI 表单/表格/弹窗组件完备,契合数据密集型后台
后端框架 Springboot 快速构建 RESTful 接口,便于前后端分离联调
数据存储 MySQL 关系型存储保障业务数据一致性与事务可靠性
数据可视化 ECharts 灵活的图表配置,满足实时预警与多维度看板需求

五、动态路由权限设计

系统面向八类用户角色,按业务职责划分功能权限。登录后后端返回角色权限标识,前端据此动态生成路由与菜单,实现各类角色专属访问控制。

用户类型 中心数据库 实时预警 文件上传 工程施工 水保验收 系统管理
建设单位 查看 查看 编辑 审批 发起
编制单位 查看 查看 编辑 审批 发起
设计单位 查看 查看 编辑 编辑
施工单位 查看 查看 编辑 编辑
监理单位 查看 查看 审核 审核 参与
监测单位 查看 编辑 上传 查看 参与
验收单位 查看 查看 查看 审批
系统管理员 查看 查看 查看 监管 管理
设计要点:权限粒度细化到"查看 / 编辑 / 审核 / 审批 / 管理"五个层级,菜单与接口双重校验,避免越权访问;监测单位作为预警数据的主要录入方,被赋予预警模块的编辑权限。

六、项目成果

系统上线后,在水保审批效率与数据质量两个核心维度取得显著成效:

指标 系统上线前 系统上线后 变化幅度
单次审批时长 3-5 天 数小时 效率 +70% ↑
数据错误率 12% 1% -92% ↓
信息同步方式 线下纸质流转 中心库实时共享 信息对齐 ↑
预警时机 事后发现 事前实时预警 风险前置 ↑
+70%
审批效率提升
1%
数据错误率
2 轮
Beta 测试
20+
员工反馈样本
成果解读:审批效率提升 70% 主要得益于流程线上化与多角色并行审批;数据错误率从 12% 降至 1% 则归功于中心数据库统一纳管、表单校验与预警规则的事前拦截。

成果归因:

效率提升归因:流程线上化(消除线下跨单位签字跑腿)+并行审批改造(原串行改多人可同时审批非依赖节点)。

数据质量提升归因:中心库统一纳管(淘汰各单位Excel分散存储)+表单校验规则(防止脏数据提交)+预警规则可视化与邮件事前拦截。

预警规则机制说明:系统的预警逻辑基于'编制值vs施工值'的对比——编制单位在工程前期填报各类水土保持措施的编制值,系统在多家施工单位填报施工值时自动累计比对,一旦施工值累计超过编制值设定阈值,即触发邮件预警给建设单位、监理单位、施工单位三方,实现事前拦截而非事后追责。

七、项目复盘与反思

做得好的地方:

  • 从需求调研切入,先厘清"审批慢、数据乱、信息不对齐"三大痛点,再反推功能架构,避免功能堆砌;
  • 动态路由权限设计前瞻,八类角色权限矩阵一次性规划,后续新增角色无需重构;
  • 2 轮 Beta 测试 + 20+ 员工反馈形成闭环,12+ 功能点迭代有据可依;
  • 兼顾 PC 端与小程序端,贴合施工现场真实使用场景。

不足与改进方向:

  • 预警规则以静态阈值为主,未引入基于历史数据的动态阈值,存在误报可能;
  • 文件上传的断点续传能力较弱,弱网大文件场景体验仍有优化空间;
  • 权限矩阵未做细粒度字段级控制,部分敏感字段依赖前端隐藏,安全性可进一步加固;
  • 数据可视化看板缺少自定义配置能力,后续可开放给管理者自定义指标组合。
核心方法论总结:B 端系统的价值不在于功能多少,而在于是否真正打通业务闭环。本项目的关键在于"以痛点定架构、以权限保协同、以预警防风险"——先把多方协同的权责理清,再用动态路由与中心数据库把协同落地,最后用实时预警把风险前移。

协作中的一次典型挑战:

前后端对齐接口时,发现对同一产品需求存在认知偏差——不同单位在审批流程中有不同的先后顺序与不同的权限操作按钮,复杂的业务流程让前后端对'谁先审、谁能改、谁只能看'的理解不一致。

我的解法:

①第一时间拉产品、前端、后端三方对齐会,梳理三方对需求的理解差异;
②对于需求无法直接实现的矛盾点,我基于业务流程图重新拆解,找到'业务必需'与'技术可实现'的交集;
③带着两版可实现的替代方案与共识结论,与甲方对齐确认最终方案;
④确认后更新PRD与接口文档,作为后续开发的基线。

这次经历让我形成了一套协作方法论:'发现分歧→三方对齐→提炼替代方案→与甲方共识→文档留痕',后续在多个复杂需求场景中复用有效。

本页