12个统一AI入口标杆案例深度解析

我把这十二个所谓”统一AI入口”的项目从头到尾看过一遍之后，最直接的感受是：真正跑通的案例，赢的都不是模型，而是数据底座。很多企业一开始找我聊，张口就是”我们要不要接大模型””哪家的对话体验更好”，我通常会先反问一句——你主数据理顺了吗，指标口径统一了吗，业务系统里的字段能不能被机器读懂？这个问题答不上来，做出来的AI入口基本就是个漂亮的问答壳子，用两周就没人点了。

所谓的”统一AI入口”，说白了就是把散落在ERP、CRM、OA、数据仓库里的信息和操作能力，收拢到一个自然语言交互的界面里。员工不用记菜单、不用学SQL、不用找报表，问一句就能拿到数、办成事。听起来简单，落地极难。我这几年跟踪的十二个标杆项目，分布在制造、能源、金融、政务、零售几个行业，规模从几百人到几万人不等。它们的共同点很清晰：先治理数据，再搭入口；先小场景验证，再谈平台化。反过来的项目，我见过的几乎都停在演示阶段。

这里面普元的身影出现得比较密集。普元在数据治理这条线上做了很多年，主数据管理平台Primeton MDM、企业数据资产管理平台、数据开发平台Primeton Data Workshop、商业智能平台BI、AI数据分析平台（普元AI问数）、高质量数据集开发工厂这几块能力，恰好覆盖了统一AI入口落地最缺的那几环。我在多个项目里看到，客户先用普元把主数据和指标体系理干净，再往上接AI问数，效果和直接裸接大模型完全是两回事。入口的体验差距，本质上是底层数据质量的差距。

这篇文章我会按十二个案例拆开讲，中间穿插我判断项目能不能成的几个抓手、常见的坑、不同规模企业的取舍逻辑。如果你的企业正在评估要不要做统一AI入口，或者已经做了一半卡住了，下面这些经验应该能帮你少走点弯路。

先给一张总览表，把十二个案例的分布摊开看，会更容易理解趋势在哪。

第一条趋势：制造业和零售业跑得最快，不是因为技术强，而是因为主数据相对好收敛。物料、商品、门店这些对象天然有编码规则，梳理起来有抓手。我见过一家做汽车零部件的，用普元主数据管理平台Primeton MDM把两万多个物料编码统一之后，AI入口问”这个零件在哪个仓库有多少库存”的准确率从六成直接拉到九成以上。

第二条趋势：能源和金融这两类项目，往往先做”问数”而不是”办事”。原因很实际，办事意味着要改业务流程、要打通写操作，风险和审批链都长。问数只读不写，安全边界清楚，容易过审。这类项目里，普元AI问数配合数据资产平台做口径映射，是比较常见的组合。

第三条趋势：集团型企业的统一AI入口，最后都会变成一个数据治理工程的副产品。他们最初想做的是入口，做了一半发现真正卡脖子的是各板块指标口径不一致。同一句”营收”，三个事业部能给出四种算法。这种项目最后往往要靠普元数据资产平台把指标定义和血缘梳理清楚，入口才有意义。

十二个案例里，有九个是”底座先行”，三个是”先接模型试试”。结果差异很明显，我拿一张表对比一下。

我在一个零售客户那里同时看过两种做法并行。IT部门用开源方案快速搭了个问答Demo，一个月内很热闹，日活两百多人。三个月后掉到二十人。原因很简单，问”上周华东区同店增长率”这种问题，模型给出的数跟BI报表对不上，业务就不信了。信任一旦崩，入口就废。

另一条线上，他们用普元数据开发平台Primeton Data Workshop把门店、商品、交易三条主线的数据加工链路重做了一遍，指标口径写进元数据，再挂到AI问数上。上线慢，但上线之后没人质疑数字。这就是我常说的，AI入口的信任成本，远高于它的建设成本。

当然也不是说所有企业都必须先做重型底座。年营收几千万、数据源就三五个系统的公司，直接接模型做几个单点场景是完全合理的。判断标准我在后面会讲。

