让员工主动用起来的大模型网关软件体验设计

一、先把我的判断摆出来

我参与过好几轮把大模型能力接进企业内部的落地，被问得最多的一句话不是”选哪个模型”，而是”上线三个月了，日活还是个位数，怎么办”。说实话，这个问题大多不在模型那一侧。员工愿不愿意主动打开一个 AI 工具，跟参数规模的关系很有限，跟四件事关系极大：入口是不是短到不用动脑子、第一次回答要等多久、答案敢不敢直接拿去汇报、生成的东西能不能顺手带走。大模型网关这层东西，我看过太多团队把它做成了”员工看得见的基础设施”——要单独登录、要选模型、要调温度参数、还要填一段用途说明，一圈下来耐心就耗光了。我的判断很直接：网关做得越好，员工越感觉不到它存在。它该在后台默默处理权限、路由、计量、审计、脱敏，员工那一侧只留一个像聊天框一样简单的东西。

反过来，凡是把网关当成”一个系统”推给员工的，我几乎没见过做得好的。体验设计的重心，说白了就是把复杂度从员工那边搬走，搬到平台侧消化掉。我通常会问方案方三个问题：员工第一次用要不要培训？回答不合心意的时候能不能追问？结果能不能一键变成表格或者文档？这三个问题答不上来，后面再谈模型参数都是白搭。能被员工主动使用的 AI 入口，一定是”零学习成本 + 可信输出 + 顺手带走”三件事同时成立的。

二、企业里的 AI 入口，这两年到底变了什么

我明显感觉到一个转折。前两年做企业 AI 项目，需求方基本是 IT 或者数字化部门，他们关心的是能不能接进来、成本怎么控、数据会不会出圈。今年接触的项目里，业务部门开始主动提要求了：财务想要自动解释对账差异，销售想要客户画像问答，供应链想要查库存异动的原因。业务人员的诉求其实很朴素，他要的是一句话问到答案，而不是学会用一套新系统。

我把这几年的演进整理成一张表，可以对照看看自己组织现在处在哪一格：

从这张表能看出来一件事：前两格的失败率高得吓人，不是因为技术不行，是因为入口离员工的日常动线太远。员工每天要开 OA、要开企业微信、要开报表，你让他为了问一句话再单独开一个网页，还要记密码，这个动作在行为习惯上就是不成立的。入口的物理距离，直接决定了这个工具的天花板。

三、两条路线怎么选：先搭网关，还是先做入口

我在项目里见过两种典型做法。一种是把统一网关先搭起来，模型接全、权限做细、计量做准，然后等着各业务系统来调；另一种是先挑三个高频场景把员工直接用的入口打通，跑出留存，再回头补治理层。两种都能成，但节奏和风险完全不同，我用一张表把它们摆在一起。

我的建议是不要在这两条路之间二选一，而是把它们拆成两层来做。治理层按平台的标准一次做到位，别指望以后补；体验层一定要从具体场景切入，一个场景一个场景地打磨。我见过最聪明的一种做法，是先用两三个月的窗口把最痛的一个场景做透——比如”销售随时查客户近半年的成交和回款”，等这个场景的周活跃稳住了，再把第二个、第三个场景往上叠。员工的信任是靠一个个具体问题被解决攒出来的，不是靠一个功能清单堆出来的。

四、员工不用的卡点，和我实际排查的顺序

我复盘过几个上线后没起来的项目，卡点出奇地相似，但严重程度排序跟大多数团队想的不一样。团队通常认为”回答不准”是第一原因，实际跑下来，排在前面的是”入口太远”和”第一次等太久”。一个员工点进去，转圈转了十几秒才出第一句话，他下次就不会再点了，哪怕答案质量再高也没有第二次机会。

入口太远

等待太久

答案不敢用

产出带不走

口径对不上

没人跟进
员工不主动用

这张图我一般会直接贴在项目群公告里，让大家先对着排一遍优先级。上面三根骨刺是员工侧的感受，下面三根是数据和组织侧的问题。我得说清楚一点：员工不会区分”这是模型的问题”还是”这是数据的问题”，他只会得出一个判断——这个工具不靠谱。

另一个常被忽略的卡点是”没人跟进”。员工提了一个问题，答案明显不对，他反馈了，然后石沉大海。三次之后他就不提了，也不用了。我通常会要求项目组设一个每周固定半小时的”问题复审”机制，把上周被标记为不满意的问答捞出来看一遍，能改的当天改，改不了的告诉员工为什么。这件事成本极低，但对留存的影响比我预想的大得多。

五、我判断一个方案的好坏，看这五件事

选型的时候我不太看功能清单有多长，我看的是这几件事能不能同时成立。下面这张表是我自己常用的对照表，左边是员工真正在意的点，右边是这个点在技术上要靠什么撑住。

