电商进销存软件：直播团队常见误区：系统迁移为什么总遇到退货难追

直播团队把订单、库存和售后从旧系统迁到新系统后，最先暴露的往往不是库存数量差几件，而是退货件“找不到原主”：后台显示退款完成，仓库却不知道这件货属于哪场直播、哪个组合、哪次发货，客服也无法判断它究竟应该重新入库、转维修还是计入损耗。我的判断是，退货难追通常不是软件不会查，而是迁移时只搬了订单结果，没有搬完整的退货证据链。

一、先讲核心结论：退货追踪失败，本质是身份链断裂

1. 退货不是库存查询问题，而是多对象关联问题

很多团队把退货处理理解成“输入订单号，找到原订单，再减掉库存”。这套逻辑只适用于单平台、单仓库、单品、无赠品、无换货的理想订单。直播电商恰好相反：一笔订单可能包含多个商品、多个活动规则、多个包裹，甚至由不同仓库分开发出。

一件退回来的商品，至少要同时回答五个问题：它属于哪笔原订单，来自哪个平台和店铺，原来对应哪个商品规格，是否属于套装或赠品，当前应该进入什么库存状态。只要其中一个关键关联缺失，系统就可能把“已退款”误认为“可销售库存已增加”。

我在分析迁移项目时，通常把退货追踪拆成三条线：业务身份线、物流实物线、财务状态线。业务身份线回答“卖给了谁、按什么规则卖”；物流实物线回答“哪一个包裹实际回来”；财务状态线回答“钱退到了哪一步”。三条线必须能相互校验，不能只依赖订单状态。

2. 迁移最容易丢掉的不是订单，而是订单之间的关系

旧系统一般有一张订单表，但真正影响退货判断的关系可能分散在订单明细、发货单、包裹单、售后单、换货单、赠品明细、入库单和退款流水中。迁移时如果只导出“订单号、商品名称、数量、金额、状态”，表面上订单数量对得上，退货处理仍然会从第一天开始失真。

尤其是直播间常见的“买一送一”“拍一发三”“主品加赠品”“多件优惠”和“套装拆分”，前台展示的是一个活动商品，仓库实际处理的却是多个实物单位。如果迁移后只保留活动名称，没有保留实物组成，退回主品和赠品时就无法准确判断库存变化。

3. 判断迁移是否成功，不能只看库存总数

库存总数相等，只能证明某一个时点上的数量做了静态对齐，不能证明退货流程可用。真正有价值的验收，是随机抽取一批已退款、已签收退货和换货订单，检查系统能否还原完整路径。

我建议至少看四个指标：退货单关联原订单的成功率、退货包裹关联商品的成功率、质检后库存状态准确率、从售后申请到完成入库的人工耗时。前两个指标衡量“能不能找到”，后两个指标衡量“找到以后能不能正确处理”。

如果系统的订单关联率达到 98%，但包裹关联率只有 70%，团队仍然会在仓库环节大量人工翻找。退货系统的短板通常由最弱的关联节点决定，而不是由订单查询速度决定。

二、背景和真实场景：直播订单为什么比普通电商更难迁移

1. 一笔直播订单往往包含四种不同的业务对象

第一种是消费者看到的活动商品，例如“清洁套装”“三件组合装”；第二种是仓库实际拣选的库存单位，例如三个不同规格的单品；第三种是物流交付对象，例如一个主包裹和一个赠品包裹；第四种是售后处理对象，例如退主品、换规格或仅退款。

这四种对象的编号可能完全不同。直播间商品编号用于承接活动，库存编码用于拣货，物流单号用于运输，售后单号用于退款。它们不是重复字段，而是同一笔交易在不同环节留下的不同证据。

系统迁移如果把它们压缩成一行“订单号加商品名称”，等于主动删除了后续追责需要的上下文。订单在销售报表里看起来完整，退货进入仓库后却只剩下一个模糊的商品描述。

2. 一个典型的退货追踪现场

下面是我整理的一次匿名复盘案例。该直播团队有 3 个销售渠道、2 个发货仓、约 40 个高频商品编码，直播间还长期使用套装、赠品和换货政策。迁移前，团队认为只要把近 12 个月订单导入新系统，就能覆盖大部分售后需求。

