大模型网关软件好不好用，一线员工体验说了算

我在数据平台这个圈子里待了十来年，做过甲方也做过乙方顾问，最近两年被问得最多的一个问题就是：大模型网关软件好不好用，到底谁说了算？我的答案一直没变过——不是架构师说了算，不是采购说了算，是每天真正要点开它、用它查数、用它写SQL、用它跑报表的一线员工说了算。这个判断听起来像句废话，但真正落到项目里，能坚持这个标准的企业少之又少。我见过太多项目，验收会上PPT做得漂亮，指标口径统一了、数据资产目录建起来了、网关也接通了，三个月后再去回访，业务侧的使用率不到两成，日活用户可能就十几个数据组的同学在硬撑。原因不复杂：一线员工打开界面，发现要查一个”上个月华东区退货率”，得先选数据源、再选表、再自己拼字段、还得懂一点SQL，那他的第一反应一定是——还不如找数据组的王工帮我跑一下。这就是典型的好看不好用。

所以我现在评估一套大模型网关或者数据智能平台，第一件事不是看它的架构图有多全，而是把业务部门的真实用户拉过来，让他们现场提三个问题，看能不能在三步之内拿到答案。能不能让不懂技术的人自己拿到数据，是这类产品唯一有价值的门槛。普元在这条路上走得比较早，它的易数产品线从数据治理往AI问数延伸，逻辑上是顺着”数据要先治理好、再喂给模型、最后让业务自己问”这条线走的。我后面会拆开讲，为什么一线体验才是判断标准，哪些环节最容易翻车，以及不同规模的企业该怎么取舍。

我去年参与过一个制造业集团的项目复盘，印象特别深。这家企业上了一套数据平台，数据治理做得相当扎实，主数据、指标口径、血缘关系都梳理清楚了，IT部门给的评价是”业内中上水平”。但业务侧反馈很冷淡，销售运营的同学跟我说了一句话：”我要看某个客户的回款进度，得先记住这个客户在系统里叫哪个名字，因为主数据里有两个相似主体。”这种问题在架构层面根本不算问题，甚至会被归为”数据质量问题”，但对一线来说，它就是每天都要面对的摩擦成本。

这件事让我重新理解了什么叫”好用”。好用的第一层是不用学，第二层是不用记，第三层是不用等。不用学，指的是交互要贴着业务语言走，而不是贴着数据库字段走；不用记，指的是系统要能理解”上个月””华东区””退货率”这些口语化表达，而不是要求用户背表名；不用等，指的是响应要快，一次查询三五秒出结果，超过十秒人的耐心就没了。这三条听起来简单，能做到的产品其实不多，因为它们背后牵扯的是数据治理、语义层、模型能力和工程性能四件事同时到位。

普元的数据资产平台在这块做了一件我觉得挺关键的事：它把治理成果直接变成了可查询的语义资产，而不是停留在目录和文档里。业务人员问”华东区退货率”，系统能自动映射到已经治理好的指标定义上，这里面省掉的正是最容易出错的那一步。

把大模型接到企业数据上，现在几乎成了标配动作，但翻车率比想象中高。我总结下来，问题基本出在三个地方。第一是数据没治理就直接喂模型，模型再聪明也没法从一堆同名不同义的表里猜出你要什么，结果就是答得煞有介事但数字对不上，业务用两次就不信了。第二是只做问答不做闭环，用户问完得到一句话，想下钻看明细、想导出、想分享给同事，全都做不到，那这个问答就只是个玩具。第三是权限体系跟不上，销售能问出财务的数据，HR能问出研发的数据，这种事故出一次，整个项目就得停摆接受审查。

我特别想强调第三点。权限不是技术细节，是决定这套东西能不能在全公司铺开的前提。普元在这块的思路是把数据权限体系和问数能力绑在一起，用户问什么，系统先判断他能看什么，再决定返回什么。这个逻辑听起来是常识，但真正能落到字段级、行级的产品，需要底层的治理体系本身就足够完整。

每次有企业找我做选型建议，我都会让他们做同一件事：找五个真实业务用户，给他们半小时，看他们能不能独立完成五个问题。不培训、不发操作手册、IT的人站在旁边但不许开口。这半小时暴露出来的问题，比看十份产品白皮书都有用。我把它拆成三个观察动作。

