海外版外卖加盟系统里，总站与分站对配送规则的权限边界若不清，要么分站完全不能改（失去本地灵活），要么各自改无版本（总部无法仲裁）。宜「分站编辑、总部审批或留痕只读汇总」，并把 rule_version 写进订单快照。
结论
规则实体带 site_id、生效时间、版本号；订单快照引用 rule_version_id。总部 API 只读汇总各站当前生效规则与历史变更。客服处理纠纷时应查下单时 rule_version，而不是查当前生效规则，否则解释会与用户记忆不一致。
json
{
"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 查快照文本，避免客服查当前规则与用户记忆打架。扩城合同宜写明「规则变更是否需总部审批」，减少口头自治导致汇总不可控。