迁移上线后第三周，某场活动产生了 18,600 笔订单，其中 2,940 笔进入售后流程。仓库收到退货包裹时，只有 2,410 个包裹能够通过物流单号直接关联售后单，剩余包裹需要客服根据收件人、手机号后四位、商品照片和包裹重量人工判断。

更麻烦的是，其中 380 笔订单包含赠品，190 笔订单属于多仓拆包，74 笔订单先退款后退货，另有 46 笔订单是换货重发。它们在新系统里都显示为“售后处理中”，但仓库真正需要的处理动作并不相同。

最终，团队花了 6 个工作日清理这批异常单。客服平均每天投入 7.5 小时查单，仓库投入 4 小时复核，财务还需要重新核对退款和入库差异。这个案例最值得注意的地方是：异常并不是订单量特别大，而是不同售后类型被迁移成了同一种状态。

3. 退货追踪应该还原一条可验证的路径

一条合格的退货路径，不是从“退款完成”结束，而是要能够从售后申请向前追溯到原订单、原订单明细、原发货包裹，再向后连接退回包裹、质检结果、入库状态和最终财务处理。

如果中间出现了无法解释的跳跃，例如“售后单存在，但没有原发货包裹”，或者“仓库已入库，但没有质检结论”，系统就应该将它标记为待核验，而不是自动放入可销售库存。

在实际操作中，我更看重“能否解释异常”，而不是系统能否把所有单据都强行闭环。强行闭环会让报表看起来整齐，却把真实损失隐藏在错误库存里。

三、直播团队最常见的五个迁移误区

1. 误区一：认为导出订单再导入订单，就等于完成迁移

订单迁移解决的是历史查询，不一定解决业务连续性。退货追踪所依赖的发货单、包裹号、售后单、退款流水和库存变动记录，如果没有同步迁移，系统只能查到订单的“静态快照”，无法还原订单如何从销售变成售后。

很多团队会先做一份订单数量核对表，确认旧系统和新系统的订单数一致，然后开始正式使用。更稳妥的方式是增加“关系核对表”：每 100 笔历史订单中，有多少笔能查到明细，有多少笔能查到包裹，有多少笔能查到售后，有多少笔能查到退款和入库记录。

订单数量一致，是迁移的入场券，不是迁移成功的证明。

2. 误区二：认为一个商品编码就能代表一个实物

直播活动中的“商品”经常是营销组合，而不是仓库库存单位。一个商品编码可能代表两个主品、一个赠品、不同规格的可选组合，甚至代表按场次临时配置的发货规则。

如果系统只保存组合商品编码，不保存组合结构，退回其中一个单品时，仓库无法判断库存应如何增加，财务也无法判断退款金额是否合理。更隐蔽的问题是，组合商品的库存可能在销售时被拆分扣减，但退货时却按一个组合单位回加，导致库存逐渐失真。

迁移前必须明确：哪些编码是销售展示单位，哪些编码是实际库存单位，哪些编码只是赠品或活动标签。三者不能混用。

3. 误区三：认为有订单号，就能处理全部售后

订单号适合定位交易，但不一定适合定位实物。一个订单可能拆成多个包裹，同一个包裹也可能装入多个订单的合并发货商品。退货包裹回到仓库时，实际首先出现的是物流单号、称重结果和包裹内容，而不是消费者输入的订单号。

如果退货面单上的物流单号没有回写到售后单，仓库只能依靠人工搜索。尤其在大促之后，消费者可能一次寄回多个订单商品，包裹外包装又缺少清晰标识，这时单纯搜索订单号的办法几乎失效。

4. 误区四：认为退款完成就代表退货完成

退款和退货是两个时间轴。平台可能先行退款，消费者数日后才寄出商品；也可能商品已经签收，仓库尚未完成质检；还可能消费者只申请退款不退货。将这几种情况合并为“已完成”，会直接影响可售库存、残次品库存和财务损益。

我建议至少设置“退款状态”和“实物状态”两组字段。退款状态可以是待审核、退款中、退款完成、退款关闭；实物状态可以是未寄回、运输中、已签收待检、质检合格、质检异常、已入库。两组状态独立变化，最终再由规则判断售后单是否真正关闭。

5. 误区五：为了上线速度，主动放弃异常处理规则

有些团队会说：“先把主流程跑起来，异常以后再处理。”这句话在普通订单录入中或许可行，在退货环节却很危险。异常单不会消失，只会被堆到仓库、客服和财务三个部门之间，最后变成无法解释的库存差异。

