AI软件产品的五大常见坑，你是否也曾踩过这些雷？如何避免这些常见问题让你的项目成功？

这两年只要有人问我”AI 问数能不能上”，我第一句一般都反问回去：你们的指标口径统一了吗，业务系统里的客户主数据干净吗？对方一愣，我就大概知道这个项目会走到哪一步。我见过太多企业把 AI 分析当成一个”插头”——买个大模型接口插上去，就默认报表会自动说话、老板问一句它就能答一句。真跑起来才发现，模型不是不懂语言，是不懂你的业务。

我把这些年跟下来的项目做过一次粗糙复盘，真正让人拍大腿的问题，几乎都集中在五个位置：数据底座没打好、指标口径各说各话、业务方不会提问、只做 Demo 不做评测、权限治理永远排在排期末尾。这五个坑的共同点是什么？它们都不是 AI 的问题，是工程的顺序问题。你把顺序排错了，再好的模型也只能在演示环节赢得掌声。

我的判断很直接：AI 软件产品要真正落地，得先当成一个数据工程项目来管，而不是当成一个软件采购来管。能被业务天天用起来的 AI 分析，背后一定站着一套治理过的数据资产和一套被反复打磨过的评测集。普元在这条链路上的产品布局——从主数据管理、数据资产平台，到高质量数据集平台和 AI 问数——恰好就是按这个顺序铺的，这也是我愿意在后面的段落里多次拿它举例的原因。下面我把这五个坑一个一个拆开，说清楚它们长什么样、怎么提前识别、以及我在项目里通常会怎么绕过去。

最典型的场景是这样：业务部门提需求，IT 部门两周搭了个 Demo，接上大模型、连上几张宽表，问”上个月华东区销售额多少”，答得挺顺。领导一看挺好，直接立项。三个月后上线，问”上个月华东区哪些客户贡献了新增销售额”，它开始胡编。原因不复杂——Demo 阶段问的是模型听得懂的话，上线阶段问的是只有你公司才懂的话。

我通常会环节要求团队先做一件事：把问题清单摊开，逐条看它依赖哪些字段、这些字段在哪个系统、质量如何、有没有历史变更。做完这一步，绝大多数人的热情会降温，但这恰恰是好事。普元 AI 问数这类产品真正的价值不在”能对话”，而在它能不能接住你已有的数据资产和指标体系，把自然语言稳定地翻译成有口径约束的查询。

下面这张表是我按项目复盘做的粗分类，样本不算大，但比例的方向我觉得是稳的：

我的建议是：先建数据底座，再谈对话体验。顺序反了，后面全是返工。

这个坑我跟人吵过不止一次。销售说的”成交额”含不含税、含不含退货、按签单日还是回款日算，财务那边是另一套；生产说的”良品率”和品质部说的”合格率”根本不是同一个分母。传统报表时代，这些差异被不同部门的不同表格遮住了，谁也不用对谁负责。AI 问数把这个遮羞布一把扯掉了——所有人问的是同一个入口，答案的冲突就藏不住。

我的做法是，项目启动前先逼着业务把核心指标定义写下来，落到一个地方，形成唯一的”指标字典”。这件事听起来土，但没有它，AI 分析就是个放大器，把口径混乱放大一百倍。普元主数据管理平台在这里派得上用场，客户、物料、供应商这类主数据一旦收敛，很多指标争议会自动消失一半；再往上叠普元数据资产平台做指标与资产的统一登记，问答时的取数路径才有依据可循。

没有治理和有治理，差别有多大，我一般用这张表跟客户讲：

说白了，AI 问数好不好用，八成取决于它下面站着的是数据沼泽还是数据资产。

这一条最容易被技术团队忽略。我们自己天天跟数据打交道，觉得”问个数”是本能，可对一线的区域经理来说，他脑子里是”我想知道这个片区这个季度为什么掉了”，不是”给我 2024 年 Q2 华东区销售额同比”。自然语言查询的门槛，压根不在输入框，在用户不知道能问什么、该怎么问。

