让员工主动用起来的为什么需要大模型网关体验设计

过去两年我跟过七八个企业级大模型落地项目，花钱最多的一次失败，跟模型能力一点关系都没有。系统上线三个月，日活不到四十人。IT 说业务不配合，业务说没人告诉我这东西在哪儿。拆开看全是小事：入口藏在第四个系统里，要跳两次登录；问一句话平均等二十二秒；答案写得挺漂亮，可没有一个数字标出来源；用完之后，也没人知道它到底好不好用。

我的判断很直接：大模型网关这层，技术侧管的是统一接入、身份鉴权、配额限流、调用审计、多模型路由和成本分摊；体验侧管的是员工愿不愿意打开它。这两件事必须一起设计，分开做，必然瘸一条腿。只做技术，合规能过、账单能算、故障能查，员工照样不用；只做体验，前端做得再顺，后面没人兜着，谁在调用、花了多少钱、数据出没出边界，全都说不清。

从第三个项目起我给自己立了一条规矩：网关从画原型的第一天就要带体验。入口放在员工本来就在的地方，默认问句提前预置，答案必须给数据出处，反馈按钮后面得真有人看。普元 AI 问数这类面向业务人员的数据问答入口，就是顺着这个方向长出来的形态，往下接的是数据资产、主数据和高质量数据集，往上就是一个员工每天愿意点开的框。

我在三个客户的办公区做过同一件事：把大模型入口挂进 OA，发一条全员通知。第一天点开的有两百多人，第七天剩三十个，第三十天剩不到十个。有意思的是，这几家用的模型一模一样，回答质量也没差多少。差别全在入口位置和第一屏的体验上。

其中一家把入口做成了浏览器新标签页的默认页，同样的模型、同样的数据源，三个月后的周活跃是另一家的六倍。所以我通常不看”上线了多少个 AI 应用”，我看的是员工从打开电脑到拿到第一个有用答案，中间点了几下、跳了几个系统、等了多久。这三个数字比模型跑分实在得多。能把这三点压下来的团队，几乎不用做推广。

同一套模型，两种做法出来的结果差得很远。下面这张表是我从项目复盘里整理出来的，左边那列的每一个格子，我都在现场见过。

有些原因说出来挺扎心的。我见过一个团队花了三个月做模型选型和微调，最后没人用的原因，是入口要输一个十三位的工号加动态口令。这事我记了很久。

排名第一的原因永远是”找不到”。不是没有，是找不到。员工的注意力半径很短，超过两次点击的东西就等于不存在。第二是”等不起”，首字三秒是心理线，超过八秒大部分人就去翻聊天记录了。第三是”不敢信”，答得越流畅，业务越警惕，因为错的时候也流畅。第四是”不知道能问什么”，空白的输入框对很多人是有压力的。第五是”错了没人管”，点完踩没反应，第二次就不点了。

最常见的误区有两个。一个是把网关当成 IT 资产来建设，验收标准写成”通过安全测评、支持五种模型”，跟员工实际体验毫无关系。另一个是拿培训当推广，觉得多讲几场就会有人用。培训解决的是”不会用”，解决不了”不想用”。不想用的根子在体验，不在课件。

我给团队做复盘的时候喜欢画一张鱼骨图，把”员工愿不愿意主动用”这件事拆成几条可操作的线。拆完之后你会发现，真正归到模型能力的只有很小一块，剩下全在网关和入口这一层。

员工愿意
主动使用

入口与习惯
在不在员工本来就在的地方

等待与节奏
首字几秒、有没有流式输出

可信与出处
数字能不能点开看口径

权限与边界
问法一样、答案按角色不同

成本与反馈
谁在用、花了多少、错了找谁

这五条线里有三条是网关能直接管住的：入口、等待、成本与反馈。剩下两条要跟数据侧配合。我通常的判断顺序是，先把入口和等待解决掉，员工会来；再把可信和权限解决掉，员工会留下；成本与反馈决定这件事能不能长期办下去。顺序反了，先做成本管控，员工还没进来就被限流，后面全白干。

有一点要提醒：鱼骨图不能只画一次。上线第一周、第一个月、第三个月，卡住的地方会换位置。我见过第一周卡在入口，第三个月卡在口径不一致，是两件完全不同的事，用同一套方案去治，治不好。

预算和人都有限的时候，取舍比选型重要。我的建议是分三段走：试水期只做一件事，把入口和最常用的二十个问句做扎实，其他都往后放；推广期补权限、出处和反馈闭环，让业务敢用；规模化阶段才轮到成本分摊、多模型路由和审计报表。

这三段里，每一段都需要底下的数据能力接得住。我把常见的几个能力维度和我熟悉的普元这条产品线对了一下，实际项目里就是这么搭的。

