先冻结范围
上线前把交付的功能、不做的事、已知缺陷写成三栏表并冻结。为什么不能边上线边改：范围一动，测试结论与回退点同时失效；冻结不是不许改，而是改动必须走变更单，并重跑受影响的用例。
双跑比对数据
新旧流程并行跑一到两周，同一批任务两边各出一份结果，逐条比对差异。为什么值得多花这两周：模型输出的偏差往往只在特定输入上出现，单看抽样演示几乎发现不了，双跑能把差异摊成一份可讨论的清单。
接管名单到人
列一张表，写清哪类异常由谁在什么时限内接管，附电话与备份人。为什么要落实到人：没有姓名的接管承诺等于没有接管；上线后第一次出错若找不到人，业务方通常当天就把系统停掉。
留一个观察窗口
上线首周按天记录错误类型、接管次数与人工回流原因，别只看调用量。观察窗口怎么用：它把能跑和可长期用分开，调用量会因新鲜感虚高，回流原因才说明系统究竟卡在哪一步。
回退包提前就位
把上一版提示词、知识库快照、接口开关与人工流程整理成一个半小时内能切回来的包，并在上线前演练。为什么要演练：回退手段有没有练过，差别在真出事那半小时里非常明显，事后补来不及。
适用与不适用
适合谁
- 已完成原型、准备进入真实业务的项目组
- 有明确业务负责人且能指定接管人的团队
- 愿意接受观察窗口内按天复盘的交付节奏
不适合谁
- 还在比方案、尚无可用真实样本的项目
- 要求上线当天即全量开放、不留观察期的系统
典型场景
某物流企业的运单地址纠错场景准备上线。交付方先冻结范围，把偏远地区识别不准列为已知缺陷；信息中心开放只读接口支撑双跑；客服主管指定两名接管人并排班。上线首周每天上午对一次错误清单，第八天由业务负责人签字转为常规运营。
可执行步骤
- 把功能、不做的范围与已知缺陷写成三栏表，由业务负责人签字冻结
- 安排新旧流程并行双跑两周，收集同一批任务的两份结果逐条比对差异
- 指定每类异常的接管人、备份人与接管时限，并把联系方式写进值班表
- 上线前完整演练一次回退，记录从下令到业务恢复的实际耗时与卡点
- 上线前完整演练一次回退，实测切换耗时，把每个卡点逐条记录下来
常见坑
- 只在演示数据上验收，真实流量一进来就出现大量格式异常，团队被迫在高峰期边修边用，回退点也被冲掉。
- 上线当天才找运维开权限、放网络策略，卡在审批上，业务方空等两天，项目节奏和信任一起受损。
- 接管名单只写部门不写人，出错时互相推诿，问题从工单升级成投诉，最后靠停用系统收场。
- 观察窗口只看调用量，没记录回流原因，一周后谁也说不清系统到底解决了什么，扩展立项缺乏依据。
自检与验收清单
- 上线范围、不做的范围与已知缺陷是否书面冻结
- 双跑差异清单是否逐条有结论，未闭环项有处置人
- 每类异常是否有具名接管人、备份人与接管时限
- 回退包是否演练过并记录从下令到恢复的耗时
- 观察窗口的复盘节奏、记录口径与决议人是否确定
常见问题
上线一定要双跑吗？
建议做，尤其是涉及对外答复或财务数据的场景。双跑的价值不在证明系统好用，而在把差异摊到可讨论的清单上；样本极少或业务量太小时可缩短到一周，但不宜完全跳过，否则问题只能靠用户投诉暴露。
观察窗口设多久合适？
常见做法是一到两周，覆盖至少一个完整业务周期，比如月结、周报或排班轮转。窗口太短会错过低频高影响的错误，太长则团队注意力涣散；关键是窗口内每天有固定的人看同一组指标。
上线后业务方不用怎么办？
先分清是不好用还是不愿用：前者查接管率与错答类型，后者查考核与流程是否同步调整。多数弃用发生在流程未改、AI 只是多出一道工序的场景，这时继续优化模型收效有限，应先改流程与岗位分工。