试点成功的 AI 项目，换个部门就不行，为啥

———— / BEGIN / ————

我做 AI 项目这几年，有个很明显的感觉：试点项目容易，规模化太难了。

几乎所有项目都是从一个部门开始试点的。选一个配合度高的部门，数据也比较干净，负责人也支持。花个半年时间把项目做起来，效果还不错。然后老板开心了，说"推广到其他部门去"。

这时候你就会发现，推广比试点难十倍。

不信你去看那些企业 AI 项目的报告。数据是这样的：92% 的企业在用 AI，但只有 8% 获得了实际回报。为什么呢？不是技术不行，而是大部分企业停在了试点阶段，复制不出去。

我之前也是这样。以为复制项目就是配置改改、数据接一下，很简单。结果第一次推广就翻车了。上线第一天就接到新部门负责人的电话，语气都不太好："你们这是什么东西？完全不能用啊。"

那次以后我就意识到，AI 项目的复制不是复制粘贴那么简单。你得先搞清楚三件事：数据权限、业务流程、评测基线。搞不清楚这三件事，复制就是送死。

为什么复制会失败？

试点项目选的部门，通常是"好伺候"的那种。

什么叫好伺候？就是部门负责人愿意配合，业务流程相对标准，数据质量还可以，团队也愿意试新东西。在这样的环境下，项目成功率会高很多。

但第二个部门可能完全不是这样。他们可能有自己的一套业务逻辑，数据也不规范，对新系统的接受度也没那么高。你带着试点的经验过去，发现处处都是坑。

我给你讲几个真实的案例。

有家企业的智能客服，试点在售后部门，效果挺好。推到售前部门以后，客户满意度直接掉了 20 个点。为什么？因为售后客户问的问题通常是"我的产品怎么修"，售前客户问的是"你们产品怎么样"。问题的性质完全不一样，模型训练的数据也不一样。

还有家银行的智能审批，试点在小微贷款部门，审批通过率挺稳定的。推到个人贷款部门以后，通过率从 85% 掉到 60%。为什么？因为小微贷款看的是企业经营数据，个人贷款看的是征信和流水。评测的基准根本不一样。

还有家零售公司的智能补货系统，在华东区用得挺好，推到西北区，库存周转率反而变慢了。为什么？因为华东区物流快，三天能到，西北区物流慢，得一周。补货策略完全不能照搬。

这些项目不是技术不行，是水土不服。

AI 项目和传统软件不一样。传统软件是逻辑写死的,只要逻辑对了，复制到哪里都能跑。但 AI 项目是数据驱动的，数据变了，结果就变了。

所以复制 AI 项目，不是技术问题，是业务问题。你得先搞清楚第二个部门的数据权限、业务流程、评测标准，跟试点部门有什么不一样。不一样的地方，就是你要改的地方。

启动复制前要核对的三项

复制项目之前，别急着改代码。先坐下来，跟第二个部门的负责人聊一聊。

聊什么？

聊这三项：数据权限、业务流程、评测基线。

数据权限：谁能看什么数据？

第一个要搞清楚的是数据权限。

试点部门能看的数据，第二个部门不一定能看。这个问题特别容易被忽略。很多人以为"反正都是公司的数据"，应该都能看。其实不是这样的。

比如说，销售部门能看客户的成交记录，客服部门只能看咨询记录。财务部门能看全公司的收入数据，业务部门只能看自己部门的。总部能看全国的数据，分公司只能看本地的。这些权限差异，直接决定了 AI 能用什么数据。

我之前给一家制造企业做生产排程系统，试点在总部工厂。总部的数据全部打通，订单数据、库存数据、生产数据都能看到，模型跑得特别好。后来推到分公司，分公司说"我们看不到总部的订单数据啊"。结果模型预测的准确率从 92% 直接掉到 70%。为什么？因为分公司的订单量小，波动大，模型学不到规律。总部的数据量大，模型才能学好。

所以复制之前，你得问清楚第二个部门能访问哪些数据表、哪些字段有权限限制、数据更新频率是多少、数据质量怎么样。这些问题要一个一个确认，不能想当然。

最好的办法是列一个数据权限对比表，把试点部门和第二个部门的权限放一起看。哪些数据第二个部门看不到，提前跟数据团队申请权限。如果申请不到，就得调整模型设计，或者用其他数据替代。