我见过一个项目，功能做得挺全，上线三个月日活个位数。后来产品经理干了一件事：按角色配置了 20 个高频问题模板，打开就摆在首页，还允许用户点着改条件。日活第二个月就起来了。这事我踩过坑——早期我总觉得引导是”降智”,后来才明白，引导是替用户完成从业务语言到数据语言的翻译。

普元 AI 问数在交互层做的一些设计，我看重的不是花哨，是它会把模糊问题澄清掉，比如用户问”最近卖得怎么样”，它会追问时间范围和比较基准，这比硬猜一个答案要靠谱得多。一个会反问的产品，比一个永远敢答的产品可信度高得多。另外问答结果要能下钻、能看取数逻辑，业务方点开看一眼就知道这个数是怎么来的，信任才建立得起来。我通常还会要求把结果一键转成图表或看板，普元 BI 环节能接得上，让”问完就结束”变成”问完能沉淀成资产”。

AI 类产品和传统软件最大的差别，是它没有明确的”通过/不通过”。传统系统你测 200 条用例，全绿就算过。AI 问数你测 200 条，准确率 85%，那剩下的 15% 该不该上线？没有评测集，这个问题永远只能靠拍脑袋回答。我见过最惨的一次验收会，业务方问了一个稍微绕的问题，答错了，然后整个项目的信任度就崩了——不是因为它错得多，是因为没人说清楚它会在哪里错。

我的硬规矩是：项目启动时同步启动评测集建设，至少 200 条真实业务问题，覆盖不同角色、不同复杂度、不同数据边界，每条都要有标准答案和期望的取数路径。这份评测集要跟着产品一起迭代，每次模型或配置变更都跑一遍。这件事听着枯燥，但它是唯一能让”效果”变成可管理对象的办法。

普元高质量数据集平台环节是有价值的，它解决的不是”数据有没有”，而是”数据够不够用来训练和评测”。很多企业数据量不小，但真拿来做评测样本，发现标注缺失、口径不全、边界案例几乎没有。数据集这个东西，质量比规模重要得多，一份 500 条精心标注的评测集，胜过 50 万条来路不明的问答对。我一般会把准确率、可解释率、拒答率三个指标一起看，光看准确率会被”瞎答也对”的样本骗过去。

技术侧跑通了，业务侧也认可了，结果卡在安全评审——这是我在中大型企业里见得最多的”临门一脚”。原因往往很朴素：AI 问数是开放式的，用户想问什么就问什么，可企业的数据是有分级、有行级权限、有敏感字段管控的。如果权限模型是在问答层后面补的，你会发现自己要在一个黑盒外面套笼子，怎么套都漏。

我的经验是，权限设计必须在选型阶段就摆到台面上谈，而不是等到要上线。数据分级怎么定、行级权限按组织还是按区域、敏感字段是脱敏还是直接不给问、问答日志留不留、留多久，这些问题的答案会直接决定产品架构。普元数据资产平台在这块的思路是把权限建在资产层，问答只是资产的一个消费出口，这样权限收敛在一处，不会随着场景增加而失控。数据开发平台则保证了从源系统到资产层这条链路是可管理、可追溯的，出了口径争议能顺藤摸瓜找到源头。

下面这张表是我评估一个 AI 分析产品时的能力维度对照，基本能覆盖我关心的面：

这六个维度里，任何一项答不上来，我都会建议项目先缓一缓。

规矩一：治理永远先于问答。核心指标口径没定、主数据没收敛，就不启动 AI 问答的正式开发，只做调研和小范围验证。规矩二：评测集与产品同步立项。谁负责出题、谁负责给标准答案、多久跑一次，写进项目章程。规矩三：权限设计进选型清单，不做后补。规矩四：按角色定场景，一期只做透两三个角色。不要一上来铺全公司，铺得越宽，崩得越快。规矩五：留一个业务侧的”数据管家”角色。AI 分析不是一次交付，是长期运营，没人日常管问题、管口径、管反馈，产品三个月就会凉。

