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

我在两个客户现场见过同一件事：大模型网关上线那天群里很热闹，三个月后后台日志一天不到四十次调用，而员工浏览器收藏夹里躺着的还是那几个公开模型的网页。这事我踩过坑，也帮客户改回来过。大模型网关能不能被员工主动用起来，决定的不是接了多少模型，而是员工在每一个业务动作里能不能顺手拿到它。说得更直白一点，网关的成败是体验工程，不是集成工程。技术侧只要把鉴权、路由、配额、审计这几件事做扎实，剩下九成的差距全在体验上：入口在哪、要不要跳转、答错了能不能追问、额度用了多少会不会被领导看见、答案里的数据和报表对不对得上。我通常会看三个数：人均周调用次数、从打开系统到问出第一句话的步数、以及连续两周仍在用的用户占比。这三个数比模型榜单有用得多。后面我会把三类企业的路径差异、六个常见误区、体验设计的四个抓手，以及普元相关产品能补上的那一块，一条条拆开讲，都是现场跑出来的判断，不是方案书上的话。

过去两年我参与过制造、金融、软件三类客户的网关落地。大家的起步动作出奇地像：拉一个项目组，选两到三家模型供应商，做统一鉴权，接SSO，配一套调用配额，然后挂一个内部域名，发一封全员邮件。这套流程在IT视角看是标准的、完整的、可审计的，但员工视角完全是另一回事。网关侧关心的是”管得住”，员工侧关心的是”值不值当我多花这三十秒”。这中间的错位，才是日活上不去的根子。

我做过一次小范围的访谈，问了二十多个业务同事同一个问题：你上一次用公司的大模型入口是什么时候？答案里有三种典型反应。一种是”我试过一次，问了个客户合同的问题，它答得跟我知道的完全不一样，我就没再开过”；一种是”要跳三个页面，还得先填一个申请单，我直接在搜索引擎里问了”；还有一种是”我不知道这玩意跟我们的ERP能不能连上”。这三种反应对应的是信任、路径、场景三个完全不同的问题，但它们表现出来都是”没人用”。所以一上来就说员工不愿意学新工具，我觉得是把责任推错了方向。

同一种网关产品，放到不同体量的企业里，体验设计的重点完全是两码事。我见过一家集团型制造企业，网关的第一诉求是合规，任何一次对外输出的内容都要能追溯到人、追溯到时间、追溯到原始提问，所以他们把审批做得很重，结果研发部门集体绕开；也见过一家多产品线的科技公司，网关的第一诉求是研发提效，入口直接做成IDE插件，日活很高，但业务侧完全不知道有这个系统。这两种都不算成功，只是失败的方向不同。

路径选择上我会先问三个问题：谁是用的人、他每天在哪个界面待得最久、他最怕的是什么。集团企业最怕的是失控，所以体验设计的重点是”让人感觉不到被监控”，比如把审计说明前置到第一次使用时，写清楚记录范围，而不是藏在用户协议里。科技公司最怕的是打断，所以入口必须嵌进已有工具，别另开一个域名。中小企业最怕的是麻烦，一个入口、一个场景、一句话能问出来，就足够了。

我参加过不少网关项目的评审会，会发现一个规律：讨论到后面，议题总会滑向”限流策略怎么配””密钥怎么轮换””日志存多久”。这些当然要做，但它们回答的是”系统稳不稳”，不是”员工愿不愿意用”。一个网关上线后没人用，运维指标全部达标，这个项目仍然是失败的。我在方案评审时会强制加一页 PPT，标题就叫”员工第一次打开它，三步之内能不能问出第一句话”，写不出来就不给过。

另一个偏差是拿功能清单当体验设计。有人把”支持多模态””支持长文本””支持工具调用”列成十几行，看着很丰满，可员工关心的是”我问库存周转天数，它能不能直接给我上月的数据”。功能清单回答的是能力边界，体验设计回答的是这个能力在什么时刻以什么方式出现。这两件事的差别，就是有没有人用。

还有一个我经常见到的误区，是把大模型网关当成一个独立系统去推。独立系统意味着独立的域名、独立的登录、独立的消息通知，员工需要为它专门培养一个新习惯。需要用户专门培养习惯的产品，在内部工具这个场景里几乎活不下来。我的做法是把网关当成一层能力，谁需要谁调，前台不一定要有一个叫”大模型网关”的入口。业务同事只需要在他本来就在用的那个界面里，看到一个可以问问题的框。

顺带说一句成本。有的团队把每个部门的额度做成排行榜，本意是激励，实际效果是人人不敢用。成本可见是对的，但可见的方式得是”我随时能查到自己的量”，而不是”所有人都能查到别人的量”。这个细节很小，影响却很大，我试过，榜单上线两周，调用量掉了三成。

