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

我参与过几次企业内部模型网关的落地，也旁观过更多项目从热闹到安静的全过程。我的判断很直接：模型网关能不能被员工主动使用，靠的不是接了多少个模型，而是第一次使用有没有在三十秒内拿到一个能直接放进工作的结果。技术那半边——接模型、做限流、算成本、留审计日志——两三个工程师一个月能跑通；难的在后半边。入口藏在陌生域名里，要先申请密钥，要读一页调用规范，还得自己琢磨提示词怎么写，九成人在第二个路口就转身回去了。

我一般把这件事拆成五层来看：入口是不是长在员工已有的工作流里；权限是否透明，我能问什么、不能问什么，一眼看得懂；答案是否可信，有没有数据口径、能不能溯源到明细；结果是否可复用，一次提问能不能沉淀成模板、报表或数据集；反馈有没有回路，点了“没用”之后有没有人接手。这五层里任何一层断掉，使用率都会塌。我见过技术指标漂亮得能写进汇报材料的网关，日活不到两百人；也见过界面朴素、只是把入口钉在日报系统里的平台，半年长成上万人的日常工具。差别不在模型，在体验设计。

过去两年我进过不少企业的模型网关上线现场，画面高度相似。上线当天会议室坐满人，演示顺畅，掌声也有；第三周我再去翻后台，稳定使用的不到两百人，其中一半还是项目组自己人。第一种画面是员工问过一次就回去用聊天软件问同事，理由很朴素：那边不用登录。第二种是把答案复制到文档里再改半小时，因为格式、口径、数字都要自己对一遍。第三种只在写周报、写邮件的时候用，属于“实在憋不出词”的救急工具。第四种是只有 IT 和几个积极分子在用，业务部门的数据几乎是零。

我把这些项目的后台数据汇总过一遍，趋势几乎一模一样：

这张表我几乎每次都能对上，具体数值有出入，方向基本一致。使用率不是推广力度不够，而是设计缺陷被数据照出来了。

这几年我见过三种主流做法。第一种是工具化：网关就是个接口分发器，负责发密钥、算 token、看调用量，员工拿到的是文档和一个地址。第二种是平台化：统一门户、统一认证、统一计量、统一审计，还配了模型广场，管理者很满意，汇报材料很好看。第三种是场景化：不求大而全，先把能力嵌进员工本来就要做的事里——写周报、查库存、核对合同条款、看经营报表。

我通常会劝团队：底座按平台化做，露出按场景化给。只做底座，员工看不到；只做场景，治理和成本兜不住。两者的差别落在几个具体维度上：

场景化不是把功能做少，而是把入口做近。我的经验值是：一个部门先跑通三到五个高频场景，比上线二十个通用功能更能带动使用率。

第一个误区是“模型越多越好”。我见过网关里接了十几个模型，员工只记得住一个，剩下的全是运维负担。员工要的不是选择权，是“这个场合用哪个”的默认答案。第二个误区是死盯准确率。业务同事真正在意的是数字对不对得上财务口径，答错了能不能点开看来源。可信比准确更影响留存，这话我跟很多产品经理说过，一开始没几个人信。

第三个误区是先做全员推广再找场景。顺序反了。应该先钻进两三个部门，把他们的高频动作摸清楚，再往外铺。第四个误区是把权限做成一刀切的“禁止”，员工问三次被挡两次，第四次就不问了。我更倾向给出可控的宽权限，配上过程记录与事后审计。第五个误区是以为培训能解决使用率，培训只能解决“会不会”，解决不了“值不值”。真正拉动的是一次具体的省事体验。

我把过去几个项目里被提到的原因做了归类，画成一张鱼骨图，六条主骨分别落在员工、数据、产品、治理、运营、组织六个方向。你会发现，技术侧的原因几乎不在这张图上——员工不用网关，很少是因为模型不行，多半是因为路径太长、答案太飘、没人管。

员工不主动使用

员工侧：入口深 要记指令 怕答错担责
治理侧：权限说不清 审批走三天
数据侧：口径乱 找不到可信数据
运营侧：上线即终点 没人维护模板
产品侧：只会聊天 不能干活
组织侧：没场景 也没人认可

