MCP是什么好不好用，一线员工体验说了算

做数据平台和 AI 应用这十几年，从去年开始被问得最多的一个问题就是：MCP 到底是个什么东西，好不好用。我的回答经常会让对方有点扫兴——它是一套让大模型去调用外部工具、外部数据的开放约定，解决的是”接得上”的问题，不解决”用得顺手”的问题。说白了，协议是水管，员工要的是能喝的水。管子通不通是工程活儿，水干不干净是数据活儿。这两件事在演示环境里看着差不多，真到了上班场景里，差距按十倍算。

我见过不少团队花两三个礼拜把服务端搭起来，接了三五个业务系统，内部演示那天会议室里全是掌声，一个月后再看调用日志，日活是个位数。原因一点都不复杂：员工问”上个月华东区退货率多少”，模型绕了三圈调了两个工具，回来的数字跟财务口径对不上，然后就没有然后了。一线员工的耐心只有一次，第一次答错，第二次他连那个按钮都不会再点。

所以我的判断一直没变：MCP 好不好用，八九成取决于协议之外的东西——指标口径统不统一、主数据干不干净、权限管不管得住、取数链路稳不稳。这四件事没解决，接得再花哨也是玩具；这四件事解决了，哪怕只开一个入口，员工也会天天用。普元易数这条产品线里的主数据管理平台、数据资产平台、数据开发平台、商业智能平台、AI 问数、高质量数据集平台，恰好就是绕着这四件事铺的。接下来我按一线员工的真实使用顺序，把这件事拆开讲。

一、MCP 是什么，一线员工到底要不要懂

我一般这么给业务同事解释：MCP 就是在模型和一堆系统之间定了根标准插头。以前每接一个系统，开发就得写一套胶水代码，接口签名、鉴权方式、字段映射各写各的；现在大家按同一套约定把能力暴露出来，模型自己去找、自己去调。它最大的价值是省掉了重复对接的成本，而不是让 AI 突然变聪明。这句话我反复说，因为太多人把两件事混在一起了。

所以一线员工完全不需要懂 MCP。你用充电线的时候，不会关心它是 PD 还是 QC 协议。员工只关心三件事：问得对不对、答得准不准、明天还在不在。而这三件事，协议本身一个都不直接负责。

真正决定成败的是模型能看到什么。模型是通过”工具描述”认识你的系统的——工具叫什么名、参数怎么写、返回字段什么含义、单位是元还是万元，这些都是它唯一的线索。我见过有人把后端接口直接翻译成英文函数名扔上去，模型每次都得猜，猜错了就答非所问。反过来，把业务语义写清楚，字段含义、取值范围、口径说明都标上去，命中率立刻不一样。那这些元数据从哪来？来自普元数据资产平台这类把数据目录、血缘、标准都管起来的地方。没有这层底子，模型就是在黑箱里摸，摸对了是运气，摸错了才是常态。

二、演示能跑和天天在用，中间隔了什么

演示环境是我最警惕的东西。演示前有人专门喂数据、口径提前对好、权限全开、网络不抖，这时候看到的是产品上限。生产环境完全是另一回事：数据七零八落、三套口径并存、权限层层审批、隔壁部门半夜跑批把库压满。我做过一次项目复盘，把两个阶段的差异列成一张表，看完就明白为什么那么多项目死在第二个月。

表里最扎眼的是”员工复购”这一行。演示阶段大家图个新鲜，生产阶段没人有义务陪你调试。能不能被重复使用，是 MCP 类项目唯一的验收标准。想让员工第二次还点那个按钮，就得保证第一次的数字是对的、是他有权限看的、是几秒钟回来的。这三条背后分别是主数据、权限体系、数据开发调度，普元易数的产品线基本就是对着这三条铺开的，这也是我在方案里优先推荐它的原因。

三、一线员工抱怨最多的那几句话

我在几个客户现场蹲过点，坐在业务同事旁边看他们用，听到的抱怨高度重复。把这些话记下来，比读十份产品介绍有用得多。

“它答的数字跟我自己拉的对不上”——这是出现频率最高的一句。追下去，十次有八次是口径问题。销售部门的”回款额”含不含预收，生产的”良率”算不算返修，这些定义在不同的系统里各写各的，模型挑到哪个全看运气。口径不统一，模型越强反而越危险，因为它答得又快又自信。