上线初期可以减少低频功能，但不能省略高频异常的归类。至少要提前定义拆包退回、少件退回、错件退回、换货重发、仅退款、赠品退回和无法识别包裹的处理方式。

四、专业判断逻辑：先建立退货对象模型，再选择系统方案

1. 用三条主线判断系统是否真的支持退货追踪

第一条是业务身份线，核心字段包括渠道、店铺、直播场次、原订单号、订单明细号、活动商品编码和消费者售后原因。它决定团队能否解释这笔交易为什么以当前价格和组合成交。

第二条是实物物流线，核心字段包括发货单号、包裹号、物流单号、仓库、实际出库商品、退回商品、签收时间和质检结果。它决定仓库能否把退回来的实物放到正确的处理队列。

第三条是财务状态线，核心字段包括应收金额、优惠分摊、退款金额、退款时间、平台扣款和损益归属。它决定财务能否解释为什么退款金额和库存价值不完全相等。

这三条线中，业务身份线解决“这是什么交易”，物流实物线解决“这是什么货”，财务状态线解决“这笔钱发生了什么”。任何一条缺失，都不应把系统宣传为完整的退货闭环。

2. 建立“事件”而不是只保存“最终状态”

最终状态只能告诉我们现在是什么，不能告诉我们为什么变成这样。退货追踪需要保留关键事件，例如售后申请、平台审核、消费者寄出、物流签收、仓库收货、质检完成、退款完成、重新入库和报损处理。

每个事件至少应该有事件时间、操作者或来源、关联对象、前后状态和异常备注。这样，当一笔退货出现“已退款但未入库”时，客服可以看到是消费者尚未寄回、物流已签收待检，还是仓库已经收货但没有完成质检。

如果系统只能显示一个不断变化的状态，而看不到状态变化过程，团队就会在争议发生时反复询问不同部门，无法快速判断责任节点。

3. 为高风险订单设置最小字段集

不建议一开始就把所有历史字段全部迁移。更有效的做法是先识别高风险订单，再为这些订单建立最小可追踪字段集。高风险订单通常包括多包裹订单、套装订单、赠品订单、换货订单、跨仓订单和高金额订单。

4. 判断系统能力时，不要只看功能清单

供应商演示时，很多系统都能展示订单搜索、库存查询和售后列表。但真正需要追问的是：能否从退货物流号反查原订单，能否处理一单多包裹，能否将换货和退款分开，能否记录赠品组成，能否冻结待质检库存，能否保留迁移前后的原始编号。

我通常会要求现场演示一笔“最麻烦的订单”，而不是一笔普通订单。测试订单应包含套装、赠品、拆包、换货和退款先行中的至少两种情况。普通订单跑通，只能证明页面流程存在；复杂订单跑通，才说明数据模型足够扎实。

五、案例与数据观察：真正有效的迁移，先降低人工判断次数

1. 用试运行而不是口头承诺验证迁移质量

一套退货流程是否可靠，最好的验证方法不是开会讨论，而是选择一段真实历史订单做回放，再选择一周新订单做并行试运行。历史订单用于验证能否还原，新增订单用于验证系统能否持续接收新的物流和售后事件。

在一组匿名试运行样本中，我们将 4 周的退货单分成普通单、组合单、拆包单和换货单四类。第一周只迁移原订单和商品明细，第二周补充包裹关系，第三周补充售后与退款事件，第四周再增加质检和库存去向字段。

结果很有代表性：第一周订单能查到，但仓库人工判断量几乎没有下降；第二周包裹识别改善；第三周客服开始减少跨部门询问；第四周财务对账差异才明显收敛。退货效率的改善通常滞后于订单迁移，因为真正耗时的是跨对象核对，而不是打开订单页面。

2. 观察三个比“系统上线”更有价值的指标

第一个指标是“首次定位成功率”，即客服或仓库第一次输入现有信息后，能否直接找到正确的原订单和包裹。这个指标比平均查询时长更能反映数据是否完整，因为反复查找会把平均时长掩盖掉。

第二个指标是“人工补录率”，即退货处理过程中需要手工增加关联关系、修改商品、补录物流号或重新判断库存去向的订单比例。人工补录率高，意味着系统仍把关键判断推给了人员。

