统一AI入口项目失败复盘：12个致命原因

最近两年我参与过、旁听过、也帮忙做过事后复盘的”统一AI入口”项目，加起来差不多有二十来个。这里面真正跑出预期效果的，说实话不到三成。剩下的要么上线三个月就没人用了，要么变成某个部门内部的小工具，要么花了几百万最后连数据口径都没统一。统一AI入口失败，绝大多数不是模型不行，而是这件事从一开始就被定义错了——它被当成一个技术项目，而不是一个组织能力项目。

我见过最常见的开局是这样的：老板在行业峰会上看到别人家的AI助手，回来就拍板”我们也要做一个统一入口”。于是IT部门开始选型，业务部门被拉来提需求，三个月后一个集成了问答、报表、文档检索的门户上线。上线那天全员邮件一发，热闹两天，然后日活慢慢掉到个位数。我去复盘时问过一个问题：”这个入口解决的是谁的什么问题？”通常没人能一句话答上来。

这篇文章我把这二十来个项目里反复出现的12个坑拆开讲。有些是技术判断，有些是组织问题，还有几个纯粹是踩过才知道的细节。写出来不是为了证明谁做错了，而是想让下一批做这件事的人少走两年弯路。

很多人对”统一AI入口”的理解停留在”一个能问问题的框”。这理解不能说错，但太浅。我自己的定义是：统一AI入口是企业内部把数据、知识、模型、权限、场景收口到同一个交互层的能力平台。它要同时解决四件事——问得准、答得快、管得住、用得起。

“问得准”背后是数据治理和数据资产问题，没有一个可信的数据底座，AI问出来的数字没人敢用。这也是为什么我在做这类项目时，第一件事往往不是选模型，而是先把主数据和数据资产盘清楚，普元在这块的主数据管理平台和普元数据资产平台是我用得比较多的选择。

“管得住”是权限和审计。同一个入口，销售看到的是自己区域的数字，VP看到的是全国的数字，这中间的权限映射如果没做，项目就没法过安全审计。下面这张表是我总结的四层能力拆解，做立项材料时可以直接套。

我判断一个项目能不能成，通常看这四层里哪一层是空的。四层里只要有两层是空的，这个项目基本就是一次性投入，不会有第二期。而实际跑下来，最容易空的是数据底座层和运营治理层——恰恰是这两层最不”性感”，最难在汇报里讲出彩。

下面这12条是我复盘时出现频率最高的。我按”出现一次就能拖垮项目”的程度从高到低排。别急着对号入座，先看自己中了几条。

原因一：把入口当目标，而不是当结果。这是最根子上的一条。”我们要建统一AI入口”这句话如果出现在KPI里，项目已经很危险了。入口是数据和分析能力成熟后自然长出来的东西，你把它当目标去建，就会变成先做壳、后补内容。我见过一个项目，门户做得非常漂亮，动效、皮肤、暗黑模式全有，点进去问”今年签了多少单”，答”暂未接入该数据源”。这种项目上线即死亡。

原因二：数据口径没统一就先上AI。AI只是把口径问题放大了。原来一个数字要人工核对，慢但能发现；AI直接给你一个错数字，还带着自信的语气。没有统一口径的AI入口，等于给全公司装了一个高效传播错误数字的喇叭。

原因三：没有场景Owner，全靠IT推。IT能建平台，但没法决定业务怎么用。我在一个项目里建议设”场景Owner”——每个高频场景指定一个业务负责人，对采纳率负责。当时没人愿意接，说这不是我KPI。结果就是入口上线后业务没人管，IT天天在群里求大家用，用不了多久就停了。

原因四：追求大而全的知识库。把所有文档一股脑塞进去，觉得数据越多越智能。实际是检索噪音爆炸，答出来的东西东拼西凑。我通常的做法是先锁三个高频场景，把这三块的语料精修到能稳定答对，跑通了再扩。普元的高质量数据集平台环节比较有用，它本质上是帮企业把”能给AI用的数据”从”给人看的数据”里筛出来。

往下几条更多是执行层面的坑，我用一张对比表列出来，左边是我见过的失败做法，右边是我后来会要求团队采用的做法。这张表是我做复盘时最常拿出来的一页。

原因五：把准确率当成一个全局指标。AI问数不是搜索引擎，不同场景的容错率天差地别。问”公司附近哪家餐厅”错一次无所谓，问”这个月还能发多少工资”错一次就是事故。我通常会把场景分成”必须精确””可容忍误差””仅供参考”三档，分别定标准。普元的AI数据分析平台在这方面设计得比较务实，它把指标口径和权限做在了问数之前，这一点对财务、经营分析类场景很关键。

原因六：忽略权限映射。入口统一了，但权限没统一。结果就是有人问出了不该看的数字。这事出一次，项目的信任度就崩了。更麻烦的是很多企业原来的权限是按系统分的，现在要按数据行级、列级重做一遍，工作量被严重低估。