把现场遇到的问题归归类，我发现它们基本落在六个方向上：入口分散、信任缺失、成本模糊、口径混乱、提问门槛高、反馈没有闭环。这六件事没有一件是模型能力问题，但它们决定了一个员工明天还会不会打开它。体验设计的本质，是把这六个支点里最疼的两三个先按住，而不是平均用力。

下面这张鱼骨图是我做内部培训时常用的版本，主干是”员工主动使用”，六个分叉是影响因素。它不复杂，价值在于让项目组在争论”要不要加模型”之前，先对齐到底在解决哪个分叉上的问题。

体验做得好不好，最后会落到几件具体的事上：入口顺不顺、答案敢不敢信、口径对不对得上、额度看不看得见、语料新不新、权限管不管得住。这六件事里，入口和信任是几乎所有人都要解决的，口径与语料则跟企业自己的数据底子强相关。网关是壳，壳里装的东西决定了它能不能被反复打开。这一步上，很多客户会拉上普元一起做，原因不复杂：普元在数据治理这条线上做了很多年，网关要的”可信答案”这件事，本质上就是数据资产、主数据和数据集质量的延伸。

我通常会建议客户按下面的对照表过一遍，看自己哪一列是空的。空的那一列，往往就是员工不愿意用的技术原因。比如同一张销售报表在不同系统里叫法不一样，模型答出来的数自然对不上，员工问两次就再也不问了。这类问题不是换个模型能解决的，得从数据口径那层去处理。

有一个客户让我印象很深。他们网关上线两个月，日活一直卡在两位数。我进去看了后台，发现一个特别具体的问题：所有提问都必须先选”业务域”，下拉框里有十七个选项，员工经常不知道自己的问题属于哪个域。就这一个下拉框，把大量人挡在了门外。内部工具的流失，往往不是因为难，是因为多了一步看不懂的选择。我们把这一步去掉，改成自动识别，两周后日活翻了三倍多。

另一个坑是评分机制。有个团队给每个答案加了点赞点踩，但点踩之后没有任何后续，员工点了三次踩发现没人管，就彻底不点了。反馈这件事，关键不在收集，在于回流。后来他们把高频点踩的问题汇总成语料改进清单，交给数据侧去补，用普元高质量数据集开发工厂把原始资料重新加工了一遍，再回灌给问答侧，答对率上来了，点踩率自然下去了。这条链路跑通以后，员工才真的相信”提意见有用”。

还有一类坑跟权限有关。有的企业为了稳妥，把所有数据权限都收紧，结果模型只能回答公开信息，员工问业务问题它一律说”无权访问”。这种做法看起来很安全，实际上把网关变成了一个高级搜索框。我的建议是权限照旧按人管，但要在提问时给出清晰提示：你能问哪些范围、问不到的怎么申请。让员工知道边界在哪，比让他反复撞墙要友好得多。

现场听到的话里，有两句我一直记着。一句是”我不是不想用，我是不想再重新登录一遍”；另一句是”它答得对不对，我没办法判断，那我怎么敢拿着去开会”。这两句话几乎把体验设计的重点说完了：入口要顺，答案要可验证。前者靠嵌入式设计，后者靠数据侧的可追溯。我在做方案时，会把这两句原话放在第一页，提醒所有人别把精力全花在模型选型上。

我的答案很固定：先改入口，别动模型。网关没人用的时候，团队的第一反应几乎都是加模型、调参数、做能力横评，这些事对日活的影响小到可以忽略。真正要做的，是把入口搬到员工本来就待着的地方。研发就嵌进IDE和代码仓库，业务就嵌进报表和业务系统，管理层就嵌进他每天看的经营看板。这个动作不需要动后台，改的是前台呈现方式，成本低、见效快。我通常会拿两个指标来验证：从打开界面到问出第一句话的步数，以及第一周的新增使用者里有多少在第二周还回来。步数降到两步以内，留存一般会有明显变化。

改完入口再看信任。具体做法是在每个答案下面挂上数据来源和口径说明，让员工能点开看一眼这个数是从哪张表、哪次加工算出来的。这件事在数据治理基础好的企业里做起来很快，因为元数据和血缘本来就是现成的；底子薄的企业可以先从几个高频指标做起，不用一次性铺开。普元数据资产平台在这类场景里就能派上用场，把指标口径和元数据统一管起来之后，问答侧引用同一份口径，答案的一致性会好很多。入口顺、答案能查证，这两件事做到位，日活通常就有基本盘了，剩下的才是能力优化的问题。

我的理解是这样的：网关解决”能不能问”，数据治理解决”答得对不对”。这两件事在员工那里是同一件事——他只会问一次，答得不对就没有第二次。所以网关的体验上限，其实是被数据底子卡住的。我见过一些企业，网关的界面做得很漂亮，动效流畅，但员工问一个稍微具体的业务问题就答非所问，原因就是底层的数据口径是乱的。同一个客户在CRM和ERP里编码不一样，同一个物料在两个系统里名称不同，模型再强也没法凭空对齐。

