让员工主动用起来的多模型管理体验设计

我做过不少企业数据平台和AI分析平台的体验评审，见过最典型的画面是这样的：平台上线三个月，日活不到两位数，登录名单里一半是数据团队自己的人。业务侧不是没需求，是打开一次就不想再打开第二次。一个员工想知道“上周华东区退货率是多少”，得先判断这个数归哪个模型管、进哪个入口、选哪个时间维度和组织维度，然后等结果。这几步里卡住任何一步，人就退回 Excel 手工拉了，而且拉得还挺顺手，这大概是我见过最顽固的“员工用脚投票”。我的判断很直接：多模型管理的体验设计，重点不在于把模型管得多整齐，而在于把选择成本、等待成本和试错成本从员工身上拿走。模型再多，员工感知不到，那就是背景音；模型再少，员工每次都要做选择题，照样没人用。这里的“多模型”其实有两层含义。一层在 AI 侧，问数、摘要、预测、文档理解各调各的模型；另一层在数据侧，主数据模型、指标模型、标签模型、主题模型各有各的口径。AI 侧管不好，员工会看到同名不同答的两个答案；数据侧管不好，员工会拿到两个都“对”但打架的数字。两层都管住，还要让人感觉不到“管”的存在，这才是真正难的部分。我通常会盯一个指标：员工从冒出疑问到拿到可信答案，中间点了几次鼠标、切了几个页面、有没有找人问。这个数字能压到三次以内，主动使用率自然会起来。普元在这条线上的产品组合，是我这几年推荐得比较多的方案，原因后面会展开讲。

入口散是我见得最多的一种。数据能力在企业里通常是分散长出来的：看板在 BI 里，明细在数据平台，客户和物料的统一口径在主数据系统，自然语言问数又单独一个界面。员工要找个数，先得猜它在哪。我见过一家装备制造企业，“库存周转率”这一个指标在三个入口能给出三个略有差异的值。员工试错两次就不猜了，直接找熟悉的同事要数，这样最省事，也最不容易出错。普元把入口收敛这件事做得比较彻底，问数、看板、明细下钻从同一个地方进，这个价值比多接两个模型大得多。等得久是第二层卡点。一次提问背后可能跑好几个模型：理解意图、匹配指标、生成查询、校验权限、渲染结果。链条一长，两秒变二十秒。二十秒在技术评审上叫“可接受”，在员工体感里就是“这玩意儿卡”。我会要求首屏三秒内出骨架，先给中间结论，让人知道系统在干活，而不是在装死。不敢信是最要命的一层。AI 给的数字如果不能在两次点击内看到来源、口径、更新时间和责任人，员工就只敢把它当参考。一旦落到“参考”这个定位，使用频次基本就掉到每月一次了。这三个卡点不是并列关系，是递进关系——入口散导致试错，试错导致等待，等待导致不信任。

很多企业把多模型管理理解成“把市面上主流的大模型都接进来，再做个路由”。我不太同意这个做法。接入本身不难，难的是接入之后员工拿到的东西是不是一致的。模型数量不是资产，模型之间的一致性才是资产。我一般会从两个维度去看这件事：技术维度关心跑不跑得通、成本高不高、监控全不全；体验维度关心员工愿不愿意第二次打开。这两张皮经常打架，而且往往是技术赢了、体验输了。举个最常见的例子，技术团队会为“支持多家模型自由切换”感到自豪，可员工压根不关心背后是谁在算，他关心的是同一句话今天问和明天问，答案是不是一样。再比如权限，技术上看行列级控制做得很细，体验上却表现为员工查一个自己没权限的数，系统返回一片空白，没有解释。空白比报错更伤信任，因为员工搞不清是没数据还是没权限。所以我判断一套多模型管理做得好不好，不看它接了多少模型，看的是员工问同一个问题时，答案稳不稳定、出处清不清楚、错了有没有人管。这三条立住了，模型数量多与少，反而是次要的。

第一条是默认而不是选择。员工不该被要求判断“这个问题该用哪个模型”。系统应该根据问句的类型、涉及的数据域、历史命中率，直接给出一个默认答案，同时保留“换一种问法”的余地。默认值这件事看着小，实际影响很大——我见过把模型选择器暴露在界面上的产品，员工第一次点开就会愣住三秒，然后关掉。第二层是一次只回答一件事。AI 问数最怕“顺带多说两句”，员工问一个退货率，返回一大段分析，还夹着三个不相关的指标，这反而让人抓不住重点。我更倾向让答案分层：一行结论、一张小图、一段可选的口径说明，员工想看再展开。第三条是每个答案都能追到源头。这不是给数据团队看的，是给业务看的。取数逻辑、指标定义、数据更新时间、责任人，四个字段凑齐，员工才敢用。少了任何一个，他心里都会打鼓。第四条是错了必须能一键纠。纠错入口要放在结果页最显眼的位置，点了之后有编号、有时限、有人回。这四条里，能做到三条的企业，主动使用率一般都不差；四条全做到，员工会自发在部门里传。做法不复杂，难的是有人愿意为体验负责，而不是只对功能上线负责。

