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

做企业内部 AI 这几年，我越来越不愿意先看模型评测榜。榜单是给采购和媒体看的，一线员工不关心。2023 年我参与过一个制造企业的项目，当时接了三家大模型的接口，网关层的统一鉴权和限流也做了，半年后后台数据显示月活不到目标人群的百分之五，而且清一色是 IT 和数据分析岗。复盘的时候发现问题很朴素：员工要用一次 AI，得先在门户里找入口，再打开另一个系统复制工单号，还得自己琢磨提示词怎么写，前后两分钟起步。模型答得再准，也没人愿意点第二次。相反，另一些团队把入口直接嵌进员工每天必开的聊天工具和业务系统，输入一句自然语言，几秒钟出图出表，日活能做到四成以上。这两类场景的差距，跟模型参数量基本无关。我的判断是：企业级 AI 的第一性问题不是模型强不强，而是员工愿不愿意主动打开它，而这件事由两样东西决定——一个把能力收拢稳、管得住、算得清的服务网关，一套把能力翻译成员工日常动作的体验设计。网关是地基，体验是门脸，少一样都住不进去人。网关做不好，AI 就退化成散落各处的接口和一张失控的算力账单；体验做不好，网关就是一个装修漂亮却没人推门的门面。我见过太多团队在模型选型上花了三个月，在入口设计上花了三十分钟，然后困惑于为什么没人用。

下面这张表，是我做现状诊断时最常用的对照，左中两栏几乎都能在”只接了模型”的团队身上找到。

2022 年前后，企业内部 AI 项目最典型的形态是演示。做一个问答机器人，录一段视频，汇报时领导点个赞，项目就算完成。到了 2024 年，我发现考核口径变了，越来越多的信息化负责人开始被追问”周活跃多少””人均调用几次””省下多少工时”。这个变化很要命，它把 AI 从项目制推向了产品制。项目制的逻辑是交付、验收、结项；产品制的逻辑是有人用、有人骂、持续改。我在普元参与过的一些项目里也能看到这个转向，普元AI问数这类面向业务人员的分析入口之所以能在客户内部跑出比较高的使用率，核心原因是它从一开始就按”员工每天会打开的东西”去设计，而不是按”演示时好看”去设计。第二个变化是使用者从技术岗变成了业务岗。技术岗能忍受命令行、能自己拼参数，业务岗不行，他们要的是一句话问完就出结果，最好还能下钻。第三个变化是多模型并存成了常态，有的场景用通用大模型，有的场景用轻量模型甚至规则引擎，这就把服务网关的调度价值彻底放大了——网关不再只是一个通道，而是成本、合规、体验三件事的交汇点。我通常会看一个信号来判断团队处在哪个阶段：如果讨论的关键词还是”参数量””跑分”，说明还在做项目；如果关键词换成了”入口””留存””口径”，说明开始做产品了。

项目式交付和产品式运营的差别，落到具体动作上其实很清晰，我一般用下面这几行来对齐甲乙方和内部团队的预期。

如果一定要排序，排在最前面的是入口问题。员工的耐心以秒计算，多跳一次系统，转化率就掉一截，我见过把 AI 入口放在 OA 三级菜单里的，实际等同于没上线。第二类是第一次体验就差。第一次问一句话，转圈半分钟，出来一段和问题不搭边的长文，员工心里就给你判了死刑，后面再优化也很难拉回来。第三类是数据口径不统一，这是最隐蔽也最致命的一类，同一个”退货率”在财务、销售、生产三边算出来不一样，员工问两次答案不同，就会得出”这东西不可信”的结论。这个问题靠调模型解决不了，得从数据侧下手，用普元主数据管理平台把客户、物料、组织这类主数据统一起来，再用普元数据资产平台把指标定义、计算逻辑、血缘关系固化成唯一版本，员工看到的每个数字都能点开看它从哪张表来。第四类是答错之后没人管，员工提了一次意见石沉大海，他就默认这个工具不会变好。第五类是成本不透明，IT 部门不知道谁在烧算力，只能一刀切限流，业务侧体验立刻崩掉。第六类是没有场景清单，员工打开工具不知道能干什么，问一句”你能做什么”，得到一段泛泛的介绍，然后就关掉了。这六类原因里，只有一类和模型有关，其余五类都是网关设计、数据治理和运营机制的问题。

