存量工作流如何分阶段迁移
旧工作流里常藏着未文档化的例外和人工补救，挑个周末全量切换，往往是把未知集中到同一个时刻爆发。
迁移前先画出真实链路：触发入口、输入来源、人工判断、外部写入和交付物。再从低风险任务开始并行运行，新流程先提供建议或结果，旧流程保留最终交付。对比两边的耗时、差异和异常处理，再扩大范围。
每一阶段都写清继续、暂停和回退条件。涉及用户数据、权限变更或资金的步骤，必须有人工确认和撤销入口。迁移不是一次发布，而是一连串收回风险的操作。
先验证行为，再交接责任
发布窗口只处理已列出的变更，临时出现的新需求放入下一阶段。这样减少同时变化的变量，异常时更容易定位。回退条件触发后，应由预先指定的人执行，不把判断与操作都压在现场最忙的人身上。迁移结束后仍保留观察期，确认边缘输入和权限变更都按预期工作，再清理旧路径。
发布窗口内只处理已经列出的变更，临时发现的新需求应进入后续阶段。这样能减少同时变化的变量，出现异常时也更容易定位。若回退条件被触发，应由预先指定的人执行，不把判断和操作都压在现场最忙的人身上。
迁移负责人维护可执行的检查表：入口流量能否回到旧流程，关键数据是否完成对账，异常队列由谁值守，权限是否按新旧系统分别收紧。模型或规则参与的步骤还要保留输入版本、输出版本和人工覆盖原因。出现差异时，团队才能判断是数据、配置还是逻辑退化。
迁移负责人应维护一份可执行的检查表：入口流量是否仍可回到旧流程，关键数据是否完成对账，异常队列由谁值守，权限是否按新旧系统分别收紧。每一项都有负责人和完成证据，避免在发布窗口里临时寻找了解细节的人。
对于模型或规则参与的步骤，保留输入版本、输出版本和人工覆盖原因。这样出现差异时能快速判断是数据问题、配置变化还是逻辑退化。只有问题能定位，分阶段迁移才真正具备学习价值。
迁移清单除了技术接口，还应列出每个例外由谁处理。旧流程中常有“某类文件由人工补齐”“某个客户需要二次确认”这样的隐含规则，必须在切换前显性化。新流程可以先运行在只读或建议模式，输出与旧流程并排，由实际处理人员标记差异。
扩大范围前，检查的不只是成功率。还要看异常是否被正确路由、人工介入是否增加、写入是否可以撤销，以及旧流程能否在规定时间内接管。涉及数据同步时，需定义主数据来源和对账方法，避免新旧两边同时修改造成难以恢复的状态。
每一阶段结束时做一次短复盘：保留哪些规则、删掉哪些临时兼容、下一阶段的风险是什么。把回退作为日常演练而不是最后手段，迁移才不会依赖某个熟悉旧系统的人。
)