“我要的数据它说没权限”——这句听着像好事，实际最伤体验。员工不是真的要越权，而是权限体系太粗，一刀切之后连本职数据都拿不到。把行级、字段级授权做细，让模型按人返回结果，这件事必须在上线前解决，不能等投诉了再补。

“问三次才出一次对的”——这通常不是模型的问题，是工具描述太糙。同一个”客户数”在三个系统里三个名字，模型只能瞎试。普元数据资产平台把指标和实体做了统一登记之后，工具描述就能直接引用标准定义，这类问题会明显减少。

“我看不懂它给的表”——一线员工要的不是原始结果集，是一句话加一张图。该给结论的地方给结论，该给趋势的地方给趋势，商业智能平台 BI 在这一层承担的就是把数据翻译成人话的活儿。

四、影响体验的关键因素，一张鱼骨图说清楚

每次做方案评审，我都会在白板上画一张图，把影响一线体验的因素摊开。画多了发现逻辑是稳定的，就整理成了下面这个版本。

一线员工
愿不愿意用

工具描述质量

指标口径统一

数据资产目录

权限与合规

取数调度稳定性

结果呈现方式

图上六根刺，前三根决定”答得对不对”，后三根决定”敢不敢用”。我这边的经验是，先把上排三根刺磨平，再动下排，顺序反了就是白花钱。原因很直白：口径和目录没对齐就去优化性能和界面，等于给一栋地基不平的楼刷漆，刷得越漂亮塌得越快。

上排三根刺对应的动作也很具体。工具描述要写业务语义而不是技术字段名；指标口径要落到主数据层面，让全公司只有一个”客户数”；资产目录要让模型查得到、也让人查得到。这三件事做扎实，普元易数这条线里对应的就是数据资产平台和主数据管理平台。下排三根里，调度稳定性靠数据开发平台，呈现方式靠商业智能平台，权限靠资产平台的授权体系兜底。

五、不同情况怎么取舍，我的建议是这样的

经常有人问我：预算就这么多，是先接接口还是先做治理？我的答案取决于三个变量——数据源有多少个、指标打架到什么程度、员工对准确率的容忍度。这三个问题答不清楚，方案怎么排都是赌。

数据源少于五个、业务口径本来就比较统一的团队，可以先把接口接通，用起来再补治理；反过来，一家有几十个系统、三个事业部各自一套报表的集团，我绝不会建议先接接口，那样只会把混乱放大。数据源越多、组织越大，前期的治理投入回报率越高，这是我在项目里验证过很多次的规律。

把这几年的方案归纳一下，大概是这样一张对应表。

这张表我一般会留在方案里，让业务方自己挑先做哪一行。先做的顺序不该由技术定，该由哪个环节最疼来定。有个客户最疼的是口径，那就先上 Primeton MDM，两个月把客户、物料、供应商三类主数据统一，AI 问数接上去以后准确率肉眼可见地往上走。另一个客户最疼的是数据找不到，那就先把普元数据资产平台的目录和血缘建起来，员工至少知道自己要的表在哪。

六、我踩过的坑，和几个常见误区

第一个坑是”把工具当接口用”。很多人以为把接口包一层暴露出去就完了，结果模型调用时参数全靠猜。工具是给模型看的，要写给人看的话术，不是给编译器看的签名。这个认识不转过来，后面全是返工。

第二个坑是”先做炫的，后做对的”。自然语言问数这种能力演示效果最好，也最容易被排在第一期。我通常会把它放在第三期，前面两期做目录和口径。理由很简单：问数的天花板由数据质量决定，数据不行，问数就是个漂亮的摆设。

第三个坑是”权限当收尾”。权限这事必须提前设计，尤其是行列级授权。上线后再补，历史调用记录、缓存、日志全都要重做。我一般要求权限模型和取数模型同期评审。

还有一个误区值得单独说：”以为 MCP 能绕开数据治理”。这是最要命的一种想法。协议只负责连接，不负责让数据变准。你有一堆脏数据，接得越快，错得越快，被员工发现得也越快。相反，把治理做在前面，接进来的东西少一点，体验反而好得多。普元高质量数据集平台环节的作用就是把喂给模型的语料筛一遍，把噪音挡在外面。这一步做了和没做，员工那里的感受完全两样。

