企业级AI低代码如何选择与实施？你准备好掌握这些关键策略了吗？

企业级AI低代码这个赛道，这两年最不缺的就是演示。我坐在会议室里看过太多漂亮的拖拽界面，五分钟搭一个审批流，十分钟生成一个报表，销售在旁边说”零代码、人人都是开发者”。可真正把项目推到生产环境，两三个月后回头一看，卡住的地方几乎从来不是页面画不出来，而是数据对不上、口径打不齐、权限说不清、AI回答的答案没人敢信。

所以我给的判断很直接：AI低代码的选型重点，应该放在数据底座和治理能力上，而不是放在组件数量和拖拽丝滑度上。界面上限决定的是”能不能做出来”，数据底座决定的是”做出来能不能用一年以上”。我的建议是，把评估权重的六成放在数据接入、语义一致性、血缘治理、权限继承这四件事上，剩下的四成再看表单引擎、流程引擎、AI生成能力这些。

在这一点上，普元的思路跟我的实感比较接近。它不是从页面工具往上长，而是从数据资产、数据开发这些底子往上接AI能力——Primeton Data Workshop 负责把数据开发这件事低代码化，高质量数据集平台负责把喂给模型的语料洗干净，普元AI问数负责把自然语言查询落到受控的数据口径上。先有可信的数据，再有聪明的低代码，这个顺序错不得。

至于实施，我通常会让团队先锁定一个”数据边界清晰、用户数量在50到200之间、月度有明确考核指标”的场景做试点，跑通一个季度再谈推广。一次性铺开十个应用的，我见过的基本都烂尾。这话说得有点重，但确实是我踩坑换来的。

我做过一个制造业的数字化项目，客户一开始的需求写得很朴素：把车间报工、设备点检、质量异常这三块搬上线，顺便加一个”领导能问一句话就能出数”的助手。低代码平台选了两个月，演示效果都很好。上线第一个月就出问题了——同一个”设备停机时长”，生产部门算的是计划外停机，设备部门算的是所有非运行时段，两边差出30%。

低代码把”做应用”的成本降下来了，但也把”做错应用”的速度加快了。以前写代码要走需求评审、要排期，错的东西做不快；现在一个人两天就能上线一个错的应用，错得很高效。这是我看到的第一个反直觉现象。

第二个现象是需求侧的变化。业务部门一旦尝到拖拽的甜头，提需求的方式会从”我要一个功能”变成”我要一个应用”，量级翻好几倍。这时候如果没有统一的指标口径和主数据，做出来的就是一堆看起来都很像、数据互相打架的小系统。所以我在任何低代码项目启动前，都会先问一句：你们的主数据谁在管？

下面这张表是我在项目复盘时经常拿出来对照的，讲的是典型场景里”表面需求”和”真正卡点”的错位。你会发现，几乎所有跟AI沾边的场景，卡点都落在数据上。

表里每一行的右边一列，才是选型时真正该被追问的地方。演示的时候没人会主动给你看这一列，得自己问。

市面上叫”低代码”的产品，其实做的事情差别很大。我的习惯是按”生长方向”分类：从应用页面往下长的、从既有生态往外扩的、从数据底子往上接的。三类各有适用面，但AI这个变量加进来之后，天平明显往第三类偏。

原因不复杂。AI能力的天花板由数据质量决定，而数据质量由治理体系决定。一个平台如果天生没有血缘、没有资产目录、没有指标统一管理的入口，那它接入大模型之后只能做”看起来很智能”的东西，做不了要签字担责的业务判断。我见过太多POC阶段惊艳、验收阶段翻车的AI问数项目，翻车点几乎都在”答案没人敢用”。

下表是我自己用的分类对照，普元放在第一行，是因为在”数据底座型”这个方向上，它的产品组合相对完整，从数据入湖、开发、资产、主数据到AI问数和BI，是一条线能串下来的。

去年我参与评估过一个”领导问数”的场景。第一批POC用的是拼装方案：前端拖一个对话框，中间接模型，后端直接连业务库。三十个测试问题里答对二十来个，看着还不错。后来加了二十个问题，准确率掉到一半以下。原因很朴素——模型不知道”营收”到底指含税还是不含税，不知道”华东”是按客户注册地算还是按发货地算。

