校园外卖一套小程序能否起步：订单接力与批量操作验收

校园创业做外卖平台，一套小程序系统能起步，但只解决工具层。真正决定能否开跑的是：同一订单号能在用户、商家、骑手、平台后台四端走通用户下单、商家出餐、校门交接、楼栋分拣、校内送达和退款结算；任一环节靠微信群和表格补，系统就只完成了下单。若项目涉及校门交接、楼栋分拣或多校区，选型时把系统放进真实校区做一次订单演练，再判断配置边界与扩展空间。

一、先看三个门槛：四端闭环、末端履约、账务权限

一套系统是否足以支撑起步，不看功能条数，而看它能否让一笔订单的责任、状态和金额持续对应。三个门槛缺一不可：四端能围绕同一订单协作；校门到宿舍的交接能被系统记录；退款、结算和角色权限能够追溯。

二、一笔订单走完五段接力：每段都要有字段和凭证

校园外卖区别于普通同城外卖的地方，主要在末端履约。把流程拆成商家出餐、校外运输、校门交接核单、楼栋分拣、校内送达五段，每段明确当前责任人、下一站、异常接续人，系统验收才有具体对象。

这张表的关键不是字段越多越好，而是同一订单号贯穿始终。用户看到的进度、站点看到的分拣清单、商家看到的结算行，都应能凭订单号反查。金额以下单时的快照为准，配送途中改价只能追加费用行并记录原因，否则退款时无法解释该退多少。

三、用服务端状态机约束跨段流转

状态不能由前端按钮直接决定。用户点击送达、骑手点击转单、站点点击批量中转，都应提交“动作意图”，由服务端校验当前状态是否允许进入目标状态。下面是一个只依赖标准库的设计示例，用于统一评审口径，不代表任何产品的内部实现。

ALLOWED = {
    ('CREATED', 'PAID'): '支付',
    ('PAID', 'ACCEPTED'): '商家接单',
    ('ACCEPTED', 'OUT_FOR_DELIVERY'): '出餐并交给校外骑手',
    ('OUT_FOR_DELIVERY', 'AT_GATE'): '到达校门交接点',
    ('AT_GATE', 'SORTING'): '核单后进入楼栋分拣',
    ('SORTING', 'DELIVERING'): '校内骑手接力',
    ('DELIVERING', 'DELIVERED'): '送达并通知',
    ('DELIVERED', 'SETTLED'): '生成结算',
    ('PAID', 'REFUNDING'): '支付后取消',
    ('DELIVERED', 'REFUNDING'): '送达后售后',
    ('REFUNDING', 'REFUNDED'): '退款完成',
}

def can_transition(src: str, dst: str) -> bool:
    return (src, dst) in ALLOWED

def transfer(src: str, dst: str) -> str:
    if not can_transition(src, dst):
        raise ValueError(f'illegal transition: {src}->{dst}')
    return dst

# 预期：transfer('CREATED', 'PAID') 返回 'PAID'；
# transfer('PAID', 'DELIVERED') 抛出 ValueError。

验证时不要只点正常流程。把支付后取消、配送中取消、部分退款、结算后退款各走一遍，观察退款记录是否关联原订单、商家应结与骑手收益是否同步调整。若系统只能改状态而不能解释金额变化，账务验收仍未通过。

四、批量中转和送达：部分成功必须显式返回

高峰收餐时，批量操作能减少重复点击，但不能把“选中订单”等同于“全部成功”。一批订单里可能有一单少餐、一单状态不符、一单码不清晰。正确做法是逐单校验，返回成功清单、跳过清单和原因，现场人员才能继续核单。

def build_batch_result(order_states, target_status, transition):
    applied = []
    skipped = []
    for order_no, src in order_states.items():
        try:
            transition(src, target_status)
            applied.append(order_no)
        except ValueError as exc:
            skipped.append({'order_no': order_no, 'reason': str(exc)})
    return {'applied': applied, 'skipped': skipped}

# 示例输入：{'A1001': 'AT_GATE', 'A1002': 'SORTING', 'A1003': 'AT_GATE'}，
# 目标状态 'DELIVERED'。预期 A1001、A1003 进入 applied，A1002 进入 skipped。

批量通知也应按“已确认送达或到达指定位置”的订单发送，通知内容写清取餐点与当前进度。少餐、错餐和无人接收单独标记，不要整批成功或整批失败。设备和码制先在低峰演练，再用于高峰。

五、权限、退款与对账的最小验收

权限不能靠前端隐藏按钮。商家账号应绑定门店，骑手只看本人任务，校区管理员只看所属校区或站点，财务按结算范围查看。列表、详情和导出应使用同一套数据范围，否则会出现页面看不到、导出却能拿到的情况。

账务验收用三类订单：正常单、部分退款单、结算后退款单。每类记录用户实付、商家应结、骑手收益、平台抽成和退款冲回，检查能否还原成同一组金额关系。权限验收用不同角色交叉访问，记录请求账号、资源归属、返回结果和导出列。

六、把演示结果写成记录，再决定是否扩商家和校区

上线前至少演练正常单、转单单、退款单、批量部分完成和越权访问。每项记录订单号、场景、四端状态、金额变化、责任人、凭证和结论。结论建议只分四类：标准配置、组合配置、需定制、未演示。这样技术结果能回到经营判断：系统能否接住异常，财务能否还原金额，校区权限是否真正隔离。

准备启动时，带本校真实校门、楼栋和取餐点做一次完整演示，同时准备一笔正常单、一笔退款单和一批含异常单的分拣任务。演示通过后再扩大商家和校区，比先买系统再补流程更稳妥。

常见问题

一套系统是否就不用运营团队？

不是。系统承接四端订单、状态、批量操作和账务记录，上线仍需主体资料、商家商品、骑手班次、支付配置、客服处理和试运营安排。系统减少重复操作，但不能替代现场交接和人员组织。

校门到宿舍，系统具体能帮什么？

可把订单按校区、楼栋和批次归组，记录校门核单、分拣、校内接力和送达通知，并让退款与结算关联原订单。本校是否允许入校、交接点设在哪里，要按学校通行规定和现场条件确认。

预算应该怎么列？

按软件模块、部署环境、第三方服务、培训维护和随单支出分列，注明一次性费用与续费项目。历史成交记录只对应具体配置和时间，当前报价按实际需求与交付范围确认。

多校区怎么核对？

用两个校区演示商家归属、骑手支援、退款账单和总部汇总，并核对导出列是否随角色变化。只看“支持多校区”不够，关键是权限、订单归属和结算范围能否隔离。