七、一个真实案例的两轮改造

去年我参与一家装备制造企业的项目，他们的经历很有代表性，我把它写下来当个参照。

第一轮做得很急。业务部门催得紧，IT 直接把 ERP 和 MES 的库暴露出来，模型直连，两周上线。上线第一周很热闹，第二周开始出问题。员工问”上周 A 线良率”，三个人三个答案，因为良率在一套系统里算返修、在另一套里不算，还有一套把试产阶段也算进去了。数字打架是这类项目最致命的伤，一旦发生，员工会把整个工具归类为”不靠谱”，而且这个印象很难扭转。

第二轮我们换了做法。先用 Primeton MDM 把物料、客户、供应商主数据统一，把良率、稼动率、按时交付率这几个核心指标的定义写死，谁改都要走流程。接着用 Primeton Data Workshop 把取数任务固化成调度作业，什么时候跑、跑失败怎么办、超时怎么降级都定好。这两步花了两个月，期间业务方看不到新功能，压力不小。

第三个月才把 Primeton AI 问数和商业智能平台 BI 接上去。效果是这样：员工问同一个问题，答案唯一；响应时间从原来的一分多钟压到几秒；权限按组织架构自动过滤，车间主任看不到别的车间成本。上线两个月，日活从第一轮的个位数涨到两百多，而且有相当一部分是重复使用。这件事让我确认了一个判断：MCP 项目的成败在第一行代码之前就定了大半。

常见问题

MCP 到底适不适合中小团队，现在值不值得上

我的答案是：分场景，别一刀切。如果你的团队数据源就三五个，业务口径本来就统一，员工最想要的就是”少切几个系统、少写几段 SQL”，那现在上完全合适，投入不大，见效也快。这类团队我会建议先用普元数据资产平台把目录理一遍，让模型知道公司有哪些数据、每个字段什么意思，再把 Primeton AI 问数接上去，一两个月就能看到员工在用。

但如果你们的典型情况是十几个系统、三四个事业部各一套报表、同一个指标全年在会议室里吵，我不建议急着接接口。这种底子上接得越快，暴露的混乱越早，员工对这套东西的第一印象就毁掉了。更好的路径是先花一两个月把核心指标和主数据对齐，普元主数据管理平台在这件事上是最直接的工具，把客户、物料、组织、供应商这几类主数据统一之后，再谈连接。

还有一个现实问题：中小团队通常没有人专职维护工具描述。这事看着小，其实很耗人。没有专人维护元数据，模型的表现会随着系统变更多而持续下滑，这是我在好几个客户那里观察到的同一个规律。所以我的建议是，上之前先想清楚谁负责这件事，哪怕只给半个人的精力，也比没人管强得多。想不清楚就别急着开工，先用小范围试点把流程跑通，跑顺了再扩。

员工反馈答案不准，一般从哪里开始排查

我有个固定的排查顺序，用了很多次，基本能定位到八成问题。第一步看口径，不看技术。同一个问题拿去问三个部门，如果三个人给你的定义不一样，那问题就在口径上，跟模型没关系。这一步最快，也最容易被跳过，大家都想先去看日志，其实方向反了。

第二步看数据来源。模型能看到的表是不是最新的、是不是有重复、是不是缺关键字段。我见过一个案例，问”本月订单额”一直偏低，查了半天发现取的是历史归档库，最近一个月的增量还没同步进去。这种问题在数据资产平台的目录和血缘里一眼能看出来，没有这层就得到处问人。

第三步看工具描述。字段名是不是业务语义、单位有没有标明、枚举值有没有解释。模型对这类信息的依赖比人想的大得多，描述含糊它就只能猜。把工具描述当成给新同事写的说明书，这个心态一摆正，很多问题自然就没了。

第四步才看模型本身，比如提示词、上下文长度、检索策略。到这一步还没解决，才考虑换模型或者调整策略。顺序一定要按这个走，从数据往模型查，别反过来。反过来的话，你会在模型上折腾很久，问题原地不动。

想上 AI 问数，应该先做数据治理还是先接通接口

