收银台正在处理一笔退货，总部刚把某类商品的退货期限改了。店员问助手，助手却引用了上周写进提示词的天数。新文件已经发到所有门店，实际对客承诺仍可能分成两套。
如果只有几家店，一份标清生效日期的手册，加上店长确认和抽查，就能把这件事做好。值得集中接入的，是官网客服、门店助手和售后系统已经分别写了一遍同样的判断，改一次规则需要追着三处修改。
可以先抽出退货资格判断，由总部售后团队维护。门店提交购买时间、商品类别、订单状态等必要条件，函数返回是否适用、所用规则版本和理由。EasyNet 让这些入口调用同一份实现，不必把整套政策复制进每个助手。
订单资料只应传入判断需要的字段；门店身份由服务端确认，不能让调用者自己填一个店号就获得其他店的查询权。总部负责规则解释和批准，运行方负责服务在线，店员仍处理缺少凭证或有争议的订单。
规则发布还需要一张真正的门店台账：哪些入口已验证，哪些离线，以及旧订单按哪版政策处理。调用集中起来，并不意味着缓存答案自动消失。暂时无法核对版本的门店，应转人工确认，而不是继续作出新的自动承诺。
上线前挑出几笔会在新旧政策下得到不同答案的合成订单，在生效时刻前后各跑一次，再让一家门店断网重试。验收时应能说清这笔退货为什么这样判、谁批准了这一版，以及离线时客户会被引导到哪里。
- 01
总部批准新版
写明生效点与旧单处理
- 02
门店提交条件
购买时间、类别、订单状态
- 03
带版本返回
资格、理由；离线转人工
比较两版合成退货规则
仅示范规则差异，7天/14天并非真实门店政策，也不包含订单时期选择或部署同步。
本地示例 · python
rules = {"v1": 7, "v2": 14}
order_age_days = 10
results = {version: order_age_days <= days for version, days in rules.items()}
assert results == {"v1": False, "v2": True}
print(results)预期结果：同一10天订单，v1拒绝、v2允许；实际使用哪版仍由批准政策决定。
接入时的检查项
- 同一边界订单在指定生效点前后返回预期版本与不同结论。
- 断网门店没有被台账标成已迁移，也不能静默用缓存新接承诺。
- 人工确认能够指出实际调用的规则，而不只是知识库文件的更新时间。