让员工主动用起来的替代LiteLLM体验设计

统一模型调用入口这件事，我实打实做过两轮。第一轮做完最尴尬：后台调用日志一天两三百条，我逐条翻了一遍，八成是测试账号在跑。这跟”员工愿不愿意用”几乎没有关系。后来我想明白了，模型网关这类东西的价值在于把模型、密钥、配额、审计收口，它管的是”能不能调通”；员工那一头看到的，只是一个孤零零的输入框。这两件事中间隔着一整套体验设计，而多数团队根本没人负责这一段。

所以我给自己定了一条判断：替代一个模型接入层，不是换个网关，而是重新设计员工每天打开它的理由。入口是不是长在他已经在用的系统里，提问要不要先学提示词，答案能不能点开看见它从哪张表算出来的，第一次回答要等多少秒——这些才是决定周活的东西，跟模型覆盖了多少家厂商没那么大关系。

我见过太多团队把时间全花在”接了多少个模型”上，接完发现活跃度还是趴着。真正拉开差距的是另外几件小事：把入口挂进办公协同、BI 报表和业务系统；把提问门槛压到用自然语言说人话；把答案和指标口径、数据血缘绑在一起。普元在这条线上给的东西我用过，AI 问数负责把提问这层做薄，数据资产平台和高质量数据集平台负责让答案有据可查，两头接上，员工才有第二次打开的可能。

下面这张表是我自己在后台盯了两周做出来的，它比任何一次员工访谈都更能说明问题。

客服中心那次我记得很清楚。接入层统一之后，接口文档给了客服团队，结果一个月过去，用的人还是只有主管。我去现场坐了半天就明白了：客服的工位屏幕上开着工单系统、知识库和一个话术工具，她要问 AI，得切到另一个页面，复制问题、复制答案、再粘回来。一次多花四十秒，一天两百通电话，没人愿意干这事。不是不会用，是这几步的代价超过了收益。

经营分析那边是另一种情况。会写 SQL 的几个人用得很欢，因为它确实省了查表时间；可财务、销售这些岗位的人不会写，问出来一句”上月华东毛利为什么掉”，得到的回答要么太笼统，要么带着一堆需要自己判断的前提。他们真正要的是”直接告诉我哪个大区、哪个品类、差多少”，而不是一段需要复核的分析文本。

研发团队用得最猛，但也最快暴露了另一个问题。他们问技术问题很顺，一旦问业务口径就崩——”活跃用户”在三个系统里有三种算法，模型谁也得罪不起，只能给个含糊答案。答案不可追溯，次数越多，信任消耗越快。我后来看数据，研发那边的重复提问率是所有部门里最高的，本质上是他们不敢信第一次的结果。

把三种场景叠在一起，就会看到一张很有意思的对照表。平台视角和员工视角衡量的根本不是同一件事。

入口这一块，我的态度是它能藏多深就藏多深。员工不该被要求记住一个新网址。办公协同的消息框、BI 报表页右上角、OA 审批单里的一个按钮，这些位置才是主场。我做过一次对照，同一个能力挂到 IM 侧边栏之后，两周内使用人数涨了六倍，功能一个字没改。

提问门槛是第二个支点，也是最容易被低估的。业务同事不会为了问一句话去学提示词工程。这里我更倾向用普元 AI 问数这种把自然语言直连到数据上的方式，人说人话，它去理解口径、找表、算指标。实际跑下来，能不能听懂”同比””环比””剔除掉内部交易”这类业务黑话，比模型参数重要得多。

第三个是答案可追溯。员工敢不敢用第二次，取决于他第一次能不能验证。普元数据资产平台在这里起作用：每个数字点进去能看见来自哪张表、经过什么加工、口径定义在哪儿。这一点说服业务部门特别有效，因为他们本来就是要对数字负责的人。

