AI做了大半年,为什么最后发现很多东西要重新来?

昨天，我拒绝了一个六位数的企业AI项目。

这个客户其实已经在AI上折腾了大半年。

找人做过好几轮培训，员工学过不少工具；

内部也做了一些智能体，积累了一批数据和资料。

但大半年下来，回到业务结果看，降本、效率、增长都没有出现明显变化。

更麻烦的是，过去很多项目一开始就没有定义清楚要改善什么指标，所以有些投入甚至很难判断到底产生了多少价值。

前两天我的客户把这家公司推荐给我们，希望我们重新梳理一遍。

最开始，双方对这件事的理解其实不太一样。

客户认为，前面已经做了这么多事情，数据有了，智能体也有了，我们接下来主要是在这些基础上重新整理、连接，再把效果做得更精准一点。

这个判断听起来很合理。

但真正进入业务诊断以后，我们发现：

他们过去做了很多AI项目，但这些项目并没有围绕一个共同的业务结果组织起来。

培训是培训，数据是数据，智能体是智能体，各个部门也都在找自己的场景。

单独拿出来看，每件事情甚至都有理由。

但把它们重新放回一项完整业务里，就会出现大量断点。

前面的人整理完信息，后面的人拿不到完整上下文；

不同地方沉淀的数据，结构、口径、版本并不统一；

一些智能体可以完成单独任务，却没有真正进入业务流程；

业务负责人已经纠正过的问题，修改理由仍然留在某次聊天里，换个人、换一个Agent，又重新来一遍。

也就是说：

从过去的交付清单看，确实已经做了很多东西；

但真正能够直接拿来继续往上搭的业务资产，并没有想象中那么多。

这也是这次诊断里，我们和客户之间第一个比较大的认知差异。

他们原来认为，现在已经走到了“整理和优化”的阶段。

但我们判断，很多关键环节实际上还需要重新从底层梳理。

再去看他们内部员工的工作情况，会发现每个人其实都做了很多努力。

培训参加了，AI工具用了，安排的任务也完成了，很多人的绩效也很好。

如果站在单个人的角度看，大家都在正常完成自己的工作。

但把视角从“员工完成了什么”拉到“公司得到了什么”，结果就不一样了。

这些AI项目究竟减少了多少成本？

原来耗时很长的工作有没有真正缩短？

哪些重复劳动被消除了？

哪些业务结果因为AI发生了变化？

有些问题的答案并不好看，还有一些问题甚至因为一开始没有建立明确的衡量标准，现在已经很难回答。

于是就出现了一种企业里非常容易发生的情况：

个人层面每个人都完成了任务，但这些任务没有被组织成一个共同的业务结果。

培训公司完成了培训，

做智能体的人交付了智能体，

员工也完成了AI应用要求。

所有局部看起来都没错，但公司层面的结果没有跟着发生变化。

其实今天很多企业和AI服务商的合作，还是一"外包"模式：

企业说自己缺什么，服务商就提供什么。

员工不会用AI，就做培训；

资料太散，就做知识库；

销售效率低，就做销售Agent；

公司已经有很多数据，就做数据分析。

问题在于，企业自己在这个阶段，未必真的知道自己应该“要什么”。

老板真正要的是：我要降本、提效、增长，我希望AI在公司里产生价值。

但从这个经营目标，到底应该先改变哪项工作，中间哪个环节最值得做，现阶段应该做什么、不应该做什么， 中间其实隔着一整层判断。

如果这一层没有完成，后面的人只能按照一个个局部需求往前推进。

最后就很容易变成这个客户现在的状态：

AI做了很多，但没有一条线真正跑到底。

所以这次我们没有一上来就讨论再给他们做什么Agent，而是开始重新往回拆。

今年真正想改善的经营结果是什么？

这个结果为什么现在没有发生？

问题到底出在业务流程、人的判断、数据，还是组织协作？

如果只能先做一件事，哪一件最值得做？

