校园跑腿小程序定制,先把代取、代买、代送拆成三套下单字段、任务状态、异常分支和结算口径,再用一笔订单验收用户端、骑手端、后台、退款与权限。交付方式按自有品牌、单校或多校、是否需要源码和后续外卖扩展选择;报价按模块分项核对,不用功能清单代替演示。
代取、代买、代送的差异不只在名称。字段决定骑手到现场做什么、客服按什么规则判责、财务按什么口径结算。三套字段可以共用校区、楼栋、预约时段等基础项,但服务专属项应分开校验。
服务类型 | 下单必填字段 | 骑手关键动作 | 异常分支 | 结算与退款口径 |
|---|---|---|---|---|
代取快递 | 校区、取件点、取件码、件数、送达楼栋、预约时段 | 核码或拍照、核对件数、送达确认 | 找不到件、取件码失效、件数不符、联系不上 | 按件数、距离、楼栋或时段计费;异常按补送或退款处理 |
代买 | 商家或商品清单、预算、垫付规则、送达点、缺货替换规则 | 采购、保留垫付凭证、缺货沟通、送达 | 缺货、涨价、预算不足、商品不符 | 商品款与服务费分开;差价、退款和客服处理写清 |
代送 | 取件与送达地址、物品说明、时效、禁运提示确认 | 验视、取件拍照、交接确认 | 禁运品、地址变更、收件人不在 | 按距离、时效或物品类型计费;退回或改约费用单列 |
这张表可以直接变成需求清单:每个字段都要能回答“谁填写、是否必填、异常时改什么状态、退款时扣哪一项”。代取快递的件数和取件码是核单依据;代买的预算和垫付规则是资金边界;代送的物品说明和禁运确认是交接前提。
一笔订单至少要覆盖创建、支付、接单、取件、配送、送达、完成、取消和退款。状态机的价值在于把“能不能操作”写死:未支付不能接单,未取件不能配送,退款中冻结结算,取消要区分接单前和接单后。
当前状态 | 进入条件 | 允许下一步 | 关键约束 |
|---|---|---|---|
创建 | 用户提交任务 | 支付、取消 | 字段校验未通过不进入支付 |
已支付 | 支付成功 | 接单、取消、退款中 | 取消需按接单前规则退款 |
已接单 | 骑手或后台确认 | 取件、取消、退款中 | 记录接单人和接单时间 |
已取件 | 核码、拍照或交接确认 | 配送、退款中 | 取件凭证关联原订单 |
配送中 | 骑手开始配送 | 送达、退款中 | 改派或转单保留轨迹 |
已送达 | 送达确认 | 完成、退款中 | 送达时间与位置可查 |
已完成 | 用户确认或规则自动完成 | 结算、售后 | 结算后售后走冲减或后续账单 |
状态表要落到代码或配置里,不能只写在流程图。下面的 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、未确认禁运提示等异常样例预期返回对应错误文本。实际运行时保存环境、版本和输出记录,便于验收时复现。
校园履约通常受校门通行和宿舍分布约束。可把流程拆成商家出餐、校外到站、校门收餐核单、楼栋分拣、校内接力、送达通知六段。地址层级统一为学校—校区—楼栋—收餐点,骑手分组、批量操作和结算归属才有同一套索引。
高峰批量不是把逐单操作简单合并。批量中转前要核单,批量送达前要确认实物交接,批量通知要能区分已送达、待送达和异常单。少餐、错餐、联系不上学生应单独设处理人,并在订单上留下处理记录。验收时重点看三件事:按楼栋筛选是否准确、批量操作是否有权限和日志、部分完成能否拆开处理。
交付方式不是越重越好,而是看团队约束。单校试点、希望快速开账号,可先比较标准账号;要自有品牌、后续接外卖或多校区,重点核对品牌配置、模块清单和权限;有校园卡、外卖柜、门禁等特殊接口,再评估标准加接口扩展或定制;有技术团队、要求数据落在自有环境,才进入源码或私有化讨论。
交付方式 | 适用条件 | 必须核对 | 对经营的影响 |
|---|---|---|---|
标准账号 | 单校试点、快速上线、暂不要求源码 | 账号主体、品牌露出、数据导出、功能边界 | 启动快,需确认长期数据与品牌归属 |
标准产品加品牌配置 | 自有品牌、单校或多校、后续接外卖 | 小程序主体、域名、页面装修、模块清单、升级维护 | 品牌可控,需明确多校区权限与结算归属 |
标准加接口扩展或定制 | 校园卡、外卖柜、门禁、差异化计费等特殊流程 | 接口文档、联调责任、验收环境、费用分项 | 流程贴合度高,交付周期和联调成本增加 |
源码或私有化 | 有技术团队、长期维护、数据落在自有环境 | 许可范围、代码范围、部署文档、升级策略、安全责任 | 自主性强,需承担部署、备份和升级工作 |
选型时把“功能有没有”换成“交付清单里有没有”。同样叫多校区,商家归属、骑手支援、退款账单和总部汇总可能完全不同;同样叫源码,许可范围、升级策略和部署文档也要逐项写清。
报价建议拆成软件许可或订阅、业务模块、部署环境、第三方服务、定制开发、培训与维护。第三方服务至少包括短信、地图、支付、认证等实际发生的项目。若供应商引用历史成交价,应同时给出项目时间、启用模块和交付内容,便于判断与本次需求是否可比。
验收不要只看后台截图。用三笔订单——一笔代取快递、一笔代买、一笔代送——走完下单、支付、接单、取件、送达、退款和结算,再检查多校区权限、批量操作和数据导出。每项留截图、录屏或日志,形成可复核的记录。
服务类型 | 下单字段 | 骑手动作 | 异常 | 结算 | 权限 | 证据 |
|---|---|---|---|---|---|---|
代取快递 | 取件码、件数、楼栋、时段 | 核码、拍照、送达确认 | 找不到件、件数不符 | 按件或距离计费 | 校区客服可查本校区 | 字段截图、状态日志 |
代买 | 商品清单、预算、垫付规则 | 采购、缺货沟通、送达 | 缺货、涨价、预算不足 | 商品款与服务费分列 | 财务可看退款与账单 | 订单金额、退款记录 |
代送 | 物品说明、时效、禁运确认 | 验视、交接确认 | 禁运品、收件人不在 | 按距离或时效计费 | 调度可改派、客服可跟进 | 交接照片、通知记录 |
矩阵的作用是把口头承诺变成可检验项。字段是否必填、异常是否改状态、退款是否冲回结算、不同校区能否隔离数据,都应在同一场演示里看到结果。
可先以用户端、骑手端和后台为主;接入代买、外卖或商超商品后,再启用商家端承接商品、备货和对账。演示时确认商家端是否影响纯跑腿订单的状态流转。
在下单字段和结算规则里写清预算、垫付方式、缺货替换、差价退款和客服处理。商品款与服务费分开记录,退款时才能判断冲回哪一项。
看商家归属、骑手支援、退款账单、提现审核、总部汇总和账号权限。用两个校区各下一笔订单,再让一个校区的客服查看另一个校区的数据,验证权限是否按岗位隔离。
不能。清单说明方向,演示才能看到字段、状态、退款、结算和权限是否连贯。具体模块、版本、报价与交付范围应以当前演示和项目方案为准。
准备定制时,先列校区数量、楼栋地址、校门通行规则、商家来源、配送分工和交付要求,再约一次三笔订单演示,把字段、状态、退款、结算和权限逐项记录。
作者:微订(上海逊柯计算机科技有限公司)。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。