本地同城外卖入口选型：小程序、APP与服务号的验收方法

做本地同城外卖，用户端先以微信小程序承接浏览、下单和支付，服务号承担订单、取餐等消息触达与私域沉淀，用户APP等订单密度和复购稳定后再评估；商家端和骑手端按接单提醒、扫码转单、小票打印、弱网重试和账号权限逐项演示后再定终端组合。判断顺序也不复杂：先用一张职责表定入口，再按七步顺序把区域、商品、骑手、支付和测试单跑通，最后用一笔订单同时核对状态、通知和金额。

一、三类入口的分工：按职责选，不按名字选

三类入口不是替代关系，而是职责不同：小程序负责把用户带进下单流程，服务号负责把订单进展告诉用户，APP负责在订单密度足够后承接高频用户。起步阶段把前两者配好，商家与骑手的移动端则按现场操作逐项验收，比争论终端形态更有用。

消息触达能力随渠道规则变化，模板条数、触发条件和用户授权以微信公众平台等渠道的最新公示为准；上线前把规则核对结果写进配置清单，避免把“配好了”当成“用户一定收到”。

二、从0到试运营：七步顺序不能乱

落地顺序建议按“先规则、后数据、再资金、最后放量”推进，每一步都有可交付物，前一步没验收就进入下一步，后面的测试单会反复返工。

1. 定模式与范围：明确多商户平台还是自营为主，首期只做一个片区或一个校区，把服务半径、起送条件、营业时段写清楚。
2. 备主体与账号资料：账号主体、认证、支付申请、备案类资料按主管部门与渠道公示准备，资料准备周期计入上线排期。
3. 配业务区域：配送范围、跨区地址拦截、起送与配送费规则一起配，避免测试单出现“能下单但送不到”。
4. 录商家与商品：菜单、规格、库存或售罄、包装费、活动规则同步录入，商品信息与包装规则不一致会直接引发售后。
5. 配骑手与权限：骑手账号、抢派单规则、转单收费、结算口径，以及客服与财务的分权，都在这一层定。
6. 开通支付与结算：支付通道、结算与分账规则、退款冲正、账期与提现审批一起确认，账务规则先于推广上线。
7. 测试单—培训—片区试运营：用下文清单走测试单，培训商家与骑手，再小范围放量，根据出餐、接单和售后情况扩区。

三、一笔订单验收：可复现的核对脚本

入口与角色端是否合适，最终要回到一笔订单：用户端看到的状态、商家端的接单记录、骑手端的任务和平台端的金额必须对得上。下面的脚本用于把演示观察结果整理成缺口清单，属于验收模板，不代表任何产品的内部实现。

// 终端入口验收模板：演示后把观察结果填入 evaluated（true / false），未填项自动列为待核对
// 运行环境：Node.js 18+，无第三方依赖；保存为 entry-check.js 后执行 node entry-check.js
const terminals = [
  { name: '用户端 · 微信小程序', items: ['区域与商家浏览', '下单与支付', '订单消息触达', '弱网重进恢复'] },
  { name: '消息配套 · 服务号', items: ['订单节点通知', '取餐提醒', '授权与退订路径'] },
  { name: '用户端 · APP（后置评估）', items: ['系统级推送', '下载与更新成本', '账号与订单互通'] },
  { name: '商家端', items: ['来单提醒', '扫码接单与转单', '小票打印', '账号权限'] },
  { name: '骑手端', items: ['锁屏接单', '取送状态回传', '转单与收益查看', '弱网重试'] },
];

// 填写示例（示意格式，不是实测结果）：{ '商家端': { '小票打印': true } }
const evaluated = {};

for (const t of terminals) {
  const filled = t.items.filter((i) => evaluated[t.name]?.[i] !== undefined);
  const pending = t.items.filter((i) => evaluated[t.name]?.[i] === undefined);
  const failed = filled.filter((i) => evaluated[t.name][i] === false);
  console.log(
    `${t.name}: 已核对 ${filled.length}/${t.items.length}` +
    (pending.length ? `；待核对：${pending.join('、')}` : '') +
    (failed.length ? `；未通过：${failed.join('、')}` : '')
  );
}

按现有填写状态运行，预期输出是每个终端都提示“已核对 0/N”并列出待核对项；把演示结果逐项填成 true 或 false 后，false 的项会进入“未通过”列表，成为要求补充配置或调整运营规则的依据。这类结论与代码版本、运行环境绑定，正式项目应保存运行记录，而不是只留口头结论。

异常场景建议单独排期演练：超范围地址、重复支付回调、骑手转单、部分退款、结算后退款、通知发送失败。每类记录操作账号、订单状态变化、通知对象和金额变化，作为上线后客服与财务的处理依据。

四、通知链路：七个节点逐一对应

把“消息通知”当成一个功能容易漏配，拆成订单节点更可靠：每个节点谁收、由什么触发、发不出去怎么办。

通知条数、触发条件和授权方式以渠道最新规则为准，运营侧更该关心的是兜底：任何一条消息没发出去，用户能否在订单页看到同样结论，客服能否按订单号查到处理进度。

五、商家端与骑手端：把“必须APP”换成七项演示

终端形态应由现场操作决定。商家和骑手的移动端可能同时存在APP、小程序和手机网页入口，选哪一组，取决于下面七项在实际设备上的表现。

这七项都能通过，用APP、小程序还是网页都可以；通过不了的项，换终端也解决不了，反而会把问题带到试运营阶段。

六、预算怎么问：把报价拆成可比较的科目

初创阶段最容易踩的坑是拿一个总价对比另一个总价。更可行的做法是拆科目再问：软件模块与终端入口、部署环境、第三方服务（短信、地图、云资源、认证）、定制开发、培训与持续维护。每一项都追问四个问题：一次性费用还是续费、由谁承担、是否已含在报价内、变更时怎么计费。

历史成交项目价和同行公开报价只能作为背景参考，对应的是当时的模块与配置，不能当作统一报价；把模块清单和交付范围写进对比表，预算才具备可比性。上线节奏同样按项目准备程度和审核进度安排，不宜承诺固定天数。

七、常见追问

初创只做小程序行不行？

用户端可以先只做小程序，服务号同步做消息配套；商家端与骑手端按上文七项演示再定，不按终端名称拍板。

服务号能替代小程序做主下单入口吗？

主下单页优先放在小程序，服务号更适合消息触达与私域沉淀；模板与订阅的具体规则以渠道最新公示为准。

骑手和商家一定要用APP吗？

用现场演示说话：锁屏推送、扫码接单、转单、打印、弱网、权限、收益查看七项都达标即可，形态本身不是结论。

上线前最少跑哪些订单？

正常单、取消单、缺货或拒单、骑手转单、超范围地址、优惠参与、部分退款、结算后退款各跑一遍，并同步核对通知对象与金额变化。

把这七步顺序、七个通知节点和七项演示核对表填满，再决定终端组合与放量范围；测试记录留存版本、操作人和结果，后续扩区或换端时可以直接复用。