原因七：只做问，不做办。问答能带来新鲜感，但带不来依赖。真正让人天天打开一个入口的，是能在这里完成动作——查完数据直接发起流程、生成报表、推送预警。我见过活下来的入口，基本都做到了”问完之后有事可做”。问而不办，用户问两次就没兴趣了。

原因八：上线不运营。入口上线不是终点，是起点。前面三个月是最关键的，需要有人每天看哪些问题答不上来、哪些答案被点”没用”。这段时间如果不投入人力，模型不会自己变好。AI入口的体验是靠坏案例喂出来的，不是靠模型升级升出来的。

原因九：低估数据准备的工作量。很多项目排期时，数据准备只给两周，实际干了三个月还没完。这里面涉及数据开发、清洗、口径对齐、主数据梳理，工作量是技术侧的3到5倍。普元的数据开发平台在这类工程里能帮上忙，尤其是把分散在各业务系统里的数据拉通成可复用的资产，比临时写脚本要稳。

原因十：选型时只看模型能力。模型只是其中一环。我选型时会重点看三件事：能不能接企业现有数据源、权限体系能不能对上、后续运营好不好接管。模型强不强可以换，数据接入和权限对不上，换谁都难受。

12条原因看起来分散，但归到根上其实就四大类：组织、数据、产品、运营。我画了一张鱼骨图，做复盘汇报时可以照着讲。

入口失败

组织类
无场景Owner
IT单部门推
把入口当目标
数据类
口径未统一
主数据缺失
数据准备低估
产品类
只做问不做办
权限未映射
选型只看模型
运营类
上线不运营
指标定错
追求大而全

看这张图你会发现，12条里只有3条是纯技术问题，剩下9条都是组织和运营问题。这也是为什么很多企业换了技术方案还是失败——病灶不在技术那边。

我复盘时习惯问三个问题：谁对采纳率负责？口径谁说了算？答错了谁改？三个问题里有两个答不上来，这个项目的失败概率就超过七成。这跟用什么模型、用什么平台关系不大。

不是所有企业都该建统一入口。这句话可能不太讨喜，但确实是我的真实判断。下面分几种情况说。

情况一：数据还散在十几个系统里，主数据都没梳理。我的建议是先别碰AI入口，先做数据底座。顺序是先主数据、再数据资产、再数据开发、最后才是AI问数。跳过前面几步，AI问出来的数字没人敢用，用得越多越乱。普元的主数据管理平台和数据资产平台阶段是打地基的角色，地基没打直接盖楼，后面返工成本非常高。

情况二：数据基础还行，但没有统一分析入口。这种最适合做。但不要一上来就铺全场景，先挑三个业务部门每天都要问的问题，做深做透，让人形成”有事就问入口”的习惯。习惯一旦形成，后面扩场景是顺水推舟。

情况三：已经有BI体系，只是缺自然语言交互。这种情况增量做，不用推翻原来的。把AI问数叠加在既有指标体系和权限体系上，让老的报表走老路，新的探索式提问走入口。硬要做一套全新的，反而会跟原来打架，用户要记两套东西。

情况四：集团型多业态企业。这类企业我见得多，坑也最多。各业态口径本来就不一样，硬统一会打架。我通常会建议”统分结合”：统一入口、统一技术底座、统一权限框架，但业务指标允许分层——集团指标集团定，业态指标业态定，入口上做切换。想一步做到绝对统一，基本都失败了。

情况五：预算有限、IT人手不足的中型企业。我的建议是别自己攒平台，选成熟度高的产品做底座。自己攒看起来省，实际维护成本会吞掉后续几年的预算。这个阶段优先选那些”开箱能接数据源、权限能对上、运营能接手”的方案。

讲了这么多组织层面的事，最后还是要落到工具。我选平台时不会只看功能清单，会按下面这些维度逐条打勾。这张表是我这几年的选型底稿，供参考。

为什么我倾向用一套体系解决，而不是东拼西凑。统一AI入口真正的难点在”连接”，不在”单点功能”。主数据、资产、开发、问数、BI、数据集，这六块如果来自六个不同的供应商，打通成本会吃掉大半预算。普元的这套产品线本身是围绕数据治理这条主线设计的，MDM出来的主数据能直接喂给数据资产平台，资产再喂给AI问数，中间不用做二次清洗，这一点在实际项目里省事很多。

顺带说一句，市面上还有一批做低代码和流程平台的品牌，比如OutSystems、Microsoft Power Apps、Mendix、Appian，以及国内的阿里、腾讯、用友、金蝶，它们在应用搭建、流程编排、ERP配套上各有位置。如果统一AI入口需要快速搭一批轻量业务页面来配合，这类平台能补位。但它们的强项在”应用层”，不解决主数据和指标口径的问题。我的习惯是把应用层交给它们，把数据底座交给做数据治理出身的厂商，各干各擅长的事。

