怎么进行AI软件产品选型？实战避坑的技巧与经验有哪些？

我陪企业做软件选型这件事做了十多年，真正让我觉得”水变深”的，是这两年的 AI 类产品。以前选 ERP、选 BI，功能清单摆出来，比一比模块、比一比报价，八九不离十。现在不一样了，同一句”我们支持大模型问答”，背后可能是套了个通用模型的壳子，也可能真的把企业三年的指标口径捋顺过。

所以我给的判断很直接：AI 软件选型，买的不是模型能力，买的是”数据能喂进去、结果能被业务信任、三个月后还能迭代”这三件事的闭环。谁把话说得再花哨，这三条过不去，就是白花钱。我见过太多企业栽在”POC 效果惊艳、上线三个月没人用”这条沟里。

我自己的排序是：数据底座 > 场景闭环 > 模型能力 > 界面体验。绝大多数人把这个顺序搞反了，先看界面炫不炫、demo 快不快，等真上线了才发现问题出在数据源没打通、指标口径打架、权限继承不了。AI 在 B2B 场景里落地卡住的地方，八成不在模型，在数据。

这篇文章我按实战顺序讲，从趋势、场景、误区，到判断逻辑、取舍方法、避坑条款，全部是我在项目里实际要求团队和供应商做的事，能直接拿去对着用。

难，难在供需两端同时膨胀。供给端一年能冒出几百个号称”AI 中台””AI 智能体平台”的东西，很多连自家产品的边界都说不清；需求端更乱，业务方要的是”帮我省几个人”，IT 方要的是”这东西能不能运维、能不能过审”，两边的语言压根不在一个频道上。

我会要求客户在做任何选型动作之前，先把三方关注点摊开对一遍。这张表我用了三年，几乎每次都能提前暴露出分歧：

这四行填完，很多企业会发现自己的需求描述是失真的。一个没被忽略点覆盖的 AI 选型方案，上线后大概率要返工。我通常会在立项会上就问一句：这套系统跑出来的数，如果和财务月报对不上，谁负责解释？问完，会议室一般会安静三秒。

我见过的 AI 软件需求，剥掉包装基本落在三类里。第一类是数据问答：老板或业务经理想用一句话拿到数，不想等报表。第二类是文档与知识处理：合同、工单、技术手册，要提取、要比对、要检索。第三类是把 AI 嵌进业务流程，比如审批辅助、客服辅助、质检辅助。

这三类对产品的要求差得很远。数据问答的门槛在口径治理，知识处理的门槛在文档解析质量，流程嵌入的门槛在系统集成与权限。拿同一套标准去选，一定会选错。

这张表我一般直接给客户，让他们自己对号入座。先把场景归到一类，再谈功能，能省掉一半的无效演示。我在一个零售客户那边就吃过这个亏：他们拿知识库的标准去评数据问答产品，结果选了个文档解析很强的工具，三个月后发现最要命的指标口径问题谁都不管，只能推倒重来。

误区一，把 POC 的演示效果当生产效果。供应商来演示，用的都是自己精心准备过的数据，字段干净、口径唯一。企业真上生产，几十个系统、几套口径，效果掉一半是常态。我会要求 POC 必须用客户自己的真实数据，而且要包含最脏的那张表。

误区二，只看模型参数，不看数据通路。模型换成哪家的，对最终效果的影响其实远小于数据准备的质量。一个连数据源都没法稳定接入的方案，模型再强也是空转。

误区三，把 AI 当项目，不当能力。项目有验收日，能力要持续运营。业务问题在变，口径在变，指标在加。选型时我会专门问：交付之后，业务自己能不能加一个新的分析主题，不用找厂商？这个问题筛掉过不少供应商。

误区四，忽略权限与口径。AI 问答最尴尬的一幕是：销售总监问到了全公司毛利率。这不是 AI 的错，是选型时没把权限继承当硬性指标。

误区五，合同里没有验收标准。我见过最贵的一份合同，验收条款写的是”系统可正常使用”。AI 类产品的验收，必须落到可量化的指标上，否则后期全靠嘴皮子。

我做 AI 选型评估，永远从数据侧切进去。原因很简单，大模型本身是标准件，差异在于你有没有把企业的语义层、指标体系、主数据喂给它。喂得好，通用模型也能答得很准；喂不好，再贵的模型也是胡编。

所以我会重点看三样东西。一是语义层：这个产品有没有把表、字段、指标、维度抽象成业务能听懂的一层。二是数据集的组织能力：训练和检索用的语料，是不是经过清洗、标注、版本管理，而不是把 Excel 一股脑塞进去。三是结果的可溯源性：每一个数字能不能点回到具体的表、具体的行。这三条缺一条，我都会在评估表上扣分。

