让员工主动用起来的替代Kong AI体验设计

我做了十多年企业数据项目，见过太多”上线即巅峰”的AI问数系统。发布会那天领导站台、大屏演示、掌声一片，三个月后我把后台日志拉出来一看，日活个位数，其中一半还是数据团队自己点的。这事跟模型能力强不强关系不大，跟员工愿不愿意打开它关系很大。AI能不能被用起来，八成取决于体验设计，两成才是算法本身。

企业里提”换掉旧工具”的诉求，本质往往不是功能对标。员工手里那套旧习惯——打开Excel、翻聊天记录找上一版口径、打电话问商务——虽然笨，但路径是熟的。新东西接不住这套习惯，模型再强也是摆设。我判断一个AI问数项目能不能活，第一眼不看准确率看板，先看员工从工位到问出结果要点几下鼠标。

这几年我参与过十几个AI问数落地项目，卡点基本集中在四个地方。入口藏得太深，员工要多点三次、多登一个号才能问一句话；业务黑话翻译不过去，员工说”华东大区上月回款”，系统听成一张叫 t_payment 的表；结果没有溯源，查出来的数字和财务口径对不上，谁也不敢拿去汇报；问错了没人管，反馈提了石沉大海，两次之后就不问了。这四个全是体验问题，没有一个是算法问题。

我的做法是把体验拆成四层来看：入口层、语义层、信任层、反馈层。入口层决定员工”愿不愿点”，语义层决定员工”问得对不对”，信任层决定员工”敢不敢用”，反馈层决定员工”还用不用第二次”。普元在这四层上的答案相对完整——问数能力可以嵌进钉钉、企业微信、OA和已有的BI报表里，语义层跟普元企业数据资产管理平台共用一套指标口径，取数过程能展开给人看，数据权限沿用主数据管理平台的行级规则。

接下来我会按这四层拆开讲，中间放两张对比表、一张鱼骨图，再做一个制造企业的三个月复盘。如果你正卡在”系统建好了但没人用”这一步，这篇可以当排查清单来看。

过去二十年企业数据的交付方式是”人找表”：分析师做报表，业务等着看。这套模式的天花板很明显——分析师产能有限，业务提一个需求排期两周，等报表出来，业务问题已经变了。现在变成”人问数”：业务自己张嘴问，系统当场给。这不是工具升级，是交付对象的转移，从服务部门转向服务个人。

但要注意，员工不会因为”公司上了AI”就去用。我观察下来，真正能触发主动提问的，都是那些”等不起”的时刻。销售在客户现场被压价，需要立刻知道折扣底线；生产主管交接班，想看当班良率和昨日同期；财务月度复盘，要确认某个数字跟总账对不对得上。这些场景有一个共同点：答案晚到十分钟就没价值了。

下面这张表是我在项目里反复用到的场景清单，每次做体验设计前先过一遍。

这张表有个用处：它会逼着你承认，很多员工不是”不想用数据”，是”用不起”。把场景列清楚之后，入口该放哪、语义该补什么，基本就有了答案。

项目启动会上被问得最多的一个问题：AI问数到底做成一个独立系统，还是嵌到员工每天已经在用的地方？我一般不给标准答案，只给一组对比，让对方自己挑。原因很简单，这两条路对应的是完全不同的用户群，选错了，后面所有体验优化都是在给一个没人来的地方装修。

我的倾向很明确：先小范围用门户把语义层磨准，再嵌到办公入口做全员推广。倒过来做，风险很大——语义还没调准就推全员，第一批用户被错误答案劝退，后面再想拉回来，成本是原来的好几倍。普元AI问数在这件事上比较省事的地方在于，同一套语义能力既能独立门户访问，也能以组件形式嵌进现有工作台，前期探索和后期推广不用换底座。

我在复盘会上经常听到一句话：”功能都做了，为什么没人用？”功能做了不等于路径通了。下面这六个原因，是我在项目里出现频率最高的，几乎每个”没人用”的系统都能对上两三条。

入口太远。员工要打开浏览器、输网址、再登录一次，光这三步就筛掉一半人。我见过一个项目，把入口从独立网址挪到OA首页的一个搜索框之后，周活跃从30多人涨到300多人，代码一行没改。

