代驾小程序系统开发方案，先把计价和派单写清

「网上有份代驾的小程序开发方案示例，照着改改能不能用？」前阵子一位客户把文档发过来，二十来页，页面截图很全，翻到计价那节只有一行按里程计费。我们问他起步价含多少公里和夜间怎么加，又问司机等客人的时间算不算钱，文档里都没写。这几行不补，后面开发出来的东西没法上线收钱。

代驾小程序系统开发方案，页面长什么样反而是最后才定的事。计价规则和派单方式，司机端节点以及里程记录，这四块定下来，方案才算能交给开发。这篇按这个顺序讲，顺带说说**版不建议做的几处。文中金额均为深圳市场公开参考区间，并非本站报价。

一、网上翻到的小程序开发方案示例，缺了什么

搜小程序开发方案，能翻到不少通用模板，开发微信小程序示例里也常见商城和点餐两种。这类文档拿来学结构可以，直接当代驾的业务方案会漏东西。代驾的单子有两头，客人端下单和司机端履约，中间还夹着一个按实际里程算钱的过程，通用模板通常只画了客人端。

把开发小程序示例里的通用结构当清单用，逐项对照补业务字段，比整份照抄稳妥。补完这张表，方案文档才算有了能开发的部分。

二、计价：起步价、里程、时长、夜间加价

代驾的计价表是整套方案里最该先签字的一页。它决定了订单金额和司机收入，也定了平台抽成，后面所有表都围着它建。深圳市场公开参考区间，起步价多在 39 元上下含 10 公里，超出部分按每公里 3 到 5 元计，夜间 22 点到次日 6 点加收，等待超过 10 分钟按每分钟 1 元计，以上数字均为深圳市场公开参考区间，并非本站报价，各家要按自己的司机成本调。

「跨时段按起点算」这条建议写死在方案里。行程从二十一点五十开始，开到二十二点二十，按起点和按终点算出来是两个价，不写清楚，司机和客人各有一套算法。计价表定稿后，开发小程序方案里的每一处金额展示都得跟它对齐，包括预估价和行程中实时价，还有结束后的最终价，三个数用的是同一套规则。

三、派单：抢单还是系统派

两种模式没有**好坏，看司机规模和运营方式。抢单实现简单，把订单推给附近司机，谁先点算谁的，适合起步阶段司机不多、想让单子尽快有人接的项目。系统派单要算距离和司机评分，还要看当前状态，规则复杂一些，好处是远单和差单也有人接，客人体验更稳。

我们的建议是**版做抢单，加一条兜底，30 秒无人响应就扩大推送半径，再 30 秒转人工指派。不建议一上来就做智能派单，权重规则得靠真实单量调，没数据的时候调出来的权重和拍脑袋差不多。

四、司机端四个节点

司机端页面可以做得简单，四个动作必须留痕，它们同时是计时的依据：

• 接单，记录接单时间和位置，超时未响应按上节的兜底规则回池；
• 到达，司机点到达后开始算免费等待时长，超过十分钟进等待费；
• 开始行程，这一下打开轨迹记录，也是里程计费的起点；
• 结束行程，关掉轨迹，生成最终账单推给客人确认。

「开始行程」这一步不建议省略。少了它，司机接单后到客人上车之间的移动会被算进行程里程，客人看到金额会比预期高，投诉就来了。四个节点各写一条测试用例，上线前逐个点一遍。

五、定位与轨迹：里程怎么记才不扯皮

里程是代驾计价的根，也是纠纷最多的地方。用直线距离算，客人不认；用导航路径算，司机说绕路，两边都觉得亏。可行做法是行程中按固定间隔采点，比如每 5 秒或每 10 米记一个位置，结束行程后把轨迹点串起来算里程，同时把轨迹留在订单里，客人有疑问可以调出来看。

采点频率别设得太密。2 秒一次，一单 40 分钟就是上千个点，存储和查询都吃力，5 到 10 秒一次够用。隧道和高架下 GPS 会漂，轨迹出现跳跃点要做平滑处理，不然里程会突然多出几百米。这些细节在开发小程序方案里通常一句话带过，实际要写进技术设计，不然上线后每单都要人工核对。

六、深圳代驾的夜间时段和停车场场景

深圳夜间代驾的单子集中在二十一点到凌晨两点，餐饮聚集区和商圈地库是高频起点。地库里 GPS 没信号，司机到达这一步经常点不了，客人也看不到司机在哪。处理办法是在方案里加一个「地库模式」，允许司机在信号弱的地方手动确认到达，同时把地库入口作为推荐集合点写进下单页。

夜间加价的时段也按本地作息划，二十二点到次日六点是常见口径，节假日另设一档。深圳这边跨城单不少，去东莞或惠州的行程，回程空驶要不要计入，建议**版先不支持跨城，把范围锁在市内，等结算规则跑顺再放开。

七、订单与结算：司机提现周期

平台抽成比例和结算周期，还有提现门槛，这三件事要在方案里定清楚，它们影响司机端页面和后台两张表。常见做法是订单完成后进入可提现余额，每周结算一次，提现申请一到三个工作日到账。微信支付提现有单笔和单日限额，按当季的商户平台规则配，别照抄别家文档里的旧数值。

退款和差错也要留口子。客人对里程有异议，后台要能改单并记录改动人和原因，改单后司机结算金额跟着重算。这张改动记录表**版就该有，等到出现纠纷再补，历史单已经说不清了。

八、深圳代驾起步阶段，这三件事不建议做

• 智能派单，没有真实单量之前，权重调不出意义；
• 跨城回程计价，规则复杂且单量小，先把市内跑顺；
• 司机评价体系，起步阶段司机少，评分样本不足，先做人工回访。

九、方案文档该写到什么程度

一份能直接交给开发的微信小程序开发方案，至少要有这几样，少一样，开发过程就会停下来等人拍板：

• 计价表，含每一项口径和跨时段边界，业务方签字；
• 订单状态图，把四个节点和异常分支画全；
• 字段清单，起点终点、轨迹点、账单明细各存什么；
• 结算规则，抽成、周期、提现限额、改单留痕；
• 验收用例，正常单、超时单、改址单、退款单各一条。

文档写到这个颗粒度，报价才谈得准。只给几张页面截图，开发方只能按自己的理解估，估低了中途加价，估高了客人觉得贵。

十、把计价表定下来，再谈开发

回开头那位客户，那份二十页的示例最后只留下了页面结构，计价和派单两节重写了一遍。做代驾小程序系统开发方案，先把起步价含几公里和超出怎么算，再加夜间按哪头算，这三条写出来，签字，再往下列模块，后面的开发会顺很多。规则定得越早，返工越少，这条在代驾这类按里程收钱的业务上尤其明显。

技术栈和页面结构怎么定，可以参考。开工前该把哪些事做完，那篇列得比较全。如需进一步沟通，可直接致电 13928418795。