5.22

项目复盘："设备运维管理系统"没有通过验收
项目背景
大二下学期，我做了一个"铁路客运站设备运维管理系统"。技术栈用了 Python FastAPI + MySQL + 原生前端，19 个配置模块，接入了 DeepSeek 大模型做智能问答，还打通了飞书机器人。光看功能清单，题库很满。

验收结果
没过。

失败原因：我做的不是设备运维系统，是配置管理后台
评委老师一句话："你的系统从头到尾都在管字典、管分类、管线路——设备本身在哪？"

回去翻了翻代码，确实如此。19 张表分别是车站、网格、位置、设备分类、设备用途、巡检线路、巡检项目、保养线路、保养项目、检测线路、检测项目、故障字典、备件库位、备件分类、备件型号、设备厂商、键值字典、流程定义、流程路由。

全是"配置"和"字典"。

一个真正的设备运维系统，核心应该是设备台账——每个设备从采购、安装、巡检、保养、维修、到报废的完整生命周期。而我的项目里连一张设备表都没有。巡检项目挂在"线路"下面，故障挂在"分类"下面，备件挂在"型号"下面——设备这个最核心的实体，被我跳过了。

为什么会出现这个问题
因为我是从数据库设计开始做的。我拿到需求文档后，第一反应是"把这些名词都建张表"，然后给每张表配 CRUD 接口，再套个前端页面。这样做的结果就是——数据库设计看起来很完整，但缺少真正的业务流程串联。

正确的做法应该是：先从业务流程出发。一个巡检工单怎么产生？设备报修怎么流转？备件怎么关联到具体设备？把这些流程画清楚，再倒推数据库设计。

复盘：被技术炫技带偏了
回头看，我的精力分配很有问题：

飞书机器人对接 + AI 对话 + 语音识别 + 图片识别 + PDF/Word/Excel 导出 → 花了 70% 的时间
业务逻辑和核心数据模型 → 连 20% 都没到
接入 DeepSeek 很酷，打通飞书很酷，但评委不会因为"你的管理后台能聊天"就让你过。他们要看的是一套真正能跑起来的运维流程。

以后怎么做
拿到需求先画业务流程图：不是 ER 图，是实际工作怎么流转的
数据结构跟着流程走：巡检单 → 设备 → 故障 → 备件 → 维修工单，这条链路要通
先把核心链路跑通：增删改查是最基础的，流程串联和状态流转才是灵魂
AI 是锦上添花，不是雪中送炭：核心业务没通之前，不碰大模型
说到底
我做了个很漂亮的锤子，但不是评委要的扳手。

下次先搞清楚要用什么工具干活，再动手。