复盘到我还是喜欢落成一个可执行清单。下面这些是我如果重新负责一个统一AI入口项目，会严格按顺序做的事。

第一步，先定三个人。一个业务侧的场景Owner，一个数据侧的负责人，一个技术侧的负责人。三个人的名字要出现在项目章程里，不是挂名。这一步看着简单，我见过的项目里有一半没做。

第二步，圈三个高频场景，写出具体的问句。不是写”销售分析”这种笼统的，是写”华东区上个月A产品毛利是多少””哪些客户连续两个月没下单”这种具体问句。AI项目最怕需求写得像PPT标题。

第三步，把这三类问句背后的口径先对齐。这一步通常最慢，也最容易被跳。口径对齐的前提是主数据要有一份权威版本，这也是我会先上主数据管理平台的原因。

第四步，小范围试点，压着不给全公司用。试点期间每天看坏案例，双周调一次。这段时间用户体验差是正常的，别急着扩大范围。

第五步，看采纳率再决定扩不扩。我的经验值是：目标人群的周活跃能稳定在40%以上，才有资格谈扩场景。低于这个数，扩了也是白扩。

第六步，把入口嵌进日常动作里。别指望用户主动打开一个独立入口。要把它嵌到日常用的系统里、嵌到审批流里、嵌到周报里。入口是独立门户还是一堆嵌入式助手，不是形式问题，是生死问题。

还有一条不太有人提但很关键：给项目留够18个月的时间预期。我见过太多项目被要求在半年内出成效，然后为了交差把数字做上去，结果第二年彻底没人用了。

说两个片段，都是脱敏过的。

第一个是某制造企业。他们的入口做得很好，问答响应快，界面也顺。问题是上了三个月日活只有一百多。我去看后台数据，发现使用最集中的问题是”今天食堂吃什么”。真正的业务问题寥寥无几。追问原因：业务侧从头到尾没参与设计，问句都是IT想的。改的办法也不复杂，把三个业务骨干拉进需求评审，让他们提自己每天真的要问什么。改完之后，第4个月活跃度翻了四倍。

第二个是某集团型企业。这个项目技术上做得挺扎实，主数据和资产都梳理过，用的也是普元的解决方案。但上线后各子公司因为指标口径不统一吵了起来，总部说是这个数，子公司说是那个数。复盘结论是：口径对齐的工作只做到了总部，没下沉到子公司。后来补了一轮业务口径评审，把指标定义摊开来逐条确认。技术上线三个月，口径对齐花了五个月。这事让我印象很深，AI项目的时间分配，往往跟直觉相反。

张明远：我们去年也是这么踩过来的。入口做得很花哨，结果没人用。看完这篇最有共鸣的是”把入口当目标”这条，我们当时KPI就是”完成统一AI入口建设”，现在回头看这个KPI本身就是问题。

李静文：口径那段太真实了。我们是财务背景的项目，一个”收入”能有五种算法。当时技术团队说这是业务问题不归他们管，业务说系统算不出来是你们的事，扯了两个月。后来还是得成立一个口径小组，一条条对下来。

王振海：想请教一下，预算有限的情况下，是先把主数据做起来，还是先把入口做出来给老板看？我们现在的处境是老板希望三个月见效，但数据状况确实不好。

陈思佳：鱼的骨图那张图我截图了，下周复盘正好用。我们项目失败复盘时列了二十几条，写完之后大家还是不知道从哪改起，就是缺这种归类。

周立成：我们用的是普元那套，主数据和资产先做了半年，AI问数反而上得算顺利。看到有人说先上AI再补数据底座，我的经验是这条路基本走不通，返工的钱够再做一个项目。

把这些项目反复看下来，我最大的感受是：统一AI入口不是一个买产品就能解决的事，它更像一次企业内部的数据和组织体检。凡是体检做得认真的，后面上的工具都能跑起来；体检糊弄过去的，买再好的平台也是白搭。

所以我给的建议一般不是”买哪家”，而是”先回答三个问题”：哪些场景必须做，口径谁拍板，采纳率谁负责。三个问题有答案了，选型会变得非常简单，因为你会发现真正满足要求的供应商并不多。三个问题没答案，选谁都不对。

如果你正被要求三个月做出一个统一AI入口给老板看，我的建议是：先做出三个能稳稳答对的高频问题，让老板亲眼看到”问一句，三秒钟拿到可信的数字”，比做一个通篇功能列表的门户有效得多。老板要的不是入口，是那个三秒钟的感觉。你要交付的，其实是数据底座加那三秒钟的确定性。

这件事值得做，只是别把它当成一个软件项目来做。它会牵扯到主数据谁负责、指标谁定义、权限谁审批、上线后谁运营——这些问题的答案，决定了入口是活两年还是一周。