项目速览
- 行业：本地生活服务（同城即时配送）
- 交付内容：用户端小程序 + 骑手端 App + 运营管理后台 + 结算对账模块
- 周期：10 周（需求 2 周 / 开发 6 周 / 试点与上线 2 周）
- 团队：项目经理 1、后端 2、前端 1、移动端 1、测试 1
- 技术栈：uni-app（小程序与 App 同源）、PHP + MySQL、Redis 队列、高德地图 SDK、OSS 存储
背景：业务先跑起来了，系统没跟上
客户是最早在本地做即时配送的团队之一。起步阶段很朴素：客户在微信群里发需求，调度员在群里喊单，骑手抢到后自己算价格，晚上用表格对账。这套方式在日均 30 单以内是能运转的，因为调度员脑子里记得住每一个骑手的位置和状态。
接到我们时，日均已经到 400 单以上，问题集中爆发：漏单（消息被刷过去）、超时（没人知道哪单卡住了）、结算争议（骑手说送了、客户说没收到、调度员记不清）、以及新骑手上手慢——老骑手靠经验，新人靠猜。
客户的原话是：「我不要一个看着很酷的系统，我要一个能让我不用每天盯到凌晨一点的东西。」这句话成了整个项目的验收基调。
目标与验收口径
- 订单全流程线上化：下单 → 计价 → 派单 → 取件 → 送达 → 评价，每一步都有可查的状态与时间戳
- 派单规则可配置：按距离、评分、当前在手单量、是否加急决定优先级，超时自动改派
- 结算可对账：平台抽成、骑手收入、提现审核、异常单处理，账目与订单流水可逐笔核对
- 可运营：优惠券、加急费、时段加价、会员免配送费，都能在后台配，不需要改代码
方案：四条主线
① 下单与计价
计价不是「一个配送费」那么简单：距离分段、重量分段、时段加价（夜间与雨天）、加急费、会员减免、优惠券叠加顺序，六种规则会互相影响。我们把它做成「规则表 + 计算链路」：后台按业务优先级排序规则，每次报价都会记录命中了哪几条规则，出问题时能复盘到具体一条。
② 派单：抢单 + 指派混合
纯抢单的问题是好单被抢、远单没人接；纯指派的问题是骑手觉得不公平。最终采用混合模式：订单进入「派单池」后，先给满足条件的骑手推送，30 秒无人接则按评分与在手单量指派，再超时自动改派并把该单标记为「调度介入」，运营在后台能看到是哪一步掉链子。
③ 轨迹与到达确认
取件与送达都要求拍照或验证码确认，位置按 30 秒节流上报、断网时本地缓存补偿上传。这一层看起来不起眼，但它是所有纠纷的裁判依据——上线后客服的沟通成本明显下降，因为「看记录」比「各说各话」快。
④ 结算与对账
每单生成两条流水：骑手收入（含补贴、扣罚）与平台收入（抽成）。提现走审核流，审核通过才出账。对账表把「订单金额 / 平台抽成 / 骑手收入 / 优惠券成本 / 实际到账」五列并排放，任何一个数字对不上都能点进去看原始订单。
技术实现中的三个硬骨头
- 弱网幂等：配送场景网络很差，用户连点两下很容易生成两个订单。所有写操作带客户端生成的幂等键，服务端以键做唯一约束，重复提交返回同一结果而不是新建一条。
- 位置上报节流与补传：原始方案每 5 秒上报一次，实测在 200 名骑手下数据库写入压力过大。改为 30 秒节流 + 距离阈值触发 + 断网缓存队列，写入量降了一个数量级，轨迹仍然连续。
- 结算流水与订单的最终一致：跨表更新用「流水先记账、余额后更新、对账任务兜底」的顺序，避免出现「订单已完成但骑手没收到钱」这类不可解释的状态。
交付过程
- 第 1—2 周：跟车观察 3 天，把调度员的真实动作拆成 26 个操作，再合并成 11 个系统动作。很多「需求」在这一步被砍掉了。
- 第 3—6 周：后端与小程序并行，每两周给客户一个可点的演示版本；计价规则与派单规则在演示环境用历史订单回放验证。
- 第 7—8 周：骑手 App 小范围试点，10 名骑手并行使用一周，收集到 40 余条反馈，主要集中在接单提示音与地图导航跳转。
- 第 9—10 周：全量切换，旧微信群保留一周作为兜底，之后关闭。
结果
派单与对账从人工转为规则驱动：订单不再依赖调度员记忆，异常单在后台一眼可见，对账从「每晚两小时」变成「抽查即可」。具体单量与利润数据由客户掌握，本站不代为披露。
如果重做，我们会改什么
一是把「骑手收入解释」做得更早：上线初期骑手最常问的是「这单为什么只有 12 块」，如果第一版就有收入明细弹层（含补贴与扣罚逐项），培训期会短很多。二是试点范围可以再小一点、时间再长一点——10 名骑手一周的反馈量已经足够，但我们仍低估了提示音这类细节对使用意愿的影响。
发表回复