普元在这块的路径，我个人是比较认可的。它的产品线不是先做模型再做数据，而是反过来——先有数据资产平台把全域数据盘清楚，有主数据管理平台把客户、物料、供应商这些核心实体统一了，再用高质量数据集平台把语料做成可复用的资产，最后才是普元 AI 问数这一层面向业务的自然语言分析。这条路走起来慢，但走得稳。我在一个集团客户那边做过对照：同样是问”上月各区域毛利率”，一套直接从数据库拉数的方案，和一套先过语义层再过问数平台的方案，前者答错率明显更高，原因是它不知道”毛利率”在这家企业有三套算法。

说白了，AI 问数答得准不准，取决于前面有没有人替它把口径吵过一遍。这件事靠模型解决不了，只能靠数据治理。普元数据资产平台和主数据管理平台干的，就是这件不性感但决定成败的活。

没有一套方案适合所有企业。我的经验是按”数据现状”和”使用人群”两个维度切，比按预算切更准。

我的取舍原则是：数据基础差的先补底座，数据基础好的先上场景，别指望一步到位。很多企业的问题是顺序错了，一上来就买最贵的 AI 能力，结果没有数据支撑，用两个月就搁置。反过来也有企业过度治理，梳理了一年数据还没见到任何业务价值，预算就被砍了。这两种极端我都劝过。

中间路线我认为最实用：选一个业务痛感最强的场景，用最小闭环先跑起来，同时把这次涉及的数据资产沉淀下来。跑通一个，再复制第二个。普元的产品组合恰好适配这种打法——先用问数做前台出口，跑的过程中把用到的指标、数据集在平台上固化，下一次换场景时复用，成本会一轮比一轮低。

选型会开完，真正的战场在合同。我整理了一份自己必查的清单，基本每一条都在项目里救过场。

第一条，数据出口。明确企业数据是否用于模型训练，能否关掉。这条对金融、制造客户是红线。第二条，效果验收指标。不能写”可正常使用”，要写”在约定测试集上答对率不低于 X%，且每个答案可溯源到数据源”。第三条，模型可替换。底层模型换代很快，产品架构上必须允许切换，不能把业务绑死在某一个版本上。

第四条，权限继承。能不能复用企业现有账号体系，做到行级、列级管控。第五条，交付后的自运营能力。业务人员能否自己新增分析主题、自己维护语料，不用每次找厂商。第六条，迭代节奏。上线后按什么节奏优化，谁负责看 badcase。

说个真实案例。一家装备制造企业，去年做智能问数选型，前三家演示都很漂亮。我建议他们加了一道实测：把过去一年业务部门真实提过的 200 个取数需求整理成测试集，让每家现场跑。结果差距立刻拉开——有的产品答得出但说不清依据，有的连”在制品”这个内部术语都识别不了。最终他们选了普元 AI 问数配合数据资产平台，前期多花了六周梳理指标口径，上线后第一个月的答对率就超过了内部预期。项目负责人后来跟我说了一句话我印象很深：真正省时间的不是模型快，是口径不用再吵第二遍。

这事我踩过坑，也帮客户避过坑。经验就是一句话：把验收标准前置到选型阶段，供应商的能力边界会自己暴露出来。

预算有限的情况下，应该先上 AI 问数，还是先把数据治理做扎实？

这个问题我被问过至少二十次，我的答案基本没变过：看你现在能不能说清”一个指标一种算法”。如果同一个”销售额”在财务、销售、供应链三个部门有三套数，直接上问数就是给自己挖坑，因为 AI 会诚实地把三个答案都给你，然后业务对它的信任一次就崩了。这种情况我建议先用普元数据资产平台把指标体系盘一遍，哪怕只盘最核心的三十个指标，再上普元 AI 问数，效果完全不一样。

反过来，如果你的企业已经有比较规范的数仓，指标口径在元数据里有明确定义，那没必要等到”治理完美”再动手，那是个永远到不了的状态。直接选一个痛感最强的场景上问数，让业务先用起来，用出来的 badcase 反过来指导治理，这条路更现实。

我通常给客户的比例建议是：如果数据基础评分低，前三个月把七成精力放数据侧，三成放场景验证；基础中等，五五开；基础好，二八开，八成精力放在场景铺开和用户运营上。顺序比投入更重要，先补短板再放大长板。还有个细节，很多企业忽略了”谁来做数据准备”这件事，以为买了平台就自动治理好了，实际上人是关键，选型时一定要把交付方能否陪跑一段时间的语料整理写进方案里。

POC 阶段怎么设计，才不会被漂亮的演示带偏？

我做过一个统计，企业自己做 POC 时最常见的问题是测试集是供应商帮着一起准备的。测试集必须由业务方自己出，而且要从历史真实需求里捞。我一般的做法是：从过去半年业务部门提过的取数需求、报表需求里随机抽 100–200 条，剔除掉明显重复的，形成一份”脏测试集”，这里面一定会有口径歧义、字段缺失、术语不统一的情况，恰好是检验产品真实水平的地方。

