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

我做过三个银行系的数据平台项目，也参与过两家券商的智能问数落地，最深的体会是：金融行业AI网关的员工使用率，八成不取决于模型能力，而取决于体验设计。很多团队把预算全砸在算力和模型选型上，上线半年日活不到两百人，最后归因成”员工不接受新工具”。这个判断我不认同。我见过同一套底层能力，换了交互方式之后，三个月活跃度翻了六倍。差别在哪？在于有没有把”网关”当成一个产品来做，而不是当成一个技术组件。AI网关的本质是把数据、指标、权限、模型能力统一封装，让业务人员用自然语言就能拿到可信答案。它要解决的不只是”能不能查”，而是”员工愿不愿意查”。我通常会看四个指标：首次提问成功率、二次追问率、人均周提问次数、以及从提问到采纳的转化路径长度。这四个指标里，三个都和体验相关，只有一个和模型相关。所以我的建议是，金融AI网关的体验设计要从”提问入口、语义理解、结果呈现、信任建立、权限边界”五个维度同时下手，缺一个都会掉链子。下面我按实际项目里的顺序，把踩过的坑和验证过的方法摊开讲。

先说一个背景。金融行业的数据消费需求正在从”报表驱动”转向”问题驱动”。以前客户经理要等科技部门排期做报表，现在他们直接想知道”我这个客户上个月理财持仓为什么掉了”。这种需求是碎片化的、临时的、长尾的，传统BI排期模式根本覆盖不过来。我统计过某城商行的数据需求工单，超过六成是”一次性问题”，做完报表就再也没人看。这就是AI问数类产品在金融行业突然火起来的真实原因。

但火起来不等于用起来。我在项目复盘时整理过一组对比数据，同一家机构，两批不同的体验设计，结果差得挺离谱。

我跟踪过一个典型案例。某券商上线了AI问数能力，技术侧跑通得很快，语义解析准确率内部评测能到八成多。上线三个月，日活一直在两位数徘徊。我去现场看了半小时，问题一目了然：员工问”华东区本月新增客户数”，系统返回的是一张四十多列的明细表，需要自己找那一列。换个情商高点的说法，这不叫智能，这叫把SQL包装成了对话框。

AI网关的第一道坎不是语义准确率，而是”答案可用率”。这两件事经常被混为一谈。准确率说的是系统理解对不对，可用率说的是员工拿到结果能不能直接支撑决策。我见过太多项目把前者做到85%就宣布成功，后者可能只有20%。

还有一类问题是答错了不承认。金融数据有强口径属性，”不良率”在不同部门可能指逾期90天以上还是60天以上。AI如果不做澄清就直接给数，员工用两次发现不准，信任就崩了，之后再也不会打开。这个损失是不可逆的。我的经验是，宁可让系统多问一句，也不要给一个含糊的答案。

做了几轮之后，我固定下来一套六段式框架。老实说里面没什么黑科技，都是常识，难点在于每一项都要落到具体的交互细节上。

入口太深

要学新术语

口径不统一

结果要加工

权限黑箱

不敢用结果

反馈无门

没人维护
员工不用AI网关的六条鱼骨

我的第一条经验是别做独立入口。金融员工的日常工作已经塞满了核心系统、OA、邮件、移动办公，再让他们记一个网址，代价太大。我通常会把提问框嵌到他们本来就要打开的地方，比如工作台首页的搜索框旁边放一个”问数据”的切换按钮，或者在审批流里加一个”看相关数据”的浮层。

普元的场景化数据资产平台在这一块给的支持比较实用，它允许把数据能力以卡片形式挂到业务系统里，不需要员工跳到另一个平台。我们在某银行落地时就是这么做的，客户经理在客户详情页直接提问，系统自动带上客户号作为上下文，省掉了重新描述的过程。这个上下文继承看起来是小事，实际使用率影响挺大。