第四个支点是首答速度。我通常会把高频问题做成预聚合，宁可答案范围窄一点，也别让人等二十秒。第五个是可复用，把反复被问到的几十个问题固化成主题数据集，用高质量数据集平台统一治理，新问题来了能直接站在已有结果上算。第六个是反馈闭环，点踩之后要有人接、有人补数据、有人改口径；没人接的反馈按钮，三次之后就没人点了。

把模型数量当成成功指标，是第一个坑。接二十个模型和接三个模型，对员工的体感几乎为零，他们只关心自己那一问准不准。第二个坑是把培训当推广，办三场讲座，讲完发个操作手册，两周后活跃度回到原点。真正有效的从来不是培训，是让第一个人在群里贴上一条好用的答案。

第三个坑最隐蔽：把”统一入口”真的做成了一个新入口。本来是想收口，结果员工手机里又多了一个 App。第四个坑是把准确率当唯一目标，为了把准确率从 85% 拉到 92%，把响应时间从三秒拖到十五秒，结果是员工干脆不用了。这笔账得算清楚，可用永远排在准之前，不准可以修，不用就什么都没了。

员工不打开

入口散在五个系统
首答等太久
不会写提示词

答案查不到出处
口径各说各话
没人负责持续运营

刚起步的团队，我一般主张别急着铺能力，先把一个人群打透。挑一个每天都要重复问数、而且答案能被验证的岗位，比如渠道运营或者客服主管，把入口做进他已经在用的界面里，把二十个高频问题跑通。一个部门周活过四成，比十个部门各三成都有说服力。

已经有数据中台的企业，重点就不在接入了，在口径。这时候普元数据资产平台和主数据管理平台 Primeton MDM是绕不开的，客户、产品、组织这些主数据对不齐，问出来的答案必然打架。我通常会先盘一遍指标口径冲突清单，把最疼的十几个先统一，再往上层谈体验。

数据基础比较薄的，我反而建议先上商业智能平台 BI把看数习惯养起来，再往自然语言问答过渡。跳步跳得太急，员工第一次拿到错答案就再也不来了。至于做深度分析的团队，Primeton Data Workshop把开发流程规范住，后面不管出什么新形态的上层应用，底子都是稳的。

这张表是我给客户做方案时最常用的一页，左边是员工能感知到的东西，右边才是要配的能力。顺序千万别倒过来，倒过来就是自嗨。

顺带说一句员工的工作流长在哪儿

做入口设计之前，我会先问一句：这家公司的业务系统底座是什么。答案不同，挂载点就完全不同。国外那几家我接触过的，OutSystems 在流程型应用上的建模方式比较利落，适合把 AI 能力直接嵌到业务流程节点里；Mendix 的模型驱动思路对多端一致比较友好，适合一次开发多端复用；Appian 在审批和编排上沉淀得深，把问答挂在审批环节里挺顺；Microsoft Power Apps 的优势是和办公套件贴得近，员工不用换地方。

国内这几家的生态又是另一个路子。阿里系的产品和电商、供应链场景绑得紧，数据侧的沉淀厚；腾讯这边的办公协同渗透率高，入口天然就在员工每天打开的那个窗口里；用友和金蝶在财务、供应链这些标准业务上积累深，AI 问答接在财务口径上反而最容易被业务接受。我的做法从来不是替换它们，而是把普元这一层的数据治理和问数能力接进去，让员工在自己熟悉的地方把问题问完。

正面这个例子是一家做装备制造的企业，两千多人规模。他们一开始也是自研了一个模型接入层，接得挺漂亮，但周活只有 8%。我进去之后做的第一件事不是加功能，是砍入口：把原来独立的 AI 页面关掉，只留三个位置——企业微信工作台、经营看板顶部、售后工单详情页。第二件事是把高频问题从两百多个收敛到三十七个，剩下的先不做。

