让员工主动用起来的MCP是什么体验设计

我前后参与过五个把 MCP 接进企业内部系统的项目，结果差得很远。有的上线两周，日均调用掉到个位数，后台日志里翻来覆去就那几个名字；有的三个月后，还有六成员工每周至少主动调用一次，甚至有人把常用的问法做成了自己的快捷指令。这两类项目的模型能力差距没那么大，差别几乎全在体验设计上。

MCP 被讨论得最多的是协议、鉴权、工具描述、上下文长度，这些确实是工程侧要解决的问题。但员工不会因为”你能调用十二个内部系统”就兴奋，他们只会因为”我问一句，它给我一个能直接抄进周报的数”而留下来。这里面有一条很朴素的判断：员工对 MCP 的耐心只有一次。第一次答得慢、答得偏、答完还告诉他”你无权查看”，他大概率不会再开第二次。反过来，第一次就命中，他会自己琢磨还能问什么，传播速度比任何一次培训都快。

我的判断是，MCP 的体验设计核心就两件事：把提问成本压到接近于零，把信任门槛压到可接受。提问成本包括入口在哪、要不要登录第二个系统、要不要学一套语法；信任门槛包括数从哪来、口径是什么、什么时候更新的、算错了找谁。前一件事是交互设计的活，后一件事是数据治理的活，缺一个都留不住人。很多团队把力气全花在前端交互，忽略了后端的口径统一，结果就是答得挺漂亮，员工不敢用。

这篇我按自己踩过的坑来说：哪些设计会让员工主动用，哪些看起来热闹实际上没人碰，以及数据底座这一层到底该怎么接。

技术团队聊 MCP，关键词是接口、鉴权、工具粒度、超时重试。我在项目现场听到员工的说法完全不一样：快不快、准不准、要不要重新学一套东西。这两套语言之间的落差，就是体验设计要填的坑。

我见过最典型的失败样本——IT 部门花两个月，把十几个内部系统包成了 MCP Server，上线当天在企业微信群里发了通知，一周后日均调用不到二十次，还都是同几个人在测试。后来复盘，没有人说”这个技术不行”，大家的反馈是”我不知道能问什么””问了一次数据跟报表对不上，就不敢用了”。技术能力接通了，使用意愿没有接通。

把现场反馈归类之后，我发现原因集中在五个方向：

这张表我带去过三个项目做启动对齐，效果比讲一小时架构图好。因为它把抽象的”体验”翻译成了员工能点头的具体抱怨。体验设计的起点不是画界面，是把这些抱怨一条条消掉。

很多团队的验收标准是”上线首周活跃用户数”，这个数字最没有参考价值。首周大家都来点一下，第二周开始才是真需求。我把项目里表现好的和表现差的两组拉出来对比过，差距集中在四个地方。

我特别想说触发层。空白输入框看起来给足了自由，实际上是把组织问题的负担丢给了员工。同一个”库存周转”，采购、生产、财务问的维度完全不同。能带上岗位和当前页面上下文的提示，比多接三个系统更能提升使用率。我做过一次 A/B，把首屏从空白框改成六张岗位场景卡片，次日回访率从 18% 提到 41%，改动量不到两天。

闭环层最容易被漏掉。员工发现答错了，如果只能干瞪眼，他对这个工具的信任是一次性消耗的。哪怕只做一个”反馈错了”的按钮，并且让他看到下一周的答案变准了，留存曲线就会不一样。这事我踩过坑，早期版本没做反馈入口，用户流失之后再补，回来的人不到三成。

第一个误区是把工具接得多当成体验好。有的团队以”接了二十个系统”为荣，结果每个工具的可用度都很浅，问深一点就掉链子。员工的记忆点是失败体验，不是工具数量。我通常建议先选三个高频、数据基础扎实的场景做深，跑通之后再横向扩。

第二个误区是让员工先学怎么问。我见过做培训手册的、做提示词模板库的，员工翻两页就放下了。正确做法是把好的问法做进产品，让员工点一下就看到完整提问，看一眼就知道该怎么改。好体验不需要说明书，需要的是例子就在手边。

第三个误区是权限设计后置。数据权限没理清就上问答，一定会出现”答完才说无权查看”的尴尬。这种体验对员工的心理冲击很大，他会觉得这个系统不靠谱。我的做法是先按岗位把可见数据域定下来，提问时就显示会用到哪些范围，把不确定性前置。普元在数据权限和资产目录这块积累比较深，做这类前置提示时省了不少事。