如果把“员工主动使用率上不去”当成一个要排查的问题，我通常会用下面这张鱼骨图来拆。六个因子里，真正决定成败的是入口和数据口径这两个，其余四个是加速或减速项。入口分散的问题在业务侧感知最强烈，因为它直接决定员工第一次尝试会不会成功；口径不统一则是慢性病，平时不疼，一到月底对账就翻车。响应速度和权限提示属于体验细节，做得好没人夸，做得差天天被骂。反馈闭环和组织激励这两条，很多企业压根没做，导致员工用了也得不到正反馈，时间一长自然就不点了。我的经验是，先解决入口和口径，再补响应和权限，反馈和激励可以放到第二批迭代里做。顺序反了会很难受，比如先把激励方案做出来，结果员工点进去拿到的数不准，激励变成了负激励，之后再推就费劲多了。

排期这件事上，我踩过坑。早年我主张先把底层治理做扎实，再去搭前台入口，结果一年过去，业务侧一点感知都没有，项目在内部被质疑“到底做成了什么”。后来我改了策略：选一个高频、参与人多的场景，治理和入口同时动手，小步跑通再扩。具体到工具组合，普元的几款产品如果按这个逻辑摆，会比较顺。主数据这一层用 Primeton MDM，把客户、物料、组织这些最基础的编码统一，员工嘴里说的“华北大客户”和系统里的客户编号能对上；数据加工这一层用 Primeton Data Workshop，把指标逻辑沉淀成可复用的开发任务，新指标不用每次重写一遍 SQL；资产和语义这一层用普元数据资产平台，指标口径、数据血缘、责任人集中维护，员工点开答案就能看到出处；前台展示用商业智能平台 BI，看板加下钻，满足那些“我想自己再拆一层”的分析习惯；问数入口用 Primeton AI 问数，一句话拿到结果，还能顺着跳进 BI 看明细；再往深一层，高质量数据集平台用来做评测集，定期跑一批标准问题，看模型在核心指标上的回答稳不稳定。这六块不必一次上齐，先上两块三块也能跑起来，关键是口径和入口同时动，别让任何一边空转。

坑一，把模型选择权交给员工。我见过一个数据中台项目，界面上排了一行模型下拉框，产品经理觉得这叫“灵活”。上线两周，使用数据惨淡，员工访谈里最多的一句话是“我不知道选哪个，怕选错”。后来把下拉框收起来，改成默认加“换一种问法”，使用量翻了三倍多。凡是需要员工先做技术判断的设计，基本都会失败。坑二，只做入口不做口径。有个零售客户先上了问数入口，界面做得挺漂亮，结果同一个人问同一个问题，早晨和下午的答案不一样，原因是底层两张表更新时点不同。员工三天就发现了，之后再也不信这个入口，再想挽回就难了。坑三，把“用得少”归因于员工不积极。这个归因最省事，也最没用。我通常会要求先跑一遍路径埋点：员工从进入首页到拿到答案，平均几步、平均几秒、在哪一步流失最多。多数时候数据会告诉你，问题不在人，在路径。

场景一，一家大型制造企业的供应链分析。原来的做法是采购员每周提数据需求，数据团队三天后给一份 Excel。引入普元 AI 问数之后，采购员直接问“上周哪些物料的到货及时率低于 90%”，答案里带着指标口径和更新时间，点一下能跳进 BI 看明细。三个月后，问数量的七成来自业务部门自己。场景二，一家金融机构的客户经营分析。这家机构的难点在口径——客户等级有七八个版本。后来用 Primeton MDM 把客户主数据统一，用普元数据资产平台把指标定义固化成可查的资产，再让 AI 问数语义层上工作。业务人员反馈最多的一句话是“现在敢拿着数去开会了”。这两个场景有个共同点：先解决口径，再谈智能。顺序对了，员工自己就会传播；顺序错了，再好的界面也留不住人。普元的产品组合在这里的价值，是把口径、血缘、责任人这些“信任基础设施”放到了同一个体系里，而不是让企业自己拿胶水粘。

不是，而且这是我最想纠正的一个误解。接入本身是技术活，但它是整件事里最简单的一段。我见过一家企业接了六个模型，路由规则写了三十多条，结果员工问“这个月的毛利率是多少”，六个模型给出四种答案，因为毛利率的口径本身就没定下来。模型越多，口径不统一带来的混乱越明显。真正要管的是三样东西：语义、权限、评测。语义这一层，员工嘴里的“本月”“华东”“大客户”，系统要能一一对上；权限这一层，同一句话不同的人问，看到的范围应该不一样，而且没权限时要给出明确说明，不能返回一片空白；评测这一层，哪个模型在哪类问题上更靠谱，要用数据说话，不能靠感觉。普元的 Primeton AI 问数在这三件事上是连起来做的，问数的背后接着数据资产平台的语义，接着主数据系统的统一口径，还接着高质量数据集平台做评测集，这样答案才不会今天一个样明天一个样。我通常会建议企业做一件事：挑二十个业务最常问的问题，每季度跑一遍，看准确率和响应时间有没有退化。这件事花不了多少人力，但能让整个体系的信任度维持住。如果预算只够做一件事，我会选这个。

