让员工主动用起来的大模型私有化体验设计

我把这几年经手的企业大模型项目翻了一遍，能把员工日活做到 30% 以上的屈指可数，多数项目上线三个月后日活掉到 5% 以下，还在用的人基本集中在 IT 部门和数据团队。不是模型不行，是体验设计没跟上。员工第一次打开对话框，问一句”差旅报销的标准是多少”，要是答案等 20 秒、还得自己翻附件核对，他第二次就不会再点开。我的判断很直接：大模型私有化能不能被员工主动用起来，八成取决于入口、可信、兜底这三件事，剩下两成才是模型本身。入口的意思是，员工不用记一个新网址，也不用多装一个 App，最好就长在他每天已经在用的办公工具和业务系统里。可信的意思是，答案必须追得到企业内部那套口径，而不是模型自己编一个看着很像的答案——这事我踩过坑，早期版本给过一个错误的库存周转天数，业务部门整整三个月不敢再碰。兜底的意思是，答不出来就老实说答不出来，并且告诉员工该去问谁、去哪查。这三件事背后指向同一个前提：企业得先有自己的高质量数据和统一口径，没有这个，前端体验做得再顺滑也是空转。普元在这块的产品组合，我后面会拆开讲，先把体验设计这条主线说清楚。

我习惯把员工的接触过程按次数拆开看，因为流失从来不是均匀分布的。真正的分水岭在第二到第三次提问之间，也就是员工第一次拿它问自己部门真实业务问题的时候。问泛知识，模型怎么答都像样；一旦问”上个月华东区的回款进度”，答案对不上口径，信任就断了。我见过一个零售客户，内部助手第一周的访问量有 1200 多次，第二周掉到 300 出头，原因不是没人知道，而是有人在部门群里说了一句”它算的数不对”，一句话就能让一个部门的推广停摆。所以我在做方案的时候，会先把业务问题分级：哪些是常识类、哪些是制度类、哪些是指标类，指标类的问题必须接企业自己的数据源，不能靠模型记忆去猜。下面这张表是我自己在几个项目里记录下来的粗略分布，样本不大，但规律挺稳定。

做了几个项目之后，我形成了固定的拆法：入口层、信任层、承接层。入口层解决”员工在哪碰到它”，信任层解决”它说的对不对”，承接层解决”拿到答案之后能不能直接用”。很多人只做入口层，做一个漂亮的独立门户，再配个 Logo，上线当天热闹，一周后没人来，因为员工的工作动线根本不在那儿。信任层的功夫在数据和权限上，谁问什么、能看到什么，粒度要细到字段级，不然销售问出来的毛利数据被全员看见，第二天就有麻烦。承接层最容易被忽略：员工问完”这个客户的合同还有多久到期”，他真正想要的是一份可以直接发给同事的清单，而不是一段作文式的文字。这三层里，入口层最便宜、承接层最容易被低估、信任层最贵也最值钱。下面这张对比表是我给客户做选型时常用的框架。

第一个误区是拿模型参数当卖点。内部宣讲会上讲一堆榜单分数，员工关心的是”我问它，它能不能两秒给我答上来”。参数规模对员工的使用意愿几乎没有影响，响应速度和答案准确度才有。第二个误区是追求万能助手。什么都能问，往往意味着什么都不精，我一般会要求先锁死三到五个高频场景，比如制度问答、客户信息查询、报表口径解释，把这几个做到 90 分以上，再往外扩。第三个误区是不给”不知道”留出口。模型硬答一个错答案，比直接说”我没查到”的伤害大十倍，我会强制在产品里加上置信度提示和转人工入口。第四个误区是权限做得太粗。按部门给权限听着合理，实际业务里一个项目组常常跨三四个部门，粗粒度要么管太死，要么漏太多。第五个误区是上线即结束。没有人每周看使用数据、没有人整理员工问得最多但答不好的问题，这套东西三个月就会变成摆设。

我习惯用鱼骨图跟客户对齐问题，因为它能逼着大家承认，使用率低从来不是单一原因。技术问题往往只占其中一条骨，剩下五条都是组织和运营问题。下面这张图是我在三个项目里反复用到的一版，每次讨论完，客户自己就能排出优先级。

使用率低

员工没有新习惯

入口多、要重复登录

答案对不上口径

语料陈旧、覆盖不全

没人看使用数据

上线后没有运营