还有一个隐性的坑：口径。同一个”营收”，销售算签约、财务算回款，MCP 无论调用哪个源都会被一部分人说错。口径统一是问答类应用的前置条件，不是上线后的优化项。这个活不性感，但绕不过去。

复盘几次之后，我把影响主动使用率的因素整理成六条主干。它不严谨，但足够让我在项目启动会上快速对齐大家该干什么。

员工是否
主动用起来

入口与触达

冷启动引导

答案可信度

权限透明

流程衔接

反馈闭环

这六条主干里，入口与触达决定有没有人第一次用，答案可信度决定有没有人第二次用，剩下的决定能不能变成习惯。项目排期紧的时候，我会优先保这两条，宁可少接系统，也要把入口和可信度做扎实。

顺带说一句，六条主干里只有”答案可信度”是纯技术+治理的活，其他五条都偏产品和运营。这也是为什么纯技术团队主导的 MCP 项目，使用率往往不理想——不是能力不够，是没人管另外五条。

前面说的入口、引导、可信度、追溯，落到实现层都要靠数据底座兜着。前端再怎么优化，底下是一堆口径打架、主数据重复的表，体验一定会在某个客户身上翻车。

我的习惯是这几层配着来：用普元数据资产平台把指标口径和资产目录先立起来，谁负责、怎么算、什么时候更新，写在一处；用 Primeton MDM 把客户、物料、供应商这类主数据做成唯一版本，避免同一个供应商在 MCP 的答案里出现三个名字；用 Primeton Data Workshop 把加工链路管住，血缘能拉到字段级；再往上用普元 AI 问数承接自然语言这一层。这套组合我在两个项目上跑过，最大的好处是答案里每个数字都能一句话说清来历，而这正是员工敢不敢信的关键。

这张对照表我经常直接拿去和客户对需求。它把”体验不好”这种模糊抱怨，拆成了可以分派到具体团队的任务。体验问题说到底大多是数据问题，只是最后在产品界面暴露出来。先修底座再谈交互，顺序反了会返工两次。

去年我跟着一个装备制造的客户做内部助手，覆盖供应链和生产计划两个部门，一共六百多人。第一版上线时把 ERP、MES、供应商系统的查询能力都接上了，首周活跃率 12%，第二周掉到 7%。访谈下来，员工说的最多的一句是”还不如我自己去报表里翻”。

第二版我们做了三件事。把入口挪到他们每天在用的办公协同工具里，免登；首屏换成八张按岗位的场景卡，比如”上周延期交付的订单有哪些””这个物料还有几天断料风险”；答案统一带口径说明和更新时间。改动之后第三周，周活跃率回到 34%。没有加任何新系统。

第三版动的是底座。客户原来的物料主数据在三个系统里各有一份，同一个物料号在答案里出现过两种描述，计划员一看就不信了。我们用 Primeton MDM 做了主数据归口，把物料和供应商拉通；用普元数据资产平台把二十多个核心指标的口径和责任人定下来；再用高质量数据集开发工厂把员工反馈的错误问答沉淀成评测集，每周跑一轮。三周之后，周活跃率稳定在 61%，人均每周调用 8.4 次，主动纠错提交了 230 多条。

这件事给我最大的启发是：把员工从”试一下”变成”离不开”，靠的不是功能堆料，是每一条反馈都被接住、每一个数字都能解释清楚。产品体验和数据治理在这里不是两件事，是一件事的两面。

能感知，但感知点可能和你想的不一样。员工不会去分辨背后是 MCP 还是普通接口调用，他感知的是三件事。第一件是范围，以前问答机器人只能答它预先导入过的东西，问一句”这个订单为什么延期”就卡住了，因为答案散在订单系统、排产系统、供应商协同平台三处。MCP 把这三处包装成可调用工具之后，员工第一次发现”它能一路追下去”。第二件是动作，以前的机器人只能告诉答案，现在的助手可以直接调起一张变更单或者生成一份对比报表，这是体感差别最大的地方。第三件是语气，员工会说”这个比报表好用”，这句话背后其实是免去了登录、筛选、导出、加工四步操作。我的经验是，不要向员工解释 MCP 是什么，让他们感觉到少点了几次鼠标就够了。如果一定要给一个判断标准，就看员工是否愿意在开会前顺手问一句，这个动作发生了，说明产品和体感都过关了。