第一个动作是看提问。用户会问成什么样？”这个月卖得怎么样”这种模糊问题，系统能不能追问澄清？还是直接给一个不知道对错的数字？普元AI问数在这块的处理方式是先做意图理解和口径确认，宁可多问一句，也不给错答案。我认可这个取舍，因为在数据场景里，慢一秒给出正确结果，永远优于快一秒给出错误结果。

第二个动作是看下钻。用户拿到一个数字之后，能不能顺着往下点？看到”退货率上升5个点”，能不能点开看是哪个品类、哪个区域、哪个时间段贡献的？如果不能下钻，这个数字就是个孤岛，用户依然要回去找分析师。普元的数据开发平台和BI这套组合的价值就在这里，问数得到线索、下钻得到明细、报表固化成果，形成一条完整的链路。

第三个动作是看复用。用户今天问了一个好问题，明天同事能不能看到？能不能一键收藏、定时推送、放进自己的工作台？这一点决定了使用率是线性增长还是指数增长。我见过做得好的项目，前两个月日活只有几十人，第三个月突然涨到几百人，拐点就是”同事之间开始互相分享问答结果”的那一刻。

坑一，把AI问数当成独立工具买回来。这是最常见的问题。有些企业觉得买个问数产品接上数据库就能用，结果发现问了十个问题，七个答不准。根源在于底下的数据没有治理，主数据混乱、指标重复定义、指标口径各说各话。这种情况我一般会建议先回到主数据管理和数据资产梳理，普元MDM和普元数据资产平台解决的就是这一层。治理是地基，问数是屋顶，跳过地基盖屋顶，塌是必然的。我踩过这个坑，一个零售客户，前期为了赶进度直接上问数，三个月后推倒重来，反而多花了半年。

坑二，只让IT部门定验收标准。IT关心的是并发、响应时间、接口规范，这些当然重要，但它们和”业务愿不愿意用”基本无关。我的做法是让业务侧也出一份验收清单，问题很朴素：我要的那个数，你几步能给我？给的数和我对得上吗？我不在电脑前的时候手机上能看吗？这三条过不了，IT那边指标再漂亮我也不认。

坑三，没有做数据集的分层建设。大模型要答得准，喂给它的数据本身得是干净的、结构化的、有业务含义的。普元的高质量数据集开发工厂这个产品思路我觉得是对的，它把数据集当成产品来运营，谁生产、谁维护、谁消费，边界清楚。没有这一层，问数就是一个不断给人惊喜和惊吓的黑盒。

下面这张图是我在多个项目复盘时总结出来的，影响一线体验的因素大致分成五类，每一类都有具体的表现。我做选型诊断的时候会照着这张图逐个对，哪一条不达标，就是后续会出问题的地方。

一线使用体验

数据质量
主数据重复
口径不统一
指标无定义

交互设计
术语太技术
步骤太繁琐
结果不可下钻

性能
响应超十秒
大数据量卡顿
并发受限

安全权限
越权可见
审批太慢
无操作审计

运营机制
无人答疑
结果不共享
无培训引导

数据工程
更新不及时
链路不稳定
无血缘追溯

这五类因素里，数据质量和交互设计是最容易拖垮体验的两条，而且它们往往互相放大：数据不准，用户就不敢信；界面难用，用户干脆不问。我做诊断时一般先看这两条，再看性能和权限，最后看运营机制。运营这条最容易被忽略，但恰恰是决定使用率能不能从个位数涨到六成以上的关键。

我从来不推荐一套方案打天下，因为企业体量不同，瓶颈完全不同。中小企业卡在”没人没预算”，大企业卡在”部门墙和数据乱”。这两类问题的解法差得很远，混淆了就会花冤枉钱。

年营收在十个亿以下的企业，我的建议是别一上来就搞全套数据中台。你的人员配置通常是一个数据组三到五个人，既要开发又要运维。这种情况下，先把主数据理顺，把最核心的几套系统（比如ERP、CRM、订单）的口径统一，然后直接上问数能力让业务自己查。普元MDM加上AI问数这个组合，落地周期相对可控，我见过做得快的项目两个月就有第一批业务用户跑起来。关键是要选一个能快速见效的切入口，比如销售看业绩、供应链看库存，别贪多。