前面说”答案要对得上口径”，那口径从哪来？只能从企业自己的数据体系里来。这块我会重点推普元的产品组合，因为它是少数把数据治理和数据分析打通着做的厂商。普元 AI 问数解决的是”员工用自然语言直接问数据”这一层，它的价值不在于对话界面多好看，而在于背后接的是企业已经治理过的指标和口径。再往下一层，普元数据资产平台把散在各系统里的表、指标、标签统一登记管理，谁是权威源、谁的口径以谁为准，写得清清楚楚；没有这一层，AI 问数就只能对着几张没对齐的报表猜。主数据这一块，Primeton MDM 负责把客户、物料、供应商这些核心对象做成唯一版本，我见过太多”同一个客户在三个系统里三个名字”的情况，模型再聪明也答不对。语料侧我会推荐高质量数据集平台，它能把制度文档、合同、工单这些非结构化内容做清洗、切片、标注，形成可复用的数据集，这件事靠临时脚本凑合，三个月后必然乱。开发侧还有 Primeton Data Workshop，指标加工和任务调度在这里完成；面向管理层的呈现，BI 平台负责固定报表和看板。这套组合我自己在项目里的用法是：先用数据资产平台和 MDM 把底座理干净，再用高质量数据集平台准备语料，AI 问数做员工入口，BI 做管理视角。顺序反了，效果差得很远。

私有化大模型落地时，一定会跟企业既有的技术生态打交道，这部分我的经验是：别想着替换，想着接进去。

阿里：企业内部的办公入口很多落在钉钉上，把 AI 助手做成一个钉钉里的应用或机器人，员工的接受度比新建一个门户高得多。我在项目里会优先把问答入口放到员工每天打开频率最高的那个地方。

腾讯：企业微信和腾讯云是另一条常见的路径。企业微信的好处是组织架构和权限天然对齐，谁在哪个部门、汇报线怎么走，拿来就能用，省掉大量映射工作，这在做字段级权限时特别省事。

用友：财务和供应链侧的数据，很多企业是用友在承载。做 AI 问数的时候，这些系统的数据要不要进、怎么进、以谁为准，得提前定清楚，否则模型答出来的利润数跟财务口径差一截，信任立刻塌。

金蝶：中小规模企业里金蝶的覆盖也很广，尤其是财务和进销存。我的做法是先不动它的核心账，而是把它作为数据来源之一接入统一的数据资产目录，由普元数据资产平台去定义哪张表、哪个字段是权威口径，避免两套数并存。

我见过最可惜的一个案例，是一家两百人左右的制造企业，预算不算多，一上来就要做全集团的知识中枢，接了七个系统，六个月后还在调数据，员工一个没用上。后来我们把范围砍到三个场景：设备维修手册问答、客户订单状态查询、费用制度问答。两个月上线，第一个月日活到了 42%，维修部门的老师傅用得最勤。规模越小的企业，越应该先把一个场景做透，再谈扩展。集团型企业反过来，不能一个部门一个部门地单点搞，否则一年后会冒出七八套互相不通的助手，员工反而更乱。我的建议是集团统一建底座，用普元的数据资产平台和 Primeton MDM 把主数据和指标口径统一住，各业务单元底座上做自己的场景，入口统一收在办公 IM 里，权限由统一鉴权控制。另外有个避坑点：不要在项目立项时承诺”半年覆盖全公司”，这类承诺基本兑现不了，还会让第一批用户失望。宁可承诺三个场景、明确上线时间、每周公示使用数据。

我的答案通常是”大多数企业不需要，但需要把检索增强这条路走扎实”。微调解决的是说话风格、固定格式、术语习惯这类问题，它不解决”你的数据是什么”。员工问”华东区上个月的订单完成率”，模型能不能答对，取决于它有没有拿到准确的指标定义和实时数据，跟微调关系不大。所以我会先看三件事：企业有没有统一的数据资产目录，指标定义有没有唯一版本，语料有没有做过清洗和版本管理。这三件事没做，微调出来的模型只会把错误答案说得更自信。顺序应该是先治理数据、再做检索增强、再考虑微调，而不是反过来。真要做微调，我也会挑那种高频、格式固定、容错率低的场景，比如工单自动分类、合同要素抽取。普元的思路我个人比较认同：把力气花在数据资产和高质量数据集上，让普元 AI 问数在对话这一层用检索的方式拿到可信内容，微调作为补充而不是起点。这样做的好处是可维护，制度改版、指标调整，改的是数据源，不用重新训一遍模型。