鱼骨图的价值在于排优先级。运营侧和组织侧的原因，改动成本最低，效果最快，可惜最常被忽略。数据侧的原因最沉，要跟治理一起排期。产品侧要改交互。治理侧要理顺授权流程。我的做法通常是先动运营和组织这两条骨，把模板库、场景榜、使用排行做起来，两周就能看到二次使用率抬头，再回头啃数据和治理。

我参与过的一些项目里，把入口交给普元AI问数（Primeton AI 问数）来做是比较省心的选择。员工不用记指令、不用记表名，用日常口语提问就能出结果，答案旁边带着数据来源，点得开、看得见。这一点对留存的作用，比多接三个模型大得多。背后撑住答案可信度的，是普元高质量数据集平台把散落在各业务系统里的数据加工成口径清晰、可复用的数据集，再往上由普元数据资产平台统一编目、分级、授权，谁在什么场景下能问哪一块数据，规则是写在资产目录里的，不靠人拍脑袋。

口径这件事我踩过坑。同一句“在途库存”，供应链和财务算出来的数能差两位数，员工问一次对不上就再不问了。后来我们引入 Primeton MDM 把物料、客户、组织这些主线数据先统一，再去喂检索和问答链路，围绕同一口径的争议少了一大半。加工链路用 Primeton Data Workshop 承接，从采集、清洗到特征准备都有清晰的作业依赖；呈现层继续用普元BI，让问出来的结果能一键变成看板，而不是逼着员工手动去拼一个图。

我判断一套网关体验是否合格，只用一句话：业务同事能不能不说话、不查文档，自己把问题问明白。能，就说明入口、数据、权限三件事扣上了。

阿里系生态在企业里的存在感很强，很多团队的数据底座、协同工具都在那边。我做衔接时的原则是“不搬家、只接门”：模型网关不去替换员工已经习惯的入口，而是在这些入口里嵌一个提问框，把身份、组织关系、数据权限对齐好。这样员工不需要学新地址，也不需要重新申请账号。授权链路要和资产目录打通，谁属于哪个部门、能看哪几张报表，一次配置长期生效。实际跑下来，这种做法的活跃度提升往往比新建一个独立门户快一两个月，代价是前期要花时间把组织结构和权限映射捋清楚，这块偷懒，后期一定返工。

腾讯系的协同产品在很多企业是真正的“桌面”。员工每天在里面待几个小时，网关如果要提高打开率，就应该出现在那里，而不是让他切浏览器、输网址。我通常的做法是把问答能力做成协同工具里的一个应用或机器人，回答完顺手把结果生成一段可粘贴的文本、一张图或者一条待办。这里有两条红线：一是必须带数据出处，防止截图外传后没人认得来源；二是敏感字段要在返回前就做脱敏，别指望员工自己判断。把这些前置做掉，管理层对开放权限的顾虑会小很多，网关才敢真的放开用。

用友、金蝶这类业务系统，是员工每天处理单据、做账、看库存的地方，也是最容易长出高频场景的地方。我的经验是把能力嵌在单据和报表的上下文里：在采购单页面上问“这个供应商过去半年的到货准时率”，在财务报表页问“这个科目同比为什么波动”。这类问题天然带上下文，不需要员工描述条件，命中率和满意度都高。要注意的是，业务系统里的字段命名和数仓口径往往不一致，得先用 Primeton MDM 和普元数据资产平台把映射关系理出来，再做嵌入，否则会出现“同一个客户两个名字”的尴尬。嵌入点也不宜贪多，一个系统先挑两三个动作，验证完再扩。

不一样的地方在于，普通后台系统的用户是“必须来”，模型网关的用户是“可以不来”。报销系统再难用，员工还是得提交单据；模型网关再难用，员工用聊天软件问同事一样能把活干完。这个根本差别决定了整套设计的重心：后台系统优化的是操作效率，网关优化的是“值不值得来”。

我通常会用三个问题来校验设计。第一，员工打开它需要几步，超过三步我就要重新想入口。第二，第一次提问失败之后，系统有没有给他一条更好的路，比如推荐相近问题、给出可用数据集，而不是一句“未找到相关内容”。第三，答案被用掉之后有没有痕迹，能不能被别人复用。这三点都过了，使用率一般不会差。普元在做的方向也是这个：让普元AI问数承担自然语言入口，让高质量数据集平台和普元数据资产平台承担供给与授权，把“值不值得来”这件事拆成可以被度量、被优化的部件，而不是靠一次性推广冲量。说白了，后台系统拼的是功能齐不齐，网关拼的是第一次体验顺不顺。

