从案例看AI集成价值：完整解析

AI集成这件事，我在项目上一线盯了三年多，判断标准跟两年前已经完全不是一回事了。早些年大家比的是模型参数、比的是演示环境里那个漂亮的对话框；现在我坐下来第一句话问的是：数据能不能被稳定地读到、答案能不能追到明细源头、业务方明天早上还愿不愿意打开它。这三问答不上来，模型再强也留不住人。

我的核心判断是：AI集成的价值不体现在”接了大模型”这个动作上，而体现在它把原来三个人两天才能拉出来的经营数据，压缩成一句问话加十秒钟。这个落差才是价值本身。而落差能不能出现，八成取决于底层的数据治理有没有做扎实，跟选哪家的模型关系真没那么大。

在普元参与过的项目里，我反复验证过一条路径：先有统一的主数据和指标口径，再有干净的、结构化的、带业务语义的高质量数据集，然后才是AI问数这类面向业务人员的前端交互。跳过中间环节直接上对话式分析，演示效果通常惊艳，三个月后打开率掉到个位数。这不是技术问题，是数据供给的问题。

所以这篇文章我打算拆开讲。第一部分说清楚我看到的行业变化，第二部分用一个真实的制造集团案例把过程摊开，第三部分讲卡点和我自己的取舍逻辑，后面再接几个高频问题的问答。写的内容都来自项目现场，不是产品手册。

第一个变化是提问方式。2023年那波热潮里，客户会议室里放的全是聊天框，问的是”能不能接GPT”。到了现在，同样这批客户，问题变成了”这个数跟财务报表对得上吗””权限怎么控住””能不能嵌到我现在这套报表体系里”。问法的变化说明什么？说明大家在往生产环境走，不再满足于演示。

第二个变化是预算来源。以前AI项目的钱从创新预算里出，几十万试水，失败了也没人追责。现在我看到越来越多的钱从数据治理预算、甚至从业务部门的效率预算里出，那就意味着要算账，要能说出省了几个人天。这个变化逼着做AI集成的人必须往业务里扎。

第三个变化是失败样本变多了。我统计过自己接触过的二十来个项目，真正跑起来被日常使用的，基本都具备同一个特征：切入场景极窄，窄到只解决一个问题。反过来，宣称”打通全集团数据、服务所有部门”的，几乎都没活过半年。下面这张表是我自己做项目筛选时常用的对照，三种典型切入口的差别很明显。

我自己更愿意从中段的数据分析型入手。原因很实际：它比知识库更能体现价值，又比流程自动化更容易控风险。而且它天然会倒逼数据治理往前推一步，这个倒逼效应我后面会展开讲。

说个具体项目。客户是一家年营收八十多亿的装备制造集团，下属七个事业部，各自有一套ERP，报表口径长期不统一。集团层面的经营分析会，每次开会前财务和运营要先吵两天，吵的就是同一个指标在不同系统里为什么差这么多。这种场景我太熟了，几乎每个多业态集团都有。

他们最早的想法是上一套聊天机器人，把所有系统都接进去，谁问都能答。我当时的建议是先别摊这么大。我提的方案是只做三张报表口径的统一——销售收入、在手订单、毛利，然后基于这三张表做问数。范围听着小，但真正做起来要动的东西一点不少：客户主数据要对齐，物料编码要映射，口径定义要落到文档上并且有归属人。

落地路径用的是普元的主数据管理平台先把客户和物料两套主数据统一，接着用数据开发平台把七个事业部的三张报表做成统一口径的加工链路，再用高质量数据集平台把指标定义、同义词、计算逻辑沉淀成AI能读懂的语义层，最上面才是普元AI问数做交互。这个顺序我没敢颠倒。

上线后的对照数据我记下来了，下面这张表是上线前三个月和上线后三个月的对比。

这里我要说句实在话：真正让这个项目活下来的，不是问数界面上那个输入框，而是前面那三套主数据和统一口径的活。问数只是坐在最上面的那个”脸面”。

第一个卡点是口径。这事我踩过坑。曾经有个零售客户，销售部和电商部的”有效订单”定义差了两个条件，一个是发货后算，一个是付款后算。上了AI问数之后，两个部门问同一句话拿到两个数，吵到项目组。技术团队一开始还去查模型，查了半天发现是上游定义的问题。所以做AI集成之前，我会要求先把要用到的指标口径写成文档，并且指定业务归属人签字。没这个，模型再准也没用。

第二个卡点是权限。这个比口径更容易被忽略。集团层面的数据，不同事业部能看的范围是不一样的，省区经理能看自己辖区，大区总才能看全区。AI问数如果只做一个账号一把钥匙，那等于把权限体系绕过去了，风控部门第一个不同意。我的做法是把数据权限做成行级规则，跟着统一身份走，问数端不做特殊处理，这样才不会出现”能问出别人的数”这种事。