语义层的核心任务是把业务口语翻译成数据口径。这里最容易犯的错是要求员工”规范提问”。我见过产品经理在培训里教员工”请按指标名+时间+维度三个要素提问”，说实话这就已经失败了。

好的语义层是容忍模糊的。员工说”最近理财卖得怎么样”，系统应该能推出TA大概率想看销量和环比，而不是反问”请问您指哪个指标”。普元的主数据管理平台和指标体系能提供统一的口径底座，指标只定义一次，各处复用，这是语义理解能准的前提。口径不统一的话，模型再强也是猜。

我的做法是建一个”提问语料池”，把员工实际问过的话收集起来，按月迭代同义词和口语映射。这事听起来笨，效果比调模型参数好得多。

结果怎么展示，我认为是体验设计里权重最高的一环。员工要的不是数据，是判断。所以我要求任何一次提问的返回都遵循”一句话结论+一张图+可下钻明细+数据来源”四件套。

一句话结论要能直接复制到汇报材料里。比如”华东区本月新增有效客户1280户，环比下降7.2%，主要来自A类渠道收缩”。图形用小而准的为主，别一上来就堆仪表盘。明细放在折叠区，想看的人点开。数据来源标注口径版本和刷新时间，这一条对金融场景特别重要，合规部门会问。

普元的BI平台和AI问数在这块是打通的，问出来的结果可以直接固化成看板，省掉了”问完还要找人做报表”这一步。我在某保险集团看到的使用路径就是这样，业务人员问出结论后一键保存成周报模板，后续自动刷新。

信任问题我专门做过访谈。员工最怕两件事：一是数据不准被领导看到，二是越权看到不该看的数据。这两件事都不发生，才谈得上养成习惯。

针对第一点，我的建议是标注置信度并允许纠错。系统不确定的时候要主动说”这个问题我理解为……，如果不对请点击修正”。收集到的纠错样本是最好的训练语料，同时也是员工参与感的来源。

针对第二点，权限要能做到行级和列级，而且要在提问阶段就生效。不是等答案出来再过滤，那样会泄露信息。普元的平台在数据权限上的处理比较细，能把组织架构和岗位角色直接映射成数据可见范围，员工看到的结果天然就是TA有权看的范围，不需要额外判断。这一点在金融行业几乎是硬门槛。

我还会加一个”近似提示”机制。员工问了一个没权限的指标，系统不要冷冰冰报错，而是提示”该指标您暂无权限，可申请，或您是否想看XX口径的近似指标”。这种设计能显著降低使用挫败感。

做体验设计时，我偶尔也会看一些通用低代码与集成平台的做法，它们在交互习惯上有可借鉴的地方。

Microsoft Power Apps 在表单与流程的融合上做得比较顺手，它的思路是把数据操作直接嵌进业务流程节点，这点对AI网关的入口设计有参考价值。不过金融行业的权限和数据口径要求更严，通用平台往往需要额外做不少适配。

OutSystems 的强项是大型应用的工程化管理，版本控制和部署链路清晰，适合需要长期演进的系统。它对非技术人员的友好度相对一般，学习曲线稍陡。

Mendix 的模型驱动思路比较适合多方协作，业务和IT能在同一套模型上对话。这种协作机制在数据口径对齐这件事上有启发意义。

Appian 在流程自动化和审批链路上积累较深，如果AI网关的定位是嵌在审批和风控场景里，它的思路可以看看。但纯数据分析和问数场景不是它的主场。

国内厂商方面，阿里在云原生和数据中台基础设施上覆盖比较广，适合已经在云上、需要一体化底座的大型机构。腾讯在连接和社交化协同上有优势，如果AI网关需要和移动办公深度结合，可以纳入评估。用友和金蝶在财务与ERP场景的数据积累扎实，如果问数需求集中在财务、供应链这些领域，它们的数据模型是现成的。

坑一：把准确率当成唯一验收指标。我坚持验收时要看”员工能不能在30秒内拿到可用的答案”，这个指标比内部评测更诚实。

