企业第一个AI项目，应该验收到哪一步？

如果公司准备给第一个AI项目做验收，你会让负责人拿什么来证明效果？

一份自动生成的报告，一套已经能用的应用，还是一张写着节省了多少时间的表？这些当然都值得看。毕竟，原来要自己整理的资料，现在能交给AI；原来要排期开发的功能，现在可以更早拿出来讨论。变化是看得见的。

可接下来还有一问：这些变化，最后让公司哪件事办得更好了？

报告写得快了，负责人作决定时是不是少找了一轮资料？应用生成了，业务人员是不是少在两个系统之间抄一遍数据？客服回复更快了，客户的问题是不是也更早解决了？

问到这里，验收就开始有点不一样了。我们要看的，逐渐从AI完成了什么，变成了这件事经过AI之后，究竟怎样到达最后那个结果。

一、一个人省下的时间，可能要另一个人补回来

我们拿软件售后问题处理做个推演，不对应某家客户的实际项目。

客户发来一段消息，说某个功能突然用不了了。客服要读消息、补问情况、整理问题，再交给技术人员。技术查清原因，客服把处理办法解释给客户，最后确认问题是否解决。

这里很容易找到一个AI切入点：让它整理客户消息，生成问题摘要和回复建议。原来要来回读的聊天记录，现在能更快看完，客服确实省事了。

但技术接手时，可能还缺几个关键信息：客户用的是哪个版本，出现问题前做了什么，换一个账号能不能复现。摘要写得很清楚，却没法帮助技术人员定位。于是技术退回来，客服再问客户，资料补齐后重新排队。

这时，客服整理消息的时间少了，技术核对和退回的工作却多了。客户感受到的等待，也未必缩短。

更进一步，如果前面整理得越来越快，后面的技术人员仍然只有那些时间，待处理的问题就可能越积越多。客服觉得AI很好用，技术觉得收到的任务更多了，老板却发现客户还在催。

谁都没有说假话。只是他们在看同一件事的不同部分。

所以，验收时很值得多追问半步：这一步省下来的工作，后面的人还要不要重新做？如果下一位同事得从头核对、补问、改写，前面省下的时间就不能全部算成公司的收益。

这也不意味着摘要没有价值。它可能确实减少了阅读负担。我们只是要把这项价值说准确，再看看它是否解决了当前最耽误业务的那一段。

二、第一条流程，最好能看到结果被谁接住

沿着刚才的问题再往下看，就能理解为什么第一个AI项目值得从一条业务流程开始。

只验收一段摘要，很难知道它有没有帮上忙。把范围放到客户报障之后，信息怎样补齐、技术怎样接手、处理结果怎样回到客户，我们才看得到那些来回发生在哪里。

但也不必一上来把整个售后部门都改一遍。可以先选一类边界清楚的问题，比如某个产品的常见使用故障，约定从收到客户反馈开始，到技术人员确认资料足够、正式接手为止。

这个范围不大，却有一个明确的接收人。技术人员可以判断：这份材料能不能开始排查，还缺什么，退回的原因是什么。

AI在其中可以承担适合它的工作，比如从一段不规整的描述里提取现象，列出还缺的材料，给客服起草补问内容。是否属于当前处理范围、资料是否足够，先由相应人员确认。确定的必填项和流转条件，则可以交给普通校验与工作流执行。

别为了做AI项目，把每一步都变成一次模型调用。有些步骤按规则处理更直接。AI适合处理什么，要看它是否比原来的办法更有帮助。

还有一种情况要留意：客服和技术部门本来就没谈好接手标准。如果今天要截图，明天又要求一段录屏，没人能解释什么情况下分别需要，反复退回就不能全算到AI头上。这个试点首先暴露的，是交接标准需要商量。

因此，我们建议挑的第一条流程，要小到能够试，又要完整到能判断有没有帮到下一位做事的人。只挑最容易生成的那一段，容易收获一场漂亮演示；一下覆盖全部业务，又很难查清效果到底从哪里来。

