校园跑腿小程序必备功能与后台清单：状态机、计价与验收

校园跑腿小程序首期不必把营销、会员、分销全部堆上。先让“用户下单—骑手接单或派单—取件与送达凭证—异常转单—结算售后”跑成一条可回放的订单链路；管理员后台的最小集是校区楼栋地址、计价规则、订单调度、骑手审核、结算记录、退款售后、账号权限和基础报表。若项目还要承接校园外卖，可让外卖与跑腿共用用户、地址和骑手池，但分别保留业务规则与账单口径。下文按数据模型、状态机、账务和验收四部分展开，给出可以直接用于需求评审和测试设计的清单。

一、首期三端功能边界：按“缺了就断链”筛

首期功能可以用一个判断标准：缺了它，一笔订单就无法从支付走到结算，或者出了问题无法定位责任人。按这个标准，三端的最小集如下。

用一笔正常单从支付跑到结算，再补一笔转单和一笔退款，功能范围才容易验收。列表上的按钮数量不是重点，重点在于同一订单号在三端能否对上状态和金额。

二、校园场景先建地址模型：校区—楼栋—点位

校园跑腿和普通同城跑腿的差异，主要不在“代取快递”这个服务名，而在地址与交接。后台应把学校、校区、楼栋、宿舍或取餐点维护成结构化数据，让学生下单时直接选择，而不是自由填写文本。自由文本会直接破坏分拣、计费和骑手路线，这也是后台最容易被低估的模块。

-- SQLite 语法示例：地址与后台权限的最小结构
CREATE TABLE campus (
  id INTEGER PRIMARY KEY,
  school_name TEXT NOT NULL,
  campus_name TEXT NOT NULL
);

CREATE TABLE building (
  id INTEGER PRIMARY KEY,
  campus_id INTEGER NOT NULL REFERENCES campus(id),
  building_name TEXT NOT NULL,
  UNIQUE (campus_id, building_name)
);

CREATE TABLE point (
  id INTEGER PRIMARY KEY,
  building_id INTEGER REFERENCES building(id),
  point_type TEXT NOT NULL CHECK (point_type IN ('gate','canteen','dorm','pickup')),
  point_name TEXT NOT NULL
);

CREATE TABLE admin_scope (
  admin_id INTEGER NOT NULL,
  campus_id INTEGER NOT NULL,
  role TEXT NOT NULL CHECK (role IN ('hq','campus_admin','cs','finance')),
  PRIMARY KEY (admin_id, campus_id, role)
);

这张结构图解决三个问题：下单时地址可选、后台分拣时能按楼栋分组、权限表能把总部、校区管理员、客服和财务限制在各自数据范围内。校门、集中收餐点、宿舍楼下等交接位置放在 point 表，计费规则可以引用楼栋或点位，避免在订单里重复存一份地址文本。校方通行条件、可送达楼层和交接方式属于运营规则，应写在服务说明中，并与地址选项一起维护。

三、订单状态机：转单和退款都写成状态转换

订单状态建议由服务端统一约束，前端只展示当前允许的操作。转单不应改写原骑手任务，而是关闭原任务、生成新任务，并保留两条任务记录；退款也不应回改已结算订单，而是进入调整流程。下面是一组可直接用于评审的状态与守卫示例。

状态集合：
CREATED -> PAID | CANCELED
PAID -> ACCEPTED | CANCELED
ACCEPTED -> PICKED_UP | TRANSFERRED | CANCELED
PICKED_UP -> DELIVERED | TRANSFERRED
DELIVERED -> SETTLED | REFUNDING
SETTLED -> REFUND_ADJUST
REFUNDING -> REFUNDED

守卫函数（伪代码）：
canTransit(order, to, actor):
  if to == "ACCEPTED" and order.status != "PAID": return false
  if to == "TRANSFERRED" and order.status not in ("ACCEPTED","PICKED_UP"): return false
  if to == "SETTLED" and order.deliveredAt == null: return false
  if to == "REFUND_ADJUST" and order.settledAt == null: return false
  return actor.role in ROLE_ALLOW[to]

几个常见反例值得写进测试用例：未支付订单被接单；骑手已取件后直接取消而没有转单记录；结算完成后用退款直接改原单金额，导致历史账单对不上。把这些转换写成守卫后，后台客服、调度和财务看到的是同一套可追溯的状态流水。

四、计价与账务：一条恒等式贯穿下单、结算、退款

计价项建议拆成起步、距离、件数或重量、时段、楼栋或点位、附加服务六类，优惠单独记录承担方。后台配置改价要保留生效时间和原因，历史订单按当时规则计算。账务可以用一条恒等式校验：

用户实付 - 退款金额
= 商家或任务方应结 + 骑手收益 + 平台服务费 + 优惠承担 ± 调整项

举例说明算式，数字仅用于校验，不代表任何报价：起步6元、距离2元、楼栋1元，合计9元；平台优惠1元后用户实付8元；平台服务费0.8元、骑手收益6元、任务方应结1.2元，则8 = 1.2 + 6 + 0.8。部分退款时要先明确商品或任务费、配送费、优惠、服务费分别如何冲回，再决定骑手收益是否调整。已经结算的订单发生退款，通过调整单冲减，不改动原单金额，这样财务对账和客服处理都能接得上。

五、管理员后台功能清单：四层分法

多校区要按“总部看汇总与通用规则、校区看本校商家骑手订单与楼栋配置”划分权限，财务与客服再按岗位收窄操作范围。演示时用两个校区切换，检查商家归属、骑手支援、退款账单和总部汇总是否一致，比只看后台菜单更能发现权限边界问题。

六、上线前用三类订单验收

验收不要把功能名逐项打勾，而要用订单场景记录四端状态、金额、凭证和责任人。建议至少覆盖以下三类。

每项结果标成“符合预期、需调整配置、需开发、未演示”四类，形成可复核的验收表。用本校真实楼栋和一笔从校外商家到宿舍楼下的订单走完整流程，能提前暴露地址、计费和交接三类问题。

常见问题

校园跑腿首期后台最少要哪些功能？校区楼栋地址、计价、订单调度、骑手审核、结算记录、退款售后、子账号权限和订单报表；营销与会员可以按运营节奏后置。

校园跑腿和校园外卖能否共用一套后台？可以评估共用用户、地址、骑手池和结算入口，同时把订单类型、计价规则和账单口径分开。用同一名骑手分别跑一笔外卖单和一笔跑腿单，核对任务与收益是否各自独立。

转单后收益怎么记？以任务为结算粒度：原任务关闭并记录原因，新任务独立生成收益，用户看到的订单进度与后台账单保持同一订单号。

结算后退款怎么处理？生成调整单冲减对应账目，保留原结算记录和调整原因，避免直接修改历史金额。

准备启动项目时，可以先整理本校校区、楼栋与交接点清单，确定计价项和优惠承担规则，再准备正常单、转单单、退款单各一笔做场景演练。把每笔订单的状态序列、金额拆项、凭证和责任人记入同一张验收表，据此确定首期上线范围，再安排后续模块。