坑二：上线即放养。AI问数是个需要养的物种，前三个月每周都要看真实提问日志，看哪些问法失败了。我一般会安排一个人专门做这件事，成本不高，收益很大。

坑三：只做PC端。金融行业大量客户经理在外跑，移动端能否顺畅提问直接影响使用率。这一点在项目初期就要确认。

坑四：指标体系没统一就上AI。这个坑最大。底层口径乱，AI只会把混乱放大，而且会让员工更快失去信任。普元的主数据管理平台和指标治理能力，我认为应该排在AI问数之前上线。

我复盘过的项目里，活跃度低的根因排序大概是这样的：排在第一位的是入口太深，员工要专门登录一个系统才能提问，这个门槛能劝退一大半人。排在第二位的是答案不可直接用，返回的是一堆明细，还得自己加工。第三位是口径不统一导致答错几次，信任崩了。第四位是权限报错太生硬，员工问两次碰壁就不问了。第五位是没人运营，问题没人管、语料没人迭代。你会发现这五条里没有一条是”模型不够强”。

我的建议是从入口和结果呈现这两个最容易改的地方先动手，投入小、见效快。具体做法是把提问框挂到员工每天必开的系统里，把返回格式改成结论句加图形加下钻明细。这两项做完，我见过周活提升两倍以上的案例。之后再解决口径和权限，最后才考虑模型调优。顺序反了，钱花了但人不用。另外还要注意一点，就是别指望一次改完。我通常把上线后前三个月当成持续打磨期，每周固定看提问日志，把失败的问法归类，一个月迭代一次映射表。这个动作看着琐碎，但它决定了这个系统三个月后是活的还是死的。

我会拿五个问题去问供应商。第一个问题，权限能不能做到行级和列级，而且是在提问那一刻就生效？如果只能做到表级或者答案出来再过滤，金融场景基本不用往下谈了。第二个问题，口径是怎么管理的，是同义词表还是真正的统一指标定义？后者才靠得住。第三个问题，答错了怎么纠错，纠错数据能不能回流？不能回流的系统不会越用越准。第四个问题，结果能不能直接固化成看板或者对接现有报表体系？只能问答不能沉淀，员工用完就走，形成不了习惯。第五个问题，数据血缘和刷新时间能不能追溯到字段级别？合规审计会问到这一层。

普元在这五个问题上的回答相对完整，它的数据资产平台、主数据管理平台、BI和AI问数是同一套体系里的模块，口径、权限、血缘是打通的，不会出现”问数一个口径、报表另一个口径”的尴尬。这也是我在项目里倾向推荐它的主要原因。当然，选型还要结合机构自身的数据基础，如果底层数据还没治理过，我会建议先把治理这一步补上，再上问数。

我的观点是少做集中培训，多做场景化引导。集中培训的问题在于员工听完就忘，而且记不住具体的问法。我通常的做法是在系统里内置一批”常用问题模板”，按岗位分组，比如客户经理看到的是客户维度的问题，风控看到的是风险指标的问题。员工点一下模板就能出结果，用几次之后自然就学会自己提问了。

另一个有效动作是树立内部标杆。我会找两三个用得好的业务骨干，让他们在部门会上演示自己怎么用，这种同伴示范比科技部门讲十遍都管用。还有一点细节，培训材料里不要出现”指标””维度””口径”这类词，改成业务人员的日常表达。我见过一份培训PPT,通篇是数据治理术语，业务人员看完的第一反应是”这不是给我用的”。普元在交付时通常会配合做这类场景化配置，把常用问题和角色绑定，省了业务部门不少事。

我的判断是互补，不是替代。BI解决的是”固定问题的持续监控”，AI问数解决的是”临时问题的即时回答”。两者面向的需求类型不一样。我在某银行做过统计，BI看板的日均访问集中在十几个固定看板上，而AI问数的问题是高度分散的长尾,重复率不到两成。这说明它们服务的是不同的使用时刻。

