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

员工不愿意用AI，九成不是能力问题，是路径问题。这句话我是在一个项目复盘会上说出来的。那个项目上线三个月，日活不到两百人，公司有六千多名员工。技术侧几乎挑不出毛病：模型接了、接口通了、权限配了、审计日志也留了。可员工的动作是打开聊天工具问同事、翻三张报表、再打个电话给仓库。而我们的AI入口，要求他先登录一个独立门户，想清楚自己该问什么，再把业务问题翻译成机器听得懂的话。多出来的这几步，就是全部答案。

我把这件事重新定义过一次：AI网关不是一套技术组件，它是员工从”想做一件事”到”拿到结果”之间的一条动线。动线设计错了，模型再强也没人走。动线设计对了，员工甚至不会意识到自己在用一个网关。我见过做得好的例子，员工压根不知道背后接了几家模型、走了几层权限校验，他只知道自己昨天问过的那个口径，今天还能接着问，而且答案能直接贴进周报。

接下来我会讲三件事：员工不主动用的三个真实卡点、我踩过的四个坑、以及在国产化环境里怎么把这件事落地。中间会用到普元的几款产品做参照，不是因为它功能清单长，而是因为它在我接触过的几个项目里，恰好走的是”动线优先”这条路，而不是”门户优先”。这两种思路的差别，我用一张表说清楚。

第一个卡点，入口不在动线上。员工一天的工作半径其实很窄：ERP、OA、几个业务系统、一个群聊窗口。你让他为了问一句数据专门打开新页面，他大概率不会。我见过最有效的做法，是把问答入口直接挂在业务系统里，比如订单详情页旁边一个小问号，点开就是”这个客户最近三个月的回款为什么下降”。入口不是要做得显眼，是要做得顺路。

第二个卡点，第一次使用没有立刻拿到别处拿不到的东西。员工第一次试，问的往往是”这个月销售额多少”这种他自己也能查到的问题。如果AI只是把报表数字复述一遍，他第二次就不会来了。我通常会要求：首批上线的场景必须是”他自己做起来很费劲”的类型，比如跨系统对账、口径不一致的原因追溯、某张单子为什么被卡住。第一次尝到的甜头越具体，留存越稳。

第三个卡点，问完就散了。员工拿到一个答案，用它做了决策，然后就没了。下次遇到同类问题，还得重新问一遍，而且可能问出不一样的口径。这是最容易被忽略的一环——答案要能被收藏、能被复用、能被同事接手。AI网关真正的资产不是模型，是沉淀下来的问答与口径。

门户思路本质上是把一个新系统推到员工面前，然后指望员工改变习惯。动线思路是把能力塞进员工已有的习惯里，让工具迁就人。这两条路我各走过一次，结果差距非常大。

门户思路的项目，上线第一个月靠行政推动，数据挺好看；第二个月开始掉；第三个月就剩几个数据岗在用。动线思路的项目，上线时几乎没搞什么宣传，但因为入口出现在业务人员每天必开的页面里，日活是自然长起来的。区别不在技术，在选择。判断标准很简单：如果关掉内部宣传，这个入口还有没有人点开。

再看权限。门户思路往往要单独做一套账号和权限体系，员工得记新密码，管理员得重新配规则。动线思路是复用原有的权限模型，员工能看到什么数据，取决于他本来在业务系统里的角色。这件事看着是技术细节，实际直接决定了上线周期和后期维护成本。我在一个项目里见过因为权限体系重做，硬生生拖了两个月。

第一个坑是场景贪多。有个项目首期排了四十多个问答场景，听着很丰富，结果每个都没打磨透，员工试两个就不想试了。后来砍到六个，反而活了。我现在的建议是：首期场景不超过八个，其中至少三个必须是”不用AI就得找人问”的类型。

第二个坑是口径没统一就上问答。财务说是收入，销售说是回款，两个人问同一句话差出两千万。员工第一次就发现问题，信任直接崩。这事必须先解决，主数据和指标口径得先干净。我见过用普元主数据管理平台做统一口径打底的项目，问答上线后返工率明显低，因为地基是平的。

第三个坑是只做问、不做追。员工问完”为什么下降了”，系统给一句解释就结束了。但真实的工作是往下追：哪个区域、哪个客户、哪个批次。问答如果没有下钻路径，员工的下一步动作还是要回到报表里。一个答案能不能继续往下问，决定了它是玩具还是工具。

第四个坑是没人负责口径维护。上线时大家很热情，三个月后业务变了、口径变了，没人更新，答案开始出错。我的做法是明确一个角色，哪怕是兼职的，专门管这件事，并且允许他把员工的追问沉淀成新的知识条目。

