AI 项目验收时，客户最在意的那三件事

上个月帮一家物流公司验收 AI 智能调度系统。技术团队准备了精美的 demo：实时路径优化、异常预警、自动派单，一气呵成。客户看了十分钟，问了三个问题，项目卡了两周。

这三个问题，和算法精度没关系。

第一件：出了问题找谁？

客户原话："系统半夜崩了，我打给谁？"

我们当时给的是一个微信群，里面有项目经理、后端开发、算法工程师。客户觉得不够——群里有人不回消息，有人回了但解决不了。

我们后来做的：写了一份一页纸的《故障响应手册》，列清楚三类问题的处理路径。P0 级（系统不可用）30 分钟内电话响应，P1 级（功能异常）2 小时内工单回复，P2 级（体验问题）24 小时内处理。每个级别对应具体联系人和升级路径。

客户看到这份文档，明显松了口气。他要的不是"有人"，而是"有流程"。

第二件：数据出了事怎么办？

客户问："如果 AI 派了一个错误路线，导致司机多跑了 200 公里，这算谁的？"

这是个责任边界问题。我们最初的设计是 AI 全权决策，人类只负责确认。但客户担心：如果 AI 判断失误造成经济损失，责任怎么划分？

我们后来做的：把系统从"AI 决策"改成"AI 建议 + 人工确认"。关键操作（如跨区调度、超时任务重新分配）必须人工点击确认才能执行。同时在系统里记录每次 AI 建议和人工决策的差异，形成审计日志。

这个改动让技术团队多花了三天，但验收当天客户当场签字。

第三件：以后还能改吗？

客户问："三个月后我想加一个新功能，比如按司机偏好分配路线，你们还能改吗？还是得重新招标？"

这背后是对供应商锁定和技术债务的担忧。很多 AI 项目交付后，客户发现系统代码一团乱麻，只有原团队能维护。

我们后来做的：交付时额外提供了一份《系统架构说明》和《二次开发指南》。不是那种几十页的废话文档，而是真正能用的——包含 API 接口清单、数据库表结构、核心算法的输入输出格式、以及常见功能扩展的代码示例。

总结

AI 项目验收，技术只是入场券。客户真正关心的是：出了问题有人管、出了责任有边界、出了新需求能扩展。

下次做 AI 交付，我会把这三件事在需求阶段就谈清楚，而不是等到验收才补。因为信任不是靠 demo 建立的，是靠流程建立的。