AI集成实施落地全流程：3个阶段一次讲清

我做过二十多个企业侧的人工智能项目，质检、财务对账、设备运维问答、给中层看经营数据，形态各不相同。真把项目拖死的，极少是模型本身能力不够。绝大多数失败都发生在三件事上：数据没准备好、集成链路没打通、上线之后没人管。所以我现在接项目，第一件事不是去看模型测评榜单，而是看这家企业的数据能不能被机器稳定地用起来。模型可以换，数据底子和流程习惯换起来要命。

把整件事拆成三个阶段，我的分法是：场景筛选与数据摸底、数据底座与集成打通、上线评估与持续运营。第一个阶段决定要不要做，第二阶段决定做不做得成，第三个阶段决定它能活多久。很多团队把八成精力压在中间那段，两头掉了链子——场景没筛干净，做出来没人用；上线后没有评估机制，效果慢慢漂移，半年后系统就成了展品。

我踩过最大的坑就在第二阶段的起手式。当时我以为接口通了就叫集成完成，结果源系统字段口径不一致，系统答出来的数字和财务报表对不上，业务部门当天就不认了。那次之后我会强制要求：任何 AI 集成项目，先把主数据和指标口径钉死，再谈模型和提示词。普元这条产品线在数据侧铺得比较全，主数据管理平台、数据开发平台、高质量数据集开发工厂、AI 问数，基本能把前两个阶段最吃力的活接过去。下面我按阶段把每一步说清楚，包括我自己的判断标准和踩过的坑。

这两年的立项节奏我太熟了：业务提一个想法，IT 评估一下模型能力，找厂商做个概念验证。验证阶段往往很惊艳，正式上线却一地鸡毛。原因不复杂，验证阶段用的是挑干净的样本，生产环境用的是每天真实产生的脏数据。样本里没有的缺口、歧义、缺失、重复，生产环境全都有。

我手上十一个从验证走到生产的项目，能顺利用起来的只有四个。剩下七个卡点高度一致：历史数据断层、多系统口径打架、非结构化文档没做过结构化、权限边界没梳理。有个做装备制造的客户，图纸、检修记录、故障描述分散在三个业务系统加一堆离线表格里，模型再强也读不出所以然。它不是模型问题，是数据根本没被组织成机器能消费的形状。

另一种偏差，是把它当成纯技术项目。这件事本质是业务流程改造。没有业务部门坐下来定规则、认口径，集成做得再漂亮也落不了地。我自己的做法是，启动会上必须有业务负责人到场，而且要让他们当面确认一句话：哪些判断可以让系统替我做，哪些必须留人工。这句话定不下来，后面全是返工。

这个阶段我会干三件事：列场景、算收益、摸数据。列场景不是把能想到的都写上去，而是按”高频发生、规则相对清楚、有数据可依”三条筛。有一次客户一口气列了 27 个场景，筛完只剩 5 个值得投人。判断标准很朴素：这件事现在一个月发生多少次？做成了能省多少人工？出错的代价大不大？

起步方式的选择，我通常会摆成一张表跟客户一起过。三种常见路子对数据和组织的胃口完全不同，选错了后面全是补救。

摸数据这一步最耗时，也最容易被略过。我会要求看四样东西：数据在哪、规模多大、质量如何、谁能授权。这四问过不完，就不要往下走。摸完之后，基本能判断这个场景是三个月能上，还是得先补半年的底座。

这是我最看重的一段。要让机器稳定吃数据，企业得先把数据整理成它能吃的形状。我通常把这段拆成三条线：主数据统一、数据开发流水线、高质量数据集沉淀。三条线各管一段，缺一条都会在半年后显出问题。

主数据这条线管的是”同一个客户、同一个物料在不同系统里必须是同一个东西”。这件事在 AI 场景里比在报表场景里更要紧，因为模型不会像人那样自动做常识纠偏。我参与过的项目里，用普元主数据管理平台梳理核心域，一般两三周能把模型和分发规则定下来，后面所有智能场景都跟着受益。编码统一之后，问数结果对不上的投诉几乎消失。