做到什么程度，才能证明AI真的产生了价值？

这些问题一问，很多原来看起来已经确定的事情，就要重新判断。

有些原来觉得能直接使用的数据，需要重新整理；

一些已经存在的智能体，并不能直接成为后续系统的一部分；

某些原来看起来已经完成的工作，其实只是完成了一个功能，并没有真正进入业务。

到这里，项目的性质已经变了。

它不再是：

“在现有基础上帮我们优化一下。”

而更接近：

重新确定目标，重新选择第一个业务场景，再把数据、流程、人的判断和AI能力重新组织起来。

这意味着交付范围、投入方式和整个项目预期，都需要跟着改变。

最后我们没有合作，真正的分歧也发生在这里。

客户仍然希望基于现有基础，通过一条相对短的路径达到比较理想的结果。

但按照我们诊断后看到的真实情况，如果要对结果负责，就不能把过去已经做过的东西全部默认成有效基础。

有些可以继承，有些只能参考，还有一些必须重新开始。

双方最终没有形成共识的，是：

我们现在究竟站在哪里，以及从这里走到目标，真正需要做多少事情。

如果这个前提没有共识，合同就不应该继续签。

否则接下来很可能发生的是：项目开始了，我们不断交付，对方也不断配合，双方每个月都有事情在推进。几个月以后再回头看，最开始那个业务目标仍然没有实现。

那不过是在重复他们过去大半年的经历。

所以最后我们决定不接。

不是因为预算有问题，而是因为如果双方连真实起点和实现路径都没有形成共识，六位数的合同解决不了这个问题。

这件事也再次印证了我现在做企业AI项目时非常坚持的一件事：

培训之前，先确定第一件准备做成的事。

员工学习AI当然有价值。

但“让员工学会AI”首先是一个能力目标，还不足以成为企业的业务目标。

企业还需要继续回答：

这批人学完以后，准备把哪一项真实工作换一种方式重新做？

这项工作的变化，又具体要改善什么业务结果？

如果这两个问题没有答案，培训内容就很容易跟着工具走。

Agent火了就讲Agent，知识库火了就建知识库，出了新模型就再培训一次。

员工的AI知识越来越多，公司却依然不知道这些能力应该先用在哪里。

所以真正的顺序应该反过来。

先从经营结果出发，找到当前最值得解决的问题，再从这个问题里选出第一个具体场景。

选完以后，把这项工作从头到尾走一遍：

输入从哪里来，谁负责判断，哪些数据必须统一，前一步的信息怎样传给下一步，

哪些地方可以交给AI，哪些地方必须由人负责。

到了这个阶段，培训员工学什么，反而会变得非常清楚。

不是所有人都需要学Agent，也不是所有岗位都需要学习同一套工具。

负责提供信息的人，要学会怎样把事实、背景和限制交代清楚；

负责执行的人，要知道怎样调用资料、检查AI结果；

真正掌握业务判断的人，要能够指出AI错的到底是哪一步，正确标准是什么。

技术人员要解决的，也不再是“公司是不是应该做一个知识库”，而是：为了让这项工作连续跑下去，哪些数据必须统一，哪些上下文必须保存，哪些系统必须连接。

这时候，工具才开始围绕业务组织，而不是业务围着工具组织。

最后，再把这个场景放进真实业务里。

验收也只回到最开始约定的那个结果。

如果一开始要解决的是客户响应慢，就看响应时间有没有真正缩短、原来因此流失的机会有没有减少。

如果一开始要解决的是重复返工，就看返工次数和处理时间有没有下降。

如果最初约定改善的结果没有发生变化，那么培训结束、Agent上线、知识库建好，都只能证明项目完成了一部分交付，还不能证明这件事真正做成了。

所以我一直坚持：

先诊断，再选场景；围绕场景培训，再把它带进真实业务里跑通。

企业做AI的第一步，不是先让所有人开始用AI。

而是先确定：

我们到底准备用AI，把哪一件事真正做成。