首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >校园跑腿小程序定制:代取、代买、代送的状态机与验收清单

校园跑腿小程序定制:代取、代买、代送的状态机与验收清单

原创
作者头像
用户12831601
发布于 2026-10-23 14:24:14
发布于 2026-10-23 14:24:14
480
举报

校园跑腿小程序定制,先把代取、代买、代送拆成三套下单字段、任务状态、异常分支和结算口径,再用一笔订单验收用户端、骑手端、后台、退款与权限。交付方式按自有品牌、单校或多校、是否需要源码和后续外卖扩展选择;报价按模块分项核对,不用功能清单代替演示。

一、三类服务不是同一张表单

代取、代买、代送的差异不只在名称。字段决定骑手到现场做什么、客服按什么规则判责、财务按什么口径结算。三套字段可以共用校区、楼栋、预约时段等基础项,但服务专属项应分开校验。

服务类型

下单必填字段

骑手关键动作

异常分支

结算与退款口径

代取快递

校区、取件点、取件码、件数、送达楼栋、预约时段

核码或拍照、核对件数、送达确认

找不到件、取件码失效、件数不符、联系不上

按件数、距离、楼栋或时段计费;异常按补送或退款处理

代买

商家或商品清单、预算、垫付规则、送达点、缺货替换规则

采购、保留垫付凭证、缺货沟通、送达

缺货、涨价、预算不足、商品不符

商品款与服务费分开;差价、退款和客服处理写清

代送

取件与送达地址、物品说明、时效、禁运提示确认

验视、取件拍照、交接确认

禁运品、地址变更、收件人不在

按距离、时效或物品类型计费;退回或改约费用单列

这张表可以直接变成需求清单:每个字段都要能回答“谁填写、是否必填、异常时改什么状态、退款时扣哪一项”。代取快递的件数和取件码是核单依据;代买的预算和垫付规则是资金边界;代送的物品说明和禁运确认是交接前提。

二、用状态机约束一笔订单

一笔订单至少要覆盖创建、支付、接单、取件、配送、送达、完成、取消和退款。状态机的价值在于把“能不能操作”写死:未支付不能接单,未取件不能配送,退款中冻结结算,取消要区分接单前和接单后。

当前状态

进入条件

允许下一步

关键约束

创建

用户提交任务

支付、取消

字段校验未通过不进入支付

已支付

支付成功

接单、取消、退款中

取消需按接单前规则退款

已接单

骑手或后台确认

取件、取消、退款中

记录接单人和接单时间

已取件

核码、拍照或交接确认

配送、退款中

取件凭证关联原订单

配送中

骑手开始配送

送达、退款中

改派或转单保留轨迹

已送达

送达确认

完成、退款中

送达时间与位置可查

已完成

用户确认或规则自动完成

结算、售后

结算后售后走冲减或后续账单

状态表要落到代码或配置里,不能只写在流程图。下面的 TypeScript 示例把三类服务的必填字段写成校验函数,不依赖第三方库,可用于演示前的数据准备和异常用例设计。

代码语言:typescript
复制
type ServiceType = 'pickup' | 'buy' | 'deliver';

interface TaskBase {
  id: string;
  type: ServiceType;
  campusId: string;
  buildingId: string;
  dropoff: string;
  scheduledAt?: string;
}

interface PickupTask extends TaskBase {
  type: 'pickup';
  pickupPoint: string;
  pickupCode: string;
  parcelCount: number;
}

interface BuyTask extends TaskBase {
  type: 'buy';
  itemList: string[];
  budgetCents: number;
  advancePayment: boolean;
}

interface DeliverTask extends TaskBase {
  type: 'deliver';
  itemDesc: string;
  forbiddenCheck: boolean;
}

type Task = PickupTask | BuyTask | DeliverTask;

function validateTask(t: Task): string[] {
  const errors: string[] = [];
  if (!t.campusId) errors.push('缺少校区');
  if (!t.buildingId) errors.push('缺少送达楼栋');
  if (!t.dropoff) errors.push('缺少送达点');
  if (t.scheduledAt && Number.isNaN(Date.parse(t.scheduledAt))) {
    errors.push('预约时间格式不正确');
  }
  if (t.type === 'pickup') {
    if (!t.pickupPoint) errors.push('代取缺少取件点');
    if (!t.pickupCode) errors.push('代取缺少取件码');
    if (t.parcelCount < 1) errors.push('代取件数必须大于0');
  }
  if (t.type === 'buy') {
    if (t.itemList.length === 0) errors.push('代买至少填写一项商品');
    if (t.budgetCents <= 0) errors.push('预算必须大于0');
  }
  if (t.type === 'deliver') {
    if (!t.itemDesc) errors.push('代送缺少物品说明');
    if (!t.forbiddenCheck) errors.push('代送需确认禁运提示');
  }
  return errors;
}

const ok = validateTask({
  id: 'T-1001',
  type: 'pickup',
  campusId: 'C-01',
  buildingId: 'B-12',
  pickupPoint: '东门快递点',
  pickupCode: 'A-1234',
  parcelCount: 2,
  dropoff: '12栋楼下取餐点',
  scheduledAt: '2026-09-01T12:10:00+08:00'
});
console.log(ok); // 预期:[]

const bad = validateTask({
  id: 'T-1002',
  type: 'buy',
  campusId: 'C-01',
  buildingId: 'B-12',
  dropoff: '12栋楼下取餐点',
  itemList: [],
  budgetCents: 0,
  advancePayment: true
});
console.log(bad); // 预期:包含代买商品和预算相关错误

