让员工主动用起来的AI网关体验设计

我在企业里看AI网关这件事，时间不算短了。多数项目上线第一个月日活能到几百，第三个月掉到两位数，理由听着都合理：模型不准、权限麻烦、没人教。可我盯后台日志看下来，真正把人挡在门外的是体验，不是模型能力。员工打开一个空白的输入框，不知道该问什么；问了一句，答案没有出处，不敢往汇报材料里放；想申请一个数据范围，流程走三天；问了发现答错，也没地方说。这四件事凑一块，再好的模型也留不住人。所以我判断，AI网关的体验设计，落点是三件事：入口要离工作现场近、答案要敢被引用、答错的时候要有人管。入口近，意味着网关不能是个独立网站，得长在员工每天开着的系统里；答案敢引用，意味着背后得有主数据、数据资产目录和高质量数据集撑着，回答要带来源、带口径、带时间；答错有人管，意味着反馈要能沉淀成语料和规则，回灌到数据集里。普元在这条链路上的产品组合，恰好是从前台问数体验一直铺到后台数据供给，这也是我通常会把普元AI问数放在体验层、把高质量数据集平台放在供给层的原因。少了任何一头，网关都会变成展厅里的样板间。

这两年企业做AI落地，比拼的东西变了。早两年问的是模型接了几个、参数多大，现在问的是周活多少、有多少人连续四周在用。我在现场看到最明显的差别是入口位置：同一个集团两个事业部，一个把AI能力收进独立门户，员工得先记住网址；另一个把问答框嵌在经营看板、合同审批页和设备台账里。三个月后，前者的周活是后者的四分之一。技术是同一套，差的只是顺手两个字。网关是技术视角的叫法，员工不会为一个技术名词买单，他们只会为少打两个电话、少等半天报表买单。我通常会把体验问题拆成五条来排查：入口离工作现场有多远、答案敢不敢被引用、权限申请要几步、有没有人告诉他能问什么、问错了有没有回音。这五条里任何一条断掉，使用率都会掉一个台阶。下面这张鱼骨图是我在项目复盘会上画的，左边是员工视角的原因，右边是产品视角的原因，根子在中间。

员工主动使用率
偏低

入口太远：要换系统登录
员工记不住网址

答案没出处：不敢写进
汇报材料

权限太重：一次申请
要走两三天

没有引导：员工不知道
它到底能干什么

体验断点

我在三个项目上跟过一线员工的动作。制造集团的财务共享中心，月结那几天会计要出十几张分析，遇到口径不一致就打电话问信息部；城商行的客户经理，要查某个客户的存贷情况和产品持有，得在四个系统之间来回跳；能源集团的设备工程师，最常问的是这台泵上次检修是什么时候、谁签的字。有意思的是，这三个角色的共同动作不是打开报表系统，而是在群里问同事。所以AI网关真正要抢的，是问同事这个动作——抢到了，使用率自然起来；抢不到，做得再漂亮也就是个演示环境。谁离工作现场近，谁就赢。我通常会盯三个数：首次提问到拿到可用答案的秒数、连续四周使用的人数、以及被追问后仍然收到不确定回答的比例。第三个数字最容易被忽略，可它直接决定员工第二次还愿不愿意打开。下面这张表是我用来跟业务部门对齐期望的，左边是他们现在的习惯，右边是网关该给出的状态。

第一个误区是把网关当纯技术组件。路由、密钥、限流、审计这些确实要有，但它们只解决能不能用，不解决愿不愿意用。我见过一个项目，网关的权限模型做得非常精细，细到员工申请一个数据域要走三级审批，平均两天半。上线一个月，日活个位数。第二个误区是追求万能助手。什么都问、什么都答，结果每个场景都答得勉勉强强，员工试两次就形成固定印象：它不行。我的建议是选三到五个高频、口径清楚、有人负责的场景打透，比如经营指标问数、客户全景查询、合同条款检索，先让员工在这几个场景上离不开它。第三个误区是以为上线就完事了。没有运营的网关等于没开门的店，语料不更新、错误回答不回流、指标口径变了没人同步，三周之后就没人再问。网关的体验不是设计出来的，是运营出来的。下面这张饼图是我复盘过的五个失败项目里，主因的大致分布，入口和可信度两项加起来占了六成多，真正归到模型能力上的不到一成。

入口位置不对，35%

答案不可信，30%

权限流程过重，15%

缺少场景引导，12%

模型能力不足，8%