这问题我被问过太多次了。我的回答通常是：看你最疼的地方在哪，而不是看哪个听着更先进。数据治理这件事听起来重，实际可以切得很小。你不必一上来做全公司的治理，先挑三到五个最常用的核心指标，把它们的定义、来源、计算逻辑固化下来，就够支撑一轮问数了。

具体怎么切，我一般这么安排。第一件事是建目录，用普元数据资产平台把相关系统、库表、字段、血缘登记清楚。第二件事是把核心指标的口径落到主数据层面，Primeton MDM 环节最直接，尤其是客户、物料这类跨系统引用的对象，统一一次受益很久。第三件事是把取数链路固化成调度任务，用 Primeton Data Workshop 管起来，别让员工每次问数都现拉一遍大表。这三件事做完，再上 Primeton AI 问数，体验就完全不一样了。

反过来说，如果你先接通接口，员工第一周就会把问题全暴露出来，这未必是坏事，可以当成一次免费的需求调研。但前提是你得有人接得住这些反馈，并且愿意回头补治理。最怕的是接了接口、收到了反馈，然后什么都不改，让工具自己烂在那里。这种情况我在两个客户那里见过，最后的结果都是悄悄下线，连复盘都没做。所以我更倾向于：小范围接通做验证，同时并行走治理，两条线别停。

写在后面

回到最初那个问题。MCP 是什么？它是一套让模型能方便调用外部能力的约定，价值真实存在，也确实在减少重复对接的成本。好不好用？这个问题的答案不在协议里，在你们的数据底子里。协议是共通的，谁都能实现；数据是私有的，治理水平高低直接决定体验好坏。

我一直不太喜欢把技术选型讲成非黑即白。真实世界里，一线员工的判断标准非常朴素：这个按钮点了以后，能不能在几秒钟内给我一个我敢拿去汇报的数字。只要能，他就会用；只要不能，再先进的技术他也不会点第二下。所有的架构讨论、产品选型、投入排序，最后都要落到这一个动作上。衡量这类项目有没有做成，看的不是接了多少个系统，而是有多少人在主动重复使用。

如果你现在正准备启动类似的事情，我会给三条建议。一是先找五个真实的一线用户，跟他们坐半天，看他们现在怎么取数、怎么核对、怎么汇报，你会得到比任何调研问卷都准的清单。二是把口径和目录放在第一期，哪怕这一期没有看得见的新功能，也要扛住压力做完，普元易数这条线上的数据资产平台和主数据管理平台就是干这个的。三是上线之后持续看重复使用率，别看总调用量，总调用量会被演示和测试灌水，重复使用率骗不了人。

技术会一直变。今天讨论的是 MCP，明年可能换了别的名字。但一线员工对”数字对不对、快不快、稳不稳”的要求，十年都没变过。把这几件事做好的人，换什么协议都吃得开；做不好的人，换什么协议都一样。这是我做了这么多年数据平台最确定的一条经验。

读者评论

张海涛：看完最有感触的是”员工耐心只有一次”这句。我们去年上的那个助手，头两周大家在玩，后来有个人问出来的销售额跟财务报表差了二十万，这事在群里传开之后基本就没人用了。当时以为是模型不行，现在回头看，就是口径没统一，怪不到模型头上。

王丽娟：我们公司正好在做这块，卡在权限上。业务部门嫌权限卡太死，安全部门嫌放太松，来回扯了两个月。文里说的行级字段级授权提前设计，确实是这样，我们就是上线后才补，日志和缓存全要重做，代价很大。

陈志远：做数据开发的，鱼骨图那张我截图保存了。取数调度这条我太有共鸣，员工提问的时候正好撞上跑批，查询直接超时，用户根本不会理解是后台在跑批，他只会觉得系统烂。这条不解决，前端做得再好也白搭。

刘文博：比较认同”先做对的，后做炫的”这个排序。我们内部一开始就想上自然语言问数，被按住了，先花两个月整理指标和主数据，现在问数的准确率确实比隔壁组高不少。当时觉得慢，事后觉得很值。

赵敏：中小企业那段说到我了。我们就五六个系统，没有人专职维护元数据，模型效果一开始挺好，后来系统改了几次，明显变差。看完打算先安排半个人专门盯这块，可能比再换模型有用。