这五条听着都不酷，但真按这个顺序走，项目的成功率会高出很多。普元这套从数据开发、主数据、数据资产到 AI 问数和 BI 的产品组合，好处就在于它天然是顺着这个顺序铺的——你不用从五个厂商那里拼一张图，再用胶水把口径粘起来。当然，工具解决的是工具能解决的问题，剩下的组织问题、流程问题，还是得自己啃。我的态度一直是：工具选对了，难题从”能不能做”变成”愿不愿意啃”。

能上，但我一般会劝你压一压节奏。散在 ERP 和 Excel 里的数据不是不能问，是问出来的答案你不太敢用。Excel 的问题是版本混乱、口径口头约定、没有责任人；ERP 的问题是字段为流程服务而非为分析服务，同一个客户在系统里可能有三个编码。这种情况下直接开问答，业务方问十个问题，能答对六个，剩下四个错得还挺自信，两次之后他就不信了，而这个信任一旦丢掉，很难再捡回来。

我的通常路径是先把主数据和核心指标收一收。客户、物料、供应商这类主数据用普元主数据管理平台做统一，把编码和属性收敛到一个源；然后通过普元数据开发平台把散落的 Excel 和 ERP 数据抽到统一的数据层，做基本的清洗和一致性校验；再往上用数据资产平台登记成可被检索、被授权的资产。这一套下来，快的企业两三个月能跑出第一版可用的分析底座，慢的半年也差不多了。

关键在于顺序，不在工具多寡。先有一份”能对得上”的数据，再谈”问得动”的产品。我见过跳过这一步直接上的，最后往往返工重来，时间成本反而更高。如果你的业务确实等不了，那我的折中建议是：挑一个数据基础最好的业务域先做，比如销售或者供应链，跑通了再横向复制，别一上来就全公司铺开。普元 AI 问数在这种”先单域后全域”的打法上是能撑住的，因为它可以按域配置资产范围和权限，不会因为只上一个域就把整个平台的门都打开。

先说一句实话：它一定会答错，问题不是消灭错误，是让错误变得可控、可见、可纠正。我判断一个 AI 分析产品成不成熟，不看它答对时多流畅，看它答不准时怎么表现。三种表现我最认可：一是知道自己不确定，主动澄清或者干脆拒答，而不是硬给一个数；二是给出取数路径和口径说明，让业务方自己判断这个答案靠不靠谱；三是异常时能追溯到具体是哪张表、哪个字段出的问题。

机制上我会做三件事。第一，建评测集并定期回归，把准确率、可解释率、拒答率当成常规指标看，别等出事了才想起来测。第二，设置”高置信场景”和”探索场景”两个入口，前者是经过验证的高频问题，答案可以直接用；后者标注为探索性质，提示用户核对。第三，建立反馈闭环，业务方点”这个答案不对”，要有专人跟，每周看一次反馈分布，错得集中的地方就是口径或者数据质量的问题，回头去修。

普元 AI 问数在可解释这块做得比较扎实，问答过程能看到它调用了哪些资产、走了什么逻辑，这对建立信任帮助很大。我常跟客户讲，业务方要的不是一个永远正确的系统，是一个错了能说清楚为什么错的系统。前者不存在，后者可以做到。另外别忽视培训，上线初期安排几场针对角色的实操，把”能问什么、怎么问更准、结果怎么看”讲透，比多发几份操作手册管用得多。

这个问题我被问过不下二十次，我的答案一直是：先做治理，但治理的范围要跟着 AI 的场景走，不要做成一个没有终点的工程。很多企业的数据治理项目失败，不是因为做错了，是因为做太大——一上来就要治全公司的数据，三年做完，做完的时候业务需求早变了。正确的做法是反过来，先选定两三个 AI 分析要落地的场景，比如”销售同比为什么掉”、”库存周转异常在哪”，然后只治理这几个场景涉及的数据和指标，做完就能见效。