有时候会发现，关键数据根本申请不到。这时候你得老实跟老板说："这个模型不适用，得重新设计。"别硬撑，上线翻车更麻烦。

业务流程：第二个部门的流程跟试点不一样

第二个要搞清楚的是业务流程。

AI 项目是镶嵌在业务流程里的。试点部门的流程是什么样，AI 就按那个流程设计。但第二个部门的流程，很可能完全不一样。

我给你举个例子。某电商公司做智能客服，试点在售后部门。售后的流程很简单：客户提问、客服回答、解决不了就转人工、人工处理完记录到系统里。很标准的流程，AI 只要做好回答这一步就行了。

后来推到售前部门，售前的流程就复杂多了。客户咨询产品、客服推荐产品、客户问价格、客服报价（这个价格还要根据客户等级、活动规则、库存情况动态计算）、客户问能不能便宜点、客服申请折扣（还得走审批流程）、客户下单。你看，复杂得多。

AI 不仅要回答问题，还要推荐产品、计算价格、申请折扣。这些功能试点的时候根本没做。结果推到售前部门，AI 只能回答问题，其他什么都干不了。客服还得手动查价格、手动申请折扣，反而更麻烦了。

所以复制之前，你得把第二个部门的流程画出来。用流程图也好，用表格也好，总之得把每一步标清楚：谁做的、输入是什么、输出是什么、有没有审批节点、有没有外部系统对接。

然后跟试点部门的流程对比，看看哪里不一样。不一样的地方，就是你要改的地方。

有时候你会发现，第二个部门的流程太复杂了，AI 根本做不了。这时候不是 AI 的问题，是流程的问题。你得跟第二个部门商量："能不能先简化一下流程？"流程不改，AI 就别想用好。

评测基线：成功的定义变了

第三个要搞清楚的是评测基线。

试点项目都会定一个评测基线。比如智能客服的准确率要达到 90%，智能审批的通过率要达到 85%，智能推荐的点击率要提升 20%。这些基线是根据试点部门的业务目标定的。

但第二个部门的业务目标，可能不一样。

我之前给一家物流公司做智能调度，试点在同城配送部门。同城配送的目标是"快"，所以评测基线是配送时效。只要能比原来快 10%，就算成功。

后来推到长途运输部门，长途运输的目标是"省"，不是"快"。他们更关心油耗、路线优化、空驶率。结果我们的模型优化的是时效，不是成本。推到长途运输部门，时效确实快了，但成本没降，部门负责人根本不买账。

所以复制之前，你得问清楚第二个部门的成功标准是什么。他们最关心的指标是什么？这些指标跟试点部门的指标一样吗？如果不一样，模型要不要重新训练？

最好的办法是重新做一次评测基线设定。跟第二个部门的负责人坐下来，列出他们的核心指标，定一个可量化的目标。然后用试点的模型跑一遍，看看能不能达到。达不到，就得调模型。

有时候你会发现，试点的模型完全不适用。这时候别硬撑，老老实实跟老板说："这个模型不行，得重新训练。"重新训练总比上线翻车强。

复制的时候要检查什么

三项核对完了，接下来就是实操。

这时候你要做的是逐项检查：配置文件、权限矩阵、数据来源、流程适配点。

配置文件要逐项确认

AI 项目的配置文件通常包括模型配置、数据源配置、业务规则配置、权限配置这几类。复制的时候，这些配置都要重新检查。

千万不要直接复制粘贴。

我见过最离谱的案例，有人直接把试点部门的配置文件复制过去，结果第二个部门用的还是试点部门的数据库。两个部门共用一个数据库，数据全乱了。

所以配置文件要逐项确认：数据库连接是不是第二个部门的？数据表名对不对？业务规则的阈值要不要调整？权限配置符不符合第二个部门的要求？

最好用一个配置对比工具，把试点配置和新配置并排放，逐项对比。对比完了，再让第二个部门的技术负责人 review 一遍。确认无误了，再部署。

权限矩阵要重新设计

数据权限很重要，复制的时候要重新建一份权限矩阵。

这个矩阵包括角色列表、数据权限、功能权限、审批权限。第二个部门有哪些角色？每个角色能看什么数据？每个角色能用哪些功能？哪些操作需要审批？谁来审批？