第三个指标是“错误关闭率”，即售后单已经关闭，但之后又发现退款、实物或库存状态不一致的比例。这个指标最能揭示系统是否为了报表好看而过早关单。

在我采用的复盘口径中，首次定位成功率低于 90% 时，不建议直接扩大迁移范围；人工补录率超过 15% 时，应先检查字段和规则；错误关闭率超过 3% 时，应暂停自动关单，优先修正状态模型。

3. 退货处理成本要按“单次异常成本”计算

很多团队只计算系统采购或实施费用，却不计算退货异常造成的隐性成本。一笔异常退货通常需要客服查订单、仓库找包裹、主管判定库存、财务核退款，实际成本由多个岗位共同承担。

可以用一个简单公式估算：月度退货异常成本 = 异常退货单量 × 单笔平均处理分钟数 ÷ 60 × 相关岗位平均小时成本，再加上错入可售库存、重复退款、丢件赔付和报损误判等直接损失。

例如每月 6,000 笔退货中有 12%需要人工深度核验，单笔平均耗时 18 分钟，客服、仓库和财务综合小时成本按 85 元估算，仅人工核验就约为 11,016 元。若每月再出现 20 笔误入可售库存的商品，每笔平均造成 260 元损失，真实成本还要继续上升。

这也是为什么有些团队觉得“系统已经上线，但没有省人”：它们只迁移了查询功能，却没有减少异常判断次数。

4. 不要被“退货率”一个数字误导

国家统计局发布的《2024年国民经济和社会发展统计公报》显示，2024年全国网上零售额为 15.52 万亿元，其中实物商品网上零售额为 13.08 万亿元。这个公开数据能够说明线上交易规模持续庞大，但并不能直接推导某个直播团队的退货率、退款率或异常率。

直播团队需要使用自己的订单数据建立口径：退货申请率、实际寄回率、签收率、质检不合格率、可二次销售率和退款完成率必须分开统计。把“申请退货”直接称为“退货率”，会把尚未寄回的订单和已经入库的退货混在一起。

在系统迁移阶段，最重要的不是找一个行业平均数，而是建立迁移前后的同口径对比。只要统计范围、订单类型和时间窗口一致，团队就能判断问题到底来自系统、仓库、平台规则还是商品本身。

六、不同情况下的行动建议：不要用同一套迁移方案解决所有团队

1. 单平台、单仓库、标准商品占比高的团队

这类团队的主要风险不是多仓和复杂组合，而是历史数据不完整、售后状态不统一。迁移重点应放在原订单、订单明细、物流单号、售后类型和退款流水五类数据。

建议先选择近 90 天订单做全量迁移，再抽取更早历史订单作为只读查询。这样既能满足近期售后需要，又避免为低频历史数据投入过高清洗成本。

• 先统一商品编码和规格名称，再导入订单。
• 为仅退款、退货退款和换货分别设置流程。
• 抽取至少 100 笔已完成售后单进行回放。
• 把无法确认的历史订单标记为待核验，不要强行补成正常单。

2. 多平台、多店铺、直播场次频繁切换的团队

这类团队最容易遇到同一商品在不同渠道使用不同编码、不同优惠规则和不同订单编号。迁移时不能把平台订单号当成全局唯一键，应该建立内部业务单号，并保留平台原始单号作为外部追踪键。

直播场次也应该成为可查询维度。它不仅用于复盘销售效果，还能帮助团队识别某场活动的赠品规则、发货承诺和售后政策。没有场次维度，出现集中退货时，团队很难判断是商品问题、主播承诺问题还是活动配置问题。

（1）平台订单号与内部订单号分离

平台订单号负责对外沟通，内部订单号负责跨平台关联。两者同时保存，能够避免同一个消费者在不同店铺下单后被错误合并，也能避免平台编号规则变化影响内部查询。

（2）优惠分摊必须落到明细

组合优惠、满减和赠品成本不能只保存在订单总额。退回其中一个商品时，如果没有明细级优惠分摊，退款金额和库存价值就会出现长期偏差。

3. 多仓发货、第三方仓配或合并发货的团队

这类团队要把“仓库”提升为退货判断的核心维度。同一订单从不同仓库发出时，退货可能分别寄回不同地址，也可能统一退回售后仓。系统必须保留原发货仓和实际退回仓，不能只记录当前库存所在仓。