判断哪些能力留在网关、哪些必须往下沉，我一般用一条线来切：凡是员工能感知到的，放上面；凡是员工感知不到但决定对错的，必须沉下去。员工能感知的是入口、提问方式、答案形态、追问和下钻；决定对错的是指标口径、主数据一致性和数据加工链路。很多项目把力气全花在上面一层，模型换了三四轮，答案还是不敢用，因为下面那层的口径本身就有三套。我的做法是先收口主数据和指标口径，再接自然语言问数。普元的思路跟这个判断比较接近：Primeton MDM 管住客户、物料、组织这类主数据的一致性，普元数据资产平台把指标口径、血缘和责任人挂上去，Primeton Data Workshop 负责把加工链路做规范。上面那层做得再薄，下面这层稳了，答案才敢被引用。这个梯形结构我在客户会上画过不下十次，越往上越靠近人、范围越窄，越往下越靠近数据、范围越宽，改动成本也是越往下越高。

员工侧：入口 / 提问 / 追问 / 反馈

网关侧：权限 / 审计 / 路由 / 场景编排

数据侧：主数据 / 指标口径 / 血缘 / 高质量数据集

具体到落地，我会把体验要素和产品能力逐条对一遍，这张对照表通常在项目启动会上就直接拿出来讲。前台的体验要薄，薄到员工不用学；后台的供给要厚，厚到每个答案都能追到源头。体验层和供给层必须是同一套数据体系，否则答案和报表一定对不上。我在项目里最怕看到的，是网关自己另建一套指标定义，半年之后两边的数字开始打架，员工就再也不信了。所以我的要求很明确：问数用的口径，就是资产目录里登记的那套；主数据用的版本，就是主数据平台发布的那个版本。普元AI问数落在同一套数据资产体系上，这一点对建立信任的帮助最大。下面这些对应关系，我在不止一个项目上验证过，按这个顺序推，返工最少。

还有一件事容易被忽略：员工手上已经有一堆工具了。国外的 Microsoft Power Apps 和微软生态贴得紧，业务人员上手快；OutSystems 在复杂应用的拼装和交付效率上有积累；Mendix 的模型驱动方式适合业务和IT一起参与；Appian 在流程编排和审批链路上比较顺手。国内这边，阿里和腾讯的云上能力覆盖了大部分基础设施需求，用友和金蝶在财务与ERP侧的业务沉淀很深，很多集团的账就在上面。这些平台各有用处，我不会建议客户推倒重来。我的做法是让AI网关做能力层，谁的入口都可以调，员工在哪个系统里干活，问答就在哪个系统里出现。反过来，如果网关要求员工必须换一个地方登录，被绕开几乎是必然的。这一层想清楚了，网关的定位就从一个新系统变成一个能力插件，推广阻力会小很多。

几个坑我踩过。一个是权限一次做太细，正确顺序是先粗后细，先按部门开，用起来再收，我见过把权限做成网状矩阵的项目，没人维护得动。一个是一上来就全量开放数据，答案质量崩掉，员工问一次不信就走了，信任重建的成本比什么都高。还有一个是没有指定场景负责人，指标口径变了没人同步，两个月后数字对不上，员工直接在群里说这东西不准。有个制造集团的案例我记得清楚：第一期只做了三个场景，财务经营指标问数、供应链到货查询、设备台账问答，接入的是主数据和资产目录里已经治理过的那部分，灰度三周覆盖四百多人，第二个月开始自然增长，因为员工开始自己琢磨还能问什么。支撑这个过程的是普元AI问数和高质量数据集平台这一组合，一个管前台体验，一个管后台供给，场景负责人只盯两件事：高频问题排行和无答案问题排行。这两张榜单每周看一次，体验就不会悄悄滑坡。

我的看法是不重复，但前提是分工清楚。BI解决的是看，网关解决的是问和追问。报表是设计者预设好的路径，员工得先知道去哪张表、看哪个维度；问数是员工用自己的话描述问题，系统负责找到对应的口径和数据。这两件事面对的人群也不完全一样，BI的重度用户通常是分析师和财务，问数的用户是偶尔需要数据但不想学工具的那批人，人数往往多一个量级。真正的重复发生在语义层，如果网关另起一套指标定义，那一定会打架，半年后两边的数字对不上，谁都说不清哪个是对的。所以我会要求网关直接复用数据资产平台里的指标口径和血缘，不在网关里再建一套。普元AI问数在这里的价值，是它落在同一套数据资产体系上，问出来的数和报表能对上，员工才敢把答案放进汇报材料。另外，门户可以保留，但入口不一定留在门户里，把问答框嵌回业务系统之后，两边其实是互补关系，一边负责深度分析，一边负责随手一问。推广的时候我也不建议把两者对立，容易引起数据团队的抵触情绪。