权限不能照搬。

试点部门的角色和权限，不一定适合第二个部门。比如试点部门有个"数据分析师"角色，能看所有数据。但第二个部门可能没有这个角色，或者这个角色的权限更小。

所以权限矩阵要跟第二个部门的 HR 和 IT 部门一起确认。确认完了，写进权限配置文件，部署的时候一起上线。

数据来源要验证

权限有了，还得验证数据来源。

具体要验证这几件事：数据接口通不通？能不能从第二个部门的数据库拉数据？数据格式一不一样？字段名、字段类型、数据范围是不是跟试点部门一致？数据质量怎么样？缺失率、重复率、异常值有没有超标？数据更新频率满不满足要求？

我们通常会写一个数据验证脚本，跑一遍第二个部门的数据。脚本会输出一份数据质量报告，包括数据量、缺失率、重复率、异常值占比、数据分布。然后把这个报告跟试点部门的数据对比一下，看看差异有多大。

如果数据质量不达标，就得先清洗数据，或者跟第二个部门商量："能不能先把数据治理一下？"数据不行，模型再好也没用。

流程适配点要逐个解决

最后，要标出旧流程和新流程的适配点。

具体来说，哪些步骤是新增的？哪些步骤是删除的？哪些步骤的逻辑变了？

每个适配点，都要写清楚怎么适配、谁负责、什么时候完成。我们通常会把这些适配点做成一个任务清单，分配给不同的人。每个任务完成后，在清单上打勾。所有任务完成了，再进入测试阶段。

不要等到测试的时候才发现有遗漏。

定制还是标准化？

复制项目的时候，你肯定会遇到一个灵魂拷问：要不要为第二个部门做定制？

定制的好处是贴合业务，效果好。定制的坏处是成本高，后期维护麻烦。如果每个部门都做定制，你会发现自己在维护十几个版本的代码。一个 bug 要改十几遍，一个新功能要开发十几次。累死你。

所以定制和标准化要平衡。

我们团队的原则是这样的。如果第二个部门的业务目标跟试点部门一致，就坚持标准化，用同一套系统，不做定制。最多调调参数、改改配置。

如果第二个部门的业务目标完全不一样，那就做定制。但定制的部分要做成独立模块，不要跟主系统耦合。这样以后维护的时候，只要改模块，不用动主系统。

如果第二个部门的流程太复杂，AI 根本做不了，那就先跟他们商量："能不能简化一下流程？"流程改了，说不定就能用标准化的系统了。

举个例子：

某零售企业做智能补货，试点在线上电商部门，后来推到线下门店。线下门店的流程跟线上完全不一样。线上是"下单-发货-收货"，线下是"到店-选货-付款"。补货逻辑也不一样，线上看的是 GMV 和库存周转，线下看的是坪效和动销率。

我们一开始想做定制，专门为线下门店开发一套系统。但后来发现，线下门店的需求太碎片化了，每个门店都不一样。做定制根本做不过来。

最后我们换了个思路：用 Multi-Agent 协同。主系统负责通用的补货逻辑，每个门店部署一个 Agent，负责门店个性化的需求。主系统是标准化的，门店的 Agent 是定制化的。两者通过 API 通信，互不干扰。

这个方案后来推广到了 200 多家门店，效果还挺好。

写在最后

AI 项目复制到第二个部门，不是复制粘贴那么简单。

你得搞清楚数据权限、业务流程、评测基线，做好配置检查、权限分配、数据验证、流程适配。这些活儿，比写代码累多了。

但没办法，AI 项目就是这样。它不是一个独立的系统，它是镶嵌在业务里的。业务不一样，AI 就得跟着变。

更重要的是，复制不是终点，是起点。

第二个部门上线了，第三个、第四个、第五个部门怎么办？你不可能每次都从头来一遍。所以从第二个部门开始，你就要思考：哪些东西是可以标准化的？哪些东西是必须定制的？怎么让定制的成本降到最低？

想清楚这些，你才能把 AI 项目真正推广到全公司。

不然，试点永远是试点，规模化永远是一句空话。很多企业就是这样，停在了试点阶段，复制不出去。最后 AI 项目变成了一个漂亮的 PPT，实际业务还是靠人工。

别让你的项目也停在试点。