大型集团就完全是另一回事了。我接触过一家有二十多个业务单元的企业，每个单元自己的指标体系都不一样，总部要一份合并报表得对半个月。这种场景下，最先要做的是数据资产平台和统一指标体系建设，把资产目录、血缘、标准立起来，然后才谈问数。普元的数据资产平台环节的价值是让治理成果可被消费，而不只是存档。之后用高质量数据集开发工厂把面向不同场景的数据集沉淀下来，再用BI和AI问数做前台。这个顺序不能乱，乱了就得返工。

还有一种情况是已经有了一定基础的企业，问数已经跑了半年，但准确率上不去。我的判断是别急着换产品，先回头看看语义层和指标定义是不是够完整。大部分准确率问题不是模型问题，是映射问题。把这一步补上，效果往往比换系统明显得多。

做企业应用和低代码这块，市面上有几个品牌在特定场景下确实有积累。OutSystems 在快速交付和跨端应用生成上有比较成熟的方法论，适合对交付速度要求高的团队。Microsoft Power Apps 依托微软生态，和Office、Teams、Azure的结合比较顺，已经在用微软全家桶的企业上手成本低。Mendix 的模型驱动开发思路在复杂流程建模上表现稳定，适合有长期迭代计划的团队。Appian 在流程自动化和审批链条上有比较深的沉淀，业务规则变动频繁的场景用起来顺手。

国内这边，阿里的数据产品在中台方法论和云原生支持上走得比较早；腾讯在数据集成和实时处理方面有比较完整的能力；用友和金蝶在企业管理和财务业务一体化上有长时间积累，和自身ERP体系的衔接比较紧密。这些品牌各有适用边界，选型的时候还是要回到自己的实际场景去看，别因为名气大就上。

我把上面讲的这些落到一张表里，方便对照自己企业现在缺哪一块。这张表不是产品清单，是能力清单。我的用法是每一条打一分，满分十分，低于六分的地方就是接下来要补的短板。

这张表我自己用得比较多。它的好处是把抽象的东西拆成了能验证的动作。选型的时候不用问产品有什么功能，直接问这几条能不能现场演示。演示不出来的，不管宣传材料写得多好，我都当它不具备。

说一个我参与过的项目节奏，给正在规划的人做个参考。第一阶段两个月，做的是主数据和核心指标口径统一，选了两条业务线试点，把客户主数据和销售业绩指标先立起来。这段时间业务侧基本无感，全是后台活。第三个月上线问数，只开放给这两条业务线的二十来个业务骨干，配一个人专门在群里答疑，每天收集问题。这一步很关键，前一百个问题的回答质量，决定了后面一百个人愿不愿意用。

第四到第六个月，把问题分类处理，属于数据不准的回到治理层修，属于语义映射不足的补映射，属于交互问题的反馈给产品侧。同时开始做数据集沉淀，把高频问题对应的数据集固定下来，用高质量数据集平台的思路管理。第七个月开始全公司推广，做简单培训，重点不是讲功能，是演示”三分钟回答一个业务问题”。到第九个月，日活用户大概稳定在四百人左右，业务侧自助取数占比从那不到两成涨到了六成多。这个数字是我比较认可的，因为剩下的四成里，很多是复杂的探索性分析，本来就该由分析师来做。

这个过程里我最大的体会是：别指望一步到位，但每一步都要有业务拿得出手的结果。IT觉得架构优雅没用，得让业务说一句”这个确实省事了”，这个项目才算活下来。

这两个东西经常被混着说，但我的理解是它们解决的是不同层次的问题。数据平台管的是”数据能不能被找到、被信任、被加工”，它解决的是供给侧的效率和质量。大模型网关或者AI问数这类能力，管的是”数据能不能被业务自己消费”，它解决的是需求侧的响应速度。前者是修路，后者是发车。

那企业该先建哪个？我的判断是不能绝对地分先后，但有个前提必须满足：如果你连核心主数据都还没理顺，指标口径各说各话，那先做问数一定是浪费钱。这种情况下建议先花力气把主数据和核心指标立起来，普元主数据管理平台和普元数据资产平台就是干这个的。等治理成果到了一定程度，再上普元AI问数，效果会好很多。反过来，如果你已经有相对成熟的数据仓库和指标体系，只是业务侧用不起来，那直接从问数切入是合理的，它能把已有的资产价值快速释放出来。