如果使用第三方仓配，至少要约定物流事件回传频率、包裹号格式、退回件明细、质检结果和异常件照片的交付方式。接口只回传“已签收”，却不回传包裹内容和质检结果，系统仍然无法完成库存判断。

• 按仓库分别统计退货签收时效。
• 区分平台退货地址、仓库退货地址和售后集中仓地址。
• 为跨仓调拨和退回入库分别建立库存事件。
• 对第三方仓返回的数据设置必填校验，不接受只有状态没有对象的回传。

4. 正在大促前紧急迁移的团队

大促前不适合做一次性全量切换。最稳妥的方式是保留旧系统作为历史查询和兜底系统，新系统先承接一个渠道、一个仓库或一组标准商品，复杂组合和换货订单暂时采用人工复核。

如果团队没有足够时间清洗全部历史数据，应优先迁移仍处于售后窗口内的订单，而不是优先迁移销售金额最高的订单。对退货业务而言，时间窗口比销售金额更能决定迁移优先级。

七、不同情况下的取舍：系统越复杂，不一定越适合你的团队

1. 一次性切换与双轨并行的取舍

一次性切换的好处是管理简单、人员不会长期维护两套流程，但它把数据清洗、员工培训、接口切换和新流程适应全部压缩在一个时间点。只要退货关系有一个环节出错，问题就会在大促后集中爆发。

双轨并行会增加短期工作量，客服和仓库需要明确哪一笔订单在哪个系统处理，但它能提供真实的对照数据。我的建议是：如果月均退货量高、组合商品多或仓库超过一个，宁愿多花两到四周并行，也不要为了表面上的快速上线承担后续清账成本。

2. 自动关单与人工复核的取舍

自动关单能够减少操作步骤，但前提是状态和对象关系足够可靠。对于单件标准商品、物流签收明确、质检规则简单的退货，可以设置自动推进；对于组合商品、赠品、换货、少件和高金额订单，应保留人工复核节点。

一个实用的做法是按风险分层，而不是全自动或全人工二选一。低风险订单自动处理，中风险订单抽样复核，高风险订单必须由仓库或主管确认后才能改变库存状态。

3. 精确到包裹与保持操作简单的取舍

包裹级追踪能显著提高多包裹和合并发货订单的可追溯性，但也会增加仓库扫描、标签打印和异常维护成本。如果团队每天只有少量订单、商品结构简单，过度细化可能让一线人员觉得流程繁琐。

判断是否需要包裹级追踪，可以用三个条件：多包裹订单占比是否超过 10%，退货包裹无法识别是否已经造成明显人工成本，仓库是否具备扫码或称重条件。满足其中两个条件，就值得建设包裹级关系。

4. 标准功能与定制开发的取舍

标准功能适合解决普遍流程，例如订单查询、售后登记、库存冻结和质检入库。定制开发适合解决团队特有的组合规则、平台字段映射、第三方仓接口和复杂退款分摊。

不要把定制开发当成弥补基础数据混乱的办法。如果商品编码、仓库编码和售后类型都没有统一，再复杂的接口也只会把混乱更快地传递到新系统。先统一对象和规则，再决定哪些环节值得定制。

八、落地执行：用三十天完成一次可控的退货迁移

1. 第1周：盘点对象、编码和异常类型

第一周不要急着导数据，先把现有系统中的对象列清楚。至少包括平台订单、内部订单、订单明细、销售编码、库存编码、包裹、物流单、售后单、退款单、质检单和库存变动单。

同时抽取近三个月的退货订单，按单件、套装、赠品、拆包、换货、仅退款和异常件分类。不要只统计数量，还要记录每类订单在现系统中的关联完整度和人工处理时间。

• 列出所有渠道、店铺和仓库。
• 建立销售编码与库存编码的对应表。
• 标记一个订单多包裹、一个包裹多订单的情况。
• 统计退款完成与实物入库之间的平均时间差。
• 挑选至少 20 笔最复杂订单作为迁移验收样本。

2. 第2周：建立映射规则并做历史回放

第二周重点不是追求全量导入，而是验证字段映射。每一类订单至少选择一批样本，将旧系统记录与新系统记录逐字段比对，特别关注组合组成、优惠分摊、包裹关系和售后类型。

历史回放时，要从退货单反向查询原订单，而不是只从订单正向查看售后。因为实际工作通常是包裹先到仓库，仓库人员需要从物流号或退货面单开始定位。