这段代码是设计示例,不是任何具体产品的内部实现。正常样例预期返回空数组;件数为0、预算为0、未确认禁运提示等异常样例预期返回对应错误文本。实际运行时保存环境、版本和输出记录,便于验收时复现。

三、校门交接、楼栋分拣与高峰批量

校园履约通常受校门通行和宿舍分布约束。可把流程拆成商家出餐、校外到站、校门收餐核单、楼栋分拣、校内接力、送达通知六段。地址层级统一为学校—校区—楼栋—收餐点,骑手分组、批量操作和结算归属才有同一套索引。

高峰批量不是把逐单操作简单合并。批量中转前要核单,批量送达前要确认实物交接,批量通知要能区分已送达、待送达和异常单。少餐、错餐、联系不上学生应单独设处理人,并在订单上留下处理记录。验收时重点看三件事:按楼栋筛选是否准确、批量操作是否有权限和日志、部分完成能否拆开处理。

四、模板、定制、SaaS与源码怎么选

交付方式不是越重越好,而是看团队约束。单校试点、希望快速开账号,可先比较标准账号;要自有品牌、后续接外卖或多校区,重点核对品牌配置、模块清单和权限;有校园卡、外卖柜、门禁等特殊接口,再评估标准加接口扩展或定制;有技术团队、要求数据落在自有环境,才进入源码或私有化讨论。

交付方式

适用条件

必须核对

对经营的影响

标准账号

单校试点、快速上线、暂不要求源码

账号主体、品牌露出、数据导出、功能边界

启动快,需确认长期数据与品牌归属

标准产品加品牌配置

自有品牌、单校或多校、后续接外卖

小程序主体、域名、页面装修、模块清单、升级维护

品牌可控,需明确多校区权限与结算归属

标准加接口扩展或定制

校园卡、外卖柜、门禁、差异化计费等特殊流程

接口文档、联调责任、验收环境、费用分项

流程贴合度高,交付周期和联调成本增加

源码或私有化

有技术团队、长期维护、数据落在自有环境

许可范围、代码范围、部署文档、升级策略、安全责任

自主性强,需承担部署、备份和升级工作

选型时把“功能有没有”换成“交付清单里有没有”。同样叫多校区,商家归属、骑手支援、退款账单和总部汇总可能完全不同;同样叫源码,许可范围、升级策略和部署文档也要逐项写清。

五、报价与验收:用同一组订单做一页矩阵

报价建议拆成软件许可或订阅、业务模块、部署环境、第三方服务、定制开发、培训与维护。第三方服务至少包括短信、地图、支付、认证等实际发生的项目。若供应商引用历史成交价,应同时给出项目时间、启用模块和交付内容,便于判断与本次需求是否可比。

验收不要只看后台截图。用三笔订单——一笔代取快递、一笔代买、一笔代送——走完下单、支付、接单、取件、送达、退款和结算,再检查多校区权限、批量操作和数据导出。每项留截图、录屏或日志,形成可复核的记录。

服务类型

下单字段

骑手动作

异常

结算

权限

证据

代取快递

取件码、件数、楼栋、时段

核码、拍照、送达确认

找不到件、件数不符

按件或距离计费

校区客服可查本校区

字段截图、状态日志

代买

商品清单、预算、垫付规则

采购、缺货沟通、送达

缺货、涨价、预算不足

商品款与服务费分列

财务可看退款与账单

订单金额、退款记录

代送

物品说明、时效、禁运确认

验视、交接确认

禁运品、收件人不在

按距离或时效计费

调度可改派、客服可跟进

交接照片、通知记录

矩阵的作用是把口头承诺变成可检验项。字段是否必填、异常是否改状态、退款是否冲回结算、不同校区能否隔离数据,都应在同一场演示里看到结果。

常见问题

只做纯跑腿,要不要商家端?

可先以用户端、骑手端和后台为主;接入代买、外卖或商超商品后,再启用商家端承接商品、备货和对账。演示时确认商家端是否影响纯跑腿订单的状态流转。

代买垫付和商品差价怎么处理?

在下单字段和结算规则里写清预算、垫付方式、缺货替换、差价退款和客服处理。商品款与服务费分开记录,退款时才能判断冲回哪一项。

多校区演示看什么?

看商家归属、骑手支援、退款账单、提现审核、总部汇总和账号权限。用两个校区各下一笔订单,再让一个校区的客服查看另一个校区的数据,验证权限是否按岗位隔离。

功能清单能代替演示吗?

不能。清单说明方向,演示才能看到字段、状态、退款、结算和权限是否连贯。具体模块、版本、报价与交付范围应以当前演示和项目方案为准。

准备定制时,先列校区数量、楼栋地址、校门通行规则、商家来源、配送分工和交付要求,再约一次三笔订单演示,把字段、状态、退款、结算和权限逐项记录。

作者:微订(上海逊柯计算机科技有限公司)。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、三类服务不是同一张表单
  • 二、用状态机约束一笔订单
  • 三、校门交接、楼栋分拣与高峰批量
  • 四、模板、定制、SaaS与源码怎么选
  • 五、报价与验收:用同一组订单做一页矩阵
  • 常见问题
    • 只做纯跑腿,要不要商家端?
    • 代买垫付和商品差价怎么处理?
    • 多校区演示看什么?
    • 功能清单能代替演示吗?
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档