车辆管理系统开发

项目背景

这是一套车辆运营管理系统，单个 JavaScript 代码库，最后一次提交在 2024 年 7 月。这个仓库在本批项目中提交次数最高，累计 61 次提交——说明它在交付期内经过了较多轮迭代，不是一次性写完就交的工程。系统覆盖车辆档案与状态、调度与任务派发、费用与里程记录，以及运营数据统计。

客户当时的状态

车辆运营的麻烦不在「能不能记录」，而在口径。同一辆车，调度记的是出车次数，司机记的是里程，财务记的是费用，三份数据各自成立，合到一起就对不上——月底做运营分析时，谁的数字为准要吵一轮。另外车辆是有状态的：在途、空闲、保养、维修，状态如果不准，调度就会把任务派给一辆正在修的车。

我们的做法与取舍

第一个取舍是把车辆状态作为调度前置条件。状态不准，调度就是无效动作。系统里任务派发只对可用状态的车开放，而不是派完再人工核实。

第二个取舍是把费用与里程挂在同一条任务记录上。费用记一次、里程记一次、任务记一次，三份数据各自存在就永远对不上；挂在同一条记录上，口径矛盾在录入时就会暴露。

第三个取舍是先统一统计口径，再谈报表。运营数据最容易做成「看起来信息量很大的仪表盘」，但如果每张图背后的口径不一样，图越多越误导。我们在做统计前先把口径写成文档，再落到界面上。

系统怎么承载这条链路

系统以车辆档案为基础，状态字段驱动调度可用性；任务派发产生任务记录，费用与里程作为任务记录的附属数据写入；统计模块只从任务与费用记录取数，不另建一套数据。61 次提交的迭代多半花在口径调整与状态流转的细节上——这类系统的问题很少在界面上，都在规则里。

交付状态与边界

代码库最后一次提交在 2024 年 7 月，交付后没有再更新。边界说明：系统承载车辆运营的业务记录与统计，不接入车载硬件与卫星定位设备，位置类数据如需接入属于另行评估范围；费用数据的最终财务认定以客户财务制度为准，系统提供的是记录与汇总；车辆状态由人工与业务规则共同维护，系统不自动判定车辆是否可用。