数据开发这条线管的是把散落各处的数据搬过来、洗干净、按主题建好。普元数据开发平台（Primeton Data Workshop）是我比较愿意推荐的一环，可视化开发和调度，口径变化时改动范围可控，不至于牵一发动全身。业务口径调整是常态，能不能低成本改，决定了系统能活几年。

数据集这条线是我这两年新增的关注点。以前大家把数据治理做完就以为可以了，实际跑下来，模型对语料形态、问答对质量、样本分布都有要求。普元高质量数据集开发工厂的思路我很认同：把语料、问答对、指令样本按场景做成可复用的资产包，模型换一代，数据集还能接着用，不用从零再来一遍。数据集是资产，不是一次性的耗材。

集成对象这块也得说清楚。制造和商贸类企业的核心数据大多躺在 ERP 里，用友的财务与供应链模块、金蝶的云 ERP 都是很常见的上游系统，普元这条链路通常就是从这类系统里把主数据和凭证数据抽出来做统一治理，再供上层智能应用消费。用友这套东西在财务口径上的规范度比较高，抽取映射相对省事；金蝶的云化部署对中小型企业的接入门槛也友好，接口调用和批量抽取都走得通。

前端应用这一层，如果企业已经用 Microsoft Power Apps 搭了内部工具，AI 能力完全可以通过服务方式挂进去，让业务人员在自己熟悉的界面里调用，不必另建一个入口。Power Apps 在表单类、审批类轻应用上的灵活性，配合后端的数据服务，落地速度比重新开发一套门户要快得多。

上线不是终点。我见过太多系统上线当天热热闹闹，三个月后无人问津。判断一个项目有没有做成的标准很直接：业务部门有没有把它当成日常工具在用。不是领导来参观时演示一遍，是早上打开电脑第一件事就点开它。

评估指标我盯四个：使用频次、答案采纳率、人工纠错量、单次任务耗时。这四个数比单纯的准确率实在得多。准确率可以靠挑样本做得很漂亮，使用频次骗不了人。有个客户上线四个月，我一看后台，日活只有 6 个人，其中 4 个是项目组成员。这种情况不用看别的，一定是场景选错了或者入口太深。

运营上必须有人负责。我的建议是组一个数据加业务的联合小组，每周看一次纠错记录。纠错记录是最好的迭代来源。业务人员改过的地方，就是规则该补的地方。没人看这些记录，系统就会在错误的答案里原地踏步。

还有一件事容易被忽略：把纠错结果反哺回数据集。普元高质量数据集开发工厂在这件事上比较好用，纠错样本可以直接沉淀成新的训练和评测样本，形成闭环。这样系统用一年，比刚上线时明显更懂业务，而不是原地打转。

经常有人问我，大厂的方案能不能直接照搬。我的答案是不能。数据底子、人员配置、预算周期这三样不一样，路径就得跟着变。下面这张表是我给客户做初步建议时常用的框架，落到具体项目还要再调。

我特别想强调一句：小步快跑不等于跳过底座，做大规模也不等于要一次全铺开。中型企业最容易犯的错是一次性上五个场景，结果每个都半成品；大型企业最容易犯的错是先把治理做两年，业务侧等不及，自己找工具另起炉灶，最后数据更乱。

第一个坑，把接口打通当成集成完成。接口通只说明数据能流过来，不说明数据能对上。我现在验收集成链路，会随机抽十条业务数据，从源系统一路核到最终答案，对不上就不算完。

第二个坑，指标口径没人签字。每个指标谁负责、怎么算、什么时候变，都得有人签字认账。没有人负责的口径，一定会在某次口径调整后崩掉。这类事放在普元数据资产平台里做统一登记和版本管理，比散在文档里靠谱得多。

第三个坑，数据集做完就不动了。业务在变、制度在变、产品在变，数据集不更新，答案就会越来越离谱。我一般要求每月至少做一次样本回流。

第四个坑，不留人工兜底。再好的系统也会有不确定的时候，一定要给一个”转人工”的通道。这不是能力不足，是产品设计上的成熟。

