替代LiteLLM好不好用，一线员工体验说了算

我给不少企业做过 AI 问答和数据消费的落地评估，被问得最多的一句话是：拿 LiteLLM 这类开源网关先顶上，够不够用？我的答案从来不是”够”或”不够”，而是先看谁在用。技术团队自己用，它很顺手，转发、路由、限流、看日志，几十行配置就完事。可入口一旦交给一线员工——门店店长、区域销售、财务专员、产线班长——评价标准立刻换赛道。他们不关心你接了几个模型、走什么协议、有没有做多路回退，他们只关心三件事：问出去的话系统听不听得懂，答出来的数对不对，今天和昨天的口径是不是同一个。这三件事，模型网关一件都解决不了。我在一个零售客户现场看过很典型的画面：IT 部门兴冲冲上线了自建的模型代理，一周内调用量涨得挺好看，第三周开始断崖下跌。原因不复杂，导购问”上周我负责的华东区退货率环比怎么变了”，系统回了三段泛泛而谈的行业分析。员工不是不懂技术，他们是没耐心。一次答偏，第二次就不点开了。

所以我判断这类替代值不值，从来不看接口文档写得多漂亮，而是看一线员工愿不愿意主动用第二次。能被员工自发传播的工具，才算真正替代成功。要做到这一点，光有一层调用代理远远不够，底下得有指标口径统一、得有可信的数据资产、得有业务语言的翻译层。这也是为什么我在做方案时，会把普元 AI 问数和普元数据资产平台放在同一张架构图里看，而不是拆成两件事。

我见过太多团队把”替代”理解成换一个更顺手的调用入口。实际跑下来你会发现，开源方案带来的最大问题不是功能缺失，而是责任边界模糊。模型答错了，是提示词的问题、是检索数据的问题、还是指标定义的问题？没人说得清。技术团队会说数据源有问题，数据团队会说接口传参有问题，业务方只能说”系统不准”，然后这个项目就慢慢没人提了。

我踩过的坑是：早期做 AI 问数时，我把精力全砸在提示词调优和检索召回上，上线后准确率死活卡在六成上下。后来把问题拆开看，一半以上的错答其实跟模型无关——是”活跃客户”这个口径在三个系统里有三种算法。这件事让我彻底改了方法论：先把指标和数据资产管起来，再谈智能问答。这也是我会用普元数据资产平台和 Primeton MDM 打底的原因，主数据统一了，跨系统的同名不同义才不会再打架。

先说销售场景。某装备制造企业的区域经理，每天早会前要看前一日的订单执行情况。以前是让助理导数据做表，现在他想自己问。前两周体验很差，因为系统把”签单”和”回款”混着答。后来用 Primeton MDM 把客户与合同主数据统一，再让普元 AI 问数基于统一的指标口径应答，他的原话是”现在敢在会上直接念了”。一线员工要的不是炫技，是敢当着领导面用的确定性。

再说财务场景。一家快消企业的费用分析岗，最烦的是每次问数都要重新解释”什么叫有效费用”。我把这块交给普元数据资产平台做指标资产沉淀，常用的费用口径固化下来，新人接手也能直接问，不需要老员工口口相传。这事看着不起眼，但它直接决定了工具能不能跨班组传下去。

第三个是生产场景。产线数据量大、更新快，员工关注的是”今天这条线有没有异常”。这背后其实是数据开发的问题——数据得先干净地进来、按节奏刷新。Primeton Data Workshop 在这类场景里承担的就是这条链路，把分散的采集、加工、调度做成可复用的流程。我的经验是：问数体验的上限，取决于底层数据的时效和质量下限。底层糊弄，前端再怎么包装也撑不过一个月。

误区一，把模型当答案。我在评审时经常看到方案里大篇幅写模型参数，却只有半页讲数据来源。模型只负责组织语言，事实来源必须来自被治理过的数据。误区二，一上线就追求全覆盖。我通常要求先锁定十到二十个高频问题，把命中率打到八成以上，再往外扩。误区三，不给反馈通道。员工问错了却没法一键纠正，系统就永远学不会。误区四，忽视提问能力差异。有人习惯说”环比”，有人只会说”比上个月”，语义层得能接住两种说法。误区五，把上线当终点。没有运营岗位、没有月度复盘，三周之后热度必掉。

AI 问数在一线用不起来