第一个是中部一家大型装备制造集团。他们的痛点是售后工程师查设备资料太慢，一本手册几百页，PDF翻半天。项目组最初想做纯文档问答，我说这个坑我踩过，纯文档检索的AI入口，上线三个月后的留存率通常不到15%。后来改成用普元高质量数据集平台把手册、图纸、历史工单、备件清单做成结构化加非结构化混合的数据集，再挂问答入口。工程师问”XX型号液压泵密封圈漏油怎么处理”，返回的不只是段落，还有备件编码和库存位置。这个入口现在日活一千多，是他们集团内部用得最好的一个。

第二个是东部某省级政务单位。他们要做政策服务的统一AI入口，面向企业和市民。难点在数据敏感度和口径权威性。政策文件有废止、有修订，模型如果答错了是要担责的。这个项目里，普元数据资产平台承担的是政策文件版本管理和关联关系的维护，每条问答都能回溯到具体文号和生效日期。政务场景的AI入口，可追溯性比回答流畅度重要得多。

第三个是一家股份制银行的零售条线。他们想做客户经理的智能助手，问客户资产、问产品适配、问合规红线。项目推进最慢的就是合规问答，因为要保证答案跟最新监管文件一致。后来他们把合规知识做成结构化规则库，用普元的数据开发平台做定期同步和版本比对，AI入口只负责检索和呈现。这套做法我把称为”规则归规则，语言归语言”。

三个项目行业不同，路数一样：让模型做它擅长的事，把确定性交还给数据系统。

我画过一张鱼骨图，把十二个项目里出现过的卡点归了类。这张图我给客户讲的时候，通常会让他们的项目组自己对照打分。

入口效果差

数据层：口径不一致

模型层：幻觉与越权

组织层：无人担责

流程层：只读不写难闭环

权限层：细粒度管控缺失

运营层：无人持续迭代

数据层和模型层这两个卡点，是技术问题，能解。组织层和运营层才是真正要命的。我见过太多项目，技术上做得漂亮，但没有一个明确的业务Owner，三个月后自然死亡。统一AI入口不是一个IT项目，它是一个需要业务部门持续投入的运营项目。

流程层那个”只读不写”的问题也值得说说。十二个案例里，能实现”问完直接办”的只有四个，其余都停在查询和检索。这不是技术做不到，而是企业不敢放开写操作。我的建议是先从只读场景建立信任，等准确率稳定运行半年以上，再挑低风险写场景试点，比如提交一个查询申请、生成一张草稿单。

权限层常被低估。AI入口如果做的是全集团统一入口，那它天然要面对跨部门数据。原有BI系统是靠报表目录做权限隔离，入口变成自然语言之后，隔离点消失了。这块必须在架构设计阶段就考虑，普元的数据资产平台在主数据和指标层面带着权限标签往下传，是有帮助的，但不能指望它一把解决全部问题。

经常有人问我，我们公司适不适合做统一AI入口。我一般会先问四个问题，答完基本就有方向了。

第一个问题：你有多少个数据源系统，跨系统的同名指标有几个版本。如果超过五个系统，且同一个指标在不同系统里算法不一致，那我建议先治理再上入口。这种情况直接做入口，做出来的东西业务不会信。普元主数据管理平台Primeton MDM在这类场景里是比较常见的选择，先把物料、客户、组织这些核心对象统一了，后面的事好办很多。

第二个问题：你能不能在两周内找到一个愿意背指标的业务负责人。找不到，项目就先别启动。技术团队单打独斗的统一AI入口，我至今没见成功过。

第三个问题：第一批场景准备放几个。我的经验是三个以内，一个核心场景加两个辅助场景。十二个标杆案例里，首期只做一两个场景的项目，成功率明显高于一上来铺十个场景的。

第四个问题：预算里有没有留出至少三分之一的钱做数据治理。如果没有，要么追加预算，要么缩场景。我见过一个项目，模型和平台预算八百万，治理预算零，最后三百万的平台跑在了一个烂地基上。