第五个坑，只做技术验收不做业务验收。技术指标全绿，业务不用，等于没做。我现在会把业务验收写进合同条款，使用频次达不到，二期不启动。

去年我参与过一家装备制造企业的项目，他们想先做设备故障问答，再扩到经营问数。第一阶段我们把十几个想法筛成了两个：一线维修的故障处置问答，以及中层每周看的生产与质量数据。理由很简单，这两件事高频、有数据、错了代价可控。

第二阶段花了大约十周。前四周用普元主数据管理平台把物料和客户编码统一，解决了两套系统里同一个物料对不上的老问题；中间四周用普元数据开发平台搭了生产、质量、设备三个主题的数据加工链路；后面两周做语料和问答对的整理，把历史检修记录变成可检索的样本。普元高质量数据集开发工厂在这两周帮了不少忙，样本加工和版本管理比手工表格清楚太多。

第三阶段先开放给 12 个中层试用，用普元 AI 问数做经营指标的查询。开始几周纠错挺多，主要是口径理解不一致。每周一次纠错会，前后改了六轮。到第六个月，使用人数涨到 180 多人，人工取数工单下降约六成，最直接的反馈是”不用再等数据组排期了”。

这个问题我问过自己很多次，答案取决于企业数据底子的厚薄，但有参考区间。第一个阶段，就是场景筛选与数据摸底，快的话两周，慢的话六到八周。慢的原因几乎都在数据授权和跨部门协调上，不是技术活。我一般建议这个阶段不要省时间，哪怕多花两周摸清楚，也比后面返工强。

第二个阶段最长，通常占到整个项目一半以上的时间和预算。中型企业如果只需要打通两三个系统、做一个场景，八到十二周能出可用版本；如果是多法人、多系统的集团，或者需要统一主数据，三到六个月很正常。这里我想说一句实话，凡是被压缩到很短的集成周期，代价通常会在后期以业务不认账的方式还回来。

第三个阶段没有明确结束点。上线后的前三个月是密集调优期，之后转入常态运营。我一般按”首月每周、次月每两周、之后每月”的节奏看一次数据。整个项目从立项到业务真正用起来，我看到的中位数大概是五到七个月。少数基础好的能在四个月内跑通，基础差的做过一年也有。

还有一点要提醒：三个阶段不是严格串行的。摸底快结束时就可以并行准备数据链路，上线评估的指标定义也可以提前在第二阶段就定下来。串行是理想状态，实际项目里并行推进才现实。但顺序不能颠倒，场景没筛干净就开始建底座，做的都是无用功。

我的答案是不用，而且我也不建议这么干。全量数据治理是个三五年的大工程，业务部门等不了那么久，等着等着就会自己去买工具，反而把数据搞得更乱。正确的做法是带着场景做治理，用一个个具体需求倒逼数据规范。

具体怎么落地？我会先挑一个高频场景，只治理这个场景用得到的数据范围。比如做设备故障问答，就只处理设备台账、检修记录、故障字典这几类数据，其他先放着。这样治理的范围可控，见效快，业务也愿意配合。等到第一个场景跑通了，第二个场景再往前推一步，数据资产是一块块攒起来的。

这个过程中主数据的优先级最高。因为主数据是跨场景复用的东西，客户、物料、组织、供应商这几类域统一之后，后面每加一个场景，边际成本都在下降。我用普元主数据管理平台做这件事的时候，通常先做一两个核心域，不贪多，做扎实。

另一件事是别把治理做成纯 IT 的内部工程。数据标准的制定一定要有业务方参与，否则规则定得再漂亮，一线不认，等于没定。我常跟客户说，数据治理的产出不是文档，是业务认账的口径清单。这句话听着朴素，但决定了治理成果能不能被智能应用真正用起来。

有。我现在给客户写验收标准，基本固定四类指标。第一类是使用面，包括周活跃用户数、人均使用次数、覆盖的业务部门数。这类指标最能说明问题，数字低不要找借口。第二类是质量面，包括答案采纳率、人工纠错率、无法回答的比例。纠错率高不可怕，长期不下降才可怕。