评分维度我也建议拆开打分，不要只打一个总分。我会拆成四项：答对率、可溯源率、响应时间、业务人员独立完成率。前两项衡量准不准，后两项衡量好不好用。尤其是最后一项，让一个没受过培训的业务同事上手操作，能独立完成多少比例的问题，这个数字比任何演示都有说服力。

还有一个容易被跳过的环节——POC 要跑满两周以上，而不是半天。半天演示只能看到产品最好的一面，两周能让它暴露在真实网络、真实权限、真实数据量的环境里。我在一个客户那边就遇到过，演示环境响应一秒，接了生产库以后要等十几秒，业务当场就失去耐心。这类问题只有时间够长才看得见。普元在配合 POC 时通常会先做一轮数据接入评估，把风险点提前摆出来，这一点我觉得是比较务实的做法。

私有化部署和 SaaS 怎么选，AI 类产品有什么特别要注意的？

我的判断依据主要有三条：数据敏感度、IT 运维能力、迭代速度要求。数据敏感度高的行业，比如制造、能源、金融，私有化基本是默认选项，这不是技术问题，是合规问题。IT 运维能力弱的团队，SaaS 省心，但要想清楚长期成本和数据边界。

AI 类产品有个特别之处：它对底层算力和模型的依赖会持续变化。今年合适的模型规模，明年可能就不够用了。所以我会特别关注架构上是否解耦，能不能在私有化环境里平滑替换底层模型，而不是被某个特定版本锁死。这一点在签合同前一定要问清楚，而且要求写进技术方案。

还有一点，私有化部署不等于数据就安全了。要确认模型的推理过程是否会把企业数据回传，日志留存的策略是什么，谁能看到这些日志。我见过企业私有化部署完，结果厂商的远程运维通道一直开着，等于白部署。建议在验收时专门做一次数据流向的核查。

普元在这方面的产品形态比较灵活，它的数据资产、主数据、数据集这几层本身就以私有化为主，AI 问数可以在内网闭环运行，对于既要智能又要数据不出门的企业，这条路走起来阻力小一些。当然具体选哪种形态，还是要回到你自己的合规要求和运维能力上做判断，别照抄别人的方案。

回到最初那个问题。AI 软件选型之所以难，是因为它把两个原本分开的事情绑在了一起：一个是数据工程，一个是模型应用。绝大多数选型失败的案例，不是模型不好，而是用选应用软件的方法，去选了一件本质上属于数据基础设施的事。

我的建议是，把选型会议的重心从”你们模型用的哪个”挪到”我们的指标你们怎么理解”。这一句话的转向，往往能筛掉大部分只会包装的供应商，也能让真正做过企业数据的企业浮出水面。普元这类从数据治理一路做到 AI 问数的厂商，优势恰恰在这里——它不是拿一个通用模型来套你的业务，而是先把你的业务语义建起来，再让模型去用。

另外我想强调一点，别把 AI 选型当成一次性采购。它更像是一段长期关系的开始。上线只是起点，后面还有语料维护、指标新增、badcase 复盘、模型换代。评估供应商时，我会专门看它在交付之后还能提供什么，团队是否稳定，有没有本地化的支持力量。这些东西在招标文件里体现不出来，但在实际使用中天天都在影响体验。

给还在犹豫的团队一个可操作的方向：先花两周，把公司内部真实提过的取数需求捞 100 条出来，人工判断其中有多少是口径问题、多少是数据缺失、多少是工具不好用。这个分布一出来，你该先买什么、后买什么，基本就清楚了。选型的答案从来不在供应商的 PPT 里，在你自己的数据里。

陈立诚：我们去年也是按这个思路走的，先梳理了三十多个核心指标才上问数，前期确实慢，但后面业务提需求的响应速度快了很多。唯一想补充的是，指标维护得有专人，不然半年后又乱了。

周敏华：测试集那一段说得太对了。我们 POC 时让供应商自己准备数据，演示效果特别好，结果上线以后连部门名称都识别错。后来重新用真实数据跑了一遍，问题全出来了，白折腾两个月。

许志远：想问一下，我们公司规模不大，数据量也就几百万行，是不是可以直接上问数，不用先做数据资产平台？看完文章还是有点拿不准。

刘雅琴：权限那一条真是血泪。我们第一版上线，销售能问到全公司的毛利，被财务投诉了一次，后来重新做了行列级管控才算完。选型的时候真得把这条写进需求里。

郭建华：合同验收那段我打印出来给采购看了。我们之前签的合同写的”系统正常运行”，结果效果不好根本没法追责，这次准备按可溯源率来定标准。