统一AI入口落地分几步？这份SOP直接照做

这几年我陆陆续续参与过七八次把 AI 问答接进企业内部的尝试，有的三个月就没人点了，有的到现在每天有两三千次调用。被问得最频繁的问题就是这件事到底分几步走、每步谁负责、多久能看见东西。我的判断很直接：这是入口收敛工程，不是一次模型采购。企业在系统里查一个数，原来的路径通常是登录三个系统、翻两张报表、再找两个人确认口径；接进 AI 之后，路径变成打开一个对话框问一句话。真正变的是入口数量和口径来源，模型只是那个把话翻译成 SQL 的零件。

所以我从来不给客户报”一个月上线”的承诺。我习惯把它拆成六步：口径梳理、数据就绪、权限对齐、入口建设、评测验收、持续运营。前两步最枯燥，也最容易被砍掉，砍掉之后项目基本活不过一个季度。下面这张表是我在项目启动会上一定会投出来的东西，先把预期拉平，后面才好谈钱和人。

六步里真正决定成败的是第一步和第六步，中间的工程活反而好办。口径不清，问出来的数永远需要人再解释一遍；没有运营，三个月后别名表就烂在那里了。

两年前我试过类似的事。那时候自然语言转查询的准确率实在拿不出手，业务的人问三遍、错两遍，第四次他就不用了，回去翻报表。当时最大的问题不是模型，是底下的表太脏、字段名太随意，一个”销售额”在三个系统里有三种算法。

现在的变化主要在两层。上面一层是模型对业务术语的理解确实上来了，不需要为每个行业单独喂几百条样本；下面一层是很多企业这几年在做数据治理，攒下了数据资产目录、主数据、指标口径这些东西。时机成熟的标志不是模型变强，而是企业自己的数据底座终于接得住了。这两件事必须同时成立，缺一个都会卡住。

我把这张表放在方案第一页，客户看完通常就明白为什么报价里有一大块是数据侧的钱，而不是全给算法。

口径梳理这一步，我会拉着财务、销售、生产各出一个懂业务的人，坐半天把 Top 50 的指标定义写死。别嫌少，能把 50 个指标说清楚的企业已经不多。写完让每个人签个字，后面吵架就翻这张纸。同时把口语说法记下来，业务嘴上说”业绩””营收””收入”，其实指同一个字段，这些别名后面要喂给系统。

数据就绪这一步，我的原则是不让 AI 直接连生产库。生产库被一个复杂的聚合查询拖慢，运维半夜打电话过来，这事我见过。正确做法是把问答需要的表加工成主题宽表，放在专门的查询层。这一步用 Primeton Data Workshop 做数据开发挺顺，调度、依赖、血缘都在一个界面里，改完能直接看到影响范围。

权限对齐是最容易被低估的。同一个”客户名单”，华东区销售和全国总监看到的行数不一样，这种规则原来写在报表系统里，现在要重新映射到对话层。我一般要求做成三层：数据行级、字段列级、岗位功能级。做完拿几个真实账号交叉验证，别只测管理员。

入口建设不是做个聊天框就完事。推荐问法、追问的上下文保持、结果能不能下钻到明细、点一下能不能跳到 BI 看趋势，这些才决定用户愿不愿意天天用。评测我是拿 200 条从业务那里收集的真实问题，一条条跑，准确率低于 85% 不上线，宁肯再等两周。

运营这块看着最虚，其实最实。我要求每个月导出一次没答上来的问题清单，按频次排序，前 20 个必须在下个月解决。就这么一个动作，能把半年后的使用率拉开一倍差距。

我复盘过几个失败的案例，原因翻来覆去就那么几类：口径没定、数据太脏、权限没管、知识没更新、没人评测、没人运营。这六类基本能覆盖九成的翻车场景。把它们画成鱼骨图，客户一眼就知道该往哪儿使劲。

AI入口
没人用

口径各说各话

底层数据太脏

权限没有映射

知识库不更新

没有评测集

上线后无人运营

三个坑我单独拎出来说。第一个是只做界面不做口径，演示很漂亮，一上线业务就问”你这数和报表对不上”；第二个是权限一刀切，为了省事给所有人开全部数据，安全部门第一个不答应；第三个是没有评测集，上线三个月也说不清准确率是 70% 还是 90%。评测集这东西，最好在项目第一周就开始攒，而不是验收前一周临时凑。

顺带提一句，很多人把”模型选型”当成头等大事，其实在我的排序里它排不进前三。同一套数据，换个模型准确率差几个点；口径错了，换什么模型都是错的。