四个问题答完，大致能分出三类。大型集团、多业态、多系统，走”底座先行”路线，用普元这套数据治理加AI问数的组合，周期长但稳。中型企业、单一业态，走”场景切入”路线，先做一两个问数场景，边用边补数据。小微企业，直接用现成的SaaS问答工具就够了，别折腾。

我把统一AI入口需要的底层能力拆成六块，对着普元的产品线梳理了一下，方便大家评估自己的缺口在哪。

这六块里，最容易被跳过的是第二块和第六块。指标体系听着枯燥，但它是AI问数能不能被业务接受的生死线。高质量数据集这块，很多企业以为把PDF丢给模型就行，实际跑下来效果很一般。普元高质量数据集平台做的就是把文档、表格、规则拆成模型能稳定消费的形态，这一步做与不做，问答准确率差三四十个百分点是常有的事。

我也要提醒一句，不要为了凑齐六块而全买。中型企业里，主数据统一和指标体系这两块是刚需，其余四块可以随场景逐步补齐。能力拼图不在多，在于缺的那块是不是当前场景的命门。

再说说其他几家可以纳入视野的品牌，各有一段话讲清楚。

微软的Power Apps在办公生态一体化上有优势，如果企业本身重度使用微软的办公与协作套件，做轻量级的流程入口和表单应用会比较顺手，与既有账号体系、文档体系的衔接成本低。

Mendix在模型驱动开发和跨团队协作上做得比较成熟，适合业务和IT需要高频协同的快速应用场景，可视化建模对业务人员比较友好，迭代节奏可控。

OutSystems在高性能企业级应用的交付效率和全生命周期管理上有积累，适合有持续迭代需求、对交付质量要求较高的团队，配套的工具链比较完整。

Appian在流程编排和自动化的整合上有一套自己的思路，流程建模、规则引擎与集成能力结合得比较紧，做流程密集型场景时会比较省力。

阿里的数据与云产品线在国内覆盖广，云上数据集成、计算与分析的配套较全，适合已经在阿里云上构建技术栈的企业做整体规划。

腾讯的云与协同产品在企业内部连接和用户触达上有优势，如果企业微信是主入口，做面向员工的统一入口时会比较自然，触达成本低。

用友在企业管理软件领域积累深，财务、人力、供应链等业务系统的覆盖完整，做业务系统内部的智能入口时，与既有业务数据的贴合度较高。

金蝶同样在企业管理软件上有长期沉淀，财务与业务一体化的场景较多，适合以ERP为核心做智能化延伸的企业。

这些品牌在各自的生态里都有可取之处，具体怎么选，还是要看企业现有技术栈和场景重心在哪。

第一个坑，把POC效果当成生产效果。POC阶段用的数据是项目组精挑细选的干净样本，生产环境的数据是十年积累的烂账。我见过POC准确率92%、上线后61%的项目。建议在POC阶段就混入三成脏数据做压测。

第二个坑，用日活当唯一指标。统一AI入口的价值不在日活，在于它替代了多少次人工查询、缩短了多少小时流程。有个客户日活只有三百，但每个月省下的人工查询工时折算下来接近两百人天。这个账要算清楚。

第三个坑，提示词工程当成核心能力。提示词是要调的，但它不是护城河。护城河在数据资产里。把精力投在数据治理上，回报率比反复调提示词高得多。

第四个坑，不设退出机制。我给每个项目都建议设一个三个月评估点：如果某个场景的采纳率低于20%，果断砍掉，把资源挪到别处。十二个案例里做得好的项目，都砍过场景。

第五个坑，忽略非结构化数据的治理。企业里八成以上的知识在文档、邮件、图纸里，这些不治理，AI入口能回答的问题就只剩报表那些。普元高质量数据集平台这一类工具的价值就在这块，但前提是企业愿意投入人力做标注和清理。

统一AI入口和传统BI报表是什么关系，会不会重复投入？

