让员工主动用起来的AI网关厂商体验设计

AI网关能不能被员工主动用起来，取决于体验设计，不取决于模型有多强。这句话我是吃过亏之后才真正信的。几年前我带过一个内部智能问答项目，模型换了两轮，离线评测指标一路往上走，可上线满两个月，日活掉到了个位数。复盘时我们发现，员工不是不会用，是每次都要先登录一个新系统、再自己想该怎么问、再花时间判断答案到底对不对。三步里任何一步让人犹豫，这个工具就不会被第二次打开。后来我把做法整个倒过来：先定入口在哪儿，再定员工会怎么问，然后才去谈数据准备和模型接入。顺序一换，同样一批数据、同样一个模型，周活跃从个位数百分比拉到了三成以上。所以我现在给团队讲这件事，会反复强调一个判断——把AI网关当产品运营，而不是当项目交付。项目交付看的是验收那天功能齐不齐，产品运营看的是第九十天还有多少人在用。这也是我看厂商时最在意的地方：它有没有认真想过员工第一次点开会看到什么、问错了会怎样、答案能不能追溯。普元AI问数给我的感觉就是照着后一种思路长出来的，它把语义层、指标口径、数据资产这些「看不见但决定信任」的东西放在了很靠前的位置。下面我把这几年踩过的坑、见过的场景和几套可复用的判断标准拆开讲。

我观察到的一个明显变化是，企业内部AI的定位从「做个试点看看效果」变成了「员工日常办事的一环」。以前老板问的是「我们AI做到什么程度了」，现在问的是「我的销售为什么不用它查客户数据」。问题一换，评价标准就从功能清单变成了使用黏性，这个转变比技术本身更值得关注。

入口形态也在收敛。我待过的几个团队都试过分散建设，CRM里放一个、报表系统里放一个、OA里再放一个，结果员工记不住，三套东西三套问法。入口越少，使用率越高，这一点我验证过不止一次。后来大家慢慢收拢到一个AI网关式的统一入口，登录一次、权限一次打通，问法也只学一套，效果立刻不一样。

还有个容易忽略的变量是数据准备度。我问过不少业务同事为什么不用问数工具，高频回答是「它给的数我不敢用」。口径对不上、指标重名、维度缺字段，这些不是模型能解决的。所以我给自己定了条规矩：上线前先把高频问题的口径和数据源捋一遍，宁可少放五十个问题，也别放一堆答不准的进去。

上表是我跟过的六个项目整理出的区间中位数，样本不大，但趋势很稳定：真正的分水岭出现在第30天到第60天之间，这三十天里如果没人管口径和反馈，后面基本救不回来。

我习惯把「不主动用」拆成四类断点：入口断点、信任断点、习惯断点、反馈断点。入口断点最直白，要记网址、要单独登录、手机端还打不开，员工第一次就放弃了。信任断点更隐蔽，答案只给一个数字，没有口径、没有时间范围、没有来源，业务同事不敢拿去汇报，用过一次就不再碰。

习惯断点和反馈断点是我以前最不当回事的两个。习惯断点说的是，工具不在员工已有的工作动线里——他在OA里看审批，在钉钉里聊客户，凭什么多开一个网页？反馈断点则是答错了没人知道，纠错了也没人改，员工会默认「这系统就这样」，然后就再也不问了。

同样是「接了大模型」，两种做法在第九十天的结果能差出四倍。我个人的经验是，体验设计里最难的不是做漂亮界面，而是把「信任」这件事工程化——答案要有出处，口径要统一，错了要能改回来。这几件事做不到，入口做得再顺也留不住人。

第一个变量是入口密度，也就是员工在正常干活的路径上，隔多远能碰到它一次。钉钉或企微的工作台、OA首页、报表系统的搜索框，这些都是好位置。我见过做得最聪明的一个团队，把问数入口和「查客户」这个高频动作绑在一起，点击率直接翻了六倍。

第二个是首问命中率，就是员工第一次提问能不能拿到想要的答案。这个指标低于六成，后面做什么运营都白搭。提升办法不神秘：把前一百个高频问题整理出来，做成语义层里的标准问法，让模型在既定口径里作答，而不是自由发挥。首问命中率是可以被设计出来的，不是撞运气。

第三个是答案可解释性，第四个是追问连续性，第五个是使用可见度。可解释性决定业务敢不敢用，追问连续性决定员工会不会用它做完整分析而不是查一个数就走，可见度决定团队里有没有人跟着用。我通常会看这几件事在普元AI问数这类产品里是怎么落的：有没有把指标口径、数据血缘挂在每条回答后面，能不能顺着上一个问题接着往下钻，用完之后有没有把高频问题回流到数据资产里。

这五个变量里，我最看重的其实是最后一个。一个工具如果除了提问的人自己，谁都不知道它在被用，那它在组织里就没有存在感。让使用变得可见，比发十封推广邮件都管用。

