坑一：演示当验收
演示环境的问题经过挑选，模型答得漂亮不构成能力证明。把演示当验收，等于把可行性判断推给真实流量；错误一旦集中在对外场景，返工要重排接口与话术。怎么做：提前用一批脏样本试跑。
坑二：权限最后才开
网络策略、接口授权、账号开通都有审批链，平均耗时以周计。排在最后的结果是系统做完却接不进流程；为什么必须并行：审批不是开发的下游工序，立项时把审批项列全，才不会卡在最后一步。
坑三：样本过于干净
整理样本时常挑格式规整、字段齐全的记录，真实工单里错别字、缺项、手写拍照比比皆是。样本干净会让指标虚高。怎么做：按真实分布抽样，专门留一批脏数据，上线后错误率才不会抬头。
坑四：责任人虚设
接管责任写成由业务部门负责，等于没人负责。异常出现时每环都认为该由下一环处理，工单在部门之间转两天。怎么做：改成具名责任人与备份人，把接管时限写进值班表，处置速度会明显不同。
坑五：一次全量
没有灰度就直接全员开放，等于把全部风险压在同一个时刻。可行做法是先小范围放开，盯住错误类型与回流原因，再逐档放量；边界是每一档都必须留出观察时间，异常时受影响的面还收得住。
适用与不适用
适合谁
- 已立项、正在做上线准备的项目组
- 需要向管理层说明风险控制的负责人
- 有真实业务样本可供抽样复盘的团队
不适合谁
- 尚未确定场景、只做技术预研的团队
- 不允许分批放量、必须一次性切换的老系统改造
典型场景
某零售集团的商品文案生成场景在上线前做了一次风险走查：演示用例换成三百条真实商品描述，发现尺码与材质两类字段缺失严重；权限审批也从上线周提前到第三周启动。走查后团队调整了评测集与排期，上线首周错答集中在两类可预期问题，接管人在两小时内处理完。
可执行步骤
- 逐条对照五个坑，标出本项目确实存在的那几项，不做形式化确认勾选
- 为每项已识别的风险指定具名责任人与补救时点，并写进上线排期表
- 用按真实分布抽样的一批脏样本替换演示用例，重跑指标之后再判断
- 把权限、网络策略与接口授权的审批提前启动，与开发并行并记录耗时
- 设计分批放量的阶梯，每一档写清观察时长、判据、停止条件与决策人
常见坑
- 由 IT 单独推动上线，业务方只在验收会上出现，场景取舍与话术改动无人拍板，系统建好之后长期闲置。
- 把季度考核节点当成上线日期，为赶时间砍掉双跑与演练，风险全部推到上线后，反而拉长整体周期。
- 验收标准在合同里只有一句「满足业务使用」，双方理解不同，交付后反复扯皮，尾款与扩展一起被拖住。
- 没有预留返工预算与人力，第一次出错就抽调不出人，修复时间线拉长，业务方直接把流程退回人工。
自检与验收清单
- 五个坑是否逐项标注状态与责任人，而不是笼统打勾
- 评测样本是否按真实分布抽样，并专门保留脏数据
- 权限与网络审批是否已启动并有预计完成时间
- 每类异常是否都有具名接管人与明确的接管时限
- 放量阶梯与每一档的停止条件是否经业务方确认
常见问题
这五个坑哪个最致命？
权限与责任两类别最容易被低估，因为它们不影响系统能不能跑，只影响能不能用。技术问题通常有人主动去修，组织问题往往拖到业务方失去耐心才暴露，那时再补流程，团队已经形成这东西不好用的印象。
小项目也要分批放量吗？
用户少、影响面窄的内部工具可以简化，比如先在一个班组内用两周；但只要涉及对外答复、合同、财务或客户数据，就应保留分批放开与观察窗口，因为这类场景的错误代价不随用户数量减少。
怎么说服管理层接受更长排期？
用决策点代替总工期：把上线拆成可行性、可用性、放量三个确认点，每点附判据与不通过时的处置。管理层真正担心的是投入后没有结论，而不是多花两周时间，这一点讲清楚更容易争取到排期。