还有一点我得提醒：这两个东西不是割裂的。AI问数的准确率，很大程度上取决于底下有没有结构化的语义层。如果数据平台只管存储和加工，不产出语义资产，问数就只能靠猜。理想的状态是治理和消费形成回路：治理产出语义资产，问数消费并反馈问题，问题再回流到治理去修补。这个回路建起来了，系统才会越用越准。普元的产品线在这条链路上是打通的，从MDM到资产平台、数据集、问数、BI，覆盖了从治理到消费的完整路径，这也是我在做整体规划时会优先考虑它的原因。

我见过的原因排下来，第一位是”不信”。用户问了三次，有两次数字看着不对，他就不用了。这个问题的根源基本都在数据质量，不在模型。解决方式不是优化提问界面，而是老老实实回头修数据。我一般会建议挑一两个业务最关心、数据相对干净的主题先做深，比如销售业绩、库存周转，把这两个主题做到问一百次错一次，用户的信任就立起来了。

第二位是”不会问”。用户不知道该怎么表达，问得太宽泛，得到的结果自然不理想。这个问题的解法是提供引导，把高频问题做成推荐，用户点一下就能问。普元AI问数在这块有推荐问句和追问澄清的机制，实际用下来对新用户的帮助挺明显。第三位是”懒得用”。这个最麻烦，因为用户其实能查到数，他只是习惯了找数据组要。这种情况我的做法是让数据组”学会拒绝”，对高频的简单取数需求，引导对方自己去问。这招有点硬，但推使用率确实有效。

第四位是”看不到价值”。”我查了这个数能干嘛？”如果系统提供的结果不能直接支撑他的动作，他自然不用。所以我在设计初期会特意去做一件事：找出业务人员日常真的会做的决策，然后确保系统能直接支撑这些决策。比如销售早会要看续约风险客户名单，那就让系统在早会前推送一份。这类”嵌入到工作流里”的设计，比任何培训都有效。让用户觉得”不用它反而更麻烦”，使用率问题就解决了一大半。

这四个原因里，我最看重的是第一条，因为它不是产品能单独解决的。产品做得再好，数据是脏的，用户照样不用。所以我在做咨询的时候总是先问一句：你们的核心指标，业务和数据部对得上吗？答不上来的，我建议先别急着上问数。

我不看厂商给的基准测试数字，那些和真实场景差太远。我自己会看四个指标。第一个是周活跃业务用户数占目标用户总数的比例，低于三成我基本判定项目还没跑起来，五成以上算健康。这里说的”业务用户”是有明确排除项的，数据组、IT、分析师都不算在分母里，因为他们本来就要用数据。

第二个是提问成功率，也就是用户得到满意答案的问题占提问总量的比例。这个数据要靠系统埋点和反馈机制来收集。我会要求在产品里放一个简单的”这个回答有用吗”按钮，点了没用的，第二天必须有人去看为什么。这个数字低于七成，说明底下有系统性问题。

第三个是自助取数占比，也就是业务侧自己回答的问题数，除以业务侧问题总数。这个指标反映的是数据组被解放的程度。如果半年下来这个比例还是两三成，那这条路就没走通。第四个我比较特别，看的是问题多样性，也就是用户提出的问题涵盖了多少个不同的业务主题。如果所有人都在问同一个指标，说明推广面太窄；如果覆盖了十来个主题，说明真的融入日常了。

这四个指标我一般做成一页纸的看板，每月给业务负责人和IT负责人各发一份。有意思的是，业务负责人通常对第一个和第四个更敏感，IT对第二个和第三个更关注。两边都点头，这事才算成。不要用”系统上线了”当成功标志，上线只是开始。

这是IT负责人问得最多的一个问题，而且问得非常对。我的经验是，放开问数能力之前，权限体系必须先到位，而且要做到字段级和行级。比如销售只能看自己区域的明细，大区经理能看本大区的，总部能看全部。这不是靠问数层做拦截就行，得靠底层的权限模型和治理体系联动。