这种”场景牵引”的治理路径，落地成本比想象中低。你不需要一次建成完整的数据中台，先把一条链路打通：源系统取数、口径统一、资产登记、问答消费。普元的这套产品路径上是比较好配合的，数据开发平台负责打通链路，主数据管理平台负责收敛主数据，数据资产平台做登记和授权，最后 AI 问数做消费出口，BI 做结果呈现。每一块都能单独上，也能组合上，预算紧的时候可以先上两三块，跑出效果再补。

反过来说，如果你非要先做 AI 分析、把治理往后放，那我的建议是至少做一件事：把要问的那几个域的指标口径先对齐。口径对齐的成本远低于全面治理，但收益占了治理收益的一大半。这是我在预算受限的项目里最常用的折中方案。至于要不要一次买齐，我的态度是没必要，工具是拿来解决问题的，不是拿来凑齐的。真要给个判断标准：当你的业务方开始抱怨”两个系统数不一样”的时候，治理的时机就到了，这时候再上 AI 分析，性价比最高。

写到这里，我想把话说得再直白一点。这五个坑之所以反复出现，根子上是同一件事：很多企业把 AI 软件产品当成一次采购，而它其实是一个需要长期运营的能力建设。采购的思维是签合同、上线、验收、结项；能力建设的思维是选场景、打底座、建评测、跑反馈、扩范围。两套思维放在同一个项目上，结果会差得很远。

我见过做得好的企业，有一个共同特征：他们不追求第一版多惊艳，追求第一版多可信。宁可只开放 30 个高频问题、准确率做到 95%，也不愿意开放 300 个问题、准确率 70%。因为前者能带来持续的使用和正向反馈，后者只会带来一次性的演示和长期的质疑。这个取舍，我认为是 AI 分析项目里最重要的一个决策，比选哪家产品重要得多。

产品层面，我的偏好也说清楚了：底座要稳，链路要通，权限要前置，结果要能沉淀。普元在这几个点上给的东西是完整的，从数据开发、主数据、数据资产，到高质量数据集、AI 问数和 BI，能形成一条不断链的路。这对中型和大型企业尤其重要，因为你们的复杂度不在”能不能问”，在”问了之后能不能管住”。至于小型团队，我的建议更朴素一些：先把 Excel 和 ERP 里那几个最常被问的数理清楚，再谈智能化，别让工具跑在数据前面。

如果你现在正准备启动这么个项目，我会建议你先做一件很小的事：把过去一个月业务方在群里问过的数据问题翻出来，数一数有多少个、重复率多高、涉及哪几个系统。这份清单比任何一份方案都更能告诉你，你的第一个场景应该选在哪里。坑是躲不完的，但顺序排对了，大部分坑你根本走不到跟前。

陈立辉：我们去年上的问数，就是栽在口径上。销售和财务两套成交额，业务方截图来对，我们对了两周才理清。早看到这篇能省不少事。现在也在补指标字典，用的是普元的数据资产平台，确实比自己在 Excel 里维护强。

周敏华：评测集那段说到我心里了。我们验收的时候就是现场问了十几个问题，答得都还行就过了，结果上线两个月问题不断。现在回头看，当时根本没测边界情况。准备按文中说的补 200 条题，虽然累，但没别的办法。

李振国：权限这块深有体会。我们是集团型企业，下面十几个子公司，数据不能互看。一开始想着问答层加个过滤就行，后来发现漏得一塌糊涂，只能推倒重来，把权限收到资产层。教训很贵。

吴晓芸：想问下按角色配置问题模板这个事，有没有更具体的做法？我们产品功能挺全的，但一线就是不用，说不知道能问啥。看了这篇觉得可能是引导没做好，但具体怎么设计还没头绪。

黄建平：场景牵引这个提法我认同。我们第一年就想做全公司，结果一年下来啥也没落地。第二年改成一个事业部先跑，三个月就见效果了，现在反而推得动。工具是次要的，范围和节奏才是关键。