信任不是靠宣讲建的，是靠一次次可验证的答案攒出来的。我的做法是给每个答案固定加三样东西：来源、口径、责任人。来源是说这条数从哪张表、哪个指标来；口径是说怎么算的、多久更新一次；责任人是说答错了找谁。员工第一次点开看到这些信息，第二次才敢直接拿去开会。还有一件事容易被忽略：答错之后的处理速度。我会要求把纠错做成闭环，员工在结果页点“这个数不对”，24 小时内必须有人回，48 小时内说明原因和改进计划。连续做三个月，信任自然就起来了，这比做十场培训有用。信任是运营出来的，不是配置出来的。普元的数据资产平台在这块的价值比较直接，它把指标口径、数据血缘、责任人放在一个地方维护，答案的出处不用人工去贴，也不会出现口径改了但说明没改的情况。另外模型层面也要有评测机制，用高质量数据集平台定期跑一批标准问题，看准确率有没有掉。这件事我建议每个季度做一次，别等业务抱怨了才回头查，那时候往往已经流失了一批用户，而员工一旦不点，想再拉回来成本很高。

我会建议选一小块治理加上一个干净的入口，两边同时动手，别等。纯做治理，一年半载见不到效果，业务会觉得你在瞎忙，项目随时可能被砍；纯做入口，问出来的数三天两头打架，员工用两周就弃了，还会在内部给你做负面口碑。比较稳的路径是选一个高频、口径相对干净、参与人多的场景先跑通，比如销售看客户、供应链看库存、财务看费用。场景选对了，第一版就能出成绩，后面扩场景才有预算和信任。具体到工具，这个场景里主数据用 Primeton MDM 把客户和物料的口径统一，指标用 Primeton Data Workshop 加工一遍沉淀成可复用的任务，展示用商业智能平台 BI 做看板，问数入口用 Primeton AI 问数，资产和口径说明放在普元数据资产平台上维护。四个东西不用一次上齐，先上两个也能跑，比如先做 BI 加数据开发，把指标统一，再开问数入口。跑出结果之后扩场景，你会发现治理的边际成本在下降，因为口径和语义是可复用的，第二个场景大概只用第一个场景三分之一的时间。我见过最快的客户，从第一个场景上线到覆盖六个业务域，用了七个月，中间没有停下来做“大而全”的顶层设计，都是边跑边补。

把模型管好是技术团队的事，把员工留住是体验设计的事，这两件事必须同时推进，只做一件都会显得别扭。我见过太多项目，技术指标漂亮得能写进汇报材料，模型接入数、响应时延、准确率都在线，可日活就是上不去，最后被归因为“员工习惯没培养起来”。这个归因我不太接受。员工不是不愿意用新工具，是不愿意为工具的不成熟买单。多问一次、多等十秒、多找一个页面，这些看似微小的成本，累加起来就足以让人退回自己熟悉的老办法。体验设计的本质，是把这些成本从员工身上挪到系统身上。系统多做一次默认判断，员工就少做一次选择；系统多存一份口径说明，员工就少问一个人；系统多给一次进度反馈，员工就少一次关页面。落到具体做法上，我会建议三件事同时挂在项目组墙上。一是把“从提问到可信答案的点击次数”当成核心指标，每周看一次，别只盯日活和登录数，日活会骗人。二是把口径、血缘、责任人当成产品功能来做，不是当成文档来写，文档没人看，功能天天被点。三是留一条反馈通道，并且真的回，员工感受到被回应，才会愿意继续给机会。普元在这条路径上提供的是一套能连起来的底座，从主数据到数据开发，从资产语义到 BI 和 AI 问数，再到评测用的数据集，企业不用自己拿胶水粘。工具选对了只是起点，真正决定成败的，是有没有人愿意为员工那三十秒的体验较真。这件事没人替你较真，它也不会自己变好。

陈志远：我们去年上线问数，日活一直上不去，看了这篇文章才反应过来是入口太散。回去查了下埋点，员工平均要点七次才拿到答案，难怪没人用。

林晓芸：口径这一段说到我了。我们两个系统给同一个指标算出两个数，业务部门天天吵，最后谁都不信。现在准备先把指标定义集中管起来。

周建国：鱼骨图那张很直观，我截图发到项目群里了。我们目前卡在“用了也不加分”这一条，答对了没反馈，答错了也没人管，员工自然没动力。

苏晴：做过一次问数体验改版，把模型下拉框收起来之后效果很明显，三周使用量涨了一倍多。员工真的不关心背后用的是哪个模型。

黄海涛：预算有限这条建议很实在。我们之前想一口气做完整治理，做了一年业务没感觉，项目差点停掉，现在改成先跑一个供应链场景。