一、问题不是缺一套后台，而是缺一条业务链
贵阳城市配送有一个很现实的场景：客户提供货，调度找外部司机或车队，车辆以4.2米高栏为主，目的地覆盖贵州8个市州和大量县份。业务看着简单，实际会同时冒出很多问题：
所以这套系统的设计起点不是“堆页面”，而是把 客户报价 → 订单 → 外协派车 → 运输节点 → 回单签名 → 客户收款 → 司机应付 → 费用/维保 → 利润 连成闭环。
二、4.2米高栏运费到底怎么报？答案不是单一公式
实际市场通常不是只按吨，也不是只按公里。短途更像“起步价＋超公里价”，跨市整车更像“线路趟价＋油费路桥成本”，轻抛货还要看体积，重货要看合规载重。系统因此没有把报价写死成一种方式，而是支持五种口径：
- 智能推荐：同时比较线路行情、里程成本和目标毛利。
- 整车趟价：适合贵阳到地州市的标准整车线路。
- 公里价：按实际驾驶里程计价，适合临时地址。
- 吨公里：适合密度高、重量接近上限的货物。
- 方公里：适合泡货、轻抛货和体积占用明显的订单。
成本 = 油费 + 过路桥隧 + 司机成本 + 维保轮胎 + 保险折旧
+ 装卸等待 + 返空补偿 + 平台服务费 + 风险准备金
4.2米高栏默认按合规2吨、约15m³校验，但最终必须看行驶证核定载质量。系统会对超重、超方给出警告，而不是用提高价格的方式把超载订单“洗白”。
| 贵阳到目的地 | 参考驾驶里程 | 参考时间 | 报价时重点 |
|---|---|---|---|
| 遵义市 | 145.6 km | 约1.5小时 | 短途跨市，关注是否需要等候和回空 |
| 安顺市 | 96.9 km | 约1.1小时 | 高频短途，适合按趟＋公里成本 |
| 都匀市 | 106.2 km | 约1.2小时 | 可形成日配线路，重点核对装卸时间 |
| 凯里市 | 182.1 km | 约1.8小时 | 线路行情与返空概率同时看 |
| 毕节市 | 191.2 km | 约2.0小时 | 山区路段时效和油耗要留余量 |
| 六盘水市 | 245.6 km | 约2.5小时 | 重货检查载重，轻抛货检查方量 |
| 兴义市 | 307.3 km | 约3.1小时 | 长距离，回程组织和司机工时更重要 |
| 铜仁市 | 321.8 km | 约3.1小时 | 报价必须覆盖空返和长时驾驶成本 |
系统另内置68个县级参考里程，并同时给出高速与国道方案。县级里程属于软数据，大额订单必须用导航复核实际装卸地址，不能拿中心点里程直接拍板。
三、“车找货”和“货找车”必须落到同一张订单上
系统把待调度订单放在货源池，司机或调度可以按车辆状态、载重、体积、常跑区域、准时率和资源评分进行匹配。匹配不是简单按车牌挑一台车，而是先判断这单能不能合规装下，再判断这辆车是否在合适位置、是否可用、外协结算是否留得出利润。
平台接入部分保留了货拉拉、满帮/运满满、快狗打车等适配器位置，但边界必须说清楚：正式自动询价、下单和轨迹同步需要平台企业授权和真实凭证。没有官方凭证时，系统只显示“待授权”，不会伪造已经接通的状态。
四、应收和应付分开，利润才是真的
很多小物流团队把“客户付款”和“司机结算”放在一个Excel里，最后很难回答三个问题：这单客户还欠多少？司机还欠多少？这单到底赚了多少？黔城快配把三条账拆开：
- 客户应收：货到付款、月结、现结、预付、回单结算和代收货款，支持部分收款、逾期和争议。
- 司机/外协应付：按订单外协结算价登记，支持银行、微信、支付宝、现金和预支抵扣，禁止超过未付金额。
- 履约成本：自有车归集油费、过路费、停车、维保等实际费用；外协订单优先使用结算价，避免重复扣成本。
五、司机不是“后台用户”，而是手机上的履约终端
司机大多数时间在路上，不可能抱着电脑操作。手机端只保留和司机有关的内容：可接货源、我的任务、车辆状态、提货/在途/送达、异常上报、定位、回单和本人结算。管理员看到的客户报价、利润、费用和其他车辆不会返回给司机。
司机点击“上报当前位置”后，浏览器获取经纬度，服务端校验位置范围和定位精度，保存定位时间，并按当前位置到目的地城市中心点估算剩余里程和ETA。它不是地图导航的替代品，但足够让调度知道车走到哪里、大概什么时候到。
六、回单、签名、权限和AI：每一层都要有边界
签收单、装卸照片和货损照片支持JPEG/PNG/WebP，单张不超过5MB。服务端不只看扩展名，还会检查图片文件魔数；电子签名用Canvas手写，空白签名不允许提交。附件读取按订单归属判断，司机不能打开其他车辆订单的图片。
权限也不是“前端把菜单藏起来”这么简单。管理员、调度员、财务和司机四种角色在服务端分别限制接口：司机只能访问绑定车辆、本人订单和本人附件；财务不能进入用户管理；调度员不能修改系统设置。最后一位启用管理员不能被停用，避免系统失去管理入口。
AI在这里不做“自动替换老板”的事。规则风险模型负责发现待调度、超载/超方、维保临期、油费异常和亏损线路；大模型只生成运营摘要，报价、派车和维保动作必须人工确认后才写入业务数据。客户名称和车牌在发送给大模型前会脱敏。
七、代码审计不是跑一遍页面，而是确认“谁来操作、数据会去哪”
这轮交付做了服务端权限、上传校验、GPS归属、司机结算、附件备份恢复和移动端回归。最终验证包括：
| 检查项 | 结果 | 说明 |
|---|---|---|
| Node单元/API测试 | 24/24通过 | 登录、报价、应收、附件、GPS、RBAC、结算、备份恢复 |
| Playwright全页面 | 19页通过 | 管理员全导航和核心业务流程 |
| 司机手机角色 | 通过 | 仅2个角色入口，1台绑定车辆，报价/费用隐藏 |
| 响应式 | 通过 | 1440、1024、768、390四档无页面横向滚动 |
| 安全边界 | 通过 | 源码、配置、数据、内部文档不能直接访问 |
| npm audit | 0漏洞 | 运行时零第三方Node依赖 |
云端运行在独立低权限账号下，systemd启用NoNewPrivileges、ProtectSystem和PrivateTmp；每日02:15备份store、auth和uploads，保留14天。部署脚本会先备份线上代码和数据，再上传新版本，最后验证HTTPS、健康接口和登录。
八、这单交付真正完成了什么
它不再是一个只有图表的后台，而是一套可以从一台车开始使用的工作台：调度创建订单、匹配车辆、司机手机接单和上报位置、回单签名、财务收款和结算、车辆维保和成本归集、老板看利润和风险。后续新增车辆、外协资源和司机账号，不需要重做页面。
仍然需要客户配合的事情也要说清楚：真实线路成交价、油费、过路费、司机工资和维保票据要用实际数据校准；货拉拉真实API需要企业凭证和官方授权；高并发多仓要进入数据库阶段。这些是下一阶段的工程边界，不应被“系统上线”四个字盖过去。