搭建同城跑腿平台：小程序开发前期的四端闭环、结算与验收清单

搭建同城跑腿平台，小程序开发前期可按“模式与范围—主体与资质—四端需求—接口与结算—运营与法务—验收”准备。先把自营或平台撮合、服务区域、是否校园封闭场景和一页计价规则定下来，再把用户、骑手、商家发单、平台后台四端写成同一订单号贯穿的最小闭环，并用正常单、转单、退款单各走一遍，最后才谈SaaS、源码或定制。这个顺序决定了主体资料、接口清单、结算口径和验收用例能否对应同一套业务。

一、先定模式和范围，再形成可交付的准备清单

经营模式会直接影响商家入驻、收款结算和小程序类目。自营模式由平台自己组织骑手履约，平台撮合模式还涉及商家发单、骑手入驻、抽成与多方结算。服务范围要写到城市、片区、配送半径、是否跨区，以及是否为校园封闭场景；品类要区分帮送、帮买、帮取、代取快递、餐饮外卖等，因为餐饮、快递等业务对应的资料核对项不同。

这张表的价值在于把“准备什么”变成可检查的交付物。资质部分需要按实际经营模式逐项确认，不能把某一种业务的条件直接套到所有项目；服务商可以提供上线指导或代办服务，审批归属和结果仍按主管部门要求处理。

二、四端最小闭环要落到字段和状态机

四端需求不要先堆营销功能。用户端要能选服务、填取送地址、看费用明细并支付；骑手端要能接单或抢单、取件拍照、更新配送状态、查看收益；商家发单端要能录单、批量发单、查看配送和对账；平台后台要能调度改派、配置区域价格、处理退款和结算。四端围绕同一订单号工作，订单是唯一主线。

订单状态适合由服务端状态机约束，页面只提交操作意图。下面的字典是设计示例，用于说明哪些流转需要被允许，并不代表任何现成系统的内部实现。

ALLOWED = {
    'CREATED': {'PAID', 'CANCELLED'},
    'PAID': {'ACCEPTED', 'REFUNDING'},
    'ACCEPTED': {'PICKED', 'TRANSFERRED', 'REFUNDING'},
    'PICKED': {'DELIVERED', 'TRANSFERRED', 'REFUNDING'},
    'TRANSFERRED': {'ACCEPTED', 'DELIVERED', 'REFUNDING'},
    'DELIVERED': {'SETTLED', 'REFUNDING'},
    'REFUNDING': {'REFUNDED', 'PAID'},
    'REFUNDED': set(),
    'SETTLED': set(),
    'CANCELLED': set(),
}

def can_transfer(src, dst):
    return dst in ALLOWED.get(src, set())

并发入口还要有幂等设计。订单表对提交幂等键建唯一约束，事件表对订单号、事件类型和事件键建联合唯一约束，重复点击送达或支付回调重复到达时只落一条有效记录。

CREATE TABLE order_event (
  id BIGINT PRIMARY KEY,
  order_no VARCHAR(32) NOT NULL,
  event_type VARCHAR(16) NOT NULL,
  event_key VARCHAR(64) NOT NULL,
  created_at DATETIME NOT NULL,
  UNIQUE KEY uk_order_event (order_no, event_type, event_key)
);

三、计价、转单、退款：用金额快照和对账公式约束

计价页要把起步范围、距离、重量或件数、区域、时段、附加服务和优惠承担拆开展示。生产环境适合使用定点小数，下面的函数只表达“拆项返回”这一设计口径。

def quote(base, distance_fee, weight_fee, night_fee, coupon):
    subtotal = round(base + distance_fee + weight_fee + night_fee, 2)
    discount = round(min(coupon, subtotal), 2)
    return {
        'subtotal': subtotal,
        'discount': discount,
        'payable': round(subtotal - discount, 2),
    }

转单不能只修改订单行上的骑手字段。更稳妥的设计是结束原骑手任务、新增新骑手任务，并写入状态流水；金额以用户下单时的快照为准，配送途中改价只能追加费用行并写明原因。对账口径可统一为：用户实付减退款，等于商家应结、骑手收益、平台抽成和优惠承担之和。任何退款单都应能按这个等式还原。

常见异常可以用三类用例提前暴露：转单后后台仍显示原骑手配送；部分退款后商家账单未同步冲回；优惠在前端计算但后台按零记账。验收时同时打开用户端、骑手端、商家账单和平台结算，逐项记录状态、金额、凭证和责任人。

四、接口与资金结算要提前问清开通条件

开发或采购前可先列接口清单：地图定位与导航、支付、订阅消息、短信、对象存储，以及可能用到的第三方订单或设备接口。每个接口写清申请主体、权限范围、回调地址、调用额度、测试环境和故障联系人。

平台撮合业务还要把资金链路拆开：用户实付、配送费、平台抽成、商家应结、骑手收益、优惠承担和退款分别记录。支付通道是否支持分账、分账开通条件、结算账期、费率、退款冲回方式，需要按项目主体和通道规则确认。系统页面展示相关配置，不等于任意支付通道、任意版本都采用同一流程。

五、涉及校园外卖时，专项补充五项

校园场景不是把普通跑腿换个名称。地址层级、交接方式、分拣粒度和权限结构都会变化，前期清单可增加下表核对项，并用本校真实地址配置一次完整订单。

六、上线前用三类订单验收，并据此判断系统路线

不要只问“有没有这个按钮”。用正常单、转单或异常单、退款单各走一遍，把每项标记为标准配置、组合配置、需定制或未演示。正常单核对下单、支付、接单、取件、送达和结算；转单核对原任务结束、新任务生成、用户进度和商家账单；退款单覆盖接单前取消、配送中取消和部分退款。

选择SaaS、私有化、源码或定制时，可按四组问题判断：是否需要自有运行环境和技术团队；标准配置能否覆盖地址、结算和接口；源码、许可、部署文档交付什么；数据导出、培训和维护如何约定。报价适合按软件模块、终端入口、部署环境、第三方服务、培训与持续维护拆分，历史成交价对应特定项目配置，不能直接当成统一报价。前期准备时长按主体资料、资质确认、接口联调和审核进度排里程碑，不用固定天数替代实际排期。

常见追问

没有技术团队，前期先准备什么？

先定模式、服务范围、四端最小闭环和三类订单验收，再与供应商谈SaaS或定制。需求清单和验收记录比单纯比较功能数量更能减少返工。

ICP、EDI是否一定要办？

按经营模式和主管部门口径逐项确认。服务商提供代办服务与主管部门作出审批结果属于两个环节，应在项目计划中分别安排。

校园外卖和普通跑腿清单差在哪？

差异集中在地址层级、校门交接、集中收餐、楼栋分拣、批量通知和多校区权限，需用真实校区地址和通行规则做演示。

前期准备要多久？

材料不足时不写固定天数。可按主体资料、资质确认、接口联调、小程序审核和试运营分别排里程碑，并保留异常处理时间。