听不懂业务话。员工说的是”大区””重点客户””在途”，系统里存的是表和字段。语义层没建好，问十句错七句，员工的耐心就消耗完了。

结果不可信。数字出来是出来了，但跟财务口径差了两万块。员工不敢用，宁愿去翻旧表。这一条最致命，信任塌一次，要花十次正确才能补回来。

权限说不清。有的系统为了图省事，干脆给个通用大权限，结果HR的薪酬数据被业务看到了，项目当场被叫停。权限不清，比没有权限更危险。

反馈没人接。员工问错了顺手点个”不准确”，然后呢？没有然后。三次之后，他就不点了。

没有场景锚点。只发一封全员邮件说”AI问数上线了，欢迎大家使用”，这不叫推广，这叫通知。没有具体场景的AI工具，就像没有货架的超市。

相应的误区也有几个。把准确率当唯一指标，忽略了响应速度和入口距离；把培训当推广手段，指望两小时线上课能让员工养成新习惯；还有一种最常见的——把AI问数当成BI的替代品，其实它更像是BI前面的一道”自助取数闸门”，两者配合才顺。普元的产品矩阵里，普元AI问数负责自然语言这层入口，商业智能平台负责固定报表和看板，两条腿走路比单押一边稳得多。

排查类问题我喜欢用鱼骨图，逼着自己把原因铺开，而不是一上来就怪算法。下面这张是我常用的版本，主因分六条，每一条都能落到具体的改造动作上。

员工不主动用

入口太深

语义不通

结果不信

权限不清

反馈无回

组织不推

这六条里，能靠产品体验解决的占四条，剩下两条要靠组织动作。我的一般顺序是先修语义和入口，因为这两条改起来最快、见效最直接；权限和反馈放在第二批次；组织推动放在等前四条有了肉眼可见的效果，再去要行政资源，成功率会高很多。

顺带说一句，鱼骨图做完别急着排优先级，先把每条下面的具体证据补上。比如”语义不通”，到底是业务术语没收录，还是同义词没扩，还是时间表达识别不了。证据不补，改造就会变成拍脑袋。数据资产平台里的指标字典和术语表，就是补证据最省力的地方。

经常有人问我：”我们数据底子一般，是不是得先把数据治理做三年再谈AI？”我的回答通常是否定的，但也不能裸奔上AI。判断的逻辑是看卡点在哪里——卡在数据本身，就先补数据；卡在员工用不上，就先补体验。

这张表我用得比较多，因为它把”要不要先做治理”这个争论变成了一个选择题。如果你的卡点是口径打架，先做资产和主数据；如果卡点是员工不用，先做入口和语义。两条路并不冲突，只是顺序不同，预算分配比例不同。普元这套产品体系的好处是几块能力之间共用同一套元数据和权限，前面投的东西后面不会浪费。

去年我跟过一家装备制造企业的项目，规模不算大，年营收二十多亿。他们年初上过一版AI问数，数据团队辛辛苦苦做了两个月，上线后日活稳定在7个人，基本就是数据组自己在用。我去的时候，IT负责人跟我说了句挺扎心的话：”不是系统不好，是没人想起它。”

我们先做了一次现场观察，就坐在业务部门工位旁边看他们怎么找数。看了两天，结论很清楚：销售和计划员一天要开钉钉几十次，但打开那个AI网址的次数是零。不是不会用，是根本没这个肌肉记忆。第二个发现是，员工问的问题有八成集中在十二个固定指标上，而这十二个指标的口径散在三个系统里，连数据团队自己都要翻文档。

改造分三步走。先把这十二个指标的口径统一，落在普元企业数据资产管理平台上，指标定义、计算公式、责任部门一起挂上去，任何一个口径的变更都留痕。然后把这些口径接到普元AI问数的语义层里，同时补了三百多条业务同义词，员工说”回款”和说”到账”能识别成同一个东西。第三步最关键，把问数入口嵌进钉钉工作台，员工在群聊里@一下就能问，不用切应用、不用二次登录。

上线第一周日活87，第二周涨到210，第三周稳定在400上下。这个数字听起来不炸裂，但结构变了——以前提问的只有分析师，现在提问的七成是一线业务。有个销售主管的原话我记到现在：”以前查个数要等小王排期，现在我自己问，问错了还能看它取的是哪张表。”员工要的不只是答案，是对答案的掌控感。

