一项 AI 流程自动化任务从十分钟缩短到两分钟，如果漏掉附件、写错状态，或把异常推给没有权限的人，就不能只凭速度验收通过。效率有意义的前提，是交付物正确、授权有效、失败可处理。
试点验收可以从三组样本开始：正常任务、失败任务、人工接管。每组都要预先约定输入、允许动作、预期结果、判定方法和证据；现场演示再流畅，也不能替代这些记录。
先固定验收对象，避免边测边换标准
把首个试点限定为一段明确任务，例如“将已确认材料整理成待复核草稿”。写清输入来源、字段、处理范围、责任人和完成状态。若试点只承诺草稿，就以草稿完整性验收；不能把人工最终批准的结果算作系统独立完成。
样本应保留版本，并把规则、工具和模型的测试配置记录下来。演示中临时修正提示词或手工补字段后，应标明干预并重新测试受影响样本，不能继续沿用修改前的结论。
三组样本分别回答不同问题
| 样本组 | 需要验证什么 | 应留下的证据 |
|---|---|---|
| 正常任务 | 输入完整时，结果是否满足业务要求 | 原始材料、预期结果、输出及目标系统记录 |
| 失败任务 | 缺项、冲突、越权或工具失败能否被识别 | 拒绝或停止位置、原因、未执行动作及现场状态 |
| 人工接管 | 责任人能否接住任务并继续处理 | 交接材料、接收人、决定、恢复或终止记录 |
失败样本不是为了让系统把所有困难都“做成功”。权限不足时拒绝执行，结果不确定时等待核验，都可能是正确行为。判定标准应把这些情况与真正的任务失败区分开。
先使用测试环境或受控数据验证写入类动作。资料不足却继续执行、未经批准扩大范围、重复产生业务记录等情况，应按预先约定的严重问题规则处理，不能靠其他成功样本抵消。
别让一个“成功率”遮住不同结果
建议分开记录：符合交付标准的任务、正确拒绝的请求、人工完成的任务，以及结果不确定的任务。它们分别代表不同能力，合成一个百分比会掩盖边界。
计算前还要固定分母。例如“通过任务数占全部测试任务数”，与“通过任务数占系统愿意受理的任务数”，回答的是不同问题。未受理、超时、人工改正和重复请求都应有去向，不能从统计里消失。
效率也要使用相同起止点：从收到可用输入，到责任人获得可复核结果。人工检查、补材料和异常处理时间应记录；若某段只计机器运行时间，就明确标注，不把它当作整条业务耗时。
用源记录和目标记录核对真实完成情况
回答“已经处理好”不能证明业务系统发生了正确变化。每项写入都要核对目标对象、字段、状态和时间，并关联原始输入与授权。只读任务则检查结论能否找到对应来源，缺少证据时是否明确说明。
微软 AI 评估与可观测性文档区分了任务完成、工具调用、输出质量与跟踪等观察维度。这里采用的是这种分开验证的思路；具体通过阈值仍需业务、项目和系统负责人根据风险共同确定。
通过、返修和暂缓，分别需要什么依据
通过时，交付物和关键边界都应满足已约定标准，缺陷处理结果可复核。需要返修时，记录原样本、问题位置、修订内容和复测范围；环境或业务规则变化后，再判断原结论是否仍然有效。
如果缺少可靠输入、合法权限或接管责任人，应先补齐条件再测试。灵核数智相关试点也应采用相同原则，不能把模型回答自然当作可运行的证据。
尚未选定任务，可先用制造业 AI 首任务评分表筛选范围；需要比较候选方案，则参考AI 数智员工的六项真实任务验收。真正的验收交付，是一组别人能复查的样本与记录，而不是一句“试用感觉不错”。