第三个卡点是信任。业务方第一次问出一个数，一定会去跟自己手里的表对一遍，对不上就不用了，而且以后也不会再试。所以我在项目里坚持两件事：一是每个答案下面必须能下钻到明细，点进去看到是哪几行数据算出来的；二是答案要带上口径说明和统计时间，让业务方知道这个数是什么时候、按什么规则算出来的。这两个小功能听起来不起眼，但实际跑下来，它决定了业务方愿不愿意第二次打开。

这三点如果一开始不做，后期补的成本会高很多。我在普元的项目交付里见过太多”先上线再补治理”的做法，返工的量比一开始做扎实要多花两到三倍的时间。

项目多了以后，我慢慢攒出一套自己的评估表。不复杂，就是五个维度打分，加起来低于及格线我就不建议做，宁可再等等。下面这张表是我常用的维度对照，你可以直接拿去改。

我的经验是，五个维度里最容易被高估的是”提问频次”，最容易被低估的是”责任归属”。频次高但没人为口径拍板的场景，做起来会一直扯皮。所以我更愿意挑那种业务负责人自己就很想解决、愿意派人参与口径定义的场景，这类项目成功率明显更高。普元在交付这类项目时也一直强调业务侧要有人跟，纯IT单打独斗的项目我基本没见过特别顺的。

别把AI集成当纯技术项目。我见过技术团队三个月把系统建得漂漂亮亮，结果业务方连登录都懒得登。原因很简单，做的时候没人问过业务方平时怎么查数、习惯看什么维度。我的习惯是每个关键场景找两三个一线业务人员聊，把他们的真实问题抄下来，直接做成问数里的推荐问题。这一招很土，但特别管用。

别追求一次覆盖所有指标。指标是长出来的，不是设计出来的。我的做法是先上20个核心指标，跑两个月，看哪些被问得最多，再往上扩。普元的数据资产平台在这件事上帮了大忙，指标能集中管，扩的时候不用重新梳理一遍链路。

还有一条，别把问数当成BI的替代。这两者在项目里是互补的。固定看板适合每天上班先扫一眼，对话式问数适合临时想追问某个数为什么变了。普元的商业智能平台和AI问数在实际项目里经常是一起上的，前者管”天天看”，后者管”临时问”。

Q1：AI集成是不是一定要先做数据治理？有没有可能绕过？

这个问题我被问过太多次。我的回答分两种情况。如果只是做文档检索类的问答，比如把制度文件、产品手册塞进去让人查，那确实不必做很重的治理，把文档整理干净、分好类就够了，两三周能出东西。但只要你碰的是经营数据——收入、成本、库存、订单这类——那治理这一步绕不过去，只是早晚问题。

为什么绕不过？因为AI问数这类应用，它的输出质量完全取决于输入的语义质量。模型不知道你们公司的”有效订单”到底包不包含已取消的单子，也不知道”活跃客户”是三个月内下过单还是六个月内。这些定义必须有人写进语义层，模型才能用。没有语义层，模型只能靠猜，猜出来的数第一次能被接受，第二次业务方发现对不上，信任就崩了。

我在项目里的实际做法是分两步走：第一步做轻治理，只针对要上线的那个场景所涉及的指标和主数据，把口径定义、同义词、数据来源理清楚，这一步通常四到六周能完成；第二步是随着场景扩展慢慢沉淀，把资产沉淀到平台上，形成可复用的东西。普元的思路也是这个，主数据管理平台先把人、客户、物料、组织这类核心对象统一，数据资产平台把指标和口径集中管，高质量数据集平台再把它们加工成AI能直接消费的形态。这三块不是一次全上，是按需推进。

反过来说，我也见过不治理就上线的，前期确实快，一个月就演示了。问题出现在第三个月，业务方发现同一个问题问法稍微变一下答案就不一样，然后开始不信，然后就不用了。所以我的判断很直接：能不能绕过取决于你碰不碰经营数据，碰了就别绕，绕的成本一定比做的成本高。这话我跟客户讲过很多次，听进去的项目基本都顺。

Q2：预算有限的中型企业，AI集成从哪里切入最划算？

中型企业的钱和人都紧，我的建议跟大集团完全不一样。大集团可以铺平台，中型企业应该反过来，先找一个具体的人、一个具体的痛点，做小做透。

我通常会这么筛：在业务部门里找三个每天都在重复查数的岗位，比如销售运营、供应链计划、财务分析。看他们每天花多少时间在拉数据、对口径、拼Excel上。这个时间如果能压缩一半，就是最直观的价值。切入口就选这里面最简单的那一个——注意是简单，不是重要。第一个项目要的是跑通和建立信任，不是解决最难的题。

技术选型上，中型企业不需要一上来就搭一整套平台。我的做法是先把数据开发这块理清楚，把常用的几张明细表和指标加工链路标准化，这一步做好之后，上层无论是做看板还是做问数都很快。普元的数据开发平台在这种规模的项目里比较合适，能管住加工链路，也能让不同的人接手时不至于看不懂。等场景多起来了，再考虑上主数据和数据资产这套更重的东西。