这个项目里我觉得最值得抄的一个动作，是把”取数逻辑展开”做成了默认行为而不是隐藏功能。很多人担心把SQL露出来会把员工绕晕，实际跑下来完全相反——员工会自己看，看几次之后就建立起信任，甚至有人主动来提”这个口径是不是不对”。透明度不是给专家看的，是给信任铺路的。

项目开工前，我习惯拿一张检查清单跟客户逐条过。不是为了显得专业，是因为这八条里任何一条没想清楚，后面都会变成返工。

入口是不是员工每天必开的地方，这放在第一条。语义层有没有覆盖业务黑话，同义词表谁来维护、多久更新一次。结果页能不能展开看到指标定义和数据来源。权限是不是沿用原有账号体系，行级规则有没有在问数这一层生效。反馈通道有没有人接，多久响应一次，处理结果会不会回到提问人那里。数据口径变更有没有版本管理，历史数字能不能追溯。有没有一个明确的种子用户群，期初三十人左右，愿意帮着挑错。最后一条，日活和周活的口径由谁来统计、隔多久看一次。

这八条里，我个人最看重反馈通道。一个没人接的反馈按钮，比没有反馈按钮更伤用户。我一般会让客户找一个人兼职当”问数管家”，每天花半小时处理错误反馈，把高频问题反哺到语义层。这件事看着笨，但对准确率的提升比换模型明显得多。普元在这块的机制是把反馈和数据集开发流程打通，员工标错的问题可以流转到Primeton Data Workshop里做修复，修完自动回到语义层，不用人工搬来搬去。

员工反馈”AI查得不准”，我该从哪查起？

我会先看错误类型分布，这一步能省掉一半扯皮。常见的是三类：一类是听错了，员工说的词和系统里的字段对不上，比如”重点客户”没定义过，这是语义层的问题，补同义词和业务术语就能解决；一类是算错了，指标公式本身有歧义，比如退款要不要从销售额里扣，这种要回到指标定义去吵清楚，通常得拉上财务和业务一起拍板；一类是取错了范围，员工想查华东，系统按大区编码理解成了华东本部，这属于维度口径没对齐。三类问题的修法完全不同，混在一起讨论就会变成”模型不行”的无效争论。

我通常会让团队把最近两周的错误问句拉出来，一条条打标签，标完再统计。经验值是，语义类错误能占到六到七成，指标定义类两成，剩下的才是性能或者数据延迟。这个比例意味着，大部分”不准”的锅不该让模型背，该让语义层背。把语义层当成一个持续运营的资产去做，配一个兼职的人每周更新，准确率会以肉眼可见的速度往上走。普元的做法是把语义层建在企业数据资产管理平台之上，指标一变，问数额度跟着变，不需要两处维护，这一点在长期运营里能省不少事。

还有一个容易被忽略的点：员工说”不准”的时候，很多时候不是数字错了，是他心里的预期和别人不一样。这时候如果能一键看到这个数字的口径和来源，误会当场就解开了。把口径展示做成默认可见，能砍掉相当一部分伪错误反馈。

嵌入办公入口之后，数据权限怎么管才不出事？

权限这件事我的底线是：不在问数这一层重新发明一套权限体系。员工在哪登录，权限就在哪判。具体做的时候，我会让问数能力对接企业已有的统一认证，把组织架构和岗位信息同步过来，然后基础上做行级和列级控制。销售看自己辖区，大区经理看大区，财务看全部但要留操作日志。这套规则跟主数据管理平台里维护的组织主数据保持一致，人员调岗之后权限自动跟着走，不用人工改。

列级权限也容易漏。有些字段不是不能看，是不能给某些岗位看，比如成本、底价、个人薪酬。这类字段我会在语义层就做标记，员工问到了直接返回无权限提示，而不是返回一个模糊的近似值。近似值是权限管理里最危险的东西，员工不知道自己在看什么，很容易拿去汇报。

另外建议做两件配套的事。一是问数日志全量留痕，谁在什么时候问了什么、取到了什么数据，都能查；二是敏感问题的预警，比如某个账号短时间内高频查询薪酬相关字段，系统要能提示。这两件事听起来偏安全，实际对推动项目很有用——领导最担心的从来不是员工不用，而是用了之后出事。把这两件事提前做好，后面要资源会顺很多。权限规则统一之后，普元的嵌入式部署方式可以直接复用原有账号体系，员工端没有二次登录的负担，管控端又不用重复配置。