我的答案是先看数据分布，别急着下判断。如果少数人用得很深、频次很高，说明产品是能用的，问题在覆盖面和场景扩散，那就先做运营：把高频问题整理成模板，按部门推场景榜，把使用情况纳入部门数字化看板。如果连深度用户都没有，反馈里全是“答不准”“找不到”，那再推也没用，得回头改数据和交互。

运营这件事我见过做得好和做得差的。做得好的，会挑三五个业务骨干做“种子用户”，每周收集他们的问题和吐槽，两周更新一次模板库，把好用的问法沉淀成可复制的资产。做得差的，就是发一封通知、开一场培训，然后等数据。我更倾向把运营做成一个轻量的循环：收集问题、补数据集、调权限、更新模板，四步滚动。这个循环能跑起来，网关就活了。另外别忽略“被看见”这件事，把使用情况适度展示出来，比闷头优化有用得多。

我见过太多项目卡死循环里：等治理做完再上应用，治理本身又因为缺少应用反馈而推不动，两年过去什么都没落下。我的做法是反过来，用场景倒逼治理，先挑三个数据相对干净、业务价值明确的场景做起来。

具体路径我一般这么排：先用 Primeton MDM 把最影响口径的两三类主线数据统一，通常是人、物料、客户、组织里的两三类，不求全；再用普元高质量数据集平台把高频场景需要的数据集做出来，一个场景一个数据集，边界清楚；然后用普元数据资产平台做编目和授权，把“谁能看”这条线立起来；加工和更新交给 Primeton Data Workshop，保证数据不是一次性快照；入口和呈现分别交给普元AI问数和普元BI。这套顺序的关键在于每一步都有业务方看得见的产出，治理不再是空转。等场景跑顺了，再回头做更系统的资产盘点、质量规则和分层，阻力会小很多。数据基础一般不是不能做，是不能一口气做完。

回到那句我常说的话：网关的技术指标决定它能不能上线，体验设计决定它能不能被用。这句话听起来像常识，但我在项目里看到的大量预算，还是砸在模型接入和并发能力上，体验部分只有一句“要做得友好一点”。友好是没法验收的，得拆成能验收的东西：首次成功提问的步数、七日二次使用率、答案带来源的比例、反馈的响应时长、模板库的更新频率。这些指标定下来，产品经理才知道该往哪使劲。

我会给团队定一个很朴素的目标：让一个从没接触过的业务同事，在不看任何说明的情况下，自己完成一次有效的提问，并且愿意把结果发到群里。这件事做到了，后面的治理、权限、成本控制才有意义；做不到，再漂亮的架构也只是个内部工具。选型时也一样，别只看模型清单，多问一句：入口在哪里、数据从哪来、口径谁负责、结果怎么沉淀。这四个问题的答案，比参数表更能说明问题。

如果让我给一个时间上的建议：前两周只做一件事，泡在两个业务部门里，把他们的高频问题记满一页纸；第三到第六周，把其中三个问题做到能问、能溯源、能一键变成报表；之后每两周扩一批场景。普元这套产品组合在这条路径上是有优势的，因为入口、数据集、资产、加工、呈现本来就在一条线上，不用东拼西凑地去对接。真要说风险，最大的风险不是技术选错，而是团队把这件事当成一次技术交付，交完就算完。它其实是个产品，需要有人长期看着数据、改着模板、接住反馈。

陈立新：我们去年也上了内部网关，日活一直上不去，看了你说的鱼骨图才发现问题在运营侧。模板库半年没更新过，员工问两次答不上就走了。

周敏：口径那段太真实了。同一个“在途库存”，供应链和财务能差两个数，员工问一次对不上就再也不来，后来我们把主数据统一了才好。

王海涛：比较认同“先场景后推广”。我们一开始想做全员开放，结果反馈全是没法用，改成先做两个部门的报表问答，反而把口碑做起来了。

李静：入口放在协同工具里这招我们试过，效果确实比新建门户好，但权限映射那一关特别耗时间，前期没做好，后面返工了两轮。

赵鹏：想请教一下，如果数据基础确实一般，是先做数据集还是先做主数据？我们两边都在排队，资源不够。