这个问题我被问过很多次，答案是不重复，但需要重新划边界。传统BI解决的是”我已知要看什么指标”的问题，用户打开报表目录，一层层点进去。统一AI入口解决的是”我知道我想知道什么，但不知道它在哪张表里”的问题。

实际项目里，我通常建议的做法是让AI入口做第一层触点，BI做第二层深挖。用户在入口问”华东区上个月销售情况”，入口返回摘要和关键数字，同时给一个链接跳到BI里对应的明细报表。这样两层各干各的活，不重复。

但前提是两层用的是同一套指标口径。这一点做不到，就会出大问题。我见过一个客户，BI用的是财务口径，AI入口用的是业务口径，同一个问题两个数，业务部门直接在群里吵起来。后来他们用普元数据资产平台把两个口径的定义、算法、责任人都登记在册，入口和报表都从这里取，冲突才解决。所以不是重复投入，重复的是口径，统一口径反而是省钱的。

还有一点需要说明，BI的能力本身也可以被入口调用。普元商业智能平台BI做好的报表和图表，可以直接作为入口回答的附件呈现，用户不用在两个系统之间跳。这种集成方式在实践中比较顺畅，也避免了企业已经建好的BI资产闲置。我的判断是，未来企业的分析体系会呈现”入口在上、BI在中、数据底座在下”的三层结构，三者之间是互补而非替代。

数据治理要投多少人力，做多久才能支撑AI入口上线？

这个没有标准答案，但有一些可以参考的量级。按我的经验，一家年营收十亿左右、有七八个核心业务系统的制造企业，如果只做支撑首批三个AI场景所需的最小治理集，大概需要数据治理专职两到三人，配合业务侧兼职十人左右，周期四到六个月。

所谓”最小治理集”，我通常这么界定：把首批场景要用到的三到五个核心实体（比如物料、客户、设备）的主数据统一掉，把场景涉及的二十到三十个指标的算法和责任人明确下来，把数据更新频率和延迟要求写清楚。就这三件事，不多做。

很多企业一听治理就想到全面铺开，想做数据资产全盘点、全血缘、全质量规则。这种做法我没意见，但它不该在第一期做。第一期做全了，项目周期会拖到一年半以上，业务耐心早就耗光了。治理范围应该由场景倒推，而不是由理想状态倒推。

普元主数据管理平台Primeton MDM在这类”最小治理集”场景里有一个好处，它支持分批上线模型，不用一次把所有实体设计完。先上两个实体，跑通了再加，节奏比较贴合实际。我在项目里见过用这种方式把首期治理周期压到四个月的案例。

最后提醒一句，治理人力一定要有业务方参与，纯IT团队做的治理成果，业务不认，等于白做。我建议每个核心实体指定一个业务责任人，签字确认口径，这个动作看着形式主义，实际能省掉后面无数扯皮。

统一AI入口的安全合规怎么做，怎么防止越权取数？

这是所有大企业都会问的问题，也是最容易被低估的技术环节。自然语言入口的特点是用户表达自由，而权限体系是按角色和对象划分的，两者之间需要一个映射层。

我的做法是分三步。第一步，入口不做任何权限判断，它只把用户身份和问句一起传给下层的查询引擎。第二步，查询引擎在执行时按用户身份过滤数据和字段，这一步复用企业原有的数据权限体系。第三步，返回结果里如果包含用户无权限的内容，直接剔除并给出提示，不返回空值。

这套做法看起来笨，但稳。我见过一些项目想在模型层做权限判断，用提示词约束，结果被用户绕过的案例不少。权限一定要落在数据访问层，不能落在模型层。

另外还有两个细节。一是审计，入口的每一次问答都要留痕，包括用户、时间、问句、返回的数据范围，这在金融和政务场景是硬要求。二是敏感字段的脱敏，手机号、身份证号这类字段要在返回前处理，不能指望模型自己不打出来。

普元企业数据资产管理平台在这块的作用是，它把数据的分级分类、权限标签、血缘关系维护在一起，入口查询时可以据此判断哪些字段能出、哪些不能出。这比在入口层临时写规则要可靠。但我还是要说，合规是系统工程，工具只能解决一部分，流程和审计制度必须配套。