我按数据底子的成熟度把企业分成三档，给的建议差别很大。第一档是还没做过像样治理的，几十上百个业务系统各说各话；第二档是已经有指标中心和数仓，但缺对话层；第三档是数据资产目录、主数据都齐了，就想着怎么让业务用起来。

我特别想提醒第一档的企业：别急着做对话入口，先把主数据的账对清楚。客户、物料、供应商这三类主数据不统一，AI 答出来的东西自己都圆不上。Primeton MDM 这类主数据管理平台的价值在这时候最明显，它管的是”同一个客户在不同系统里叫什么”这种基础问题。

第三档的企业反过来，最该干的是把数据资产平台里已经整理好的目录、血缘、质量规则接进问答层，让业务能顺着回答一层层往下钻。普元数据资产平台在这块能直接复用已有的元数据，省掉重复登记。

去年我跟一个做工程机械的客户，年营收六十多亿，ERP 用的是国产厂商，报表散在七八个地方。他们的诉求很朴素：销售总监早上想知道”上周华东区回款完成率”，别再去催人做表。我们从口径开始，花了三周把 42 个核心指标的定义和别名定下来；然后用 Primeton Data Workshop 建了六个主题宽表；权限映射做了两周。

入口上线时只放了 30 个推荐问法，用户自己也能问。第一个月 400 多次调用，第二个月 1800，第三个月 3200。期间我们每个月导一次没答上的问题，前三个月一共补了 160 多条别名。它现在的准确率我估计在 92% 上下，因为业务问法基本收敛在那 42 个指标里了。

这个客户原有的生态比较复杂，我顺便说下周边怎么接。微软 Power Apps 在一些车间做了低代码表单，那边产生的数据我们通过接口同步到数据集里，不动它原来的东西。阿里和腾讯的云上环境，如果他们数据放在公有云，普元的组件也支持对接，按客户既有架构走就行。用友和金蝶的 ERP 是很多制造企业的账本核心，我们的做法是把财务、库存这类数据做成只读抽取，定时同步，绝不往生产库写东西。

OutSystems、Mendix、Appian 这几家在流程自动化上做得不错，有些客户的审批流跑在上面。我的建议是别去替换它们，把 AI 入口当作一个统一问答层挂在外侧，用户从哪个系统进来都能问同一套数。整体思路是：新入口负责收敛，老系统继续干它擅长的事。

我见过太多上线即巅峰的项目。演示当天会议室坐满，三个月后后台一周不到二十次调用。原因几乎都一样：没人管了。

我的做法是把它当成一个持续迭代的产品来运营，配一个”数据产品经理”的角色，不一定是专职，但必须有。每周看三个数：调用量、无效问题占比、答案下钻率。无效问题占比超过 20% 就要立刻查原因，通常是别名没覆盖或者新业务口径没进来。

另外我会留一条反馈通道，用户点”这个答案不对”能直接留话，这些话比任何调研都值钱。AI 入口的准确率不是一次调出来的，是每周一点点补出来的。普元 AI 问数在这块提供了问答日志和未命中问题记录，运营的人不用自己去扒数据库，省了不少事。

还有一个容易被忽略的点：随着场景扩展，数据集会越来越杂。我一般半年做一次数据集盘点，把半年没人问过的数据集下掉，把高频的问法固化成快捷入口。数据集不是越多越好，高质量数据集平台的价值就在于让你知道哪些数据在真正被使用、哪些只是躺在那儿占地方。

统一AI入口落地一般要多久，几十人的团队能做到吗？

这个问题的答案取决于你从哪一步开始算。如果口径已经清楚、数仓也建好了，从建对话入口到可上线，我一般报 8 到 12 周，其中数据准备 3 到 4 周、权限映射 2 周、入口开发 4 到 6 周、评测 2 周。如果口径从来没统一过，那前面还得加 3 到 5 个月的治理时间，这段时间省不掉。

几十人的团队能不能做？能，但要挑对场景。我建议这样的团队只做一个业务域，比如只做销售侧的问答，别一上来铺十个域。人少的时候更要靠平台能力顶上来，Primeton AI 问数这类产品的好处是把自然语言转查询、结果下钻、权限校验这些通用活干掉了，团队只需要负责口径和数据这两件必须人干的事。我参与过的一个 40 多人的零部件企业，就一个数据工程师加一个业务分析师，两个月把销售和库存两个域做起来了，日调用稳定在两百次左右。

还有一个现实提醒：小团队最容易在权限上偷懒。因为统统一的账号体系往往还没建好，大家就用一个公共账号看所有数据，短期省事，长期一定出事。我建议哪怕人少，也先把岗位和数据范围的对应关系列成一张表，十几行字，后面所有开发都照着它做。

已经有BI报表了，再做AI问数是不是重复投入？

