一、项目背景

我们做同城即时配送的第一版，用的是纯自营运力。三十多个全职骑手，平时单量平稳够用，一到午高峰和恶劣天气就崩。最夸张的一次，午市两个小时涌进来四千多单，运力的承接能力只有一半，剩下的单子挤在队列里，骑手手机上同时挂着十几单，用户端显示配送超时，投诉量比正常送达量还高。那次事故之后，我们被业务方追着问了快一周才把积压清掉。

我们当时想再加自营骑手，但招聘和管理的成本吃不消，而且峰值就那几个小时，养全职运力平时又闲置，算下来每单成本反而更高。后来决定把众包运力接进来，平时用自营保底，峰值靠众包弹性顶上去。这个决定其实也纠结了一阵，因为众包意味着服务质量不可控，我们要在弹性和体验之间找平衡。

二、落地场景

这个平台服务的是商超便利、餐饮外卖、还有一部分跑腿代买，配送半径在三到五公里。落地场景分三块。一是运力接入，众包骑手要过实名和资质审核，接进来之后进运力池，平台能看到每个人的实时位置和接单状态。二是派单，订单进来之后系统根据骑手位置、负载、预计送达时间算出最优派单，不是简单就近扔给最近的人。三是结算，骑手每完成一单按计价规则结算，高峰期有动态溢价，平台抽成和骑手收入要算清楚。

动态计价这块我们一开始很保守，怕溢价太高用户骂。后来发现，不溢价的后果是运力争抢爆单区域的单、冷门区域的单没人接，反而更不公平。所以我们把溢价做成了区域和时间两个维度的函数，爆单区域多补一点吸引运力过去，冷门区域也靠溢价把闲置骑手拉过来，两边体验都改善。

三、关键技术挑战与解决思路

派单算法是最核心的一块。我们早期用最近距离派单，结果骑手 A 明明离得近但已经挂了八单，还是把新单派给他，他接了送不过来，整条链路超时。后来改成位置加负载加权，每个骑手有个实时可承接分数，派单时分数高的优先，同时给预计送达时间留余量。我们还加了一个兜底，如果某个骑手挂单数超过阈值，新单一律不再派给他，强制把负载摊开。

众包运力的质量是个头疼事。有的骑手接了单不送、有的送错了地址。我们做了两件事，一是给每个骑手建履约信用分，超时和取消率高的降权甚至暂停接单；二是关键节点拍照回传，取货和送达各拍一张，出了纠纷有凭证。信用分不是一成不变的，每周滚动更新，表现好的骑手权重慢慢涨回来，避免一刀切误伤。

运力池的扩缩也要动态。我们用实时在途订单数和空闲运力数的比值做扩缩信号，比值高说明运力紧张，就提高溢价吸引众包接单；比值低就降溢价。这个信号我们调了几轮阈值，一开始太灵敏，价格波动把用户吓跑，后来把时间窗口拉长到十分钟、又加了平滑，才稳下来。我们还设了运力下限，低于这个数即使不溢价也要保底派单，防止冷门时段没人接单。

结算这块还有个细节，众包骑手的劳务报酬要走独立的清分通道，和平台抽成分开算，税务口径不一样，我们专门对接了灵活用工的结算服务，避免把众包收入混进普通商户结算引发合规问题。高峰期溢价部分也单独列账，骑手能看到每一单的溢价明细，争议少了很多。

四、效果数据

接众包之后，订单准时率从七成出头提到了九成三，平均配送时长降了大概四分钟。运力利用率，也就是骑手在线时长里有单跑的比例，从五成提到七成二，空驶率明显下降。骑手侧我们看了下，众包骑手月均完成单量比纯自营时高，因为高峰期溢价让他们愿意出来跑，平台抽成也跟着涨，是件多方共赢的事。

案例片段（已脱敏）： 派单加权的一段配置（json 示意）： {"dispatch_weight": {"distance": 0.4, "load": 0.35, "eta_margin": 0.25}, "eta_margin_sec": 300, "max_concurrent_orders": 5, "credit_weight": 0.15} 某个午高峰日志：在途单 4120，空闲运力 980，比值 4.2，系统触发溢价 1.4 倍，十五分钟内空闲运力回升到 1900，比值回落到 2.1，未派单积压从 1800 单降到 300 单。同日信用分兜底拦截了 23 名高取消率骑手的新单派发。

五、可复用经验总结

派单这事儿我后来想，距离近不等于该派，骑手挂了几单才是关键变量，我们最早就是栽在只看距离上。把负载和预计送达余量一起算进去，链路才顺。

动态计价别一开始就怕用户骂而不敢溢。我们保守了快一个月，结果是冷门区域没人接单、爆单区域骑手爆仓，比溢价更伤体验。把价格当成运力调度信号用，反而两边都能照顾到。

运力信用分一定要建，而且要让骑手看得到。我们一开始信用分是后台黑盒，骑手不 care，后来把信用分和接单优先级挂钩、前端也能看到，异常履约立刻下来了。

扩缩信号别调太灵敏，我们那次价格波动把用户吓跑的教训挺深刻，加时间窗口和平滑之后才稳，这种参数上线前最好拿历史单量回测几轮再放。