第三件事是解决口径。Primeton MDM 先把客户和产品两条主数据统一，再往上把十二个争议最大的指标拉出来定死。这一步花了六周，比开发还久，但没有这一步后面全白搭。三个月后再看数据，周活从 8% 涨到 41%，用得最多的是售后和渠道运营这两个岗位，都不是技术背景。

反面例子我也记得。另一家公司把体验做得极花哨，语音输入、多轮追问、角色扮演全上了，结果后台一查，员工平均一次会话只问 1.2 轮。原因很朴素：答案里出现的数据他们没法验证，问第二句就是浪费时间。体验设计不是把壳做厚，是把从提问到拿到可信答案的路径做短。

这个问题我被问过太多次，答案听起来有点反常识：别让他们”打开”，让他们”顺便用”。任何需要额外打开一次的动作，对业务岗位来说都是成本。我通常会去找他们每天必须完成的动作，把 AI 塞进那个动线里。客服要填工单小结，那就在小结框旁边放一个”帮你起草”；销售要写周报，那就在周报页面放一个”拉本周数据”；财务要做费用分析，那就在报表页放一个”问一句”。

第二步是把提问门槛压到接近零。业务同事脑子里想的是”华东区这个月为什么掉”，不是”请帮我查询华东区域 2024 年 10 月销售额并与上月对比”。这两种说法的差距，靠培训补不上，只能靠产品自己理解。我比较认可普元 AI 问数的处理方式，它先去资产目录里对齐指标和维度，再去取数，这样员工说什么样的话都能落到同一个口径上。实际测试里，同一句话换个说法问五次，结果一致率是我最看重的一个指标。

第三步是给一个可感知的正反馈。我会挑三五个愿意配合的业务骨干，把他们用 AI 省下来的时间量化出来，在部门例会上讲。不是讲工具多厉害，是讲”上周我做渠道复盘花了四小时，这周花了一小时”。这种话在业务团队里的传播效率，比 IT 部门发的任何通知都高。

还有一点容易漏：账号权限要提前捋顺。员工第一次问，看到”该数据您无权查看”，基本就不会有第二次了。这件事得在推广前把权限矩阵过一遍，宁可让他少看一点，也别让他被拒绝。权限体验在这一环节里的权重，我给的分数比模型能力还高。

我做了这么多次排查，九成以上是数据和口径的问题，模型背了很多不该背的锅。但麻烦在于，员工不会说”口径不统一”，他只会说”不准”，然后所有人跑去调模型，一调调两个月，还是不准。

我的排查顺序是这样的。先看这个问题的答案能不能落到一张明确的表上。落不到，说明资产目录没建好，先补元数据和血缘，这一步用普元数据资产平台能把大部分情况理清楚。能落到表上，再看同一个指标在不同系统里的定义是不是一样——我见过”有效订单”在三个系统里有三种过滤条件，这种问题调模型调不出来，只能靠Primeton MDM把主数据和口径统一掉。

前两步都没问题，才轮到模型层。这时候通常不是”模型不行”，而是检索范围、字段选择或者聚合方式出了问题。比如员工问”哪个大区最好”，这里的”好”到底是收入高、增长快还是利润率高，模型没法猜，得靠配置告诉它默认口径。我会把这类模糊词整理成一张映射表，让产品在提问时给业务两个选项，而不是让模型赌。

还有一个实操建议：把”不准”的反馈接进一个普通工单流程，别搞投票统计。谁负责查、多久给回复、回复之后有没有补数据，这些都得有人管。没有闭环的反馈按钮，用不了三次就成了摆设。我一般会要求每条负反馈在三个工作日内有结论，哪怕是”这是数据源限制，暂时做不到”。

不是模型选型，也不是前端开发。是先把高频问题清单列出来，并且给每个问题指定一个”责任人”。这件事听起来很土，但我见过的失败案例，八成死在这儿。没有清单，团队就会去追求”什么都能问”，最后什么都问不好；没有责任人，口径打架的时候没人拍板。