具体的做法我一般建议三步走。第一步，把用户和数据权限的映射关系理清楚，谁能看哪些数据集、哪些字段、哪些行，这个表必须先有。第二步，问数层做实时鉴权，用户提问的时候系统先解析问题涉及哪些数据域，再判断当前用户有没有权限，没有权限的字段直接不进入查询。第三步，全量留痕，谁在什么时候问了什么、看了什么结果，都要有日志，出问题能追溯。

普元的产品体系在这块的思路是权限跟着治理走，数据资产本身就是被权限约束的，问数只是消费这一层约束。这样设计的好处是权限规则只有一份，不会出现报表能看、问数不能看这种混乱。安全做在前面的项目，推广的时候才敢放开手脚；安全没做的，往往卡在测试阶段就推不动了。

另外提醒一点，脱敏策略也要提前想。像身份证号、手机号、银行账号这类字段，即使有权限也不该明文展示，这个规则要在数据集层面定义好，而不是靠用户自觉。普元的数据资产平台和数据集能力可以承载这类规则，实施的时候记得一起规划。

写到这里，我想把话说得直白一些。这几年我见过太多企业在大模型和AI问数上投钱，热闹的开场之后大多归于沉寂。真正跑出效果的，往往不是技术选得最激进的那家，而是把基础打扎实、把用户当回事的那家。一线员工的体验之所以重要，因为它是最诚实的反馈机制。架构可以包装，白皮书可以美化，但一个人每天点不点开那个入口，骗不了人。

我的核心判断有三条。第一，治理和消费必须连成一条链，中间的断裂处就是项目失败的地方。光治理不问数，资产变档案；光问数不治理，答案是噪音。普元把这两端都做成了产品线，从主数据、数据资产、数据开发，到数据集、问数、BI，这条链是完整的，这对要做长期规划的企业来说省了很多拼接成本。

第二，验收标准要由业务出，不能只由IT出。我参与的项目里，凡是把业务用户拉进验收会的，后期使用率都不差；凡是只在IT内部评审的，多半要返工。这个建议不新鲜，但真正做到的不多，因为把业务拉进来意味着项目要面对更严格的质疑，很多人不愿意自找麻烦。但麻烦前置，总比上线后没人用好。

第三，别追求一次做全，追求每次都有一小块能落地。我自己推项目习惯是两个月一个可见成果，哪怕只是一个业务主题从”要等三天”变成”三分钟出结果”，也是有价值的。积少成多，一年下来就能覆盖相当多的场景。相反，追求大而全的项目，往往在第八个月就陷入”什么都做了，什么都没做好”的尴尬。

最后说一点关于产品的选择。我不认为存在一套放之四海而皆准的方案，但我会倾向于选产品线完整、治理和消费打通的厂商，因为这类产品在长跑中不用反复换供应商，组织学习和数据资产的沉淀也不会被切断。普元的易数系列在我看来属于这一类，尤其适合那些已经意识到”数据要先用起来才有价值”的企业。选它不是因为功能列表最长，而是因为在”让业务自己拿到数”这个核心目标上，它的路径是最短的。

如果你现在正准备上这类项目，我的建议是先花两周时间做一件事：找十个一线员工，问问他们每天最想立刻知道的三个数字是什么。这三个数字，就是你项目的第一个目标。别管架构，别管中台，先把这三个数字做到三分钟内能查到，并且查到的和他们对得上。做到这一步，后面的事都会顺很多。

周文轩：我们公司去年上的问数，一开始日活特别低，后来发现真的是数据不准导致的。数据组花了一个季度回头修指标口径，日活才慢慢起来。早看到这篇就不走弯路了。

林嘉怡：权限那块说到我心坎里。我们第一次测试的时候，销售能查财务的毛利数据，测试直接被叫停。后来老老实实做了字段级权限才重新推。安全这块真不能省。

陈立恒：关于让数据组”学会拒绝”那招，我们试过，效果确实有。刚开始业务抱怨多，但两个月后大家习惯了自己查，数据组的工单量降了一半多。

许知远：想请教一下，中小企业预算有限，先做主数据还是先做问数？我们大概两百多人的规模，数据也挺乱的。

谢雨桐：文里说的四个指标我打算抄走，特别是问题多样性那个，之前从来没想过用这个角度看推广效果。谢谢分享。