我一直觉得，汽车4S店的维保业务特别适合做一套线上系统：预约排期、接车预检、施工派单、质检交付、结算回访，整个链路又长又讲究时效，光靠纸质单据和微信群来回折腾，效率低还容易扯皮。最近刚帮一家经销商集团交付了一套基于 Python 后端 + 微信小程序的车辆维护与保养服务系统，覆盖用户端、员工端、管理端三个小程序，正好把整个方案和踩坑过程整理一下。
这套系统解决的核心问题有三个：一是车主预约保养不用再打电话排队，线上选门店、选时间段、选服务项目；二是店内的接车、派工、施工、质检流程全部电子化，技师和SA（服务顾问）在手机上就能流转工单；三是管理层能实时看到进场台次、产值、完工率这些关键运营指标，不用等月底报表。适合正在做4S店售后数字化的小伙伴参考，也适合想了解 Python 后端配合微信小程序三端架构怎么落地的朋友。
1. 项目概述与需求拆解
1.1 三端架构到底怎么划分
很多第一次听到"三端"的人会以为是一个小程序里分三个角色，其实我做的是三个独立的小程序工程，共用同一套后端 API。用户端叫"车主维保服务"，给车主用；员工端叫"服务顾问助手"，给 SA、技师、质检员用；管理端叫"门店运营后台"，给店长和集团运营看数据、做配置。
为什么拆成三个独立小程序而不是一个大程序里做角色切换？因为微信小程序有主体和类目限制，员工端和管理端如果在车主端里，审核时业务场景对不上，而且三个小程序的用户体系、权限边界、分享卡片逻辑都不一样。拆开之后每个端只做自己该做的事，代码体积也更小，维护起来不打架。后端共用一套 Django 服务，通过 JWT 里的角色字段区分访问权限，数据层面天然隔离。
三个端的核心使用者差别很大：车主端用户是小白，界面要足够傻瓜；员工端用户天天用，操作路径要短，按钮要大；管理端用户要的是数据密度，一张卡片要能看出今日进场、在修、完工、产值四个数。这些差异从一开始就决定了三端的交互设计各自独立，模板和组件不强行复用。
1.2 技术选型：Python 生态为什么合适
后端选择 Python + Django REST Framework，主要看中三件事：一是 Django 自带 Admin 后台，运营配置和基础数据维护可以直接用，不用额外写一套 PC 管理端；二是 DRF 的序列化器和视图集写 CRUD 极快，维保业务模块多、表结构复杂，开发效率非常关键；三是 Python 生态里处理微信小程序需要的能力都有现成库，比如解密手机号、生成二维码、发订阅消息，都有对应的 SDK 或官方接口封装。
小程序端我采用的是原生微信小程序框架，没有用 uni-app。原因很简单：三端页面都是定制化较强的表单项和工单流，原生语法写起来虽然啰嗦，但不会有跨端兼容问题，而且微信的原生组件（比如 camera、chooseLocation、subscribeMessage）支持最稳。如果以后要扩展到支付宝或抖音小程序，再考虑 uni-app 重写也不迟，目前阶段稳定优先。
数据库用的是 MySQL 8.0 + Redis 缓存。Redis 主要扛三块：登录态 token 黑名单、保养工位排期锁、首页看板汇总数据的短缓存。项目里没有引入消息队列，因为维保工单流转的并发量远没到需要削峰的程度，Django 的信号机制加事务回调足够应付，少一个中间件就少一个运维点。
1.3 业务功能清单与核心流程
用户端功能：门店列表与预约、服务项目与套餐展示、维保历史记录、电子保养手册、预约改期/取消、到店签到、取车码、订单支付（微信支付）、评价与回访。
员工端功能：今日预约列表、接车预检（拍照+填写检查项）、工单创建、派工（选技师和工位）、施工记录（领料、工时、操作项）、质检拍照与签字、交车结算。
管理端功能：工位与技师管理、预约排期看板、工单状态监控、配件库存与领料统计、优惠券与套餐配置、客户标签与流失预警、经营数据报表（进场台次、人均产值、准时完工率）。
核心流程是一条状态机：预约 -> 到店 -> 预检 -> 派工 -> 施工 -> 质检 -> 结算 -> 完工 -> 回访。每个状态变化都会触发订阅消息通知车主，同时记录一条工单日志，方便事后审计。状态机的流转规则在 Django 的 model 层做了保护，前端只是拿到当前状态和可操作按钮，不能跨状态跳转，从源头避免脏数据。
2. 系统架构与数据库设计
2.1 后端分层与服务划分
后端代码按业务域分了四个 app：accounts（登录鉴权与用户档案）、appointment（预约与排期）、workorder（工单与施工）、operations（运营配置与报表）。每个 app 内部按 views / serializers / services / models 分层，services 层专门放业务逻辑，views 层只做参数校验和序列化返回。这样做的最大好处是工单状态流转这类复杂逻辑可以单元测试，不用每次调 HTTP 接口。
我额外做了统一的响应包装和异常处理。所有接口返回格式固定为{code, message, data}，业务异常自定义ServiceException，由全局 exception handler 捕获，转换成对应的 HTTP 状态码和错误信息。这个看似基础的设计，实际调试时能省大量时间，前端只需要统一处理一个 response 结构，不会出现"有的接口返回 errmsg，有的返回 message"这种混乱。
短信服务对接的是阿里云短信，验证码和通知模板分开。微信端手机号获取用的是<button open-type="getPhoneNumber">，后端通过 code 换取手机号，不走短信通道，这样车主端登录体验最顺。员工端和管理端则用账号密码登录，后台统一创建账号并绑定微信 openid。
2.2 核心数据表设计要点
工单表是整张数据模型的核心，我给它设计了独立的t_work_order，主键用雪花算法生成的 19 位 ID，避免暴露自增 ID 被爬取。工单里冗余了门店 ID、车牌号、车主手机号、SA 工号、技师工号、预计交车时间、实际交车时间这些高频查询字段，虽然违反了一点范式，但换取了列表页不用 JOIN 五张表的高效查询。
预约表单独拆了一张t_appointment，状态包括待签到、已签到、已取消、已过期、已完成。预约时除了记录服务项目和车辆信息，还会做一个排期快照：把所选工位的占用时间段写进t_schedule_slot，相当于提前占坑，避免人工排重。如果用户取消预约，对应的 slot 自动释放，这个逻辑在事务里完成，保证数据一致性。
保养历史表记录的是每次工单完成后的汇总数据，包括行驶里程、更换配件列表、下次建议保养里程和时间。这张表是给车主端展示用的，也承担了保养提醒的触发来源。我是通过 Django 信号在工单状态变为"已完工"时自动写入，不依赖定时任务，简单可靠。
2.3 三端共用 API 的权限设计
API 权限用 Django REST Framework 的IsAuthenticated+ 自定义RolePermission，每个视图声明允许访问的角色。车主端 token 走微信登录流程获取，员工和管理端 token 走账号密码获取，登录时后端统一返回access_token、refresh_token和role。小程序端把role存在全局变量里，跳转页面时做前端路由守卫，后端再验一次权，双重校验。
这里有个容易踩的坑：微信小程序的wx.request无法像网页一样跨域带 Cookie，所以我全部采用Authorization: Bearer <token>的头部传递方式。refresh_token 有效期设了 7 天，access_token 2 小时，小程序每次启动时静默刷新。为了保证弱网环境下请求不频繁失败，我在小程序端做了 token 过期自动重放的逻辑，用 Promise 队列避免多个请求同时刷新 token。
3. 核心功能实现与实操细节
3.1 预约排期算法：别小看这个"抢工位"
预约模块看起来简单，实际排期是有讲究的。4S 店售后一般有多个工位，每个工位对应不同工种（快保、机修、钣喷），保养项目耗时也不同。如果只是简单地让用户选日期，不控制时间段，很容易出现工位撞车或技师超负荷。
我实现的是一套"工位时段占用表 + 容量校验"方案。每个门店在管理端配置营业时间段（比如 9:00-18:00，拆成半小时的 slot），每个 slot 上绑定可用工位数量。用户提交预约时，后端拿到服务项对应的预计工时，按向上取整计算需要的连续 slot 数，然后在事务里对这些 slot 执行条件更新：
# 伪代码：锁定连续可用时段 slots = ScheduleSlot.objects.filter( shop=request.shop, slot_time__gte=start, slot_time__lt=end, status=SlotStatus.FREE ).select_for_update() if len(slots) < required: raise ServiceException("该时间段工位已满，请选择其他时间") locked_rows = ScheduleSlot.objects.filter( id__in=[s.id for s in slots], status=SlotStatus.FREE ).update(status=SlotStatus.LOCKED)select_for_update加行锁是为了防止两个请求同时选中同一批 slot，这在 MySQL InnoDB 下才生效。实测并发预约时偶尔会报死锁，排查后发现是条件更新和行锁混用导致的，最后的解法是把锁定的判断和 update 放在同一个事务里，并加了个重试装饰器，死锁自动重试两次，目前压测 50 并发稳定通过。
泰好用的做法是在用户选择时间段时先做一次前端预估，只让用户看到还有工位的时段，减少无效提交。前端可以根据后端返回的"可约时段列表"渲染时间轴，每个时段显示剩余工位数，这样交互直观，后端也不会被无效请求打到。
3.2 微信手机号快捷登录的实现
车主端登录是我重点打磨的环节，不能让用户输手机号，那样转化率会掉一大截。微信小程序现在支持getPhoneNumber一键获取手机号，流程是：前端按钮触发手机号弹窗授权 -> 后端调用code2Session获取 openid -> 调用phonenumber.getPhoneNumber接口用 code 换取手机号明文。
后端在 Django 里统一封装了一个WechatAuthService：
def login_with_phone(self, code, phone_code): session = self._code2session(code) openid = session["openid"] phone_info = self._get_phone_number(phone_code) mobile = phone_info["phone_info"]["purePhoneNumber"] # 查询或创建用户，绑定 openid 和手机号 user, created = UserProfile.objects.get_or_create( mobile=mobile, defaults={"nickname": f"车主{mobile[-4:]}"} ) if not user.openid: user.openid = openid user.wx_unionid = session.get("unionid") user.save() return self._generate_tokens(user)这个接口在提交手机号 code 的时候要抓好超时问题，一次性 code 有效期只有 5 分钟，前端弹窗即使授权了，如果后端处理慢了也会失效。所以我在前端拿到 code 后立刻调接口，不做任何中转。另外备注一下，个人主体小程序用不了这个能力，必须是企业主体且开通了相应接口权限，项目启动前要确认好资质。
3.3 工单状态机与订阅消息推送
工单模块是状态流转最复杂的部分。我在WorkOrder模型里维护一个status字段，合法状态用枚举定义，状态迁移表单独放一个STATUS_TRANSITIONS字典：
WORKFLOW = { WorkOrderStatus.PENDING: {WorkOrderStatus.PRE_INSPECT, WorkOrderStatus.CANCELLED}, WorkOrderStatus.PRE_INSPECT: {WorkOrderStatus.ASSIGNED, WorkOrderStatus.CANCELLED}, WorkOrderStatus.ASSIGNED: {WorkOrderStatus.REPAIRING, WorkOrderStatus.REPAIR_DONE}, WorkOrderStatus.REPAIRING: {WorkOrderStatus.QUALITY_CHECK, WorkOrderStatus.WAIT_PART}, WorkOrderStatus.QUALITY_CHECK: {WorkOrderStatus.SETTLEMENT, WorkOrderStatus.REPAIRING}, WorkOrderStatus.SETTLEMENT: {WorkOrderStatus.COMPLETED}, }状态迁移统一封装在WorkOrderService.transition(work_order, target_status, operator)方法里，先做权限校验（比如只有技师角色能把工单从"施工中"推到"质检"），再写日志、再发消息，最后落库。这里特别注意顺序：一定是先落库、再发订阅消息。如果把消息发送放在事务里，微信接口耗时可能长达 1-2 秒，数据库连接被干等，并发一高就大量超时。
订阅消息这块有个限制：用户主动订阅一次只能发一条消息，且一次性订阅最多只能授权 3 条。我的做法是在几个关键节点引导用户订阅——预约成功页引导订阅"服务进度提醒"，交车时订阅"回访评价提醒"，每个节点只发一条，避免滥用。消息文案用微信模板，模板 ID 在管理端按门店配置，这样不用改代码就能换模板。
3.4 移动端多图上传与图片压缩
接车预检和质检都要拍照，一个工单至少 4-6 张图。小程序端wx.chooseImage拿到的原图可能 2-5MB，直接上传用户体验很差，而且后端存储压力大。我在小程序端做了压缩：wx.compressImage压缩到 80% 质量，宽度限制 1200px，实测单张图片从 4MB 降到 300KB 左右，上传时间从四五秒降到了一秒内。
后端接收图片用的 Django 的ImageField+ OSS，直接用 OSS 的直传策略，由后端签名、前端直传，不走应用服务器中转。这样上传带宽压力全部在 OSS 上，不会打满 Django 服务。直传的地址带过期时间，一小时有效，前端传完把返回的文件 key 再提交到工单接口，工单里存的是 key，展示时拼上 CDN 域名。
照片命名我用的是workorder_id + 序号 + 时间戳，方便出问题时定位。质检模块要求必须拍到技师签名，签名是用canvas做的，生成 base64 图片后也走 OSS 上传。这里有个小坑：部分安卓机的 canvas 尺寸和 CSS 尺寸不一致，导致生成的图片模糊，解决方法是固定 canvas 宽高并用wx.getSystemInfo做像素比换算。
4. 性能优化与调试记录
4.1 小程序端请求合并与弱网容错
用户端首页和工单详情页要请求多个接口，如果一个个等，体验很差。我在 request 层封装了一个简单的批量请求队列：收集 100ms 内的所有请求，合并成一个并发请求发送，后端用一个自定义的 batch 接口接收多个子请求，分发给对应视图处理。这样弱网环境下首页加载从 3-5 秒降到 1 秒左右。
不过这个 batch 接口也会带来一个问题：任何一个子请求失败会导致整个 batch 返回失败。我的处理是给每个子请求独立的超时和错误吞掉机制，返回时带上子请求状态，前端针对data.partial标记做局部刷新，而不是一整个页面 toast 报错。实测下来这种"部分成功"策略比整体失败体验好很多。
缓存策略上，门店列表和保养套餐这类变化少的数据，小程序端做了本地 storage 缓存，有效期 10 分钟，启动时先渲染缓存再拉新。工位剩余量不能缓存，因为实时性要求高，每次进入预约页都走网络请求。
4.2 后端慢查询与接口压测
整套系统上线前我用 Locust 做了压测，目标是最低支撑 100 并发预约操作。压测时发现最大的性能瓶颈不是 Django 本身，而是两个地方：一是预约时段校验时的 SQL 查询次数太多，每个工位 slot 单独查一次，高峰期 50 个并发就把数据库连接池打满；二是工单列表页的关联查询有 N+1 问题，每行工单都要查一次客户电话和技师姓名。
第一个问题通过把 slot 查询合并成一条范围 SQL 解决，预计占用时间和已占用时间一次性查出来，在 Python 内存里做差集计算。第二个问题用select_related和prefetch_related优化，列表接口响应时间从 800ms 降到了 120ms。再配合 Redis 缓存"今日工位总览"，数据库压力小了非常多。
压测还发现了一个 Djangorestframework 序列化的坑：嵌套序列化器会把所有外键关联的子对象全部序列化成 JSON 再取舍，如果只用到部分字段，效率极低。我用SerializerMethodField加自定义查询，只取需要的字段，工单详情接口的返回体积从 15KB 降到了 3KB，对小程序弱网环境非常友好。
4.3 线上日志与监控
线上环境我接入了三套日志：请求日志、业务操作日志、异常日志。请求日志记录每个接口的耗时、状态码、请求体大小，用 Django middleware 实现；业务操作日志记录工单状态流转、预约变更等关键动作，用 model signal 实现；异常日志主要靠logging+ Sentry，ServiceException不打印 traceback，只有真正的系统异常才上报。
小程序端调接口时有个固定套路：每个请求都带trace_id，后端把它写进日志里。这样出问题时，直接用trace_id在日志和 Sentry 里查全局链路，不用猜是前端还是后端的问题。三端项目尤其需要这个，因为同样一个接口可能被三个不同的端调用，没有 trace_id 很难定位是哪端传的参数不对。
5. 安全与权限控制细节
5.1 小程序端防刷与风控边界
车主端的预约、签到、评价这些接口，都加了频率限制。Django 里我用了django-ratelimit，按用户维度限制每分钟最多请求 30 次，关键接口比如"提交订单"单独限制每分钟 5 次。再配合一个简单的 IP 黑名单机制，单个 IP 短期大量请求直接拒绝。微信小程序端拿不到真实 IP，后端可以通过X-Forwarded-For获取，但公网小程序一般经过微信请求代理，需要多做一层校验。
风控这块还要注意"设备指纹"。维保系统的优惠券和套餐经常有新人专项补贴，防止黄牛用模拟器批量注册，我在登录时通过小程序端拿到设备信息（机型、系统版本、屏幕尺寸），后端存一个简单的设备指纹 hash。如果同一设备 hash 下短时间内注册了多个账号，直接进风控名单，这个机制上线后帮运营拦下了好几拨刷单。
5.2 接口参数校验与越权防护
越权是这类系统最容易出现的安全问题。员工端和管理端的每个业务接口，后端都显式校验当前操作人所属门店和被操作对象所属门店是否一致。比如 SA 只能修改自己门店的工单，技师只能操作自己被指派的工单，这个逻辑不能只靠前端隐藏按钮来保证，后端必须严查。我在WorkOrderService里统一封装了get_work_order_for_update(id, operator)，内部先做 role 和 store 的双重校验，所有更新入口都走这个方法。
参数校验层面，Django 的 DRF serializer 帮我挡掉了大部分脏数据。需要注意的点是"列表接口的翻页参数"，如果不对page_size做上限限制，一个恶意请求直接拉走全表几百万条数据，给数据库带来压力。我将page_size限制最大 50，默认 10，超出的直接截断而不是报错，保证接口永远可用。
5.3 敏感信息脱敏与数据导出
运营管理端常常需要导出客户数据、工单明细做分析，但全量导出的话会把车主手机号也带出去，风险大。我在导出逻辑里做了字段级脱敏：手机号默认展示前三位和后四位，中间用星号代替，如需完整号码要走二次审批。这个审批逻辑没有做得很复杂，就是后台一个按钮加负责人签字确认，但一定程度上避免了运营人员随手把全量手机号导走。
管理端看板显示的所有统计数据也经过了权限分层，集团总部能看到所有门店，单店店长只能看本店。这个权限树的实现是给ShopUser表加了一个domain字段，值可能是SHOP或GROUP，统计数据查询时自动根据这个字段追加shop_id过滤条件，从 SQL 层面杜绝越权访问。
6. 部署与运维经验
6.1 后端环境与镜像化部署
后端最终产物是一个 Docker 镜像，基础镜像python:3.11-slim。依赖管理用的poetry，锁定了所有传递依赖的版本，构建时只在需要 dev 依赖的环境安装多余库。生产镜像只拷贝代码和依赖安装目录，不保留源码包，镜像体积控制在 900MB 左右，比常见的 2GB 级 Djang 镜像干净很多。
数据库用 MySQL 8.0 的官方镜像，装了utf8mb4字符集，表引擎 InnoDB。首次部署时我踩过一个坑：默认时区是 UTC，导致 Python 里datetime.now()和数据库当前的now()差了 8 小时，工单时间全部错乱。解决方法是容器启动时统一设置TZ=Asia/Shanghai，并且 Django 的USE_TZ配合全局时区配置，所有入库时间都是东八区时间。
6.2 Nginx 与域名小程序配置
小程序端要求所有wx.request的 URL 必须是 HTTPS 域名，而且域名必须在小程序后台配置为"服务器域名"，否则真机调试直接报错。这意味着本地联调阶段要想办法绕开限制：我做法是在微信开发者工具里勾选"不校验合法域名"，方便用局域网 IP 联调；正式环境一律走 HTTPS。
Nginx 上我做了三件关键配置：一是所有 HTTP 请求 301 跳 HTTTPS；二是/static/路径直接返回文件，不经过 Django；三是给管理端的接口路径加了前缀/api/ops/，方便后续做独立的频率限制和基础认证。Django 的ALLOWED_HOSTS只允许域名白名单，防止恶意域名直接打到服务。
6.3 定时任务与数据备份
系统里有两个定时任务：凌晨两点把昨天的经营数据汇总进t_daily_report表，每天早上九点跑一次保养提醒检查，把当天需要保养的车主筛选出来并推送订阅消息。这两个任务用django-celery-beat做的，Celery 的 worker 和 beat 分别跑两个轻量容器。需要说明的是，如果你不想引入 Celery，Django 自带的manage.py runscript配 cron 也能实现，只是可观测性和灵活性差一些。
数据库备份我用的是mysqldump+ 一个保留策略脚本：每天凌晨四点半备份到/backup目录，保留最近 7 天，每月 1 号单独导出一份全量备份。运维上我强烈建议备份和恢复脚本上下线前都要演练一遍，光有备份不会恢复等于白备份，曾经遇到过一次测试环境误删表，花了半小时才把数据恢复回来，之后的教训就是定期做恢复演练。
7. 常见问题与排查经验
7.1 三端联调时的高频问题
三端项目联调过程中，问题最多的是参数不一。同一个入参，用户端传shop_id，员工端传storeId，管理端传门店ID，虽然语义一样，但三边代码各自维护一套命名，后端就不得不做兼容。后来我强制统一了一个前端api/request.js公共封装，所有端都用同一个请求体构造器，参数名由后端定义的api.js自动生成。联调时反复出现的400和422基本都是玩参数名。
另一个高频问题是手机号登录的code被重复使用。微信的phone_code只能使用一次，开发者工具里很容易因为重新编译触发重复调用。排查问题时一定要先看后端日志里是不是报code been used，如果是，让前端不要每次页面 onLoad 都调登录接口，而是用wx.checkSession判断登录态是否有效，有效就直接拿本地 token 用。
7.2 预约时段冲突的排查思路
预约时段偶尔会出现"明明显示可约，提交却说工位已满"的现象，这是并发场景下预期内的竞态，但次数多了用户就会投诉。排查思路是：先把t_schedule_slot的锁定者和锁定时间查出来，看是不是有预约在确认流程卡住后未释放；再检查管理端的营业时段配置是否和工位的排班一致，比如某个工位当天被临时占用做钣喷，但系统没有同步。
我加的最终保障是"预约自动释放"机制：用户提交预约后如果 15 分钟内没有支付定金或到店，系统会自动把锁定的 slot 释放。小程序端在倒计时结束前会弹窗提醒，超时后预约状态变为已取消。这个机制上线后，预约冲突类投诉直接归零，因为再也不会出现"占着坑不用"的情况。
7.3 小程序审核被拒的常见原因
三端小程序审核时，最容易出问题的不是技术，而是内容和资质。车主端涉及预约和支付，类目要选"汽车服务"，需要提供门店的营业执照和经营许可；员工端涉及技师接单，如果界面上出现"工资""提成"字样，会被归入招聘或人力资源类目，所以我把员工端的相关文案统一改成了"绩效""产值"这种运营向的措辞，避免类目争议。
管理端基本不对外，审核限制相对少，但也要注意不能出现录入客户身份证号、银行卡号的表单，这类敏感信息收集会被微信驳回。我的做法是管理端只做统计展示，不做敏感信息录入，任何需要完整身份信息的操作都走线下或其他合规系统处理。
8. 扩展思路与个人经验
8.1 后续可接入的能力
这套三端系统后续可以往两个方向扩展：一是接入微信的"视频号直播"，直播里展示保养套餐，用户点击链接直达小程序预约页，节假日做活动时非常适合，但需要注意直播挂载需要提前申请权限；二是引入 BI 报表系统，管理端目前的数据看板还是偏轻量的基础统计，如果想做更复杂的留存分析和产值预测，可以考虑集成第三方 BI，API 层把数据表开放出去即可。
另一个值得尝试的是"保养套餐自动续费"。维保业务天然适合会员订阅制，车主买了三次基础保养套餐后，每次到店自动核销，剩余次数在小程序端可见。技术上只需要在订单模块加一个package_balance字段和核销接口，业务价值却很高，能有效提升客户回厂率。如果后续有时间，我打算把这个功能补上，再搭配保养到期提醒，形成完整的售后闭环。
8.2 我踩过最值得分享的坑
最后分享一个对我影响最深的问题：第一次联调员工端扫码接车时，发现二维码怎么扫都识别不了，最后定位到是后端生成的码把 URL 里的?转义成了%3F，导致微信扫出来是个非法链接。解决很简单，生成参数时不要用quote全套转义，而是只编码参数值，但这个问题排查了大半天。建议所有做二维码生成的同学，先在开发者工具里直接用自带的"二维码生成器"对照验证，再上真机。
另外一个小建议：三端项目的接口文档一定要做版本管理，我用的drf-spectacular自动生成 OpenAPI 文档，前端拿到文档可以直接生成 TypeScript 的类型定义。文档不是写给别人看的，是写给自己一个季度后的，接口一多，没有自动文档真的会疯。
这套系统从需求梳理到上线大概用了十周左右，一人负责后端和数据库，一位同事负责三端小程序，这样的分工在资源有限的情况下跑通了整个项目。维保系统业务链路虽长，但只要把状态机设计清楚、排期逻辑做好、三端权限边界捋明白，整体并没有想象中那么复杂。如果你们也在做类似的汽车售后数字化项目，欢迎交流排期和工单流转的实现细节。