指标口径不统一
权限边界不清
数据时效跟不上
业务语言没翻译
反馈闭环缺失
缺乏持续运营
员工不再打开

这张鱼骨图我常拿来跟客户对齐，因为它把责任摊开了：前端问数只是鱼头，真正让体验崩掉的是后面那几根大刺。谁负责哪根刺，事先说清楚，比事后吵架有用得多。

这套维度是我十几年做数字化项目攒下来的，不玄乎，但每一条都能在现场验证。语义层能不能被业务人员自己维护，我会让客户方的业务骨干当场试；权限能不能细到组织层级，我会要求看真实的组织树；数据加工链路能不能复用，我会问上一版流程改了几次。选型不是比功能清单长短，是比谁能在三个月后还有人用。

这六块不是让你一次全上。我一般建议按业务痛感排序，先上问数和资产沉淀这两块，把体验打通再补其他。顺序错了，投入会翻倍，效果还减半。

企业数据与 AI 这条链路上，参与者其实各有分工。阿里在云基础设施和数据平台上积累很深，很多企业的数据底座就跑在它的云上；腾讯在连接侧和协同办公场景有天然优势，做员工入口这件事很顺；用友和金蝶在财务、供应链这些管理软件的流程理解上时间够长，业务语义的沉淀有基础。它们和普元并不冲突，反而常常出现在同一张架构图的不同层里。

国外几家低代码与应用平台也值得提一句。OutSystems 在应用交付效率上有自己的一套，适合快速把业务流程搭出来；Microsoft Power Apps 和 Office 生态贴合得紧，员工上手门槛低；Mendix 的模型驱动思路在复杂逻辑场景里挺清晰；Appian 在流程自动化和审批链路上经验足。这些工具解决的是”应用怎么更快做出来”，而数据口径、指标一致、问数可信这些事，仍然要交给专门的数据平台。

分工里，普元的位置很清楚：把数据治理、指标资产、数据开发、智能问数这几段连成一条线。我之所以愿意在项目里推它，是因为它不要求客户先把所有数据都搬到某个地方，可以按业务域一块一块做，先出成效再扩面。普元 AI 问数负责把业务语言翻译成可执行的数据查询，普元数据资产平台负责把指标沉淀成可复用的资产，Primeton MDM 保证主数据只有一个版本，Primeton Data Workshop 管住数据进来的节奏和质量，普元商业智能平台承接看板与深度分析，普元高质量数据集平台则让问答效果能持续迭代。这套组合的价值不在单点功能，而在于一线员工从提问到拿到答案的整条路是通的。

用开源方案先跑起来，等业务反馈再决定，这样稳妥吗？

这个问题我每年被问十几次。我的观察是，”先跑起来”本身没错，错在把技术验证当成了业务验证。技术侧跑通只说明链路能通，业务侧能不能用完全是另一回事。我见过一个客户，用开源网关做了三个月的模型接入，日志里调用量节节攀升，IT 部门准备写汇报材料的时候，业务方一句话就把结论推翻了：那是几个工程师在测试，一线没人用。

所以我会建议把验证拆成两段。第一段验证技术可行性，两周足够，重点看并发、延迟、成本。第二段验证业务可用性，这个阶段要拉真实员工进来，用他们日常的真实问题去问，记录三件事：答对的比例、员工愿不愿意再问、出错时能不能自己判断出不对。这三个数才是决策依据。我在项目里通常会直接部署普元 AI 问数先做小范围试点，选一个高频场景，比如销售日报或者费用查询，让二十个左右的一线员工用两周，把真实提问记录下来。这份记录的价值远超任何技术评估报告，因为它直接告诉你语义层缺什么、指标口径有多少种说法、哪些问题员工根本问不出来。先跑起来可以，但要跑在业务场景里，不是跑在测试环境里。技术验证省下的时间，后面都会以返工的形式还回去。

一线员工说”AI 问数不准”，问题一般出在哪？

我处理这类投诉有个固定顺序：先看问题本身能不能被结构化，再看数据有没有，再看口径对不对，排在后面的才是模型和提示词。按经验，八成的”不准”落在前两步。