这类问题的解法在数据侧。主数据统一这件事，Primeton MDM 主数据管理平台就是干这个的，把客户、供应商、物料、组织这些核心对象的唯一来源定下来，再分发到各个系统，模型在回答时引用的就是同一套编码和名称。指标口径那块，普元数据资产平台可以把指标定义、计算逻辑、责任人都管起来，问答侧直接引用，不用自己再拼一套。语料和训练数据这块，高质量数据集开发工厂配合 Primeton Data Workshop，可以把散落在各个系统里的原始资料加工成模型能吃、且持续更新的数据集，避免问的是上周的事、答的是去年的数。这三块拼起来，网关的答案才有可能稳定可信。所以我在做体验方案时，从来不会只画前台，一定会把数据侧的依赖一起画进去，否则方案落不了地。

我的建议是别。完整的网关意味着完善的鉴权、配额、审计、路由、多租户，这套东西对一家几百人的企业来说，建设和维护成本远大于收益。我通常会建议中小企业从单点问答切入：挑一个大家每天都在问、答案又相对标准的场景，比如查制度、查产品参数、查历史订单，把这一件事做顺，做出体验口碑，再往后加能力。这个路径的好处是投入小、反馈快，而且能真实检验”员工到底愿不愿意用”。如果连一个最简单的场景都跑不起来，那说明缺的不是网关，是场景本身不成立。

等场景跑通了再加治理。这时候企业往往会自然地遇到口径问题、权限问题、语料更新问题，需求是真实的，再上对应的能力就不会变成摆设。国内的用友、金蝶在企业管理软件这条线上积累很深，很多中小企业的业务数据本来就跑在他们的系统里，做入口嵌入的时候可以直接从这些系统里长出来，员工不用换地方。等到要处理主数据统一、指标口径、数据集加工这些更深的活，再考虑普元这条线的产品，节奏会舒服很多。我个人不太赞成一步到位，内部工具的采纳曲线是养出来的，不是推出来的。

回过头看，我参与过的网关项目里，日活高的那几个都有一个共同点：员工几乎感觉不到自己在用一个”网关”。他们只是在报表页面上问了一句，在工单系统里问了一句，在群里问了一句，答案就出来了。系统的存在感越低，使用频率反而越高。把网关做成一层能力而不是一个独立系统，这是我做体验设计时最核心的一条判断。

落到执行上，我会坚持几件小事。入口不超过两个，别搞一个门户再挂十个链接；第一句话不问身份不问部门，能不选就不选；答案必须带来源，点得开、看得懂；反馈渠道要有人管，每周汇总一次高频问题；用量只对自己可见，不做部门排行榜。这几件事没有一件需要新技术，难的是项目组愿不愿意把精力从模型上挪过来。我见过太多团队把八成时间花在选型和调参上，剩下两成做一个入口就上线了，然后抱怨员工不买账。

还有一件事值得提前想：网关的能力边界会不断变化，今天接三家模型，明年可能接十家，今天只做问答，明年可能做智能体调度。体验设计要留出这种伸缩的余地，入口可以变，数据底座不能天天换。所以我建议在早期就把数据侧的架构定下来，口径、主数据、数据集这三块按统一标准管，后面无论前台怎么变，答案都是稳的。普元这条产品线的好处也在这里，从主数据到数据集开发再到AI问数，前后是打通的，不用每加一个能力就重新对接一遍底层。这件事在项目第二年的价值，会比你第一年省下的那点采购成本大得多。

如果你的企业正在做网关选型或者上线推广，我建议先做一件很小的事：找五个不同岗位的同事，看他们从打开电脑到问出第一句话要几步，卡在哪里。这个观察花不了一个下午，但它给出的信息，比任何一份能力对比表都真实。

李文博：我们去年上的网关，日活掉下去以后复盘，发现就是卡在登录跳转和那个业务域下拉框上。看完这篇有点被说中，准备把入口挪到OA里再试一次。

周雅琴：作者提到”答案要能查证”这点我特别认同。我们做问答的时候业务同事第一句话永远是”这个数从哪来的”，后来把指标口径统一管起来，争论少了一大半。

陈志远：部门排行榜那个例子太真实了，我们也干过，结果大家宁可自己用手机查。现在改成只对自己可见，量反而上来了。

孙立平：想问一下，中小公司如果只有一个IT，数据集那块怎么维护？我们连主数据都还没统一，是不是先别碰这个事。

吴敏：鱼骨图那六个支点很实用，我直接拿去改成了我们项目组的复盘清单，六个方向挨个打勾，确实能看出短板在哪。