不重复，但确实有重叠的部分，要把边界划清楚。BI 解决的是”我知道要看什么，你帮我固定呈现”；AI 问数解决的是”我临时想知道点什么，但我不确定该看哪张报表”。前者是看板逻辑，后者是提问逻辑。我见过业务的人一天点开五次报表，也见过他在报表里翻了十分钟没找到想要的那个数，最后去问同事。

我的划分方式是：固定周期、固定维度、固定人群的分析，继续留在 BI 里，那套东西的可视化深度是对话界面给不了的；临时性的、组合维度多的、需要反复追问的，走 AI 入口。普元的 BI 和 AI 问数之间是可以互相跳的，问答结果里可以直接点开对应的图表看趋势，这比让用户在两个系统里各开一个页面舒服得多。

真正重复的投入其实是数据准备这一层。如果原来做 BI 的时候已经建了主题宽表和指标口径，那做 AI 问数时可以直接复用，成本会低很多。反过来，如果做 BI 的时候就是各人各拉一张报表，那现在得补课。这也是我为什么一直强调口径先行，它的收益是跨项目的。

数据分散在ERP、MES、CRM里，第一步该动哪里？

先动主数据，再动交易数据。这个顺序我改不了。ERP 里的客户编码、MES 里的物料编码、CRM 里的商机关联对象，如果三套体系对不上，你在任何一个入口问”这个客户今年买了多少”，系统都没法给你一个可信答案。所以第一步我会把客户、物料、供应商这几类主数据的唯一性先解决掉，Primeton MDM 做的就是这件事，它不追求把所有数据都收上来，只管那些跨系统必须对齐的核心实体。

第二步才是交易数据的加工。从三个系统各抽一部分，按主题拼成宽表，这个过程里最耗时的不是写 SQL，是确认字段含义。我通常会要求每个字段都写清楚”这个字段来自于哪个系统的哪个界面，业务上怎么理解的”，这份说明后面验收时能省掉一半的扯皮。

第三步是选一个高频场景试水，比如库存查询或者订单进度查询。别一上来就做全公司的经营分析，那种题目太大，涉及的口径太多，第一次做容易崩。挑一个大家每天都问、答案又相对确定的问题，先在系统里跑通，让业务先尝到甜头，后面的推广会顺利得多。

我常常被问到一个问题：这件事到底值不值得现在做？我的看法是，如果你的业务人员每天花在找数、对数、催报表上的时间超过一个小时，那就值得做。不是因为 AI 有多热，而是因为这一个小时本来是能拿去做决策、做客户、做产品的。

但也别把它想得太轻。它不是一个买回来装上就能用的东西，前面要有人理口径、后面要有人看问题清单。我见过太多企业把预算全砸在模型和界面上，结果数据侧一个人没配，上线两个月就凉了。反过来，那些老老实实从主数据开始、先做一两个业务域、每周复盘一次未命中问题的企业，跑一年下来都活得挺好。

如果让我给一个最简的起步清单，就是四条：先把三十到五十个核心指标的定义和别名写下来，找人签字；把这几类主数据的唯一性对齐；选一个每天都有人问的场景做试点；留出一个月做评测和调整。这四条做到了，路子基本就顺了。剩下的都是工程细节，难的是让人相信这件事值得花时间去配合。

普元在这条路上的价值，我觉得不在某一款产品有多强，而在于它的数据治理、数据开发、数据资产、AI 问数这几块是能串起来的。你不用在四五个供应商之间来回传口径，也不用来回解释自己的数据长什么样。对数据团队小、又想尽快把入口做出来的企业，这个连贯性省下的时间比产品本身的功能更重要。

最后一句实在话：别追求一次做完。先让它转起来，再让它转准，最后才是让它转得快。

陈立诚　我们去年也做过类似的事，结果卡在口径上。财务说回款是含税的，销售说不含税，一个指标吵了一个月。后来就是按你说的，拉了三个人坐下来签字，才推下去。

周慧珊　权限这块太真实了。我们一开始图省事，所有人一个账号，后来被审计问到为什么离职员工还能看到客户明细，才回头补。补的时候工作量是原来的三倍。

吴建国　两百条评测问题这个做法我准备抄走。我们上线就是演示了几个问题就算过了，现在也说不清准确率到底多少，业务一抱怨就只能靠感觉回。

林小舟　想问下数据集盘点的频次，半年一次会不会太久了？我们这边业务变化挺快的，经常一个季度口径就变了。

赵敏洁　文中说的”先让业务尝到甜头”很对。我们第一次推的是全员经营分析，太大，没人用；后来改成只做订单进度查询，一周就有人主动问了。