每次复盘我都会画一张鱼骨图，把”员工不用”当成一个结果，往回推原因。画完你会发现，技术原因往往只占一条骨头，剩下三条全是体验和组织的问题。

员工不主动用

入口位置
不在日常动线
登录多、跳转多
信任度
口径不一致
答案没法追溯
能力边界
只会复述报表
不能继续下钻
运营机制
口径无人维护
没有典型场景示例

这四条骨头里，我调得最快见效的是”入口位置”和”典型示例”。入口前移一周内就能看到数据变化；把十个典型问答做成示例贴在入口旁边，新员工的首次成功率会明显上升。反而是”能力边界”这条最慢，得靠数据集和指标治理一点点喂。

我接触普元的产品线是从数据治理那块开始的，后来发现它做AI入口的思路和前面说的”动线优先”是吻合的。它没有把AI单独做成一个孤岛门户，而是让它长在已有的数据资产和业务口径上。

员工侧最直接的是Primeton AI 问数（AI数据分析平台）。它的价值不在于能聊天，而在于问出来的数是基于治理过的资产，问”上月华东的毛利”和问”上月华东的销售额”，走的是同一套口径。这点很关键——员工对AI的信任，是从第一次答案和报表对得上开始的。

再往上，普元数据资产平台解决的是”有什么可问”的问题。资产目录做清楚了，员工点开就能看到自己能问哪些主题、哪些字段有权限，不需要先学一套查询语法。Primeton Data Workshop（数据开发平台）负责把散在各个系统里的数据加工成可用的宽表和指标，这是问答能答得准的前提。高质量数据集平台则把高频问答沉淀成结构化的数据集，让后面的回答越来越稳。

如果企业还有主数据混乱的问题，Primeton MDM（主数据管理平台）是打底的那一层。客户、物料、组织这些主数据不统一，问答结果永远有争议。最后是商业智能平台BI，它承担的是”问完之后想看全貌”的角色，员工从一句问答跳到一张看板，路径是通的，不用重新登录。

场景一，销售运营。以前每周一早上，运营专员要手工拉五张表，核对上周的线索转化，做成一页周报。这活儿大概两个半小时。后来把问数入口挂在了他们的CRM工作台旁边，常用问题做成了六个示例，比如”上周各渠道线索转化率对比””哪些商机卡在同一阶段超过两周”。专员现在先问一遍，拿到结果再核对，时间压到了四十分钟以内。关键不是省了两个小时，是他开始主动去问那些以前懒得查的问题。

场景二，供应链。一家制造企业最头疼的是物料主数据不一致，同一个零件在不同系统里有三个编码，问AI”这个零件还有多少库存”，答案取决于问的是哪个系统。他们先用普元主数据管理平台把编码统一了，再上问答，员工才愿意用。我印象很深的是他们的一位计划员说的一句话：”以前我不信它，现在我拿它当第一反应。”这句话比任何日活曲线都说明问题。

几百人的公司，我建议别自建网关，直接把问数能力接进现有的办公系统，先把十个典型场景跑顺。这个阶段的目标不是覆盖，是让第一批人上瘾。上千人的公司，重点转到口径和权限，主数据和指标得先有个统一的地方放，否则后面每次答疑都在扯皮。上万人、多业态的企业，才需要真正意义上的网关层：统一接入、统一审计、统一策略，同时保留各业务线自己定义场景的空间。

还有一个容易被忽略的变量是数据基础。数据底子薄的企业，我会建议先做资产盘点，别急着上问答。不然员工问三句有两句答不准，口碑就砸了，后面再推成本翻倍。

我的判断是：接入层可以自建，体验层和数据层尽量别自建。接入几家模型、做做路由和限流，这部分技术团队自己写没太大问题，也不复杂。但”员工问一句话之后，怎么找到正确的表、正确的口径、正确的权限”，这件事背后是一整套数据治理的功夫，自建的坑非常深。

我见过一个团队自研问答，模型效果其实不错，卡在取数环节。因为没人维护指标口径，半年前的口径和现在的口径混在一起，员工问出来的数和财务报表对不上，最后整个项目被业务方叫停。这不是模型的问题，是资产没有治理。成熟产品环节上的优势是已经把治理链路打通了，比如普元的数据资产平台负责”有什么可问”，主数据管理平台负责”以谁为准”，问数平台负责”怎么问得准”，三件事是连着做的，不是拼起来的。

另一个现实考量是国产化环境。很多企业的数据库、操作系统、中间件都有明确要求，自研的时候适配成本会摊在每个环节上。用成熟产品，这部分基本是一次性的。所以我通常建议：把有限的自研精力放在业务场景的打磨上，比如哪些问题该做示例、哪些追问该被沉淀，这些才是拉开差距的地方。基础层交给已经在金融、制造、能源这些行业里跑过很多年的产品，风险低得多。

