坑一：样本失真
用的是精心准备的演示问题，而不是真实工单里的错别字、省略与多意图混合。为什么危险：模型在干净样本上表现好，在真实分布上未必。改法是从生产日志抽样，保留原始表达，不替用户润色，也不要把长问题截断成短问题。
坑二：标准后置
先跑测试再定及格线，看到结果后把标准调到刚好通过。怎么改：在测试开始前把判定项与容错范围写进验收单，过程中只允许记录不允许改标准，确需调整要走变更并整轮重跑，否则前后两轮的数字不能放在一起看。
坑三：自测自验
开发者既写功能又判定结果，容易把我知道它想说什么当成系统正确。怎么做：业务方判断输出是否有用，技术方只看稳定性与日志，两套记录分开留存，由业务方在验收单上签认，判定权与实现权分开才有人对结论负责。
坑四：只测主流程
正常下单、正常问答都通过，但拒答、越权、超长输入、并发与断网都没测。为什么：异常表现更能说明系统边界，涉及权限与数据的场景漏测代价最高，补测还要重新排队列，正式上线前应补一轮异常专项测试。
坑五：缺陷无归属
记录了一堆问题却没人认领，修复版本与验证人都空着，最后不了之。怎么做：每条缺陷必须填责任人、目标版本与验证人，未填完不得进入上线评审，评审时逐条过而不是只看汇总数字，评审记录留档以便下轮对照。
适用与不适用
适合谁
- 第一次组织 AI 系统验收的项目组
- 验收反复但上线后问题仍然很多的团队
- 需要把验收流程制度化的企业质量岗
不适合谁
- 尚未有可用系统、仍在概念验证阶段
- 不打算留存任何测试记录的一次性试用
典型场景
某零售集团的客服助手首轮验收通过率很高，上线后投诉集中在多意图提问。复盘发现测试样本是产品经理自己写的标准问法。团队改为从真实会话抽样，并把多意图与拒答列入必测项，第二轮测试才暴露出真实问题。
可执行步骤
- 从生产日志随机抽样，保留错别字、省略与多意图并存的原始表达。
- 测试开始前把判定项与容错范围写进验收单并冻结，之后不再调整。
- 业务方判断输出是否有用，技术方只判断稳定性，两类记录分开留存。
- 把拒答、越权、超长输入、并发与断网列为每次必测的异常场景项。
- 每条缺陷必须填写责任人、目标修复版本与验收验证人姓名并跟踪关闭。
常见坑
- 用产品经理写的标准问法做样本，测出的通过率与真实用户体验没有关系，验收结论也就失去参考价值。
- 测试中途修改判定标准，前后数据不可比，验收结论事后无法追溯，争议时谁也说不清依据。
- 开发者自己判定输出正确，把模型的自解释当成事实，偏差被系统性忽略，上线后才集中爆发。
- 只跑正常路径，权限与异常场景零覆盖，上线后第一个严重问题正来自未测项，复盘时很被动。
自检与验收清单
- 测试样本是否来自真实生产数据而非人工编造，且不允许中途调整。
- 判定标准与容错范围是否在测试开始前冻结并公示
- 业务判断与技术判断的记录是否分开留存归档，覆盖是否足够。
- 拒答、越权、超长输入等异常场景是否覆盖，缺一项不算关闭。
- 每条缺陷是否都有责任人与验收验证人签字确认
常见问题
样本量要多少才够？
没有统一数值，取决于场景数量与分布复杂度。实践上先做到每类场景都覆盖样本，再逐步扩充长尾；比起追求数量，更重要的是覆盖真实分布中的典型表达与边界情形，否则样本再多也测不到真问题。
业务方没时间参与怎么办？
那就把验收范围缩小到业务方愿意确认的部分，其余部分明确标注为未验收。让技术方代替业务判断看似省事，实际把风险留到了上线之后，而且出了问题无人能为此负责，最后还是要业务兜底。
验收测试能自动化吗？
重复性的回归可以自动化，判定答案对业务是否有用仍需人工。可行做法是自动跑通流程与格式校验，人工只看抽样结果与失败项，把有限的人力放在判断题上，而不是机械比对。