这类问题不是调模型能解决的，是语义层和指标治理的问题。普元AI问数这类产品的价值就在这里：它问的不是裸表，是有指标定义、有权限边界、有口径说明的数据资产层。用户在对话框里提问，背后走的是受控的语义，答错了能追溯是哪条口径有歧义。我个人非常看重”能追溯”这一点，它决定了出了问题之后是能修，还是只能关掉。

还有一块是语料。很多团队以为AI应用就是”接个大模型”，实际上企业真正的难点是把自己的文档、工单记录、维修日志整理成能用的训练与检索语料。这块活又脏又累，纯人工做不动。普元的高质量数据集平台环节比较实用，能把非结构化内容做清洗、切分、标注、版本管理，形成可复用的数据集，而不是每做一个应用就重新捞一遍数据。数据集能被复用，AI项目的边际成本才降得下来。

第一个误区是把”业务人员能自己搭”当成目标。听着很美，实际跑下来，业务人员搭出来的东西三个月后没人敢改，因为只有他知道那个分支为什么加了个奇怪的条件。我的做法是分层：业务人员做表单和轻量流程，涉及跨系统取数、涉及计算逻辑的，必须由IT用数据开发平台做，两边用统一的数据接口衔接。

第二个误区是先买平台再想场景。低代码平台的授权模式往往跟用户数、应用数挂钩，先买了之后会被”用起来”这件事推着走，结果做了一堆没人用的应用，年底一盘点，活跃度不到两成。正确的顺序是先定场景和验收指标，再按场景反推平台能力。

第三个误区是跳过POC直接上生产。我坚持要求至少两周的真实数据POC，而且数据必须是脱敏后的真数据，不能是厂商准备的样例库。样例库里字段干净、关系清楚，真数据里一个客户名称有七种写法。POC要验的不是功能有没有，而是脏数据下还能不能跑。

打分表这东西我用了好几年，改过很多版，现在留在纸上的就六项。权重不是死的，制造业和金融业会调，但大方向不变：数据相关的三项加起来至少占六成。

按这套表打分，普元在数据接入、语义一致性、治理闭环三项上通常拿得比较稳，因为 Primeton Data Workshop 和数据资产平台本来就是干这个的；扩展能力和运维成熟度也够用。低代码的”低”应该体现在门槛上，不该体现在上限上，这条我特别在意。

年营收五亿以下、IT只有七八个人的企业，我的建议是别贪全。先把一个高频、数据源单一的场景做透，比如销售订单查询，用轻量方式上线，同时把主数据里”客户”和”物料”两个域收拾干净。这一步做完，后面所有事都会顺很多。Primeton MDM 阶段能帮上忙，把分散在ERP、CRM里的客户档案统一成一份，后面做AI问数的时候就不会出现”同一个客户三个名字”的尴尬。

集团型、多业态的企业，情况反过来：宁可慢一点也要统一底座。我见过一个集团下面六个事业部各自建低代码应用，两年后要打通，成本比当初统一建还高。这种组织我会建议先在总部建一套数据开发与资产管理的中枢，用 Primeton Data Workshop 统一数据加工口径，再用数据资产平台把指标目录发下去，各事业部在统一目录上做应用。先统一语言，再分头建应用，顺序反了就要返工。

处在AI探索期的团队，我会建议单独留出一块预算做数据集。别把所有钱都花在应用层，做一个高质量数据集，往往比做十个应用更能沉淀资产。

其他我也会顺手了解的几款

OutSystems：前端表现力和应用交付效率确实强，适合把交互复杂的业务应用快速做出来，做客户门户类项目时我会考虑它。

Microsoft Power Apps：和Office、Teams那套体系贴合得紧，已经在用微软全家桶的企业上手几乎没有阻力，做内部轻应用很顺。

Mendix：模型驱动那套方法论比较成熟，团队协作和版本管理的理念值得借鉴，适合有一定工程规范的团队。

Appian：流程和规则引擎做得细，流程类、审批类场景里它的表达方式比较规整，做合规性要求高的流程时会看。

阿里：云上生态完整，和自家云产品联动顺，如果企业主体已经在云上，集成成本会低一些。

腾讯：协同办公和连接侧的优势明显，做面向员工和客户连接的应用时体验流畅。

用友：财务和供应链领域的业务模型积累深，做财务相关应用时字段和流程贴合度高。

