第一步：冻结评测集
把真实业务样本整理成带预期结果的评测集，覆盖常见、边界与应当拒答的情形，并在测试开始前冻结版本。为什么：边测边改样本，结果无法比较，也无法证明系统在真实分布上的表现。冻结后若要补样本，应另开一轮并单独记录。
第二步：定通过标准
明确每个指标的判定方式与容错范围，例如任务完成、人工接管、引用是否可查、拒答是否正确。怎么做：把标准写成可勾选的判定项，写进验收单并当场确认，避免用基本可用、体验良好这类无法验证的描述。
第三步：分工执行
业务方判断结果对不对，技术方判断系统稳不稳，安全方判断越权与数据暴露。为什么分开：让开发自己测自己的功能等于没有测试。业务判断是验收不可替代的部分，技术记录只解决稳定性问题。
第四步：缺陷与回归
每个不通过项登记复现步骤、影响范围、责任人与修复版本，修复后在同一评测集上回归。边界：影响主流程的缺陷未关闭不得进入上线，非主流程缺陷可列入观察清单，但需业务方书面确认接受，避免上线后才补救。
第五步：签署验收单
验收单要写明测试范围、评测集版本、通过项与未通过项、遗留风险与后续责任。为什么：验收单是后续争议时唯一的事实依据。口头确认在换人之后没有约束力，也难以追溯当时到底测了什么，也便于后续复盘。
适用与不适用
适合谁
- 即将把 AI 应用交付业务使用的项目组
- 需要向客户或审计证明系统可用的实施方
- 上线前缺乏统一验收口径的多团队协作项目
不适合谁
- 还处在需求讨论、没有可运行系统的阶段
- 不接受用真实业务样本做评测的项目
典型场景
某医药流通企业的订单助手进入验收。业务方从三个月真实工单中抽取样本并标注预期答案，技术方在预发环境执行，安全岗补测越权查询。测试发现三类拒答错误，修复后在同一评测集回归通过，双方在验收单上签字并附遗留清单。
可执行步骤
- 从真实工单中抽取样本、标注预期结果，并在测试开始前冻结样本版本。
- 把通过标准写成可勾选的判定项，逐项写明容错范围与判定责任人。
- 按业务、技术、安全三方分工执行，各自留存测试记录与判定依据。
- 登记每个缺陷的复现步骤、影响范围、责任人与目标修复版本号并跟踪。
- 修复后在同一评测集上整轮回归，确认原问题关闭且没有新增退化项。
- 业务与技术双签验收单，并附未通过项、遗留风险与后续责任人名单。
常见坑
- 用演示数据代替真实样本，测试顺利通过而上线后问题集中暴露，返工成本比预期高得多。
- 看到测试结果后再调整通过标准，验收退化为确认既有结论的仪式，风险被留在生产环境。
- 只测正常路径，不测拒答、越权与异常输入，风险被完整带入生产环境才被发现，排查更慢。
自检与验收清单
- 评测集是否已冻结版本、标注预期结果并可被复用
- 通过标准是否可勾选、可复核、不含模糊描述
- 业务、技术与安全三方的测试记录是否分别留存
- 每个缺陷是否登记到责任人并明确目标修复版本
- 验收单是否双签并附未通过项与遗留风险清单
常见问题
验收测试要跑多久？
取决于场景数量与样本准备情况，通常在评测集冻结后按轮次推进：首轮发现缺陷，修复后回归，直至主流程缺陷清零。时间不宜压缩在最后两天，因为样本标注与业务确认往往比执行更耗时。
谁来提供测试数据？
由业务方提供并负责脱敏，技术方负责导入与环境隔离。测试数据不应包含可直接识别个人的信息，若必须使用真实数据，应先做去标识化并限制访问范围，用完按约定清除。
通过率多高才算合格？
不设通用数值，由业务方根据场景风险确定，并写进验收单。高风险场景应逐条通过，低风险场景可设容错比例。关键是标准事先确定、口径一致，而不是事后解释为什么某一项没过。