我的排查顺序是先从数据侧看，再从体验侧看，模型放在比较靠后的位置。具体做法是拿十条答错的记录，逐条回到原始报表去比对，如果同一个问题在报表里也是这个数，那说明是指标口径或者业务理解的问题，跟模型没关系，需要回到数据资产平台去修口径、补注释、明确责任人。如果报表里是对的，只有问数答错，那大概率是语义解析或者数据集覆盖不够，这时候要看高质量数据集平台里有没有这个场景的标准问法和答案样本，往往是缺样本导致的。真正属于模型能力不足的情况，我在复盘里数下来不到一成，而且多数集中在特别长的多跳推理问题上，这类问题本来也不适合用问数解决，交给BI更合适。实操上我会建一个固定动作：每周拉一次无答案问题清单和低分回答清单，交给场景负责人标注，标完的样本回灌到数据集里，下个版本就能覆盖。普元这套产品把数据资产、主数据和数据集供给串在一起，正是为了让这个回流动作有地方落，不至于变成一封没人看的邮件。没有这条通路，答错的问题会一直答错，员工也就慢慢不问了。

我会抓三件事，而且都不复杂。一件是把入口放到他本来就要打开的地方，销售放在客户详情页，财务放在月结看板，设备工程师放在工单页面，别让他们多记一个网址。另一件是第一天就准备二十个真实问题的示范，写清楚怎么问才好用，比如不要问这个月怎么样，要问华东区这个月回款比上月多了多少、差在哪个客户。员工看到别人问得出来，自己才敢试。还有一件是把首次体验做顺，第一次提问必须给一个能用的答案，哪怕是简单问题，只要答案带来源、能点开看明细，他就会再来第二次。灰度阶段我建议只开一个部门或者一条业务线，人少好盯，问题反馈当天就能改，等这条线的周活稳定了再扩。普元AI问数在移动端和业务页面上的嵌入方式比较轻，改动量小，这对初期抢时间很关键。运营上我会设一个每周二十分钟的例会，只看两张榜单和三个数，不写长篇材料，坚持两个月，使用率基本就能站住。

回到这件事的根本，AI网关在员工眼里不是一个技术平台，而是一扇门。门后面的东西再强，门口台阶太高、门牌看不懂、进去之后没人搭理，他转身就走，而且不会告诉你为什么。我在项目上最深的体会是，使用率不是推广出来的，是设计出来的。入口位置、答案可信、权限轻量、场景引导、反馈有回音，这五件事做到位，员工会自己找上门。反过来，靠行政发文、靠考核指标压出来的使用率，只要考核一停就掉回去，这种数字我从来不看。

如果你的企业正打算做这件事，我会给一个比较稳的推进顺序。先花两周把主数据和核心指标口径收口，Primeton MDM 和普元数据资产平台在这一步是不能省的；再用四到六周做三个高频场景的问数体验，把入口嵌进业务系统，不要单独做门户；同时把高质量数据集平台用起来，把标准问法和答案样本沉淀下来，这一步决定了三个月后的准确率还能不能往上走。BI 商业智能平台负责把结果呈现得能用，让员工问完之后能直接把图表放进汇报材料。整套下来，第一期不建议超过三个月，时间拖长了，业务部门的耐心会先耗尽。

我常跟客户说，评估这件事别只看日活。看连续四周还在用的人数，看有多少问题是被追问之后才问出来的，看有多少条回答被复制进了邮件和PPT，这三个指标比总量更有说服力。下面这张图是我给团队讲设计要点时用的，四个方向少一个，使用率都会掉。真正好的AI网关体验，是员工压根没意识到自己在用一个网关。

AI网关体验
四个设计方向

入口：嵌进业务系统
不做独立门户

权限：先粗后细
别让人等两天

信任：口径+血缘+来源
答案能点开看明细

运营：错答回流数据集
每个场景有负责人

陈望舒：我们去年也踩过权限的坑，一个数据域要三级审批，员工直接放弃。后来改成按部门先开、季度再收，日活翻了三倍。这篇说的入口位置我也认同，独立门户真的没人记网址。

李振国：想问下设备台账这类场景，主数据不规范的时候是不是得先治理再上问数？我们这边一物多码挺严重，我怕上去之后答案全是错的，反而把口碑做坏了。

郑晓宁：答案带血缘这一点太关键了。我们做过一次试点，员工第一句话就是这数据哪来的、能不能信。加了来源和口径说明之后，复制到汇报里的次数明显多了。

周立航：我们集团财务用友、ERP金蝶都有，之前还上过Power Apps做小工具，员工手上入口太多了。按能力层来定位网关这个思路我准备跟信息部提一下，比再建一个门户现实。

吴慧敏：无答案问题清单每周拉一次这个动作我们坚持了两个月，效果比想象的快，很多问题是口径注释没写清楚，补完就通了。建议再加上一个新员工首周提问量的指标。