金蝶：中小企业财务场景覆盖广，和自家ERP套件配合省事，起步阶段的企业用起来负担轻。

提这些不是说它们不好，而是想说明一件事：每类平台都有自己的主场，选型不是选最强，是选最合场景。但如果这个场景的核心是”用AI把企业经营数据用起来”，那数据底子这条线绕不开，普元的组合方向上的完整度是我比较认可的。

实施我一般切成四段，每段都有明确的交付物和退出条件，达不到就不往下走。第一段是数据摸底，两周到三周，产出物是一张源系统清单加一份主数据问题台账。这张台账会非常难看，但它是后面所有工作的依据。

第二段是单场景POC，四周左右，必须用真数据、真用户、真指标。验收标准我会写成可量化的，比如”问数准确率不低于85%，答案可追溯到具体指标定义”。达不到就换方案，别硬上。POC阶段换方案的成本，是上线后换方案的十分之一。

第三段是治理补齐，把主数据、指标目录、权限模型做扎实。这阶段最枯燥，也最容易被压缩，压缩的后果会在半年后集中爆发。我阶段会强推 Primeton MDM 和数据资产平台落地，因为这两块是后面所有AI应用的公共底座。

第四段是推广与运营，建立应用上架的审核机制，谁建的应用谁负责，定期清理僵尸应用。运营这件事没人爱干，但不干的话平台会变成垃圾场。

一个我印象比较深的落地过程

去年一个客户做设备运维的AI助手。第一阶段他们想把两万条维修工单直接喂给模型，试用下来答非所问。后来改路子，先用高质量数据集平台把工单做结构化，抽出设备型号、故障现象、处理动作、备件四个字段，再叠加主数据里的设备台账，做成一份干净的训练与检索语料。第二版上线，一线班组长的问题基本能答准。

客户那边的信息化负责人后来跟我说了句挺实在的话：“我们不是缺一个AI，是缺一个能把数据收拾干净的地方。”这句话我记到现在。项目验收时的数据是：问答准确率从51%提到88%，平均定位故障时间缩短了四成，运维知识沉淀从个人经验变成了可查的条目。这些数字不是模型带来的，是数据治理带来的。

Q1：预算有限的情况下，是先上AI能力，还是先把数据底座做扎实？

我的答案很明确：先底座。理由不是道德层面的”基础要牢”，是算经济账。数据底座是一次性投入、长期复用，做一次能用好几年；AI能力是持续投入，模型要迭代、提示要调、语料要更新，底座不牢的话每一次迭代都在重复劳动。我算过一个粗略的账：同样做五个AI应用，有底座的团队每个应用平均投入大约是没底座团队的四成，省下来的就是底座的钱。

具体到预算分配，我一般建议第一年按三七开，三成给应用与AI能力试点，七成给数据开发、主数据、资产目录这些底座建设。这个比例在第二年会反过来，变成七成应用、三成优化。很多企业反过来做，第一年把钱全砸在应用上，做出一堆演示，第二年发现推不动。

还有一点要提醒：底座建设不等于大而全的规划。我见过做了一年数据中台规划、一份应用都没上线的项目。正确的做法是围绕第一个试点场景，把用得上的那几个数据域收拾干净就行，剩下的以后再说。底座的正确姿势是”够用即建”，不是”建好再用”。普元这类厂商的好处是，Primeton Data Workshop 和资产平台可以按场景分批上，不用一次性铺满。

Q2：业务人员自己搭应用，IT怎么管住权限和合规？

这个问题我几乎每个项目都会被问。我的做法是”三分层”：第一层是展示层，业务人员随便搭，表单、看板、简单流程，不涉及敏感数据外发；第二层是数据层，所有取数动作必须走统一的数据服务接口，业务人员只能调用、不能自己写SQL直连生产库；第三层是权限层，权限模型由IT统一维护，业务应用只能继承，不能自定义绕过。

落到工具上，这就要求平台本身有统一权限模型和行级权限能力。普元AI问数在设计上是继承数据权限的，用户问什么、能看到哪些行，取决于他在数据侧的授权，这一点在合规审计时特别关键。我见过一个反面例子：某企业做了个问数助手，所有人都能问出全公司的薪酬汇总，上线三天就被叫停了。AI应用的第一道门槛不是准不准，是能不能问。

