AI交付怎么验收？三条硬指标

传统软件验收看功能清单：这一条做了没有，打勾。AI 项目沿用这套方法会出大问题——所有功能都打了勾，业务却一点没变好，这种情况太常见了。

一、硬指标一：业务指标相对基线的变化

这是唯一真正重要的指标。项目开始前测出基线，结项时测同一个数，对比变化。报价周期、漏检率、单据处理人时，选一个能代表这个场景价值的数。

关键在于基线要在项目启动第一周就测好并双方确认。事后再补基线，一定会有争议——客户会说「我们以前没这么慢」。

还要约定测量口径：统计范围、时间窗口、剔除哪些异常情况。口径不明确，同一份数据能算出两个结论。

二、硬指标二：真实使用率

系统上线了不等于有人用。要看的是目标岗位在目标场景下，实际使用这套工具的比例是多少。

这个数据很容易采集，也最能揭示真相。如果使用率只有两三成，说明要么工具不好用，要么流程没改到位，要么有人在抵制。这三种情况都需要处理，而不是签字了事。

一个可参考的门槛：目标岗位使用率低于七成，就不该算验收通过。低于这个数，系统半年后大概率会被弃用。

三、硬指标三：客户能自主操作

验收现场要做一件事：让客户的人在不看服务方脸色的情况下，独立完成一次完整操作，包括处理一个异常情况。

做不到，说明知识转移没有完成。这时候补一轮培训比签字重要得多，否则服务方一撤，系统就成了摆设。

更进一步的检验是：客户能不能自己做一点小调整——改一个规则参数、加一条例外情况。能，说明这套东西真的交出去了。

验收签字只是流程，真正的验收发生在服务方离开后的第一个月。

四、阿优至简的视角

我们把验收分成两次：结项验收看三条硬指标，90 天回访看系统还活着没有。第二次不通过，我们会免费回去处理。

这条规矩让我们在项目过程中就格外重视使用率和知识转移，而不是赶在结项前把功能堆完。把验收往后推 90 天，整个交付的重心就变了。

落地前的三条至简建议

1. 先立基线：项目第一周测出目标指标当前值，书面确认口径。
2. 先看使用率：把使用率写进验收条件，低于门槛不签字。
3. 先做实操考核：让客户的人独立跑一遍含异常处理的完整流程。

签字那一刻不是终点。三个月后系统还在被用，才叫真的交付完了。