倒排而非顺排
先定上线日期，再倒推签署、回归、修复各占多久，最后确定测试开始时间。为什么倒排：顺排容易把测试挤到最后几天，倒排能尽早暴露样本还没标注这类硬约束，留出协商与压缩的空间，遇到依赖方不配合时应前移日期而不是压缩测试。
准备段最易低估
样本抽取、脱敏、标注、用例编写往往比执行更耗时，且依赖业务方排人。怎么做：把准备段单列里程碑，样本未冻结不进入执行段，避免边测边补样本，导致最后两轮结论无法比较，样本冻结后再改口径，等于重做一轮。
依赖一：环境一致
测试环境与生产的模型版本、检索库、权限配置需一致，否则结果不可迁移。边界：无法一致的项要写入验收单的未覆盖范围，不能默认等价，也不要在汇报时把未覆盖说成已通过，差异清单要附在验收材料里。
依赖二：账号权限
测试账号、数据访问授权、外部接口白名单常在执行当天才发现没开通。怎么做：把账号清单与权限申请提前到准备段，指定一人跟踪开通状态，并每天同步一次开通进度，开通状态应作为执行段的准入条件。
依赖三：人员档期
业务判定人往往是最忙的人，档期冲突会直接拉长执行段。怎么办：提前锁定判定人的时间段，采用半天集中判定的方式，比分散在全周更现实，也更容易保持判定口径一致，判定人缺席时宁可延期也不要代判。
适用与不适用
适合谁
- 需要给出验收与上线日期的项目经理
- 业务方档期紧张、测试常被压缩的项目
- 跨部门协作、依赖多方开通权限的场景
不适合谁
- 随时可测、无固定上线窗口的内部实验
- 尚未确定范围、无法倒排排期的项目
典型场景
某车企的售后知识助手计划在季末上线。项目经理倒排后发现问题不在执行而在样本标注：业务专家只有两天可参与。团队把判定集中到两个半天，并提前一周完成脱敏与账号开通，测试按期完成，回归与签署留出了缓冲。
可执行步骤
- 从上线日期倒推签署、回归、修复与执行四段各自占用的工作日数。
- 把样本抽取、脱敏与标注单列为准备段的里程碑，完成才进入执行。
- 逐项核对测试环境与生产在模型版本、检索库与权限配置上的差异。
- 提前提交测试账号与接口白名单申请，并指定专人每天跟踪开通状态。
- 提前锁定业务判定人的集中时段，采用半天集中判定而不是全周分散。
常见坑
- 把验收排到最后一周，样本尚未标注就开始执行，边测边改导致结论不可比，也无法补测。
- 测试环境的模型版本落后于生产，通过的结果上线后无法复现，需要重新验证并推迟发布。
- 账号与白名单到执行当天才申请，执行段空转数日，修复时间被挤压，最后只能带缺陷上线。
自检与验收清单
- 排期是否从上线日期倒推并留出回归与修复缓冲
- 样本抽取、脱敏与标注是否单列为独立里程碑
- 测试环境与生产的差异是否书面列明并逐项评估
- 业务判定人的集中时段与替补是否提前锁定，避免临时换人。
- 测试账号与接口白名单是否在执行前开通完毕
常见问题
验收能和生产上线并行吗？
不建议对同一批功能并行。并行会让人分不清问题是版本引入还是环境差异，也会让业务方在系统变动中难以判定。可行的是分批验收：先验收稳定的核心场景，再验收增量部分。
业务方档期实在排不开怎么办？
缩小验收范围并与业务方确认哪些场景本期不验收，写进验收单。不要用技术方代判来填补空缺，那等于把风险转移到上线后。范围缩小但结论真实，比范围大而结论虚假更有价值。
回归要占多久？
取决于缺陷数量与评测集规模，通常按修复完成后的完整重跑估算，而不是只测改动的点。因为 AI 系统的改动常有连带影响，只测改动点容易漏掉退化，回归时间不应被压缩到半天。