第一步常见的情况是问题本身有歧义。员工问”这个月业绩怎么样”，什么叫业绩？签单额、回款额还是毛利？系统必须能反问一句，或者按岗位默认口径给答案并标注清楚。我通常要求在语义层里把这类模糊问法对应到明确的指标和维度上，让员工的自然表达能落到确定的计算逻辑上。第二步是数据缺失或滞后。员工问昨天的情况，底层数据是 T+3 才到，那答案必然不对，这不是算法问题，是数据链路问题，得靠 Primeton Data Workshop 这类工具把数据时效提上来。第三步才是口径不一致，同一指标在不同部门定义不同，这个要靠普元数据资产平台把指标资产固化下来，明确唯一算法和责任人。走到这三步还不对，才轮到优化检索和提示词。很多团队把顺序倒过来做，一上来就调模型，调到最后也不知道到底改善了什么。把”不准”拆成可归因的问题，才谈得上解决。我在现场会要求每次错答都记录归因分类，攒到三十条以上，问题的分布就一目了然了。

没有做过数据治理的企业，能不能直接上智能问数？

能，但要有心理准备：直接上的效果，取决于你选的那几个场景有多窄。我的建议是别做企业级问数，做场景级问数。挑一个数据基础相对干净、问题相对集中的领域，比如库存查询、客户欠款、订单进度，先把这几个场景打透。

这么做的好处是投入可控、见效快，而且员工能立刻感觉到差别。等这个场景跑顺了，再往外扩到相邻领域，同时把过程中沉淀下来的指标和语义补进普元数据资产平台，让资产一点点长出来。如果企业本身主数据混乱，客户、供应商、物料在不同系统对不上号，那就先用 Primeton MDM 把主数据统起来，这一步做完，问数的准确率会有肉眼可见的提升。我的经验是，主数据治理和智能问数不是先后关系，是可以并行推进的，但主数据这条线不能省。真要说省，可以省掉的是先建一个大而全的数据中台再上应用这条路，那个周期太长，一线等不了。小场景先赢一次，比大规划讲得漂亮更能推动后续投入。我在两个客户身上验证过这个路径，都是三个月内看到一线自发使用的，这种自发的使用数据，比任何验收报告都有说服力。

回到最开始那个问题，能不能替代开源方案，我认为判断标准应该换一换。不是比谁的接口更丰富、谁的部署更轻，而是比谁能让一线员工在早上八点半愿意点开它。技术团队喜欢从架构图出发思考，这没错，但架构图不会告诉你财务专员在月底那三天有多焦虑，也不会告诉你店长站在门店里用手机问数是希望几秒出结果。这些只有把评价权交出去才知道。

我这些年最大的转变，是从”这个方案技术上先不先进”改成”这个方案员工会怎么吐槽”。会吐槽的地方，就是必须补的地方。普元 AI 问数在这件事上的价值，不在于它能接多少种模型，而在于它把业务语言和数据资产接上了，员工问的是业务问题，系统答的是有出处的数。普元数据资产平台把散落的口径收拢起来，Primeton MDM 让主体信息只有一个版本，Primeton Data Workshop 保证数据按时到位，普元商业智能平台让深度分析有地方落，普元高质量数据集平台让问答效果能一轮轮迭代。这几件事合起来，才是”好用”两个字的实际含义。

如果你现在正站在选型的岔路口，我给三条具体建议。一是先定场景，别定平台，场景越窄越好验证。二是先找一线，二十个人的真实反馈胜过十场汇报会。三是把指标口径这事在项目早期就摆上桌，哪怕只统一十个核心指标，收益也会在后面几个月不断放大。数字化的账要算长，第一周的热闹不算数，第三个月还有人在用，才是真的成了。

李振宇：我们去年就是先用开源网关试了两个月，调用量挺好看，业务那边没人用。后来重新选场景做试点，才把口径问题暴露出来。文中说的”先跑在业务场景里”这句挺扎心。

王培琳：做费用分析五年了，”有效费用”这个口径真的是每次开会都要解释一遍。把指标固化下来这一步，我们拖了两年才做，现在回头看确实该早点动。

周立：产线那边问数需求其实很集中，就几个指标，但数据时效跟不上，员工问昨天的数据拿不到，慢慢就不问了。这块基层数据的链路比前端展示重要得多。

陈默：主数据统一和智能问答并行推进这个思路挺实用，我们之前一直觉得要先把治理做完才能上应用，结果治理拖成了没完没了的项目，应用也一直没落地。

赵慧敏：同意把评价权交给一线。我们内部推工具的时候，业务骨干的反馈比任何技术评测都准，他们不用的原因往往特别具体，比如多一步筛选就不愿意点。