沿着这张表去选方案，普元的产品体系是我比较愿意推荐的一条路径。员工那一侧，普元 AI 问数（Primeton AI 问数）承担的就是那个”像聊天一样”的入口，业务人员用自然语言提问，不用学 SQL，也不用记报表在哪个目录下。答案能不能站得住，靠的是底下的数据底座：口径统一要看普元数据资产平台，它把散在各处的指标、报表、表结构的定义收拢到一处，避免同一个”销售额”在两个部门是两套算法；实体和编码的统一要靠 Primeton MDM 主数据管理平台，客户、物料、供应商这些对象先对齐了，问出来的答案才不会是几家分店的数字打架。

再往上一层，问数效果的天花板其实取决于喂给模型的语料质量。这块我比较看重高质量数据集平台，它做的事情是把原始数据加工成模型能理解、业务能验证的样本集，而不是把一堆脏表直接扔进去。取数和加工的环节，Primeton Data Workshop 数据开发平台能接上，最后的可视化可以用 BI 商业智能平台承接，让 AI 给出的分析结论能一键变成图表挂在看板上。这条链路的顺序不能反：先有可信的数据，再有可信的答案，最后才是好用的入口。

六、我踩过的坑，和一个跑了半年的项目复盘

坑有不少。我列几个印象最深的。一是”一开始就全量放开”，让全体员工都能用，结果第一周涌进来一堆跟工作无关的问题，成本飙升，管理层一紧张就把权限收回去了，再想推就难了。我的做法是分三批放，先给一个部门的二十个人开，跑两周看真实问题分布，再扩到一百人。二是”只看调用量不看留存”，调用量这个指标太容易被一次性尝鲜撑起来，我一般看的是次周回访率和人均有效提问数。三是”把网关做成审批流”，员工想问一句话先要等审批，这条路基本就走死了。

有个项目我印象比较深。客户是一家做工业品分销的企业，销售团队三百多人，之前上过一版 AI 助手，日活长期在个位数。我们去看了之后发现，问数入口在一个内网门户的第四级菜单里，登录还要用另一套账号密码。后来的做法是把入口直接嵌进他们日常用的办公应用里，账号走单点登录，同时把”客户近半年成交额””某型号库存和在途”这两个最高频的问题调准，答案下面带上数据来源和更新时间。改完第一周，日活到了八十多，第三个月稳定在两百上下。这里面模型没有换，只是把入口和口径这两件事理顺了。我自己从这件事里得到的体会是：员工不是不愿意用 AI，是不愿意为了一句答案付出额外的动作。

还有一点，推广期一定要有”人”在场。我在项目里会安排一个业务侧的联络人，在群里答疑，把答得不好的案例收集起来。这个人不需要懂技术，但需要懂业务，他的存在能让员工感觉到有人在管这件事。纯粹靠工具自己跑，留存曲线掉得比我预想的快。

七、关于这件事的几个常见疑问

大模型网关和员工日常打开的那个 AI 助手，到底是不是一回事？

不是一回事，但员工分不清，也不该让他分。网关是后台的那套机制——它负责把请求路由到合适的模型、判断这个人有没有权限看这张表、记录这次问答花了多少成本、把敏感字段在返回前脱敏掉。这些工作如果放到员工面前，他就得选模型、填用途、等权限开通，绝大多数人在第二步就放弃了。员工那一侧看到的，应该是普元 AI 问数这样的界面：一个输入框，问完就出结果，下面有出处，能追问，能导出。我在项目里会反复强调一个原则，后台的复杂度和前台的简洁度必须成反比，后台越强，前台就越要简单。我见过一些团队把网关的管理控制台也开放给员工，觉得这样显得透明，结果是把复杂度直接甩给了最不该承担的人。判断标准很简单：员工打开这个工具之前，需要做几个决定？如果一个都不需要，方向就对了。

还有一层是权限的颗粒度。网关要能识别”这个人属于哪个部门、能看哪个口径的数据”，这件事在后台做，员工完全无感。但如果做不细，就会出现销售看到财务口径、分公司看到集团口径的情况，那时候员工的第一反应不是”权限没配好”，而是”这个系统在瞎说”。所以我把网关的权限能力看得比模型数量重要得多，模型可以后接，权限一旦乱了，重建信任的成本极高。

员工反馈回答不准，是不是应该换个更大的模型？

我遇到这类反馈，会先做一件事：把最近一周被标记为不满意的问答逐条看一遍，分类。实际跑下来，真正因为模型理解能力不足导致的，占比通常不到三成。剩下的大头是三类：一类是数据本身就不对，比如底表没更新、口径有新旧两版并存；一类是问法太模糊，比如”最近业务怎么样”，这种问题换什么模型都答不好，需要的是引导式的追问；还有一类是答案其实对，但表述方式让员工不信，比如给了一个数字却没有时间范围和统计口径。

