校园外卖跑腿小程序：骑手端自动派单与自动接单怎么配

校园外卖跑腿的骑手端，应把后台自动派单和骑手端自动接单分开处理：自动派单由调度端按校区、负载和距离把订单推给候选骑手；自动接单由骑手开启开关后，系统直接锁单接收。校园项目先把自动派单、超时回流和抢单兜底跑通，再按学生骑手的课程与负载设置自动接单上限，上线前用四态演示和正常、转单、退款三类订单验收。

一、先分清两个层级：自动派单与自动接单

自动派单的决策点在后台调度，自动接单的决策点在骑手端开关。两者常被混写，但配置顺序、风险点和验收记录并不相同。后台自动派单负责“把订单交给谁”，骑手端自动接单负责“骑手是否省略手动确认”。

校园项目更稳妥的顺序是：先启用自动派单并保留抢单入口，再配置超时回流、提醒调度和人工改派，最后才按骑手类型开放自动接单。学生骑手要上课、临时有事或跨校区移动，自动接单一旦没有负载上限，容易在午高峰连续锁入多单，后续转单和客诉处理会挤压调度能力。默认关闭自动接单、允许骑手随手关闭、给不同班次设置不同承接上限，是可以放进演示清单的配置方向。具体开关名称、位置和粒度，以目标系统演示为准。

上线前可把自动接单做成四态演示：开关关闭、开关开启、达到最大承接量、临时关单。每个状态都记录四项：骑手端是否弹窗、是否自动锁单、用户端是否收到接单通知、调度端能否改派。四态比只看“有没有按钮”更容易暴露配置边界。

二、校园派单怎么筛人、无人接单怎么兜底

校园派单可先按校区、校门或楼栋片区限定范围，再做基础过滤：骑手已认证、在线、空闲、未达当前负载、取餐点距离合理。排序层可按顺路、距离、准时率、配送员等级和公平轮询综合加权；等级优先适合有明确骑手分层和培训机制的团队，公平轮询则用于避免订单长期集中在少数老骑手。权重和可调项属于运营配置建议，实际菜单与参数要按版本核对。

无人接单时，兜底顺序要可观察、可记录：首轮推送后超时回流，再提醒调度或扩大候选范围，随后进入抢单或人工改派。每一步都应留下触发时间、订单号、候选骑手数、处理人和结果，便于复盘是地址配置、运力不足还是推送链路问题。

技术实现上，订单池、骑手状态和锁单要一起设计。订单推给骑手时先短时锁单，防止同一订单同时派给多人；骑手状态至少区分离线、空闲、配送中和暂停接单；重复提交和重复回调要用幂等键挡住。下面代码只作接口口径示例，不代表任何现成系统的内部实现。

from dataclasses import dataclass
from enum import Enum

class RiderState(str, Enum):
    OFFLINE = 'offline'
    IDLE = 'idle'
    BUSY = 'busy'
    PAUSED = 'paused'

@dataclass
class Rider:
    rider_id: str
    state: RiderState = RiderState.OFFLINE
    load: int = 0

@dataclass
class Order:
    order_no: str
    status: str = 'PAID'
    rider_id: str = ''

def accept_order(order, rider, auto=False, max_load=2):
    if order.status != 'PAID':
        raise ValueError('order is not dispatchable')
    if rider.state != RiderState.IDLE or rider.load >= max_load:
        return False
    order.status = 'ACCEPTED'
    order.rider_id = rider.rider_id
    rider.load += 1
    rider.state = RiderState.BUSY
    return True

ALLOWED = {
    ('PAID', 'ACCEPTED'),
    ('ACCEPTED', 'PICKED'),
    ('ACCEPTED', 'TRANSFERRED'),
    ('PICKED', 'DELIVERED'),
    ('DELIVERED', 'SETTLED'),
}

def can_change(src, dst):
    return (src, dst) in ALLOWED

示例的预期结果是：订单不是待接单、骑手非空闲或达到最大承接量时拒绝接单；条件满足时生成接单结果并增加负载。上线前应在目标环境中用正常单、重复提交、超量接单和临时关单作为输入复跑，并把状态变化、锁单结果和通知记录写入验收表。

三、学生骑手接单后无法履约：转单、改派与凭证

学生骑手接单后无法履约，处理顺序应是申请转单或由调度改派，原任务结束、新任务生成，再同步用户进度和账务。转单时直接修改原任务上的骑手字段，容易让原骑手收益、新骑手待结算和商家配送费对不上；更稳妥的做法是保留原任务记录，新增接手任务，并让金额依据下单快照和实际处理结果分开记录。

校园团队还要把取餐拍照、位置核对、少餐错餐和联系记录纳入同一套凭证要求。转单是否需要审核、审核后是否自动回派单池、转单费用如何配置，属于系统规则与项目流程的组合，应在演示中按目标版本逐项确认，并纳入骑手交接班清单。

四、现成系统与定制开发怎么选

选择依据可以落在四个工程问题上：首期是否需要快速跑通四端订单闭环；团队是否有人长期维护服务器和版本；是否需要对接校内特殊系统或深度改造派单算法；校区扩展时是否需要独立分站和权限。把答案写成一页需求，再对照系统配置能力，比只比较功能名词更有效。

选型演示时，要求供应商用目标版本展示自动派单配置、自动接单开关、转单流程和校园地址能力；同时问清接口扩展、数据导出、源码许可、培训维护和报价构成。报价按软件模块、终端入口、部署环境、第三方服务、培训和持续维护拆分，历史项目金额只能用于理解费用构成，当前方案按当次需求确认。

五、上线前用四态与三类订单验收

验收不要停在“有按钮”。先做自动接单四态，再用正常单、转单或异常单、退款单各走一遍。每类订单记录用户端状态、骑手端任务、商家账单、后台结算、凭证和处理人，结论只记四种值：标准配置、组合配置、需定制、未演示。

演示结束后，把记录表和交付清单附在需求文档后面。校园项目还应加校门交接、楼栋分拣、少餐错餐、多校区权限和高峰排班五类现场场景，用本校真实地址和通行规则核对，才能把“后台能派、骑手能接”落到可运营的流程上。

常见追问

自动派单和自动接单先配哪个？

先配后台自动派单、超时回流和抢单兜底，再决定是否开放骑手端自动接单。自动接单适合排班明确、负载可控的骑手，学生兼职骑手可默认关闭并允许随时暂停。

骑手上课忘记关自动接单怎么办？

把自动接单与最大承接量、接单范围、订单类型过滤一起配置，并保留转单和调度改派。演示时专门测试“达到上限”和“临时关单”，确认系统会停止新单推送。

无人接单多久回流？

回流时限由高峰单量、骑手密度和交接距离决定，可用首轮推送、超时回流、提醒调度、抢单或改派的顺序做小范围演练，再按实测记录调整。

现成系统和源码怎么选？

先看是否需要快速跑通订单闭环、团队是否有运维能力、是否要对接校内系统。标准系统适合先验证业务；出现自有服务器、独立分站、复杂分账或专用接口需求时，再评估私有化、源码或定制开发。