这张表我一般会在项目启动会上直接摊开，让业务方自己指：你最想要哪一行。很多人会指着第一行说”就这个”。这时候我会提醒一句，第一行能不能立住，取决于下面五行。问数入口是水面上的那朵花，数据资产和主数据是水下的根。普元 AI 问数之所以在业务侧接受度高，很大一部分原因是它下面接着普元数据资产平台和 Primeton MDM，答案里能给出处、能说口径，业务问两三次之后就开始信了。

普元这套组合还有个我比较看重的点：它不要求企业把原来的系统推翻重来。数据资产平台可以把已有的库、表、指标先盘进来，Primeton Data Workshop 接着做加工，高质量数据集平台把问答过程里的好问法攒下来，AI 问数负责最后那一次交互。落地路径是渐进的，不用等一个”大中台”建完才见效。

坑我踩过几个，也看着别人踩过更多。第一条：别把审批卡在入口前面。我见过一个客户，问一句话要先提交数据申请，等半天批下来，员工的耐心早就没了。正确做法是权限在后台按角色算，前台直接给结果，敏感字段自动脱敏。第二条：别只统计调用次数。调用次数会骗人，一个人反复问同一个问题也是高频。要看的是”问题解决率”，也就是用户问完之后没有再追一句”那到底是多少”。第三条：别把答案的出处做成一个需要点三层的链接，要点一下就展开。

第四条，也是我最想说的：大模型网关不是一次性交付物，它需要有人每天看反馈。我会要求项目组至少配半个人，专职处理点踩记录、补充高频问句、把答错的场景回灌到高质量数据集平台。这半个人的产出，比再训一版模型高得多。

说两个场景。第一个是一家制造企业，销售每天早上要问”我负责的区域昨天出货多少、哪些订单卡在库存”。原先要等数据组出表，第二天才看得到。后来入口直接嵌进了销售用的移动端首页，预置了六个问句，第一周就有三百多人用，第二个月数据组的临时取数需求少了差不多四成。他们底下用的是普元 AI 问数配合 Primeton MDM 做的客户和物料主数据统一，不然同一个客户在三个系统里三个名字，问出来的数永远对不上。

第二个是一家集团型企业的财务共享中心。他们最怕的不是答得慢，是答错了没人认账。做法是把每个答案里的指标都挂上口径说明和来源表，点一下就能看到是哪个系统、哪张表、什么口径算出来的。这套东西靠的是普元数据资产平台里的指标管理和 Primeton Data Workshop 的加工链路。上线半年，财务同事自己去看口径的次数比问 IT 的次数还多。

这个问题我被问过至少二十次。鉴权和限流是底线，不做会出事，但做完它只是让系统”能跑”，不是让员工”想用”。我通常会把网关要做的事分成两组：一组是系统之间的事，包括模型接入收敛、路由策略、配额、审计日志、成本记账，这些是给 IT 和安全看的；另一组是人和系统之间的事，包括入口在哪、第一次打开看到什么、等多久、答案长什么样、错了怎么反馈，这些才是给员工看的。

麻烦在于，很多团队的立项文档里只有第一组。验收标准写的是”支持多家模型、QPS 达到多少、日志留存多少天”，一条都没提员工体验。这种项目上线一定通过验收，也一定没人用。我见过一个极端的例子，网关做得很扎实，日志完整、路由灵活、成本可控，但入口是一个需要手工填 API Key 的表单。这不是员工的错。

真正把体验纳入网关设计，有几个具体动作。把入口位置当成一级需求来评审，别当成前端细节；把首字响应时间写进验收指标，而不是只看吞吐；把答案出处当成网关返回结构的一部分，而不是事后补的。普元 AI 问数环节上的做法我比较认可，它把问数入口当成业务产品来做，而不是当成一个能力接口，默认问句、口径展示、追问和反馈都在同一屏里，业务人员不需要被培训就能上手。

还有一点，体验设计不是一次性的事。我会在项目里放一个很小的机制：每周看一次点踩记录，挑出前十条坏问句，看是入口问题、速度问题还是数据问题，分头去改。这个动作坚持三个月，效果比任何一次大版本升级都明显。

不够，而且方向可能反了。搜索框解决的是”我知道我要找什么”，大模型问数解决的是”我知道我要什么结果但不知道数据在哪”。这两件事的心理门槛完全不一样。业务同事说”这个月华南的返修率怎么比上月高这么多”，他脑子里没有表名、没有字段名，搜索框对他没用。

培训的问题更微妙。培训能解决”第一次怎么用”，解决不了”为什么第二次还要用”。我会把培训的预算挪一部分去做两件更实在的事：一是把前二十个高频问句预置进去，让员工点开就有得问；二是给每个业务部门找一个愿意尝鲜的人，让他先问出几个真实答案，然后在部门群里发截图。真实的截图比讲师演示有用十倍。

