误区一：把演示当产品
演示为了好看，往往只保留顺利路径与精选数据；最小可用产品要能承受真实输入的杂乱。为什么危险：业务方按演示效果做承诺，落差最后由一线承担。改法是把演示脚本换成真实工单抽样，先看错误率再谈上线范围。
误区二：只测正常路径
大多数事故发生在异常输入、超时与并发上。只测正常路径，等于把风险留给上线后的客户。改法是列一份异常清单：空值、超长文本、语义歧义、系统超时、权限不足，逐条设计预期行为并纳入评测集，每次发布前跑。边界是清单随事故类型更新。
误区三：忽略权限与数据边界
演示环境常给全量权限，生产必须按岗位最小授权。边界不清的后果是安全评审卡住，或上线后被要求整改停用。改法是在设计阶段画出权限矩阵，明确谁能看哪些字段，并同步确定日志留存期限与脱敏规则。
误区四：没有接管人与排班
接管机制写在文档里，却没有具体人和时间，等于没有。为什么常见：项目组以为模型足够准，不需要人盯。改法是把接管写进值班表，明确响应时限与升级路径，首月按日统计接管量，据此判断是否需要缩范围。
误区五：把上线当结束
上线只是开始，模型、数据与业务都在变。没有月度复盘与评测集更新，系统会在几个月内悄悄退化。改法是设一个轻量月度检查：抽样错误、更新评测题、核对知识有效期，并指定负责人，把结果写进下季度计划。边界是检查要留记录，否则等于没做。
适用与不适用
适合谁
- 即将进入上线评审的项目组与产品负责人
- 已上线但错误反复、无人说得清原因的团队
- 需要给演示项目做上线前自查的负责人
不适合谁
- 只做一次性演示、不承担责任范围的项目
- 不愿安排值守、也不准备做月度检查的组织
典型场景
一家保险公司的理赔助手演示时准确率很高，上线后却频繁给出错误的材料清单。排查发现演示只用了标准案件，真实案件大量缺页与模糊扫描。团队补了异常清单与低置信转人工，缩到三类标准案件先跑，两个月后才逐步放开其他类型。
可执行步骤
- 用真实工单抽样重跑一遍演示，记录错误率、错误类型与缺失数据的比例
- 列异常清单，逐条定义预期行为并纳入评测集，发布前必须跑过，结果由技术负责人留档
- 画出权限矩阵，明确字段级访问、脱敏要求与日志留存期限，由安全评审签字
- 设月度检查，更新评测题与知识有效期，并指定负责人跟踪，结论进季度计划
常见坑
- 用精选数据演示，业务方按理想效果排产，上线后落差由一线消化，信任很难恢复，二次推动更难
- 异常场景没有预期行为，出错时开发与业务互相推责，问题反复出现，客户投诉后才补测试
- 权限一次给全量，扩范围时无人敢收，审计时也说不清谁看过什么，只能整体重建权限，审批也更难通过
- 上线后无人复盘，评测集半年未更新，退化无人察觉，直到客户投诉，恢复需要重新评测，客户已经在别处采购
自检与验收清单
- 是否用真实工单重跑过演示并记录错误类型与数据缺口
- 异常清单是否覆盖空值、超时与权限不足，每条有预期
- 权限矩阵是否细到字段级并可审计，扩范围是否重评
- 是否有月度检查与明确的负责人，结论是否留档
常见问题
演示阶段就要准备这些吗
至少准备评测集与权限草案。演示阶段的目标是验证方向，不必做全部工程；但把真实样本与权限要求提前想清楚，可以发现方向本身是否可行，避免投入后才发现数据拿不到。
权限给多了会有什么后果
短期看不出问题，长期难以收回，且一旦发生数据泄露难以界定责任。生产环境按岗位最小授权，扩范围时重新评审，这是责任边界，不是流程繁琐；把矩阵写下来，后续交接也更容易。
怎么判断该缩范围还是继续调
看错误是否集中在少数场景。若某类问题反复出错且与数据缺失有关，先缩范围；若错误分散、原因不明，继续调也很难收敛，应回到评测集找出系统性缺口。