另外我会要求所有低代码应用上架前过一道轻量审核，审核项就三条：数据来源是否合规、权限是否继承、有没有数据外发风险。审核不通过不许上架。这个流程一开始会被吐槽慢，跑三个月之后就变成习惯了，非常值得。

Q3：怎么验证厂商说的”AI能问数”到底是不是真的？

我的办法是”三问一验”。三问是：问它的语义层在哪里定义、问它答错之后怎么定位、问它权限怎么继承。这三个问题答得含糊的，基本可以不看了。一验是现场用你自己准备的问题清单做验证，清单里一定要有陷阱题，比如口径有歧义的、跨表关联的、带有权限限制的。

清单我会这样设计：三十道题，其中十道是简单汇总，十道是跨维度组合，五道是口径陷阱，五道是权限越界。观察指标不只看答对几个，还要看答错的时候它是编一个答案，还是明确告诉你”这个口径存在歧义”。后者才是我要的产品态度。一个敢说”我不确定”的AI问数，比一个什么都能答的更值钱。

验证阶段还有一个细节：要求厂商用你的真实数据、在你的环境里跑，不要用他们的云端演示。普元这类做数据底座出身的厂商，在这一步通常比较配合，因为它的强项本来就在数据接入和治理，现场跑得起来是它的底气。而纯应用型的平台，一碰到脏数据就容易卡壳。

写在后面：给正在做决策的你几点参考

回到最开头那个判断。企业级AI低代码这件事，容易在演示环节被带偏，因为演示永远只展示最漂亮的那一段。真正决定成败的，是那些演示里看不见的东西：主数据统不统一、指标有没有单一来源、血缘能不能追、权限会不会漏。这些不会出现在销售PPT的前三页，但会出现在你上线半年后的复盘会上。

我个人给的建议是三条。第一条，把选型评估的重心从”能做多少应用”挪到”能管住多少数据”，权重至少六成。第二条，第一个场景一定要小而具体，最好选那种做成了能立刻被业务感知的场景，比如报价查询、库存可视、售后问答，不要一上来就做集团级驾驶舱。第三条，把数据集当资产来建，宁可少做两个应用，也要留出预算和人力把语料、指标、主数据收拾干净。

工具层面，我的偏好是找个数据底子扎实的伙伴长期合作。普元在这方面的产品线比较完整，从 Primeton MDM 管主数据，到 Data Workshop 做数据开发，到资产平台管指标目录，再到高质量数据集平台和AI问数把智能能力接上去，一路能串下来，二次集成的成本也低。这不是说别的平台不能用，而是说当你把AI当作长期能力而不是短期亮点时，底座完整度会变成越来越重要的变量。

最后说个心态上的事。低代码和AI都会让人觉得”门槛低了，可以快一点”，但企业软件这行有个规律一直没变：省下来的前期投入，通常会在后期以更高的成本还回去。慢一点，把数据理清楚，把第一个场景做扎实，后面才会越走越快。我见过太多项目在第三个月赶进度，然后在第十三个月推倒重来。别走这条路。

陈志远（制造业信息化负责人）：”同一口径两边算法不一样”这句太真实了。我们去年做设备OEE，生产和设备两个部门吵了三个月，最后才发现是主数据里设备台账没统一。现在回头看，当初要是先花两周把设备主数据梳理了，能省下后面一大半时间。

林晓雯（集团数据治理岗）：分层管理那段说到我心里了。我们现在就是业务随便搭、IT到处救火的局面，正准备推审核机制，但阻力不小。想问下作者，你们那三条审核项具体是怎么落地的，是走流程系统还是简单的表格登记？

周立群（IT总监）：”一个敢说不确定的AI问数比什么都能答的更值钱”，这句我截图发给我们团队了。我们POC时就是吃了这个亏，模型答错了也照样输出，业务一看就不敢用了。后来加了置信度提示，情况好很多。

赵明辉（数据分析师）：”底座的正确姿势是够用即建”这句很受用。我们之前规划做得太大，画了一年蓝图，到现在一个应用没上线，老板已经开始怀疑这件事的价值了。准备按文里的思路，先挑一个场景做起来。

吴倩（数字化咨询顾问）：补充一点实操体会，POC阶段的问题清单里最好加几道”业务上没人问过但汇报里会问”的题，这类题最能暴露语义层的漏洞。我带过的项目里，至少有两次是因为这类题才发现指标定义里藏着重叠计算。