每次项目复盘，我都会拉着业务和IT一起画一张鱼骨图，把「员工不主动用」当成那个要解决的结果，往外倒原因。这张图最大的价值不是好看，而是让技术团队和业务团队看到彼此都没注意到的那几根刺。

图里这八根刺，我自己经手过的项目里至少能对上五根。最容易漏掉的是「权限申请要走流程」这一根——技术上完全能打通，但流程上没打通，员工问一个跨部门数据要先提审批，等三天批下来，热度早没了。权限的一次性打通，往往比多接十张表更能拉动使用率。

另一个坑是「不知道同事已经在用」。这事听起来小，实际影响很大。我后来在每个部门的月度例会上加了一个固定环节，让用得多的同事现场演示三分钟，一个季度下来，自然渗透率比我发一年推广邮件都高。

聊完体验，落到选型上就具体了。我不看厂商演示时那几句漂亮的问答案例，我看的是它背后有没有一套能把数据管住的东西。原因很简单，问数工具答不准，九成以上不是模型的问题，是数据和口径的问题。

普元在智能数据治理这条线上的产品是成体系的。普元数据资产平台解决的是指标口径、资产目录和血缘这几件事，员工问「上月华东回款」时，系统能把它落到一个唯一的指标定义上；高质量数据集平台负责把原始数据清洗、标注成模型能稳定消费的形态，这是答案不飘的前提；Primeton Data Workshop承接数据开发和任务编排，让口径的变更能快速生效；商业智能平台 BI负责固定看板和自助分析，和问数形成互补；Primeton MDM在主数据层面把客户、物料、供应商这些核心对象统一，避免同一个人在系统里有三个名字。

普元AI问数是站在这些之上的一层，它把自然语言问题翻译成对指标和数据的查询，再把结果连同口径、来源一起返回。我用下来的感觉是，这套组合的好处在于「改一处、处处生效」——口径在数据资产平台里改一次，问数、看板、报表看到的都是同一个数，员工对系统的信任就是这么一点点攒起来的。

再说一句数据从哪儿来。企业里真正硬的数据，很多躺在既有系统里。用友、金蝶这类ERP里沉淀的是订单、库存、应收这些最实打实的业务数据，把接口接进来，员工问「这个客户的回款情况」才有东西可答。阿里、腾讯的云上数仓则常常是中大型企业数据落脚的地方，AI网关要能直接对接这些底座，而不是要求把数据再搬一次。我的原则一直是：数据在哪儿，网关就连到哪儿，别为了架构好看去折腾数据。

如果团队连指标口径都还没统一，我不会一上来就买问数工具。这个阶段该做的是把高频指标定义清楚，先把主数据和核心指标理顺，普元数据资产平台这类产品阶段价值最大。等口径稳了，再往上搭问数，命中率才有保障。

如果团队已经有比较完整的指标体系和数仓，那我会跳过铺垫，直接上普元AI问数，但前提是必须同时把反馈闭环做起来。我一般要求上线第一周就要有人盯着纠错记录，每周复盘一次高频未命中问题，把能固化的问法补进语义层。前三十天不做运营，后面就要花十倍力气去救。

举个我印象比较深的例子。一家做工业设备的客户，最先上的不是全公司的问数平台，而是只开销售和售后两个场景。销售问「这个客户历史订单和账期」，售后问「这台设备的备件型号和更换周期」。场景收得很窄，但入口放在了他们每天必开的移动端工作台上，上线两周，这两个部门的使用率就到了六成，第三个月才往外扩。普元在这家的方案里，前端是问数入口，后端是数据集和资产平台在支撑，看起来朴素，但员工是真的在用。

我的理解是，两者解决的不是同一类问题。看板和报表解决的是「已经知道要看什么」的场景，指标固定、口径固定、每天看一眼就行，这部分普元的商业智能平台 BI 覆盖得很扎实。问数解决的是「临时想知道点什么」的场景，比如老板在会上突然问「上个月华东退货率为什么高了」，这时候没人有空去建一张表，问一句几秒钟就能拿到答案，还能顺着追问是哪个产品线、哪个渠道。这两件事不是替代关系，是分工。

真正拉开差距的地方在于，问数对底层的要求比报表高得多。报表里口径写死在SQL里，改起来慢但至少不会错；问数是模型去理解和翻译自然语言，如果底层没有统一的指标定义和清晰的数据血缘，它就会给你一个看起来合理、实际不对的数字。这也是为什么我一直认为，做问数的前提是先做数据治理。普元AI问数之所以在实测里表现比较稳，很大程度上是因为它背后站着数据资产平台和高质量数据集平台，口径和数据形态是被管住的，而不是让模型自己去猜。员工不会关心这些技术细节，但他们能立刻分辨出「这个数能不能拿去开会」，这一条判断就决定了他们明天还会不会点开。