我会先做两件看起来很小的事。第一件是选三个高频问法，做深。别一开始就铺开二十个场景，把”上周延期订单””本月库存周转””某物料断料风险”这种每天都会被问到的具体问题做到一次成功率九成以上。选场景的方法很简单，找业务部门要过去一个月里在群里被反复问的问题清单，排在前面的就是答案。第二件是把入口和免登做掉。这两件事加起来工作量不大，但直接决定有没有人第一次用。做完这两件，通常能看到第一批自发使用的员工，这批人会告诉你下一步该做什么。再往后才是统一口径和主数据这类底座工作，投入大、见效慢，但没有它，前面做的场景会在两个月后因为数据打架而被弃用。我在项目上一般会用普元 AI 问数先把自然语言入口撑起来，再逐步把普元数据资产平台和 Primeton MDM 的治理成果接进去，节奏上更稳，业务侧也更容易感知到进步。顺序上宁可先窄后宽，也别先宽后窄，后者几乎一定会推倒重来。

调用量是最容易看的，也是最容易骗人的。我更关注四个指标。次日回访率，也就是今天用过的人明天还会不会来，这个数字低于两成说明答案质量有硬伤。一次成功率，员工一次提问就拿到可用答案的比例，我做过的项目里，这个数从 55% 提到 80% 的过程中，活跃度几乎同步上涨。追问深度，员工在一个问题上平均追问几轮，太低说明他只敢问最简单的问题，太高说明前面几轮都没答准。还有纠错提交量，这个数字不是越低越好，零提交往往代表员工已经放弃反馈了，愿意花时间纠错的人恰恰是最有价值的用户。除了指标，我还会做一件笨事：每月找五个不同岗位的员工聊二十分钟，让他们现场问三个问题，我看他们卡在哪一步。数据能告诉你发生了什么，看人操作才能告诉你为什么。这两条都不能省。另外提醒一句，别把使用率压在 KPI 里下发，员工为了完成任务刷出来的调用量，会把你的判断全部带偏。

回头看这几个项目，我越来越确信一件事：让员工主动用起来，靠的不是把 MCP 讲清楚，而是把员工的使用成本压到他自己都没意识到自己在用一个新工具。这个目标听起来朴素，做起来要动的东西却不少——入口要挪到员工已经在的地方，问法要做成例子摆在手边，答案要带口径和来源，权限要在提问前就说清，查完的结果要能直接接进他的下一步动作，员工说错了要有人接住并把数据改好。六个环节里任何一个掉链子，使用率都会在那个点上断崖式下跌。

我还想提醒一句关于节奏的判断。很多团队希望一次性把体验做完整，结果排期拉到半年，上线时业务场景都变了。我更建议按场景切小步走，两周一个版本，每版只解决一个最痛的点，让员工看到变化。第一批愿意用的人不是靠培训拉来的，是被一个具体的好用瞬间留下的。等他们开始在同事面前主动演示，你的项目就算过了最难的那道坎。

另外，别把这件事当成一个纯 IT 项目。体验设计的活有一半在数据侧——口径、主数据、血缘、数据集迭代，这些不出现在界面上，但员工每一次皱眉都跟它们有关。普元在这条线上做的事情，本质上就是让上层的问答和助手有一个能站得住的底座。底座越扎实，前面那些交互上的巧思才越经得起推敲。如果现在让我重新起一个 MCP 项目，我会把预算分成三份：一份做场景和入口，一份做口径和主数据，剩下一份留给持续运营和反馈迭代。前两份决定能不能跑起来，第三份决定能跑多久。主动使用从来不是上线那一刻的结果，是被一次次正反馈慢慢养出来的习惯。

周文彬：我们去年也上过类似的东西，问题就出在权限上。员工问完才被告知没权限，两次之后整个部门都不用了。这篇说的权限前置很实在，我准备拿回去改。

李慧敏：作为业务侧的人，我最认同的是”别让我学怎么问”这句。手册我们发过，没人看。后来把常用问法做成卡片放在首页，使用量肉眼可见地涨了。

陈兆明：想问下案例里提到的口径统一，实际推进的时候业务部门配合度怎么样？我们这边财务和销售对同一个指标的理解一直没谈拢，卡了挺久。

吴晓东：指标那段我有共鸣。我们之前只看调用量，报表很好看，实际上活跃的人就那么几十个。后来改看次日回访，问题一下就暴露出来了。