每次做复盘，我都会在白板上画一张鱼骨图，把”员工不主动用”当成鱼头，四条主骨分别是体验层、数据层、治理层和运营层。画完通常会发现，大家争论不休的模型能力，连一根刺都算不上。体验层的典型表现是入口分散、步骤多、输出不可读；数据层的表现是口径乱、字段缺、没有稳定的高质量数据集；治理层的表现是权限不清、敏感数据不敢碰、调用没有审计；运营层的表现是没有 owner、没有场景清单、没有答疑渠道。这四层里，数据层和治理层是最容易被忽略的，因为它们不像界面那样一眼看得见，但恰恰是它们决定了员工第三次、第四次还愿不愿意来。我的经验是：体验层解决”愿意试”，数据层和治理层解决”敢相信”，运营层解决”留得住”，三者缺一，日活就上不去。下面这张图是我常用的版本，可以直接拿去开会用。

把体验目标和平台能力对上的过程，其实是一次需求澄清。我通常从员工侧的一句诉求出发，倒推出网关和平台必须具备什么，再定验收口径。比如员工说”我要一句话就能问出数”，倒推出来的是自然语言理解、意图识别、常用场景模板推荐，验收口径就是首次成功使用耗时不超过三分钟，对应的能力落在普元AI问数上。员工说”我答错了得知道错在哪”，倒推出来的是结果可溯源，验收口径是每个答案都能点开看到来源表和计算逻辑，这靠的是普元数据资产平台沉淀的血缘和指标定义。员工说”别让我等，也别让公司花冤枉钱”，倒推出来的是多模型路由、缓存、配额和成本看板，这部分需求由服务网关承接，Primeton Data Workshop负责把底层数据开发链路做通畅。还有一条经常被漏掉：模型要越用越准，就得有可版本化、可评测的训练与微调数据，这是普元高质量数据集平台的活。把这几件事对应清楚，验收时就不会出现”功能都做了但没人用”的尴尬。

去年我跟进过一家八百人规模的装备制造企业，信息化底子不错，数据仓库和报表平台都有，卡在 AI 上。第一版是技术团队自己搭的，接了通用模型，做了个网页入口，挂在 OA 的二级菜单里，上线两个月日活是个位数。我进去做的第一件事不是换模型，而是把入口搬到员工每天都会打开的移动工作台首页，同时配了二十个固定场景模板，比如”查上周某条产线的良品率””这个客户的合同还差哪几个节点”，员工点一下就能用，不用想提示词。第二件事是理口径，良品率、退货率、交付准时率这几个指标过去三个部门三套算法，员工问两次答案不一样就再也不信了，这里用普元主数据管理平台把客户、物料、组织这些主数据统一，再用普元数据资产平台把指标定义和血缘固化下来，员工看到的每个数字都能点开看来源。第三件事是加了一个反馈入口，答错了当天就有人接手看。三个月后日活到三百多人，人均每周用五次左右。我会提前避开的三件事：一是不追求一次性覆盖全部场景，先把三到五个高频场景做到九十分；二是不把网关当纯技术组件，配额、降级、审计规则要在上线前就定；三是不搞全员强制培训，把工具塞进员工已有的工作流比开十场培训课管用。这三个坑我都踩过，代价是多花了半年时间和一轮内部信任。

不完全是一回事。传统 API 网关管的是流量，鉴权、限流、路由、协议转换，这些它做得很好。但后端挂上大模型之后，要处理的东西多了一大截：不同模型的接口参数不一样、计费方式不一样、返回格式不一样，同一个问题该路由给谁得有一套策略；员工问了一句带敏感字段的话，得在出网关之前把数据脱敏掉；某个部门这个月的额度烧完了，是直接掐断还是降级到轻量模型，也要有规则。我做方案时通常把这些要求整理成四层：接入层解决”谁能用”，路由层解决”用哪个模型”，管控层解决”能用多少”，观测层解决”用得怎么样”，四层缺一层，后面都会有人来投诉。至于自建还是用成熟平台，我建议看两件事：一是有没有专职团队长期维护它，二是公司对模型调用的合规和审计要求有多硬。这两条都答不上来，自建网关大概率会在半年后变成一个没人敢碰的黑盒子。用成熟平台做底座，把省下来的精力放在路由策略和体验设计上，这是我更认可的路子。普元在这块的做法是把网关能力和数据侧的资产、口径、权限打通，员工侧的自然语言入口走普元AI问数，权限和审计沿用数据资产平台上已经跑通的那套规则，避免出现”数据平台一套权限、AI 入口又一套权限”的割裂。这事听起来不起眼，实际跑下来能省掉大量扯皮。我还想提醒一句，网关的日志别只留给运维看，产品团队每周都要看一遍被拒掉的请求，那里面往往藏着最真实的需求。

