企业官网建设流程全解析

本文是「汽修 SaaS 开发连载」第 1 篇。我们是一个做中小企业定制软件的团队，今年在开发一套面向连锁汽修厂的管理系统。这个系列记录开发过程中的需求分析、架构设计和踩坑，全部来自真实项目。

缘起

去年接了一个单店汽修厂的管理系统需求，做完之后老板介绍来了第二个客户，是一家有三家门店的连锁汽修。写方案的时候我们发现，前一套系统几乎要重写。

单店系统和连锁系统不是"多几个门店选项"的区别。连锁意味着会员卡要在 A 店充值 B 店消费，配件要从总部仓调到分店，总部老板想在手机上看每家店昨天赚了多少钱。这些问题在单店版里根本不存在。

所以这次立项，我们决定按"单店起步、连锁扩张"的路线来设计，从第一行代码就为多门店留好位置。

调研：三家汽修厂的真实流程

写需求之前我们跑了三家店，一家快修连锁的分店、一家社区修理厂、一家做钣喷的。把接待到交车的流程完整跟了两天，记了几个有意思的细节：

1. 纸质工单是主角。前台开单写一张纸，技师修完在纸上划勾，结算时收银员再把纸上的项目录进一个单机版收银软件。中间任何一环字迹潦草，配件费就算错。
2. 查历史记录靠翻本子。一位车主来问"去年三月是不是在你们这换过刹车片"，前台翻了十几分钟登记本，没找到，最后是老师傅凭记忆确认的。
3. 车主最关心的是记录，老板最关心的是钱。车主想要"我这台车每次做了什么、换了什么件"，老板想要"这台车在我店里总共赚了多少"。这两件事在大部分现有软件里是分开的。

第三个细节直接影响了我们的架构。后面会专门写一篇讲这个需求怎么把我们的表结构逼着重构了一次。

核心决策：以"一车一档"为主数据

市面上不少汽修软件以"客户"为中心建档案。我们调研后发现这不合适：家庭用车场景下，一辆车可能来过三个不同的人（丈夫、妻子、儿子），而一个人也可能有两三台车。如果档案挂在客户上，车辆的维修历史就散了。

所以我们把车辆作为主数据，客户通过关系表挂到车辆上。车辆档案的锚点用 VIN 码（车架号），而不是车牌——车牌会变（过户、换牌、拍新号），VIN 一辈子不变。同一台车换牌之后，历史记录必须还能追回来，这是汽修行业和别的行业不太一样的地方。

车辆档案下挂六类数据：

这套结构落地的效果是：前台输个车牌或手机号，两秒调出这台车的全部历史。车主扫码也能在小程序里看到自己车的记录，包括每一项花了多少钱。有个店老板看完 demo 说了句话我们记到现在：“这个记录拿给车主看，比我说十句都管用。”

总体架构：9 大模块 + 车主端

┌────────────── 车主端（小程序）──────────────┐ │ 车辆绑定 · 维保记录 · 维修进度 · 预约 · 提醒 │ └────────────────────┬───────────────────────┘ │ ┌────────────────────┴───────────────────────┐ │ 商家管理后台（SaaS） │ │ PC 后台 / 技师 App / 口袋小程序 │ ├─────────────────────────────────────────────┤ │ ① 组织权限 ② 客户车辆档案 ③ 维修工单 │ │ ④ 配件进销存 ⑤ 预约与车间 ⑥ 会员营销 │ │ ⑦ 财务业财 ⑧ 连锁总部管控 ⑨ 报表 BI │ └─────────────────────────────────────────────┘

模块之间不是平行的。维修工单是心脏：领料挂在工单上，工时挂在工单上，质检照片挂在工单上，财务凭证由工单生成。别的模块都是在给工单供数据或者消费工单的数据。

分四个阶段做，每个阶段都是能上线的产品

一开始我们想一口气把连锁功能全做出来，评估完工作量（大概是大版本 v1 的三倍）就放弃了。改成四个阶段：

• P1 · 单店可用：档案 + 工单 + 基础进销存 + 基础报表。目标只有一个：完整记录"谁的车、做了什么、换了什么件、花了多少钱"。
• P2 · 效率提升：预约排班、车间看板、保养到期提醒、车主小程序、基础财务。
• P3 · 连锁扩张：总部管控、中央库存调拨、跨店消费结算、集团报表。
• P4 · 生态对接：维修电子健康档案上报、4S 店 DMS 对接、保险理赔、开放 API。

这样做有个额外好处：P1 的客户也能立刻用起来，不用等整个连锁体系完工。

写在最后

这个系列接下来的安排（会边写边调）：

如果你们也在做汽修或类似的多门店管理系统，欢迎在评论区交流，尤其想听听多租户数据隔离和跨店结算方面的经验。

「汽修 SaaS 开发连载」· 01 / 记录一个软件团队的真实开发过程