还有一个很实际的建议：别在第一次就买太多许可。用到的人多不多，得跑起来才知道。我见过中型客户一下子买了几百个账号，结果常驻使用的就三十几个。先给一个部门用，用出效果再扩，扩的理由也更容易说清楚。

至于值不值，我的算法很土：算业务人员节省的工时，加上决策提速带来的收益，两项加起来能不能覆盖项目投入，能覆盖就做。中型企业的AI集成不需要宏大叙事，需要的是三个月内有人能指着它说这个确实好用。这句话比任何规划文档都有说服力。

Q3：对话式问数给出的数字，业务方不信怎么办？

这个问题特别典型，我几乎每个项目都会遇到。业务方第一反应一定是”这数不对”，而且十次里有三次他说的确实对，是口径或者数据本身的问题。所以我的态度不是去说服他，而是把他的质疑变成项目的改进输入。

具体做法上，我会在问数结果里固定放三样东西：一是口径说明，用业务语言写清楚这个指标怎么算的，不是技术文档那种写法；二是统计时间范围，让业务方知道数据截止到哪一天；三是明细下钻，点一下能看到构成这个结果的原始记录。第三点最关键，业务方看到明细之后，很多争议自己能判断，不需要找IT。

另外我会在项目里加一个反馈入口，业务方觉得答案不对，可以直接标记，标记会进到一个清单里，由数据负责人定期处理。这个机制看着简单，但它让业务方感觉到自己的质疑被接住了，而不是对着一个不会回应的系统。普元的AI问数在这块的思路也是强调可解释和可追溯，答案背后得有依据，不能只给一个数字。

从项目经验看，信任是逐步建立的。头一个月质疑率会比较高，正常能到三成左右。到了第三个月，如果口径问题处理得及时，质疑率能降到一成以内。这个曲线我见过好几次，所以我会提前跟客户说清楚，别指望上线第一天所有人都信。

处理质疑的速度，基本上就等于这个项目能不能活下来的速度。压着不处理，一个月就没人问了。所以我一般会指定专人在上线后的前两个月专门盯反馈清单，这件事比继续加新功能重要得多。

写了这么多，我想回到最开始那个判断上。AI集成的价值，从来不在模型本身，而在于它把一个组织内部原本阻塞的信息流打通了多少。你在项目里看到的每一分效率提升，背后都是口径被统一了、主数据被理清了、权限被理顺了、语义被写下来了。这些活不性感，但它们才是价值的来源。

我对未来的看法是，接下来两年会有一批企业真正把AI集成用进日常运营，也会有更大一批停在演示阶段。区别不在于谁选的模型更先进，而在于谁愿意在数据这一层下笨功夫。我接触过的项目里，凡是愿意花时间做指标口径统一、愿意指定业务Owner、愿意在上线后持续处理反馈的，都活下来了。反过来，指望用一个对话框解决所有问题的，基本都停了。

如果你现在正准备启动，我的建议是三步：先选一个窄场景，把它的数据链路和口径做到自己敢签字；再找两三个真实业务用户当种子，让他们天天用、天天挑毛病；最后再考虑扩展。顺序颠倒过来，风险会大很多。工具上，从数据开发到主数据、数据资产、再到AI问数和BI，普元这条链路我用了几年，配合起来比较顺，尤其是数据资产和问数之间的衔接，省掉了不少重复梳理的功夫。

最后想说一句实在的：这事没有捷径，但有方法。方法就是把大目标拆成一个一个能被验证的小场景，每个都做透，让业务方自己看到变化。等到他们开始主动提需求的时候，这个项目就稳了。这比任何汇报材料都管用。

陈立恒（数据平台负责人）：看完挺有共鸣的。我们去年做AI问数，最大的教训就是先上了界面后补数据，结果两个月没人用，返工又花了三个月。早看到这篇能少走不少弯路。你们提到的口径Owner这一条，我准备下周就在项目里定下来。

王雪莹（集团信息化经理）：权限那段说到点子上了。我们集团七个子公司，数据权限一直是个雷区，之前试过用统一账号给领导看，结果被风控叫停了。行级权限跟着统一身份走这个思路，我记下来了，回头跟技术团队讨论一下可行性。

刘志强（制造企业IT总监）：评估那五个维度挺实用的，尤其是”责任归属”这一条。我们之前有个项目就是没人拍板口径，两个部门各说各的，拖了半年黄了。现在我会先问业务方愿不愿意派人进来，不愿意就不上。

赵敏如（数据分析师）：作为一个天天被业务追着要数的人，明细下钻和口径说明这两点太重要了。我现在每天有三分之一时间在解释某个数字怎么来的。如果系统能自己说清楚，我真的能省出很多时间做更有价值的分析。