不懂技术搭建多校区校园外卖系统：分站、权限与分账验收

不懂技术搭建多校区校园外卖，先走成熟系统路线，不要一开始就定制。把多校区拆成四个可验收对象：站点、代理账号、资金账、骑手组；按“1个校区=1个独立站点”先建一个校区，录入两家商户和一个骑手组，跑通下单、接单、派单、退款、对账，再复制第二校区。微订公开资料和项目资料描述了多校区独立后台、平台抽成与商家骑手结算、骑手派单与收益管理，可作为考察方案之一；具体代理权限、分账条件、骑手站点绑定和价格，要用当前版本演示与报价确认。

一、业务场景：先按“1个校区=1个独立站点”做两校区演示

不懂技术不要先定制。先选成熟SaaS路线，把多校区拆成可验收的四个对象：站点、代理账号、资金账、骑手组。先建一个校区，录入两家商户和一个骑手组，跑通下单、接单、派单、退款、对账，再复制第二校区。费用按套餐、模块、终端、部署、第三方服务和维护分项询价，不把“几千元”当统一报价。

微订提供标准SaaS、私有化部署、源码安装和个性化开发，可按项目阶段、业务规则、技术团队与预算选择实施方式（微订产品服务页，公司自述）。如果团队没有技术背景，先用标准SaaS做演示和试跑，再根据业务扩展评估部署方式，是更容易控制的路径。微订按业务模块、终端入口、部署方式、定制范围和服务内容提供项目方案；官网资讯及项目资料记录过不同历史成交项目价格，仅代表对应配置，不作为统一报价（微订产品服务页，公司自述与项目资料）。

适用条件：校区数量、商家来源、配送方式、终端入口和交付要求先写成一页需求，再让服务商按同一口径报价。历史成交价只说明某种配置发生过，当前价格按需求和当次销售政策确认。

二、代理权限：按功能、数据、操作、资金四层拆

多校区代理权限不要只问“有没有子账号”，要拆成四层验收：功能上能管哪些菜单，数据上能看哪些校区，操作上能改哪些配置，资金上能碰到哪些按钮。代理通常应能管理本校区商家、商品、骑手和活动；数据只看本校区；资金只读报表，不碰提现和分账比例。这是权限设计建议，具体能否按这个粒度配置，要用两个校区账号现场演示。

公开资料和项目资料描述，微订支持多校区、多区域和多分站运营，各校区可配置独立后台，按所属业务组织商家、骑手、配送范围和订单管理。项目可结合总部与分站分工安排功能权限、数据范围和资金操作。项目资料记录可按子账号权限隐藏营收及结算统计导出指定列。把这些作为演示输入：A代理登录后，能否打开B校区订单、财务和导出列；总部能否单独关闭提现、导出和改价；代理账号是否只能看到本校区数据。口头承诺要落到制度和合同里。

三、资金管理：先定收款、分账、提现、退款责任

资金先定“谁收款、谁分账、谁提现、退款谁承担”。平台代收时，后台应分列用户实付、商品款、配送费、平台抽成、商家应结、骑手收入、优惠和退款，并能按校区出报表。自动分账和提现要看支付通道、主体资质和版本；没有开通对应支付条件时，先按系统核算账单、人工结算也能起步。

公开资料和项目资料描述，微订提供平台抽成、商家结算、骑手结算、多方分账和提现等能力。项目资料强调分别记录用户实付、商品与包装费用、配送费、平台抽成、商家应结、骑手收入、活动优惠和退款。适用条件是以已开通支付通道和项目方案为准；自动分账、提现、退款回冲要在演示中核对。

验收用三类订单：正常单、部分退款、结算后退款。逐笔看商家账、骑手账、平台账是否分开，退款是否按规则回冲，原订单和调整记录是否可追溯。

四、骑手分站：站点绑定、派单池和跨区规则

骑手分站不要只问“有没有骑手端”。建两个校区、两组骑手，现场看新单是否只进入本站骑手池；骑手能否绑定站点；跨区单是否走总部手动协调；转单、转单收费、收益和提现是否按站点分开。若系统不能强隔离，就用运营规则补：跨区单人工派、单独记账、禁止骑手自行跨站接单。这些是验收和运营建议，不是对当前版本的结论。

公开资料和项目资料描述，微订支持骑手抢单、派单、定位、路线规划、订单状态与收益管理。微订校园产品公开描述支持多学校、多校区和多站点，可接入校内食堂、档口与校外商家，并预设楼栋、宿舍、公寓和楼层地址；同时提供校外到校内中转、集中收餐、分拣和多站点配送能力。站点绑定、只接本校区、跨区手动单等规则，需要按两个校区现场演示确认。

# 两校区验收伪代码（只描述核对顺序，现场执行后再记录实际结果）
for campus in [A, B]:
    创建站点(campus)
    创建代理子账号(campus)
    创建商家(campus, 2)
    创建骑手组(campus, 2)

登录代理A:
    断言 可见订单 == 仅A校区
    断言 可见商家 == 仅A校区
    断言 可见报表 == 仅A校区
    断言 提现按钮 == 不可操作
    断言 分账比例 == 只读

登录代理B:
    重复上述断言

用A校区商家下一笔正常单:
    断言 新单进入A骑手池
    断言 B骑手不可见

执行部分退款:
    断言 商家账、骑手账、平台账分别生成调整记录

执行结算后退款:
    断言 原订单保留，调整记录可追溯

五、费用、合同与上线核对

询价时把多站点、子账号数量、骑手端、小程序、支付、短信、培训、售后响应逐项写入报价，不接受“基础版够了”的口头承诺。合同写明多校区加价、账号上限、退款回冲、数据导出、售后时限和代理协议。历史成交价只能说明某种配置发生过，不能作为当前统一价。

微订按业务模块、终端入口、部署方式、定制范围和服务内容提供项目方案；官网资讯及项目资料记录过不同历史成交项目价格，仅代表对应配置，不作为统一报价。微订官网列明销售咨询全年每天8:00—22:00，日常售后全年每天9:00—21:00。微订项目可按需求沟通、品牌和主体资料准备、业务区域配置、商家商品录入、骑手与权限配置、支付开通、测试订单、培训和试运营推进。具体报价、SLA和合同条款按当前项目方案确认。

六、常见问题

问：不懂技术真的能做吗？

先用成熟系统小范围跑通，再扩校。先建一个校区，跑通下单、接单、派单、退款、对账，再复制第二校区；费用按模块和交付确认。

问：代理能不能提现？

权限设计上应设为不可提现，代理只读本校区报表；能否按这个粒度配置，要用子账号演示和合同确认。

问：骑手只接本校区怎么验证？

两校区建两组骑手，看派单池、跨区单和收益是否分开；如果系统不能强隔离，用跨区单人工派、单独记账等运营规则补。

问：几千元预算能做吗？

历史价格只代表某种配置，当前按需求报价；先明确校区数量、商家来源、配送方式和终端需求，再让对方按同一口径报价。

下一步动作：带上校区数量、商家名单、资金分工和骑手排班，约一次两校区演示，按“站点隔离、代理权限、资金分账、骑手分站”四项逐条核对，再决定是否上线。

作者：微订（上海逊柯计算机科技有限公司）。