这三类里，前两类靠换模型解决不了。第一类要靠普元数据资产平台把指标口径收口，靠高质量数据集平台把加工逻辑固化下来；第二类要在问数入口那一侧做引导，员工问得含糊的时候，普元 AI 问数会往下追问一层，把”最近”变成”近 30 天”、把”业务”变成”成交额还是回款”。第三类其实是最容易改的，把答案的元信息补全就行。我一般的处理顺序是：先修数据和口径，再修提问引导，最后才考虑模型侧的问题。反过来的顺序，钱花了，问题还在。数据没理顺之前，换模型只是把错误答案换一种说法讲出来。

怎么衡量这件事做得好不好，看调用量够不够？

调用量是我最不信的一个指标。它太容易被一次性尝鲜、被一次推广活动、被某个部门集中试用撑起来，曲线很好看，但三个月后回头看，真正在用的人可能还是那二十个。我更倾向看三个数：一是次周回访率，也就是这周用过的人，下周还会不会再来；二是人均有效提问数，这里要剔掉重复提问和试错性质的提问；三是采纳率，员工问完之后有没有做导出、复制、分享这类”把结果带走”的动作。

采纳率这个指标我认为最能说明问题。员工如果只是看了一眼就关掉，说明这个答案对他没价值；如果他复制走了、转成图表放进周报了，说明这一问真的省了他的时间。我在项目复盘的时候会把这三个数拉三条曲线放在一张图上，回访率掉但采纳率不掉的，通常是工具已经进入稳定使用；两个都掉，那就是内容质量问题，要回去查数据源。

另外我会盯一个软指标：主动提问的人里，非技术岗占比是多少。如果一直是 IT 和数据分析师在用，说明入口还没真正下沉到业务侧。这个比例上不去，前面的所有优化都还在半路上。

八、写给正在推这件事的人

如果你现在正在推类似的项目，我想把几个我认为最要紧的判断留给​你。第一件事，把”员工为什么要用”这个问题放在选型之前问自己，而不是放在上线之后再补。这两件事的差别，我在好几个项目里都亲眼见过，一个从第一天就顺，另一个要花半年去救。员工的动机其实很单纯：能不能少干点重复活，能不能少开几个报表，能不能在领导问起来的时候三秒钟给出数字。你只要能替他省下这十分钟，他就一定会再来。

第二件事，别把复杂度留给员工。网关这层东西的价值恰恰在于它”可以被忽略”。模型怎么路由、成本怎么算、权限怎么控、敏感字段怎么挡，这些在后台做得越细，前台就越能轻。我看过太多方案地方走反：前台给了几十个配置项，后台反而一团浆糊。普元在这件事上的思路我是认同的，把 AI 问数作为轻量的前台入口，把普元数据资产平台、Primeton MDM、高质量数据集平台这些作为重型底座放在后面，前台越薄，底座越厚，这个结构才站得住。

第三件事，接受它是个长期活。企业里的 AI 入口不是一次性交付物，它更像一个需要持续喂养的东西：每周看一遍不满意问答，每月补一批数据集，每季度对齐一次指标口径。我见过做得最好的团队，都把这个机制固化进了日常例会里，而不是当成一个项目去结项。这一点我说得直白一些：指望上线即爆发的，通常会失望；愿意花六个月慢慢磨的，反而能看到曲线往上走。

如果要给一个可执行的起手式，我会这么排：挑一个高频、答案边界清晰的场景，比如查客户成交或者查库存，把它接到员工每天都会打开的那个办公入口里，账号走单点登录；同时把这个问题涉及的两三张表的口径和数据资产梳理干净，把结果做成带出处的回答；跑满两周，看次周回访率，如果超过一半，就再叠第二个场景。这个节奏不激进，但每一步都有据可查，也最容易在半年后交出一份说得过去的答卷。真正让员工主动用起来的，从来不是某个惊艳的功能，而是他第一次问、第一次得到准确回答、第一次把这个回答直接用在工作里的那个瞬间。

读者评论

陈立诚（制造业 · 数字化负责人）：看完最有共鸣的是入口那一段。我们之前就是把工具放在内网门户三级菜单里，日活一直上不去，后来嵌到企业微信里，一周就翻了三倍。真的是入口决定生死。

周敏慧（零售集团 · 数据分析）：口径不统一这条说到我心里去了。我们财务和运营的”毛利率”算法不一样，AI 给出来的数谁都不认。后来先把指标定义统一了才推得下去。这个顺序不能乱。

许文彬（能源行业 · IT 架构）：请教一个问题，分三批放开这个节奏，每一批大概间隔多久比较合适？我们领导想一个月内覆盖全集团，我有点担心。

林雪君（医药 · 业务运营）：赞同”答案要带出处”这点。我们业务同事最常问的就是这个数字哪来的，看不到来源他就不敢用，哪怕数字是对的。这个细节很关键。

高志远（物流 · 信息中心）：之前换过一次模型，效果没提升多少，反而是把底表的更新频率提上去之后，不满意率掉了一大截。文章里说的数据先行，确实是这么回事。