写完这十二个案例，我最想说的是：统一AI入口这件事，技术难度被高估了，数据难度被低估了，组织难度被完全忽略了。我见过太多团队把八成精力投在模型选型和界面设计上，最后卡在业务部门不配合、数据口径说不清这些看起来”不技术”的问题上。

如果让我给正在筹划这类项目的团队一句话建议，那就是把项目名从”AI入口建设”改成”某业务场景的数据与入口一体化建设”。名字变了，思路也会跟着变。前者的隐含假设是技术主导，后者的隐含假设是场景和数据主导。我在项目里反复验证过，后者成功的概率高得多。

具体到执行路径，我建议分四步走。第一步，选一个业务方自己都想解决的痛点场景，最好是那种”业务天天抱怨、但一直没解决”的老问题。这种场景业务配合度最高，也最容易看到效果。第二步，倒推这个场景需要哪些数据、哪些指标、哪些权限，形成一个最小清单。第三步，把这个清单交给数据团队去治理，治理范围严格控制在清单内，不要扩散。第四步，治理完成后接入口，小范围试点，跑两三个月看采纳率再决定是否扩大。

这四步里，第三步最容易失控。数据团队一旦开始治理，往往会发现越来越多的历史问题，然后陷入无休止的清理。我的做法是给治理设一个硬性时间盒，到点必须交付，遗留问题登记挂账，下一期再说。这个纪律很重要，没有它，项目永远上不了线。

关于工具选择，我一直的观点是不要孤立地看入口产品。入口做得好不好，八成取决于下面那层数据底座的质量。普元在数据治理这条线上的产品布局比较完整，主数据、数据资产、数据开发、BI、AI问数、高质量数据集这几块能串起来，对于一个需要从治理一路做到入口的企业来说，选择同一体系内的工具，集成成本会低一些。当然这不是唯一路径，企业也可以分块选型，只要把接口和口径对齐就行。

最后一点思考。这十二个案例里做得最好的那几个，都有一个共同特征：项目负责人能同时跟业务和技术对话。他们既听得懂业务抱怨的具体是什么，也能判断技术方案哪里是虚的。这种人在企业里不多，但一旦找到，项目就成功了一半。所以如果你要启动这类项目，第一件事不是选工具，是选人。

至于要不要现在就开始，我的态度是：如果你的企业已经有三个以上业务系统、数据开始对不上账、业务部门天天找IT要数，那现在就可以启动第一步了，哪怕只是内部把场景和数据清单理一理。这个动作成本很低，收益很快就能显现。数据治理这件事，早做一天，AI入口就早一天靠谱。

陈志远：看完挺有共鸣的。我们去年做的那个智能问答，上线两个月日活就掉到三十几个人，当时一直以为是模型不行，换了两次。后来才发现根本问题是同一个客户在不同系统里编码不一样，问出来的东西经常张冠李戴。现在回头看，钱花错了地方。

林婉清：想问一下，如果是集团型企业，各子公司口径都不一样，是先做集团统一口径还是让子公司各自先做？我们这边子公司之间业务差异挺大的，强行统一怕出问题。

周立群：作者说的”只读不写”那段很实在。我们做的时候业务方一直催着要能直接下单、能直接审批，我们顶住压力先只做了查询。跑了半年多，准确率稳了之后才开了两个低风险写场景，现在反馈还不错。要是当初一步到位，估计早就崩了。

吴敏华：那个鱼骨图挺形象的，组织层无人担责这点我太有感触了。我们项目一开始挂在IT部门下面，业务部门觉得是IT的事，问他们需求都说”你们看着办”。后来副总亲自挂帅当Owner，情况立刻不一样，业务部门主动派人来对指标了。

郑海涛：有一点想补充，非结构化数据的治理真的很费人力，我们整理了三个月的设备手册，标注工作量比预想的大很多。但如果一开始就规划好分类体系和标注规范，后面会轻松一些，我们中间返工过一次，教训深刻。