3. 第3周：用真实新单做双轨试运行

第三周可以选择一个仓库或一个渠道承接新退货。旧系统保留原有流程，新系统同时记录关联结果，但不立即让新系统自动改变库存。这样可以把新系统的判断结果和人工最终结果进行对照。

每天记录三类问题：系统找不到对象、系统找到对象但判断错误、系统判断正确但操作太复杂。三类问题的解决方式不同，不能都归结为“培训不到位”。

4. 第4周：设置冻结规则和正式切换门槛

正式切换前，应设置几条不可妥协的门槛：高风险样本的原订单关联率达到 98% 以上，包裹关联率达到团队可接受水平，组合商品能还原实际库存单位，退款状态和实物状态能够分开查询，异常单能够进入待核验队列。

如果某个指标没有达到要求，不一定要推迟全部上线，但必须缩小上线范围。例如先上线标准单，再保留组合单人工处理；先上线一个仓库，再扩展到其他仓库；先迁移售后窗口内订单，再迁移历史订单。

5. 每天保留一份退货异常台账

异常台账不应只是记录“某单有问题”，而要记录问题对象、发现环节、临时处理方式、根因、是否需要补数据以及最终修复时间。连续一周后，团队通常会发现大量异常都集中在少数几类关系上。

九、最后的决策建议：先问清楚三件事，再决定是否迁移

1. 你要迁移的是数据，还是要迁移一套可继续运行的业务

如果目标只是查历史订单，迁移范围可以较小；如果目标是让新系统承接未来退货，就必须迁移关系、状态和事件。两者的字段数量、验收方式和上线风险完全不同。

我见过不少团队把“历史订单导入完成”当作“售后可以正常接续”，结果新订单从新系统产生，旧订单的退货还在旧系统处理，两个系统之间没有统一的关联方式。最终客服需要同时登录多个系统，仓库仍然靠人工判断。

2. 你真正要降低的是哪一种成本

如果最痛的是客服查单，就优先补齐订单、售后和包裹关系；如果最痛的是仓库错入库存，就优先建设质检状态和库存去向；如果最痛的是财务对账，就优先处理退款分摊和状态时间轴。

不要为了“功能齐全”一次性建设所有模块。先找到每月损失最大、重复发生最多、最容易形成责任争议的环节，再用数据关系解决它。

3. 你愿意为多高的准确率付出多少操作成本

追踪越细，扫码、标签、质检和人工复核就越多。对低价值、低风险商品，过度精细化可能得不偿失；对高价值、易调包、组合复杂或退货损失高的商品，增加包裹和质检记录往往是必要成本。

最终方案不应追求“所有订单都用同一种流程”，而应根据商品价值、退货概率、仓库复杂度和错误损失设置不同等级。最好的退货系统不是把所有事情自动化，而是把人工判断留在真正值得判断的地方。

4. 下一步可以马上做的七个动作

1. 随机抽取 100 笔已退款订单，检查能否从退货信息反查原订单。
2. 再抽取 50 笔套装、赠品或换货订单，检查实际库存单位是否能够还原。
3. 统计订单、包裹、售后、退款和入库五类对象的关联成功率。
4. 把“退款完成”和“实物入库”拆成两个独立字段。
5. 为无法识别的退货包裹建立待核验队列，不允许直接进入可售库存。
6. 用一周真实新单做双轨对照，记录人工补录率和错误关闭率。
7. 根据数据决定采用一次性切换、双轨并行，还是分仓分阶段迁移。

电商进销存软件的迁移难点，从来不只是把旧数据搬到新页面，而是要把一笔交易在销售、发货、退货、质检、入库和退款之间的关系继续保存下来。直播团队最容易踩的坑，是把“订单存在”误认为“退货可追踪”，把“退款完成”误认为“库存已恢复”。

我的独特判断是：评估迁移质量时，最应该测试的不是最顺畅的普通订单，而是最复杂的退货包裹。如果系统能解释一件混合套装退回了什么、缺了什么、钱退了多少、库存应该去哪，并且每一步都有可复核记录，那么迁移才真正完成。下一步不要先问系统有多少功能，先拿真实异常订单做回放，用数据决定哪些关系必须迁移、哪些流程可以简化、哪些环节必须保留人工判断。