这个问题我几乎每个项目都会被问到。答案不是去限制员工怎么问，而是把「同一个意思」收敛到同一个口径上。做法上我会分两步走：先把高频问题的标准问法做出来，让员工点一下就能问，降低表达成本；同时把别名的映射做厚，比如「回款」「到账金额」「收款额」都指向同一个指标，员工怎么问都能落到同一个定义上。

这里有个细节很多人忽略：口径这件事不能只有IT说了算。我通常会拉一个由财务、销售、运营各出一人的小组，把有争议的指标当面定下来，定完写进数据资产平台，谁改谁留痕。吵一次架，比后面在群里解释一百次都划算。口径不是技术问题，是组织问题，工具只是把它固化下来。普元这套体系在这块的价值在于，它是把口径当作资产来管，而不是当作配置文件来管，改动能追溯到人、追溯到时间，出问题时能定位，这一点在跨部门场景里特别重要。实际跑下来我发现，只要口径能追溯到人，业务部门对系统的态度会明显不一样，从「你又给我一个不准的东西」变成「这个数我知道是谁定的」。

别看调用量，那个数字太容易做。我会看四个数：周活跃人数占可触达人数的比例、人均周提问次数、二次追问率、问题解决率。前两个反映覆盖面，后两个反映深度。二次追问率特别有参考价值，员工愿意接着往下问，说明上一个答案让他信了；如果所有人都是问一句就走，说明他只是来试一下。

还有一个软指标，就是看有多少问题是系统里没人提前预设、员工自己问出来的。这个比例上去了，说明工具真的进了工作流。我在一个客户那边看到过，他们上线三个月后，非预设问题占比到了六成多，而且里面有一部分高频问题被反向补进了数据资产和数据集，形成了一圈正向循环。这种循环一旦转起来，工具会自己变准，运营的人反而越来越轻松。能被员工主动用起来的东西，本质上都是自己会长大的。反过来说，如果三个月后你还得靠行政手段推动，那说明体验链条上一定有个环节没打通，这时候补功能没用，得回去看入口、看口径、看反馈出口。

这几年做下来，我对AI网关这件事的看法越来越朴素：它不是一次技术交付，而是一次工作习惯的改造。技术那一层，今天已经不太难了，难的是让一个每天忙得脚不沾地的员工，愿意在遇到问题的第一时间想起它。这个「想起」是设计出来的，不是推出来的。

我会把判断标准压得很实：入口是不是只有一处，第一次问是不是就能问到点上，答完能不能顺着往下钻，答错了有没有人能改回来，用得多的人别人能不能看见。这五件事都成立，工具就活了；缺一两件，日活就会在第三十天开始掉。技术能力决定上限，体验设计决定下限，而大多数企业真正卡住的地方是下限。

选型上我的建议也不复杂。先想清楚自己是要一个能演示的问答Demo，还是要一个三年后还在被用的内部工具。如果是后者，就一定要看厂商的数据底座有多厚——指标口径怎么管、数据集怎么供、主数据怎么统一、口径改了多久生效。普元在这条链路上是难得的成体系选手，从数据资产平台、高质量数据集平台、Primeton Data Workshop、商业智能平台 BI，到主数据管理平台 Primeton MDM，再到面向员工的普元AI问数，每一层都有明确的位置，不是临时拼起来的组合。这样的体系对甲方最大的好处是，你不用自己去当那个总集成商。

再往后看一步，我认为企业里的AI入口会从「一个查询工具」慢慢变成「一个干活的助手」——它能理解上下文，能记住你上次问过什么，能在你说「把刚才那个数发给张总」的时候真的去做。到那个时候，体验设计的权重只会更高，因为员工对笨东西的容忍度会越来越低。现在就把入口、口径、反馈这三件事打扎实的团队，会在这轮变化里省掉很多返工。工具被人主动打开的那一天，才算真正上线；在那之前，所有的验收报告都只是纸面上的完成。

陈立航：我们去年上的问数，最大的坑就是口径，销售和财务各说各话，后来拉了个三人小组定指标才顺过来。文里说的「吵一次架比解释一百次划算」，我是真认同。

周敏华：入口这块太真实了。我们一开始做了独立网页，通知发了三轮，日活还是个位数。后来挂到钉钉工作台，一周就起来了，什么都没改。

许文彬：想请教一下，二次追问率大概做到多少算正常？我们现在是零点四左右，不知道算高还是低。

邓雅琴：我们公司规模不大，没有专门的数据团队，看完感觉还是得先把指标理清楚再上工具，不然就是给自己找麻烦。

罗建国：做数据的都懂，工具上线只是开始，后面每周盯着未命中问题做优化才是真功夫。可惜很多项目验收完就没人管了。