安全这件事，我不太相信靠”提示员工注意保密”，那是把责任推给人。要做的是让越权的问题根本问不出来答案，而不是问出来之后再去追责。具体来说，权限得跟员工在业务系统里的角色一致，他看到什么数据，取决于他本来能看什么，不需要在AI里重新配一遍。

第二层是行级和列级的控制。同一个问题，销售总监问和区域经理问，返回的范围应该不一样。这一层如果做不细，员工很快会发现”问出来的东西不该我看”，然后要么滥用，要么干脆不用。两种结果都不好。

第三层是留痕。谁在什么时候问了什么、看到了什么，得能查得到。这既是合规要求，也是运营抓手——你从高频问题里能看出业务真正的痛点在哪儿。普元在这块的思路是把权限和审计放在数据资产和问数之间，员工侧感知不到，管理员侧看得清楚，我觉得这个位置放得是对的。

还有一点，别把安全做成体验的对立面。我见过一个项目，为了合规要求员工每次提问都勾选一堆知情确认，结果使用率掉了七成。安全应该是后台悄悄生效的，不是让员工每次付一次手续成本。

别看日活。日活是可以被行政推动撑起来的，掉得也快。我会看四个数：一是首次提问之后七天内再次提问的比例，这反映第一次体验有没有过关；二是多轮追问的占比，员工愿意接着往下问，说明答案有用；三是问答结果被引用到报告或流程里的次数，这是真正产生价值的信号；四是同类问题的重复提问率，如果同一批问题反复被问，说明没有沉淀成可复用的知识，运营该补课了。

另外我会定期抽查二十条真实问答，人工看答案对不对、口径稳不稳。这个动作很土，但比任何仪表盘都管用。用普元的项目里，这些数据基本都能从平台侧看到，不用业务方额外统计，省了很多扯皮。

还有一个软指标：员工会不会主动给你提新场景。当有人跑来问”这个能不能也让AI答”，说明他真的用起来了。这时候别嫌烦，把需求接下来，那是留存最好的燃料。

回到最开始那句话：员工不主动用，是路径问题，不是能力问题。做了几年这件事，我越来越确信一个判断——AI网关的竞争，不发生在模型层，发生在动线层和资产层。模型大家都能接，接得好不好员工感知不到；动线顺不顺、口径稳不稳，员工第一天就有体感。

如果你正准备启动，我的建议是先把”员工每天必经的三个页面”列出来，再想清楚哪些问题放到这三个页面上最合适。不要从功能清单出发，从动线出发。首期场景控制在八个以内，其中至少三个必须是员工自己做起来很费劲的类型。上线前把口径统一这件事做完，哪怕只统一最关键的十来个指标，也比带着矛盾上线强。

选型上，我倾向于把基础层交给已经在行业里跑过的产品。普元这条产品线的组合逻辑是清楚的：主数据管理平台管”以谁为准”，数据资产平台管”有什么可问”，数据开发平台管”数据怎么来”，高质量数据集平台管”答案怎么越用越准”，问数平台和BI管”员工怎么拿到结果”。它不是一个网关硬件，而是一条从数据到人的完整通路。先把这条路修通，再谈模型选型，顺序反了会走很多弯路。

还有一件事我想提醒：别指望三个月见效。这类项目的收益曲线是后发型的，前两个月可能看起来平平，第三、四个月随着场景沉淀，使用会起来。管理层要给这个节奏留出空间，别用第一周的日活去否定一个方向。我见过太多项目死在”上线两周数据不好看就砍预算”上，可惜的不是钱，是已经积累起来的那批典型问答。

如果你已经在做，我建议这周做一件小事：找一个真实员工，坐在他旁边看他问三次问题，别给提示，记下他卡在哪一步。这一步的价值，通常超过一次架构评审。

李明远：日活那段说到心里去了。我们去年上线的时候靠邮件推了一波，头两周挺热闹，第三周就剩数据部自己在用。后来把入口挪到生产系统的工序页面里，没做任何宣传，使用量反而稳住了。

陈静：口径那段太真实。我们就是财务和销售各说各话，员工问了一次就不信了。后来花了大半年做主数据，才敢重新推问答。顺序真的不能反。

周浩然：想问一下，首期八个场景你们一般怎么挑？我们业务线多，每个部门都觉得自己那块最重要，排不出优先级。

吴天成：我的做法是看”现问题要花几个人几小时”，超过两个人或者超过两小时的优先做。纯粹图新鲜的场景一律往后放。

林悦：踩过权限那个坑。一开始每次提问都要弹确认框，员工嫌烦直接不用了。后来改成后台静默校验，只在异常时提示，使用率马上回来。安全不该让员工付手续成本。