三、人工审核也有成本，要看它怎样帮助人判断

说到人工确认，有人可能会担心：加了AI还要人审核，忙来忙去，究竟省了什么？

这个问题应该认真算，不能用“有人把关更安全”就把成本略过去。

还是刚才那份客户反馈。如果AI只给出一段语气肯定的总结，技术人员要判断它有没有漏掉重要信息，可能得把全部聊天重新读一遍。这个审核过程，与自己整理一次相差多少，需要实际比较。

如果它能把判断对应回原始消息，清楚区分客户已经提供的内容、还没提供的内容，以及它自己的推测，审核者就有机会沿着依据核对，而不用四处翻找。是否真能省事，仍要拿实际记录验证。至于涉及合同承诺、费用或敏感资料的操作，还要另外确认授权和处理边界，不能只因为一种问题经常出现，就让AI直接作决定。

两种做法都叫人工审核，对人的要求却差很多。前一种把一个答案交过来，要求人负责；后一种尽量把作判断需要的材料准备齐。

所以，设计试点时，不能只问哪些地方要留给人，还得继续问：留给人的那个决定，他拿到什么才能作出来？

退回也是这样。材料不够、超出处理范围、AI识别错了，应该分开记录。否则下一轮优化时，只知道退回很多，却不知道该补知识、改提问，还是调整部门间的约定。

这些记录还会改变项目负责人的选择。如果反复退回都因为一个固定信息缺失，增加必填项就可能有效；如果不同客户的表达很难统一，才更值得继续改进AI的提取和追问。试点的价值，就在于让我们有依据地决定下一笔投入。

四、验收时，把省时、等待和结果分开看

到这一步，第一轮试点该怎样验收，已经比较清楚了。

先找一批处理范围相近的业务记录，保留原来的做法作为比较。新旧记录的复杂程度、参与人员和观察周期尽量接近；如果赶上集中故障或人员变化，也要单独注明，别把外部变化当成AI的功劳或问题。

然后看三件事：大家实际花了多少时间处理，业务从开始到被接手经过了多久，以及接手后还要退回多少次。三件事一起看，才能分清工作有没有减少、等待有没有缩短、质量有没有守住。

比如人员花的时间少了，客户仍要等很久，下一步可能该查排队和处理安排；接手速度快了，后面却频繁返工，就要回头检查资料和判断质量。仅看AI调用次数、摘要数量，很难得到这些答案。

而且，省下工时也不能直接写成节省了同等工资。人还在团队里，时间可能被用来处理更多业务，也可能只是从加班变成正常下班。把这些收益各自说清，再计入模型、平台、配置、维护和审核投入，才适合进一步讨论经济回报。

对织信来说，我们希望AI开发带来的速度，能用在这种可以反复验证的业务应用上。先把一个具体问题做成可讨论、可修改的系统，再让实际使用者告诉我们，哪里少了重复工作，哪里仍然在等人。

织信公开提供的AI建模、工作流、权限和仪表盘等能力，可以作为这类应用的建设基础。但某条流程怎样运行、需要接哪些数据、AI处理到哪里，仍须结合项目配置和验证。AI帮助我们把应用做出来，与这套应用投入使用后改善业务，是两次不同的验收。第一次通过了，第二次才有条件开始。

如果公司正在挑第一个AI项目，不妨请业务负责人拿一件最近办完的事过来。从最初的消息开始，看看谁接过手、哪里等过人、哪里补过材料，最后由谁确认可以继续往下办。

再挑出其中最值得改善的一段，约定它要交给谁、交到什么程度。等试点运行起来，把同样的记录重新走一遍。

到了那时，我们再问AI有没有价值，手里就会多一些具体答案：哪位同事不用重做了，哪次交接不用退回了，哪件事比以前更早办成了。

第一个AI项目值得留下的，是企业知道了下一条流程该怎么改，以及拿什么证明改得有用。