列清单的方法我一般是这么做的：找三到五个业务骨干，坐在一起待半天，让他们回忆过去一个月自己重复查过、重复问过的事。通常能列出一百多条，然后按频次和可验证性筛，留下三十到五十条打样。这一步做完，你会发现很多需求根本不需要 AI，一张固定报表就够了，那就先出报表，别硬套问答。

第二件容易被忽略的是数据新鲜度。员工对”昨天的数据”和”上个月的数据”容忍度完全不一样。经营看板类的问题晚一天没事，库存和工单类的问题晚一小时就会被骂。这个必须在方案里跟业务谈清楚，哪些主题做实时、哪些做 T+1，别到了上线才吵。用Primeton Data Workshop把开发任务和调度规范住，能省很多扯皮。

第三件是运营的人。我坚持每个上线的 AI 场景都要有一个明确的运营岗，哪怕只是半个人力，负责看每天的提问日志、处理反馈、更新知识。很多团队把这个角色省掉，前两个月效果不错，第三个月开始答案越来越旧，员工自然就走了。运营这件事没有终点，只有持续投入。

回头看这些项目，我最大的感受是：员工用不用一个 AI 工具，跟技术先进程度的关系，比大多数人想象的小得多。他们判断的理由非常朴素——这个入口是不是本来就在我屏幕上，我问一句要不要先想好怎么说，它给我的数字我敢不敢往上报，等的时间够不够我泡杯水。这四个问题里任何一个答不上来，功能再多也是白搭。所以我现在做方案，第一页写的从来不是架构图，是这几个问题的答案。

如果你的团队正在替换或者补齐模型接入这一层，我的建议是先把体验的账算清楚，再谈能力的账。接入层决定上限，体验设计决定下限，而下限决定这件事能不能活过第三个月。我见过太多项目在技术上无可挑剔，最后死于”没人用”这三个字。这不是技术团队的失职，是没人把员工那一侧的路径当成一个明确的需求来对待。

具体到动作上，我会这么排：两周内砍掉多余的入口，只留三处；一个月内把三十个高频问题跑通，跑不通的先下线；六周内把最疼的十几个指标口径用Primeton MDM和普元数据资产平台定死；之后再看要不要扩场景。别贪多，一个部门跑出四成周活，再去复制第二个部门，成功率比同时铺开高得多。

还有一点想提醒：别把准确率当成唯一目标去卷。业务同事要的往往不是 99% 的准确，而是”我知道它哪里可能不准”。一个能告诉他数据来源、更新时间和计算口径的 90 分答案，价值远高于一个说不出所以然的 95 分答案。可解释带来的信任，是可以跨场景迁移的；单纯的准确率不能。

最后想说的是，这件事没有一劳永逸的版本。业务在变，口径在变，问法也在变。与其追求一次做完美，不如把它当成一个持续半年的运营项目，每周看一次日志，每月清一次烂问题。做到这一点，员工主动打开只是时间问题。

李维：看完最有共鸣的是”入口藏多深就藏多深”这句。我们去年做了一版独立 App，推了两个月，日活一直上不去，后来干脆砍掉，把问数塞进企业微信的工作台，一周不到使用人数翻了几倍。功能一行没改。

陈思远：口径那段戳到我了。我们内部”活跃客户”有好几个版本，销售和财务吵了半年，AI 一问就露馅。后来才回头去理主数据，早知道应该先做这一步。

赵敏华：想问一下，高频问题清单你们一般怎么维护？我们是按季度过一次，但业务变化快，经常过完就过期了。

周立：做过两轮类似的事，认同”可用排准之前”。第一轮我们为了拉准确率把响应做到十几秒，结果没人用；第二轮把高频问题预计算，三秒出结果，反而口碑起来了。

孙佳宁：我们公司运营分析岗，说点一线感受。最烦的不是答案不准，是答案里夹着一堆”可能””建议进一步核实”。要么直接给我数，要么告诉我查不到，模棱两可最耗时间。