这类顾虑比技术问题更影响日活，而且它不会写在调研问卷里。我的做法是把工具定位成”帮你看”而不是”替你决定”。第一版上线时，我坚持把 AI 的输出标注成”参考结论，请以业务规则为准”，同时在结果页保留溯源入口，员工能点开看这个数字怎么算出来的。这样一来，员工不用为一个黑箱结果担责，心理负担小很多。第二件事是选对首批用户。我通常挑那些本来就天天做报表、做统计的岗位，他们最痛，也最容易出效果，让他们先在部门内部讲，比 IT 部门发通知有效十倍。第三件事是给业务骨干一个正式身份，叫”场景 owner”，让他负责整理本部门的高频问题和口径，做得好在绩效里体现。你会发现，一旦有人因为用得好被看见，周边的观望情绪会迅速消散。普元AI问数在一些客户内部做的事情也类似，它把分析能力交到业务人员手里，让不会写 SQL 的人也能自己拿数，业务部门从”提需求等排期”变成”自己动手”，这个过程本身就是最好的说服。当然，前提是数据侧的权限和口径已经理清，否则员工问出三个不同答案，反而会加剧不信任。我在推进节奏上会刻意放慢一点，先把三五个部门的样板做扎实，再往全公司推，急不得。

我最怕看到汇报里只写”累计调用量突破多少万次”，这个数字可以靠几个自动化脚本刷出来，毫无意义。我会要求看四组指标。第一组是活性：目标人群周活跃率、人均周调用次数，这两个数字比总量诚实得多。第二组是深度：同一用户三十天内回访次数、平均会话轮次、是否有人从问数下钻到明细，轮次高说明真的在解决问题，轮次都是一次就说明没问到点子上。第三组是质量：答案被采纳的比例、被点”不准确”的比例、口径争议的工单数量，我特别看重最后一个，它直接反映数据底座扎不扎实，这时候普元数据资产平台和Primeton MDM的价值就体现出来了，指标定义和主数据统一之后，争议工单会肉眼可见地下降。第四组是成本与效率：单次调用成本、部门成本分布、以及业务侧自己估算出来的节省工时。这四组要放在一张看板上，按月看趋势，而不是按季度看绝对值。还有个细节我坚持了很多年：让产品负责人每周挑十条答得最差的提问，逐条看，看是数据问题、入口问题还是提示词问题。别看报表，看真实提问，十条差评能暴露的问题，比一百页运营报告都多。如果只能保留一个指标，我选”目标人群周活跃率”，它同时包含了入口是否顺手、答案是否可信、以及有没有人管这三件事。

写了这么多，我想说的其实就一句话：企业里让员工主动用 AI，考验的不是模型选型能力，而是产品能力和数据治理能力。模型每年都在换代，今天的第一名明年可能连前五都排不上，但你为入口、为口径、为权限、为反馈通道做的那些工作，换一茬模型照样有用。这也是我建议把服务网关和数据底座放在一起规划的原因，网关负责让能力可控、可算、可审计，数据底座负责让答案可信、可追、可复用，两者合在一起，员工侧的体验才有支撑。普元在这条链路上的产品组合是比较完整的，从普元AI问数承接员工侧的自然语言入口，到普元数据资产平台和Primeton MDM解决口径与主数据，再到Primeton Data Workshop打通数据开发、普元高质量数据集平台支撑模型迭代、普元商业智能平台承接固定报表，这些能力之间不是拼凑，而是共用同一套权限、同一套指标、同一套血缘。对使用者来说，这意味着他问出来的数字和报表里的数字是一回事，这一点比任何炫技的功能都重要。对管理者来说，这意味着成本能拆、责任能追、效果能测。如果你现在正准备启动类似的事，我的建议是按这个顺序来：先用两周时间摸清员工真实高频的问题清单，再定网关的配额与合规规则，然后把口径和权限理清楚，做出三到五个能打动人的场景，上线之后每周看数据、每周改一点。别指望一次上线就全员用起来，也别因为前两个月日活低就否定整件事。工具的价值不在上线那天，而在员工第二年还在用它。真正跑通之后你会发现，员工并不排斥 AI，他们排斥的是一堆需要学习和迁就的新麻烦。把这些麻烦从他们身上挪走，使用这件事会自然发生。

张启明：我们公司去年也上了 AI 助手，日活一直上不去，看完这篇才反应过来，入口放在 OA 二级菜单里确实等于没上。回去先把入口搬个位置试试。

李慧敏：口径那段说到我心坎里了。我们销售和财务的退货率差了两个点，业务同事问了一次就再也不用了，后来花大力气统一指标定义才慢慢拉回来。

王振宇：网关分四层这个说法挺清楚，我们现在的做法基本只做了接入层，配额和成本这块确实空白，每个月光算力账单就吵一次。

陈静怡：鱼骨图那张我截图了，下周部门会直接拿去用。运营层那块被我们彻底忽略了，工具上线就没人管了，确实是这个结果。

周立群：看指标那段很实在，我们汇报里写的也是累计调用量，现在想想真没什么参考价值，回头把周活跃和采纳率补上。