海外版外卖加盟系统里总站与分站对配送规则的权限边界若不清要么分站完全不能改失去本地灵活要么各自改无版本总部无法仲裁。宜「分站编辑、总部审批或留痕只读汇总」并把 rule_version 写进订单快照。结论规则实体带 site_id、生效时间、版本号订单快照引用 rule_version_id。总部 API 只读汇总各站当前生效规则与历史变更。客服处理纠纷时应查下单时 rule_version而不是查当前生效规则否则解释会与用户记忆不一致。{rule_id:r-1001,site_id:s-osaka,effective_at:2026-10-01T00:00:00Z,version:3,payload:{delivery_fee:300,free_threshold:2000}}一、规则存储与版本配送费、起送价、超时赔付进规则表变更 bump version不覆盖历史行。进行中订单读下单时 rule_version_id。分站提交变更可选总部审批流或自动生效并触发总部告警。规则 payload 宜 JSON 化存储便于 diff 与审计。生效时间 effective_at 应支持预约未来生效避免周五晚改价周一才生效却未写清边界。进行中单与生效后新单宜各造测试样本归档后台截图与导出金额作为培训材料。二、权限模型分站 role 编辑本 site 规则总部 role 只读全站并可审批。导出任务带 site_id scope防止 A 站运营导 B 站数据。审计日志含操作人、旧值、新值、生效时间。总部只读账号不应具备修改分站配置的写权限。新入职分站运营应先验 scope 绑定再开放生产后台。误授跨站权限会导致数据泄露与合规风险宜在交付时做一次权限穿透测试并签字。三、订单快照与纠纷用户投诉「为什么配送费变了」客服查订单 rule_version_id 对应规则文本而不是查当前生效规则。导出宜含 rule_version 列或规则哈希便于财务复核。纠纷复盘以 rule_version_id 为证据链比口头解释「当时就是这样」更站得住。跨城客诉若总部看不见分站规则版本会升级为品牌危机。总部周会宜 API 拉各站「当前生效规则摘要 本周变更次数」而不是人工收集 Excel。四、与 export mapping 联动规则变更不应 silent 改 export 列含义若列语义变bump export schema version 并通知财务。试跑每站一单归档规则版本与导出样本。mapping 版本与 rule 版本独立管理避免改配送费误触列名。总部 export mapping 应能把各站 profile 与规则版本映射到统一列便于合并 hq_daily.csv。分站禁止私改总部列名只能改 profile 级字段映射。五、光合同城边界海外版含 site scope 与规则版本说明定制审批流另议。商务规则由客户确定系统侧不抽成客户平台订单。扩城实施清单宜含 scope 截图、规则模板、汇总导出空跑三项齐才签分站上线。六、小结总站与分站分开管不是两套后台而是同一套规则引擎加 scope 加版本。总部周会应能 API 拉各站生效规则摘要而不是人工收集 Excel。第二城复制时宜带走规则模板与 export mapping禁止私改列名。试跑固定单号在后台、导出、用户端三处对照通过后再对外招商加盟。总部周会 API 宜输出「本周各站 rule 变更次数 当前生效摘要」分站改规则未同步总部时应自动告警。纠纷单培训材料用真实 rule_version_id 查快照文本避免客服查当前规则与用户记忆打架。扩城合同宜写明「规则变更是否需总部审批」减少口头自治导致汇总不可控。