迁移与回滚：换工具之前先把退路想清楚

团队要引入新工具时，最容易被忽略的是"万一不行怎么退回来"。我把这次迁移的方案写下来，重点是回滚。 第一步，确定迁移范围。不要一次全换。我的做法是先挑一条独立的工作流做试点，比如"资源处理管线"，它和主流程耦合低，失败了影响面小。试点跑够时间（我用了三周）再决定是否扩大。 第二步，建立基线。迁移前记录现状指标：这条流程的耗时、人力投入、出错率、返工次数。没有基线就没法判断迁移是否成功，人的感受往往是不可靠的。 第三步，双轨运行。试点期间两套方案并行，新工具的输出不做唯一依赖。这个阶段成本高一些，但能保证业务不中断。 第四步，明确验收标准。我定的是三条：耗时下降 30% 以上、出错率不高于原方案、团队不需要额外培训就能用。三条都满足才切换。 第五步，也是最重要的——准备回滚方案。回滚要满足几个条件： 一，回滚有触发条件。指标连续两周不达标，或者出现严重的质量问题，就触发。 二，回滚有执行人。明确谁来决策、谁来执行，别到时候互相等。 三，回滚有时间窗口。超过某个时间点就沉没成本太高，要么坚持要么彻底放弃，不要拖。 四，数据要能带回来。新工具产生的配置、脚本、资产，要设计成能导出的格式，别形成锁定。 两个容易忽略的点： 一，人的因素。工具换了，人的习惯要时间，前两周效率下降是正常的，别拿前两周的数据做决策。 二，知识资产的归属。新工具里积累的提示词、技能、配置，要放在团队能管理的地方，不要散落在个人账号里。 一句话：迁移的成本不在切换那一刻，在切换之后的长尾。把回滚方案写下来，本身就是降低风险的动作。