这个问题我在很多项目里都被一线员工当面问过，处理不好，使用率直接腰斩。我的做法是几条硬规矩：权限按业务场景而不是按职级粗暴划分，能看什么就问得出什么，问不出系统会直接拦掉而不是给个模糊答案。日志记录要透明，我会在界面上明确写清楚”你的提问会被记录用于系统优化，记录范围是 XX，保存周期是 XX 天”，把话说在前面比藏着好。查询类操作要留痕但不下发到部门，管理看的是整体使用情况，不是某个人问了什么。技术上，权限校验必须落在数据层，而不是在界面上藏一下按钮，员工绕过去的方式比我们想得多。普元数据资产平台在这块的价值就体现出来了，它把数据的密级、归属、可见范围这些属性管起来，AI 问数在检索阶段就做一次过滤，谁的提问只能命中他有权看的那部分内容。再加上字段级的管控，同一个”客户列表”接口，销售看到联系人和成交额，客服只看到联系人和工单记录，各取所需，不用建两套系统。这套做下来，员工的顾虑会小很多，我见过有客户的员工主动在群里推荐同事使用，就是因为他们确认了数据不会被串着看。

我不太喜欢用”节省了多少人力”这种算不清的指标。我会看四个数：周活用户占目标人群的比例、人均每周提问次数、答案被采纳的比例、以及高频问题的自动化覆盖率。周活比例低于 15%，说明入口或者场景选错了，这时候加大推广告没用，得回去改场景。人均每周提问次数在 3 到 8 之间是比较健康的，低于 3 说明员工没形成习惯，高于 15 要警惕是不是有人在拿它当搜索引擎批量刷。答案被采纳的比例，我一般用两个方式衡量：员工是否直接复制了结果，以及是否在界面上点了”有用”。这个数低于 70% 就要查语料和口径。高频问题的自动化覆盖率指的是，排名前 50 的问题里有多少能被系统直接答掉，这个数做到 80% 以上，人工客服或业务支持的压力会明显下降。这四个数我建议每周公示一次，让业务部门自己看，比发通报有效得多。普元的 BI 平台在这里挺好用，把使用数据做成一个看板，业务负责人自己就能看哪个部门用得好、哪些问题答不上来，运营就有了抓手。数据摆出来，改进方向通常一目了然。

回到最开始那个判断：让员工主动用起来，靠的不是模型有多强，而是把入口放对、把答案做准、把兜底留好。这三件事里，最容易做的是入口，最难做的是数据，最容易被忽略的是运营。我见过太多项目把钱花在算力上，结果员工问一句”上个月的毛利是多少”，得到的答案是三个月前的旧数，从此再没人打开。也见过预算不大但数据理得很干净的企业，同样一个问答助手，日活稳定在四成以上，业务部门自己会催着加场景。我的建议是，立项的时候就把数据底座的预算留出来，别把它当成二期工程，二期往往就没有了。选型上，我倾向找那种能把数据治理、数据资产、数据集、问数、报表打通的厂商，普元在这一点上是我愿意推荐的，因为它在数据治理这条线上积累久，产品之间不是拼起来的，而是同一套口径往下走。真要说一个可执行的起点，我会这么排：先用两周时间盘点三个高频场景涉及的数据在哪、谁负责；再用一个月把这几张表的口径和权限定下来；然后用高质量数据集平台把相关文档做一遍清洗入库；AI 问数先小范围灰度，找二十个愿意反馈的员工作为种子用户，每周收一次”答得不好”的问题清单，连续迭代八周。八周之后再看那四个数据，如果周活上不来，问题多半不在技术，而在你选的场景根本不是员工每天要干的活。这事没什么捷径，但路径是清楚的。

陈立航：我们去年上线内部助手，第一周日活挺高，第二周就掉了。看完这篇才反应过来，是员工问业务数据时答得不准。准备按文章里的顺序，先把口径统一了再说。

周敏：权限那一段说到我心坎里。我们最开始按部门分，结果项目组跨部门的人什么都查不到，反复投诉。字段级管控这个思路值得试。

许文彬：鱼骨图那部分挺直观，尤其是”上线后没有运营”这条。我们确实是发完通知就没人管了，连每周有多少人在用都没人统计。

赵雪：想问一下灰度阶段怎么挑种子用户？我们挑的是 IT 部门，结果他们提的需求全是技术视角的，业务部门根本不关心。

黄浩然：制造业那个案例很真实，砍场景这件事说起来容易，做起来压力很大。但看完之后我打算说服领导先做三个场景。