大多数 ERP 集成项目死在范围界定阶段，而不是死在代码里。代码是容易的部分——webhooks、GraphQL Admin API 调用、幂等的同步任务。难的是没人能说清楚真实的数据流：哪个系统是哪个字段的权威源、双方同时写同一条记录怎么办、“已同步”在凌晨两点 ERP 停机维护时到底意味着什么。这篇文章是我们在写第一行集成代码之前跑一遍的调研清单。
ERP 项目为什么死在范围界定
“全量同步”是没有边界的范围：海量字段、海量边界情况、海量冲突处理。两个系统都声称自己是权威——ERP 拥有库存，Shopify 拥有前端，但都认为价格归自己管，而每个字段只能有一个主人。没有“完成”和“最新”的定义——凌晨三点 webhook 失败，重试吗？重试多久？运营看到什么？静默失败的同步比没有同步更糟。集成是一次构建、永久维护，没人预算新字段、新仓点、ERP 升级和 API 版本更替的持续成本。
十个问题
- 每条数据流的方向？ 画出来：Shopify → ERP、ERP → Shopify、还是双向？双向流需要冲突规则，多数实体其实不需要双向。
- 每个字段的权威源？ 不是每个实体，是每个字段——ERP 拥有成本与采购，Shopify 拥有发布价格。写下所有权矩阵，这里是中途重写的头号原因。
- 什么触发同步，延迟预算多少？ 实时 webhooks、定时轮询、每晚批量，按流匹配业务：会售罄的店铺库存要近实时，成本数据批量就够了。“还没同步”是被定义的状态，不是 bug 报告。
- 冲突怎么处理？ 后写覆盖、先写优先、还是人工审核队列？钱和库存要有审计轨迹，商品描述人工审核往往更便宜。
- ERP 挂了怎么办？ 不是“如果”是“当”。定义排队行为、指数退避重试、最大可接受的过期程度，以及商家看到什么：过期的库存数字还是警告。
- ERP 里的一张订单长什么样？ ERP 订单不是 Shopify 订单。映射行项目、折扣、税、运费、退款、支付捕获、礼品卡、草稿订单——映射不干净的地方就是真正的活，永远比预估耗时。
- 部分更新怎么工作？ 客户改地址、履约后加行项目。ERP 支持部分更新吗？这决定你能用细粒度 webhooks 还是需要对账任务。
- 对账方案？ 同步会失败，问题是怎么发现。定义每日对账任务，比较总量并对漂移告警——这是让集成可信的特性，也最常被范围文档省略。
- 坏了找谁？ ERP 供应商、集成本身、Shopify API，三个故障域。决定商家打给谁、谁能读日志、谁有权限紧急暂停同步。上线前写好 runbook。
- 测试和上线计划？ 沙箱对沙箱、影子阶段（同步真实数据但不写入 ERP）、受控上线（先一个仓点或市场）。定义回滚触发条件——定义不了回滚，就没定义风险。
怎么跑这场调研
开成一次工作坊，而不是邮件链。请上商家的运营负责人、真正处理订单的人、ERP 供应商的实施人员。商家的答案和供应商的答案会不一样——那个差异就是范围。把一切写下来，包括分歧，让所有权矩阵成为提案的附录。
整个对话的框架：集成不是“同步两个系统”，而是逐字段决定谁拥有真相，并构建让每次写入的输家最终同意一致的那台机器。
什么时候需要外部帮助
如果你正要为 ERP 集成界定范围，或接手了“在同步但没人信得过”的集成——一次集成调研可以跑完这十个问题，产出所有权矩阵和流程图，把提案变成能真正定价和交付的东西。代码从来不是有风险的部分；有边界的调研才是让项目安全的部分。带着你的答案来预约 Commerce Architecture Review。