误区一：把验收排在最后
标准临时凑，双方当场争论算不算完成。纠正动作是把可观测的通过条件写进项目启动时的确认单，让开发过程围绕它推进。这样做的成本只是多写一页纸，却能把争议从交付现场提前到立项会上解决。
误区二：标准不可观测
体验流畅、准确率高这类说法无法判定，评审只能靠印象。应换成任务样本、判定口径、抽检比例与失败处置四项，使两个人在不同时间看同一批样本能得出相近结论，否则验收只是一次表态。
误区三：只看功能不看接管
模型答错时谁来接、多久接、接了记在哪，比功能清单更决定系统能否长期运行。漏掉接管设计的系统一旦出错就会被业务停用，前期投入同时归零，因此这一栏必须在验收单里单独设项并指定责任人。
误区四：结论不留证据
口头通过后，三个月出现争议时无从回溯，责任只能由项目组承担。验收应产出证据包：样本清单、抽检记录、问题处置结论与签认页。它既是复验依据，也是审计与人员交接时能说清当时口径的关键材料。
适用与不适用
适合谁
- 已交付过 AI 项目、验收环节反复拉扯的团队
- 正在撰写 AI 项目确认单与验收条款的负责人
- 需要向管理层解释为何还不算完成的项目经理
不适合谁
- 尚未启动任何 AI 场景、只想先了解概念的企业
- 把验收视为走流程、不打算留任何书面证据的组织
典型场景
某集团信息部在两个 AI 场景上连续返工。第三个场景立项时，业务、技术与风控一起把通过条件写成可观测条目，约定样本量与抽检比例，并在交付前做一次预验收演练。正式验收当天只剩确认与签认，返工从两轮降到零，争议也有了书面依据。
可执行步骤
- 立项时把通过条件写成可观测条目，明确样本来源、判定口径与抽检比例。
- 指定有权签认的岗位，写明标准未达成时的拒收权、复议方式与答复时限。
- 交付前做一到两次预验收演练，把口径分歧与证据缺口提前暴露出来。
- 把样本清单、抽检记录与问题处置结论整理成一份可归档的证据包。
- 为遗留问题写清关闭条件、责任人与复验时间，避免长期挂账无人认领。
常见坑
- 验收标准写在合同附件里却没人读，交付时才发现口径不一致，双方按各自理解争论是否完成。规避：立项会上逐条过一遍并请签认人当场确认。
- 只验收功能清单，没有测接管流程，系统上线后每次答错都升级为客户投诉，最终被业务要求下线，前期投入无法收回。
- 验收结论只有会议纪要没有样本证据，出了争议无法回溯，责任只能由项目组单方面承担，后续复验也缺少基准。
自检与验收清单
- 每条通过条件是否可观测、可复现并留有证据
- 验收人是否具备签认权以及标准未达成时的拒收权
- 接管与异常处置是否逐项纳入验收范围并指定责任人
- 样本与抽检记录是否归档，复验时能否随时调取
常见问题
验收标准由谁定？
业务负责人定什么算可用，技术方补怎么测，风控或合规补边界条件，三方在对齐会上逐条确认。最后由有权签认的岗位签字，而不是由供应商单方面给出标准，也不由项目组自己判自己。
小项目也要做证据包吗？
要，但可以极简：一页样本清单加签认页即可。轻量证据的成本远低于争议时的回溯成本，也让后来接手的同事知道当时的判定口径，不必重新猜一遍当时的边界。
验收不通过怎么处理？
按确认单里的处置条款走：列出未达成条目，约定修复窗口与复验方式，复验只针对未达成条目。客户的签认决定由客户作出，我方提供证据与整改记录，不代替客户判断。