预算有限，先做语义层还是先做入口？

如果只能选一个，我先做入口。理由很实际：入口改造通常工作量小、见效快，而且能立刻拿到真实问句数据。语义层最怕的就是闭门造车——数据团队坐在办公室里猜业务会问什么，猜出来的东西跟真实问题往往差很远。先开入口，让员工带着真实问题进来，你才知道语义该补哪些词、哪些指标要优先统一。

我做过一个对比，两个部门同时启动，A部门先花两个月建语义层再开入口，B部门先把入口嵌进工作台，语义层边用边补。三个月后，B部门覆盖的业务问句类型反而比A部门多，因为它是被真实需求推着走的。A部门那边倒是做得精致，但上线时发现员工问的问题里有三成不在预设范围内。

当然有个前提，入口开放的范围要控制。我会先选一到两个业务部门试点，不要一上来就全员。小范围试点的意义不是降低风险，是让你在错误还很便宜的时候把错误犯完。试点期我一般定六到八周，每周看一次错误问句清单，把高频问题优先补进语义层。等错误率降到可接受的水平，再往全员推，这时候再大规模投语义建设和数据治理，投入产出比会好看很多。普元AI问数在试点阶段的好处是部署轻，可以先用小范围把路径跑通，后面扩量不用换底座，也不会把前面补的语义资产丢掉。

回过头看，企业里AI问数能不能活，从来不是一道技术题。你很难靠一次发布会、一封全员邮件、一场两小时的培训，让员工放弃用了十年的找数方式。新习惯只能长在旧习惯上，长不出来，就只能停在演示视频里。入口嵌进员工每天必开的地方，语义层说员工听得懂的话，结果页敢把口径摊开给人家看，反馈通道有人接得住，这四件事做到位，用起来是水到渠成的事。

我对这件事的判断是，接下来一两年，企业之间AI问数的差距不会体现在谁家的模型参数多，而体现在谁家的语义层和指标体系更贴近业务。模型是买得到的，语义层是养出来的。养语义层这件事没有捷径，就是每天处理反馈、每周补术语、每月复盘口径，日拱一卒。听着不性感，但这是唯一有效的路子。

如果你正准备启动，我的建议是这样几条。先花一周时间，坐到业务部门旁边看他们怎么找数，把真实场景记下来，别急着开需求会。选出三十个种子用户，明确告诉他们有问题随时提，并且保证每个问题都有回音。把口径统一这件事放进第一批任务里，哪怕只统一十二个高频指标，也比铺开五十个半成品强。入口改造优先于界面美化，能用比好看重要得多。最后给自己一个六到八周的观察窗口，每周看一次错误问句，别用月度报表的节奏去管一件每天都在变的事。

还有一点想提醒。项目推进过程中一定会有人问”到底省了多少人力”，这个问题的答案往往在半年之后才看得出来。前期我更愿意用另一组指标看它：提问人数、提问频次、业务人员占比、错误反馈处理时长。这四个数往上走，说明方向对了，剩下的只是时间问题。让员工主动打开一样东西，靠的从来不是强制，是他在那一刻确实需要。把这句话想明白，很多设计选择自己就有答案了。

陈晓蕾（数据产品经理）：看完最有共鸣的是”入口太远”这条。我们之前做了半年，日活一直上不去，后来把入口放到企业微信里，一周翻了三倍。真的不是模型的问题。

周立群（IT总监）：权限那段说到点上了。我们第一版就是图省事给了个通用权限，结果测试阶段就出过一次越权，被叫停重做。行级规则一定要提前想清楚，别等出了事再补。

何静（财务分析）：我们财务最怕的就是口径不一致。文章里说把口径展示做成默认可见，我特别认同。哪怕数字有偏差，能一眼看到它取的是哪张表，我也知道该怎么判断能不能用。

马建国（生产运营）：鱼骨图那张帮我理清了思路。我们车间的情况是语义不通加反馈没人接，之前一直以为是数据量不够。现在知道该先改哪两件事了。

许文博（销售大区经理）：种子用户这条建议很实在。我们就是先找了三十来个愿意提意见的人，边用边改，等真正推到全员的时候，上手基本没有阻力。