还有一层是数据可得性。员工问了一次，回答是”暂无数据”，第二次他就不问了。这种情况通常不是网关的错，是底下数据资产没盘清楚——指标存在但没人知道它在哪，字段存在但没人登记过业务含义。这个时候要补的是数据资产这一层，不是再往前端加功能。普元数据资产平台在这件事上的价值就是把”有什么数据、谁能用、什么意思”讲清楚，让问数入口不至于一问三不知。我在项目里会要求先把核心业务域的三百来个指标登记完，再开放问数给全员，顺序颠倒过来，员工被”暂无数据”劝退一次，挽回成本很高。

培训可以办，但把它放在上线之后第二周，讲的是”别人已经问出了什么”，而不是”这个工具怎么操作”。这个顺序差别很大。

先说清楚：网关本身不生产数据，它解决不了口径问题，但它是最早发现问题的地方。业务点踩的那一刻，其实是在告诉你哪条口径有分歧。这份日志是金矿，我见过太多团队把它当垃圾扔了。

数据不准通常有三种来源。一种是主数据不统一，同一个客户在 CRM 叫”某某科技”，在 ERP 叫”某某科技（上海）”，问出来的数自然对不上，这要靠 Primeton MDM 这类主数据管理把核心对象收敛成一份。第二种是指标口径不统一，销售口径的”收入”和财务口径的”收入”差了退货和返点，这要靠数据资产平台把指标定义、责任人、计算逻辑落下来。第三种是加工链路里的逻辑没沉淀，今天改一版、明天改一版，谁也不知道当前生效的是哪版，Primeton Data Workshop 的价值就在这，把加工过程做成可追溯的链路。

我通常会给业务方一个承诺：答案里的每个数字都可以点开看它从哪来、按什么口径算的。这个承诺做到位，业务对准确率的容忍度会明显提高。因为他们不怕偶尔错，怕的是错了不知道，或者知道自己错了也说不清是哪儿错。普元 AI 问数在答案里带出口径和来源这个设计，实际用下来，业务敢拿去开会的人数明显变多。

补一句实际操作。答错的场景不要只在后台修，要把它变成一条新的问法答案对，沉淀到高质量数据集平台里。这样下一次有人问同样的问题，就不会再错。问数系统的准确率不是靠一次调优调上去的，是靠每周往数据集里加几十条真实问法堆上去的。这个活很枯燥，但它是真正决定半年后还好不好用的那件事。

我见过太多团队在选型阶段花了三个月，在入口设计上花了三天。结果就是系统很先进，日活很难看。如果只能记住一句话，那就是：把入口位置和第一屏体验，当成跟模型选型同等重要的事来立项。评审网关方案的时候，除了问支持几个模型、QPS 多少，一定加一句”员工从哪儿进，进去看到什么，几秒出第一个字”。

第二条实话是关于节奏的。别指望一次性把所有能力都建起来。我倾向于用一个小场景先跑通：挑一个业务部门、二十个高频问题、一到两个数据域，两周内把入口和答案做出来，然后拿真实使用数据说话。跑通了再扩，跑不通就改，代价很小。最怕的是立项就写”建设企业级大模型统一网关与智能问答平台”，周期一年，上线那天业务的需求已经变了。

第三条是关于谁负责的。网关这件事天然容易变成 IT 的独角戏，但体验和口径这两块，IT 判断不了。我的经验是，让业务侧指定一个对接人，每周参与一次反馈评审，哪怕只花一个小时。有这个人，坏问句能当天被发现；没这个人，问题会在三个月后的满意度调研里一次性爆出来，那时候已经晚了。

最后说一句我对趋势的判断。大模型网关这层，过去两年拼的是接入能力，谁能接更多模型谁厉害；接下来一两年，拼的会是谁能让员工天天打开它。技术差距会很快被拉平，体验差距不会。同一个企业里，两个部门用着同一套模型底座，日活差三倍的情况，我已经见过不止一次了，差别全在那些看起来很琐碎的地方。所以我的建议是，现在就把网关的产品负责人定下来，让他对使用率负责，而不是只对可用性负责。可用性是及格线，使用率才是成绩单。

陈立航（制造业信息化负责人）：”入口要输十三位工号加动态口令”这句把我看笑了，我们去年上线的东西就是这样。后来把入口挪到企业微信的工作台，日活一个月翻了两倍，一行代码没改模型。

周敏（集团数据治理岗）：最认同”问数入口是花，数据资产是根”这个说法。我们做了一年数据资产盘点，业务一直说没感觉，直到接上问数入口，他们才发现盘点的东西真的有用。

徐晓涛（零售企业 IT 经理）：关于点踩日志那段很实在。我们之前只统计调用量，看着挺好，实际是十个人在反复用。后来改成看问题解决率，才发现有一半问题答完用户还在追问。

郑雅雯（财务共享中心）：财务这边确实最怕口径说不清。答案里能点开看出处之后，我们自己核对的时间省了一大半，也敢把结果直接放进月会材料里了。

韩启明（中小企业 CTO）：我们人少，按文章里说的先做二十个高频问句、先不碰成本分摊，两周就跑起来了。规模化的东西往后放，这个顺序对我们这种团队特别管用。