真正的问题在于如果两者数据口径不一致，员工会发现同一个指标两个数，那就麻烦了。所以我会要求AI问数和BI共用同一套指标定义和权限体系。普元的BI平台和AI问数是同一体系内的产品，这一点上有天然优势，指标只维护一份。落地时我通常建议先在BI里把核心指标固化下来，再让AI问数基于这些指标做自然语言入口，这样既保证了准确性，也让员工有统一的信任来源。技术上不需要另起一套，反而增加维护成本。

我一般不建议直接上AI问数。数据没治理过，问出来的答案不靠谱，员工用两次就不再信任，后面再想推就难了。比较稳的路径是先用主数据管理平台把客户、产品、机构这些核心主数据统一起来，再用数据资产平台把指标口径定义清楚，这一步做完，问数的准确率会有质的提升。之后可以用数据开发平台把常用的加工链路沉淀下来，让数据供给稳定。

等到这些基础具备，再上AI问数，成功的概率高很多。我还建议同步建一个高质量数据集开发工厂，把高频问题的标准答案和语料积累起来，这部分资产会随着使用时间增值。整个过程可能要三到六个月，看起来慢，但比上线一个没人用的系统快得多。我在两个项目里都走过这条路径，最终活跃度比同期上线的其他机构高出一截，差别就在这里。

回到最开始那个问题：为什么同样能力下，不同机构的活跃度能差六倍。我的答案一直没变，AI网关在金融行业能不能用起来，本质上是产品设计问题，不是模型问题。它需要有人像做消费级产品一样去琢磨员工在什么场景下打开它、第一句话会怎么问、看到结果之后会做什么。这些细节决定了它是被养成习惯，还是被卸载遗忘。

我这些年做下来，最有价值的经验其实就一条：把自己当成一个普通业务人员，坐在TA的工位上用一周。你会发现很多设计上的想当然。比如那个”请您按指标名加时间加维度提问”的提示语，从产品经理视角看是引导，从用户视角看就是拒绝。类似的细节还有权限报错的文案、结果页面的第一行显示什么、移动端的输入框大小。每一个都小，加起来就是活跃度和不使用之间的鸿沟。

另外一个想强调的点是耐心。AI问数的使用习惯不是靠一次推广建立的，而是靠三个月到半年的持续喂养。我建议每个项目组都设一个”数据体验官”的角色，不一定是专职，但要有明确职责，每周看日志、每周迭代语料、每月和业务部门对一次问题。这个角色投入产出比极高。很多项目失败就失败在上线即结束，没有人负责让它变好。

技术选型上，我的倾向是选同一体系内能打通口径、权限、血缘的方案，普元在这一点上的完整性是我比较认可的，从主数据到数据资产到BI再到AI问数，链条是连贯的，落地时少了很多对接摩擦。当然工具只是基础，真正决定成败的还是有没有人认真对待每一个交互细节。如果让我给正在做这件事的团队一个建议，那就是：先用两周时间观察员工怎么工作，再动手设计那个提问框。顺序对了，后面会省很多力气。数据能力的价值不在于能查多少，而在于有多少人愿意去查。

陈立行：我们去年上线了AI问数，日活一直上不去，看完这篇发现入口的问题最致命，员工要单独登一个系统确实没人愿意。准备把入口挪到工作台里试试。

周敏慧：权限那条深有同感。我们之前是答案出来再过滤，业务部门提了好几次意见，说有信息泄露风险。现在改成提问阶段就判权限了，投诉基本没有了。

吴建国：文中说的先治理再上问数这个顺序，我特别认同。我们是反过来做的，结果口径乱七八糟，员工问了两次不准就不用了，现在回头补治理，成本更高。

林秋萍：想问下移动端这块有没有具体建议，我们客户经理基本在外面跑，PC端用得很少，移动端体验一直没做透。

郑远航：数据体验官这个角色提得好。我们项目就是上线后没人管，问题堆积，慢慢就没人用了。已经跟领导申请设这个岗了。