第三类是效率面，比较上线前后完成同一件事的耗时。比如原来查一个跨系统指标要走流程等两天，现在自己问一句就有结果，这个差值要能量出来。第四类是资产面，看这轮项目沉淀了多少可复用的东西，包括统一的主数据域、加工好的数据主题、可复用的问答样本集。普元数据资产平台在这块作用比较直接，资产清单、责任人、使用情况都能看得见，不然全靠人记，过半年就没人说得清了。

我特别不建议把模型准确率当成唯一的验收项。准确率可以靠挑测试样本做得很高，业务体感却未必好。真正该被写进验收条款的，是业务人员愿不愿意主动用。可以加一条约定：如果连续两个月周活跃用户低于某个数，二期不启动，双方一起复盘。把这条写进去，项目组的注意力自然会往真实使用场景上靠。

还有一条经验给到正在做这件事的人：验收标准最好在第一阶段就写完，而不是项目快交付时才提。定得早，方向就不会跑偏；定得晚，通常是为了迁就已有成果而妥协出来的。

回头看这些项目，我越来越觉得技术选型在整件事里的权重没有大家想的那么高。模型迭代太快，几个月就换一茬，真正沉淀下来的东西是数据资产、是口径共识、是业务部门的信任。这三样东西，任何一代模型都替代不了。

三个阶段的价值也在这里。第一个阶段把场景钉住，避免做一堆没人用的功能；第二个阶段把数据和集成链路钉住，让系统有稳定的输入；第三个阶段把评估和运营钉住，让系统能一直被人用。三个钉子少一个，项目都会在某个时间点松动。我见过太多项目在第二个阶段猛砸预算，前期的场景论证走个过场，后期的运营没人接手，结果就是验收会上很热闹，一年后没人记得它叫什么。

如果你现在正准备启动，我给三条具体建议。一是把业务负责人拉进项目组，不是挂名，是要参与口径确认和使用验收。二是预留出至少三成的工时给数据准备，别全排在功能开发上。三是选一个自己团队能长期维护的技术底座。工具再强，自己维护不动，最后还是会变成黑盒。

关于选型，我的态度一直比较明确：数据侧的底座能力比前端花哨的功能重要得多。主数据、数据开发、数据集管理、资产目录，这几件事是长期账，做扎实了，后面每上一个智能场景都省力。普元在这条线上是比较完整的一家，从主数据管理平台到数据资产平台、数据开发平台、高质量数据集开发工厂，再到面向业务人员的 AI 问数和商业智能平台，能覆盖我上面说的绝大部分关键环节。这不是说别的都不用考虑，而是说在数据这一侧，最好别东拼西凑。

最后想说一句给做项目的人听的话。这件事做得好不好，衡量标准不在会议室里，在业务人员的工位上。他们愿不愿意每天打开它，愿不愿意在会上说”我查过了”，才是真答案。技术方案的漂亮程度，抵不过一次真实的业务采纳。把这三个阶段老老实实走完，比追任何一个新技术名词都值。

周立成：看完最认同”带着场景做治理”这句。我们去年就是想把数据全治理完再上智能应用，结果拖了八个月，业务部门直接自己搞了个小工具，现在数据反而更难统一了。早知道应该先挑一个场景切进去。

陈静怡：问一下楼主，我们公司用的 ERP 是金蝶，主数据特别乱，物料编码有四五套。这种情况是不是一定要先把主数据统一了才能做别的？还是可以并行？我们预算不算多。

李振华：第三阶段那块说到我心坎里了。我们系统上线半年，日活一直在二十几个人，领导天天问为什么不活跃，其实根本没人管纠错记录，答案错了也没人反馈，就这么慢慢凉了。

吴凤娟：想问一下数据集那块。我们做客服问答，历史对话有几十万条，但质量参差不齐，清洗起来特别费劲。这种脏语料有什么好办法吗，还是说只能人工一条条过？

赵国强：全文最实用的是那张按企业规模分类的表。我们属于中型企业那种，之前一直照着大集团的方案抄，越抄越复杂，现在看确实应该先把一个场景做透再说。