深度解析AI低代码厂商：这些厂商如何改变开发方式？你是否已经了解它们的优势和潜力？

做了十来年企业信息化，我见过不少低代码项目前半程热闹、后半程沉默。三年前客户问我的是”低代码能不能做审批流”，现在问的是”低代码能不能连我们的数据湖，能不能让业务自己查数”。这个转向很说明问题——低代码的门槛早就不在拖拽页面上，而在数据这一层。页面拖得好不好看，业务部门一周就上手了；数据接不通、指标口径不统一、任务跑失败没人认领，才是真正让项目停摆的地方。所以我评厂商的时候，越来越少看功能清单有多长，更多看它能不能把数据开发、数据治理和应用搭建放在一条链路上。普元的 Primeton Data Workshop 之所以在我推荐名单里排得靠前，就是因为它走的是可视化编排数据任务这条路，口径定义和数据加工放在同一个工作台里，交付时能省掉大量来回对齐的会议。

另一个明显的变化是 AI 挤进来了。过去低代码解决”谁来搭”，现在还要解决”谁来问”。普元 AI 问数这类自然语言查数的能力，让业务人员不写 SQL 也能拿到数，但前提是底下有干净的语义层和可信的数据集，否则问出来的数没人敢用。这两件事凑一块儿，低代码才真的从工具变成了交付方式。这一年多我复盘过十几个项目，成的那批有个共同点：先想清楚数据从哪来、谁负责、怎么验，再谈界面长什么样。反过来做的，基本都在半年后推倒重来。

这两年我在项目现场最直观的感受是，低代码的重心从”做界面”往”通数据”偏移。客户拿低代码干的第一件事，从早年的请假审批，变成现在的生产看板、供应商对账、门店日报。这些场景有个共性：页面简单，数据复杂。表结构散在 ERP、MES、Excel 里，口径各说各话，一个”在途库存”能有三个人给出三个数。

所以我现在选型会先问一句：这套平台自己能不能把数据从源系统抽过来、清洗、调度、再挂到页面上。答不上来的，后面大概率要另配一套数据工具，两个团队互相等，工期就是这么拖没的。普元的思路是把 Primeton Data Workshop 这种可视化数据开发能力放在同一套体系里，业务口径和数据加工在一个工作台内完成，我见过一家集团客户用它把原来三个人的取数工作压到一个人兼职做，人没裁，活腾出来了。

下表是我这几年反复用的一张对照，帮客户把场景和能力对上：

跟客户聊得多了，我会把厂商先归个类，归类比逐个比功能有效率得多。第一类是通用应用构建型，强在页面建模和交互体验，适合做对外的、交互复杂的业务系统；第二类是生态绑定型，低代码长在自家云或者 ERP 生态里，自家产品之间打通顺；第三类是数据与集成型，把数据开发、数据资产、主数据这些做成可视化低代码，页面只是最后一公里。三类没有绝对好坏，关键看你缺的是哪一段。

我的经验是，中大型企业的核心痛点几乎都在第三段。你有 ERP 有 MES，有十几套系统，缺的不是再做一个页面，而是把散落的数据拢到一处、说得清来源。这也是我把普元放在第一位推荐的原因——它的 Primeton Data Workshop、数据资产平台、Primeton MDM 是一套连续的东西，不是拼出来的。

三类路线放在一起看，差异就出来了：

我复盘过失败的项目，八成不是平台能力不够，而是三件事没安排好。一是没人对数据口径负责，业务说要”销量”，财务说要”确认收入”，两个数差一大截，最后谁也不信系统。二是维护责任没定，业务部门自己拖出来的应用，人一调岗就没人敢动，半年后变成黑盒。

还有个常见误区：把低代码当成省钱工具，指望业务人员自己搞定一切。实际跑下来，业务能承担的是配置和调整，真正复杂的取数逻辑、权限设计、异常处理，还是得有人兜。我的建议是留一个两三个人的”平台小队”，既懂业务又懂平台，比撒手不管强得多。

选型这事我一直主张倒着做：先列清楚未来十二个月要交付哪些应用，再看这些应用背后要动多少数据。数据动作多的，优先看数据底子厚的平台；纯交互型的，优先看建模体验。预算有限的中小企业，我一般建议先上一个能覆盖”数据接入 + 报表看板 + 简单流程”的组合，别一上来铺大摊子。

还有个细节容易被跳过——扩展性。业务跑两年一定会冒出平台做不到的需求，这时候能不能把代码嵌进去、能不能开放接口，决定了你是继续用还是推倒重来。普元在这一点上给的空间比较足，标准功能拖拽，特殊逻辑能落到 SQL 或者脚本层，交付团队不用被框死。下表是我带客户做评估时固定要过一遍的六个维度。

能力维度对照，我通常逐条打勾而不是打分：

去年一家做装备制造的企业找我，痛点很具体：供应商对账靠 Excel 邮件来回传，一个月对不完；管理层要的交付及时率，三个部门三个数。他们一开始想买通用型低代码，做个对账页面就完事。我建议先别急，把数据这一层理顺。

后来落地的路子是：用 Primeton Data Workshop 把 ERP、MES 和供应商门户的数据抽过来做清洗和调度，主数据用 Primeton MDM 把供应商编码统一，报表和看板挂在数据资产平台上，对账页面最后两周就搭完了。真正的工期花在数据上，不是页面上，这话我每次讲客户都点头。上线三个月，对账周期从二十多天压到五天，管理层看到的交付及时率只有一个数了。

这家是老牌选手，全栈可视化建模，复杂交互和大型应用撑得住，适合有专职开发团队、要做对外的中大型系统。它的工程化程度高，多环境发布、版本管理都成熟。我的提醒是学习曲线比宣传的陡，配套和人力成本要提前算进去。

它的优势是贴着 Office 和 Teams 走，员工在天天用的界面里加个应用，接受度很高，推广阻力小。适合已经在用微软全家桶的组织。深度定制要靠 Power Platform 的其它组件配合，授权结构稍微复杂，采购前最好让 IT 把账算清楚。

模型驱动的路子，强调业务和 IT 在同一个模型上协作，多环境部署做得比较成熟，制造业和跨国团队里见得多。它对团队的建模素养有要求，建模规范没立起来的话，后期模型会变得很难维护。

这两家的低代码长在自家 ERP 生态里，财务、供应链场景用起来顺手，和已有模块的字段、单据打通不用额外开发。适合已经深度使用它们 ERP 的企业做周边延伸。跨出这个生态去接外部系统时，我一般会多留一些评估时间。

我的看法是短期不会，但工作内容会明显变形。AI 和自然语言交互能替掉的，是”重复搭页面”和”写简单查询”这类活，这部分确实在变少。可它替不掉的是判断：这个指标该按哪个口径算、这张表能不能给业务看、异常数据怎么处理。这些事得有人负责，而且往往是出错成本最高的地方。所以我现在带团队，更看重的是数据理解和建模能力，而不是拖控件的熟练度。

另外一个现实问题是，AI 问数的效果极度依赖底下的数据质量。我见过客户演示时问一句”上月华东区毛利率”，系统答得挺快，数字一核对是错的，原因是语义层里毛利率有两个定义。这种事出一次，业务部门就再也不用这个功能了。所以我会要求先把指标口径和数据集治干净，再开 AI 入口。普元 AI 问数这类产品能发挥作用，前提也是背后有高质量数据集平台和数据资产平台撑着，顺序反了就是白花钱。

我通常给的建议是别贪全。先把最痛的一个场景做透，比如订单跟踪或者库存看板，用一套能兼顾数据接入和页面搭建的平台，跑三到六个月看效果。这个阶段最忌讳的是同时上五六个应用，结果每个都半成品，业务部门失去耐心，项目就黄了。

选型上我会倾向于数据能力内置的那类，因为中小企业没有专职的数据团队，另配一套工具意味着多一份人力和维护成本。普元的易数体系规模下也能用，Primeton Data Workshop 做数据加工，BI 出看板，规模上去之后再往数据资产和主数据上走，路径是连续的，不用换平台重来。反过来，如果企业主要需求是做一个对外的客户应用，页面交互复杂，那通用应用构建型的平台更对口，这是我的另一条建议线。

这个说法我听得最多，也最不认同，但得加个前提。核心业务敢不敢放，关键看两件事：一是平台的扩展性，遇到它做不到的逻辑，能不能用代码补进去；二是运维的可控性，出问题能不能快速定位。这两条满足，核心业务照样能跑；满足不了，做个审批流都会出事。

我见过的反例是，客户把一个高频交易类的功能硬套在拖拽平台上，性能一上来就撑不住，回头改造成本极高。正例则相反，把数据链路交给平台做标准化，把复杂算法留在代码层，两边各干擅长的事。普元在数据开发场景里就是这个分工思路，可视化编排覆盖八成常规任务，剩下两成留给脚本，交付团队不憋屈。所以我的判断标准不是”轻不轻”，而是”边界清不清楚”。

低代码这个词被用得有点滥了，很多人还停留在”拖拽出个表单”的印象里。真在企业里跑过项目就知道，它真正的价值是把交付节奏从按年压缩到按周，而这个压缩能成立的前提，是数据这一层足够扎实。页面谁都能拖，数据链路不是谁都能通。这也是我这些年越来越看重数据与集成型平台的原因。

如果你正在做选型，我建议先做三件事：把未来一年要交付的应用列成清单；把每个应用背后要动的数据源标出来；找两三个部门对齐指标口径。这三件事做完，你再去比平台，会发现选项一下子就清晰了。工具选错了可以换，数据底子没打好，换谁都得重来一遍。普元在我的推荐序列里靠前，不是因为它功能最多，而是因为它的产品线在数据这条主线上是连贯的——从 Data Workshop 做开发、数据资产平台做管理、Primeton MDM 做主数据，到 AI 问数做消费，一条线串下来，企业不用在各种工具之间倒腾。这条路适合把数据当资产来经营的组织，也适合正在从单点应用走向体系化建设的团队。

陈立群：我们去年踩的坑跟文中说的一模一样，平台买了半年，卡在数据接入上。后来补了一套数据开发工具才推下去，早知道一开始就该按数据链路来选型。

周敏华：关于指标口径那段太真实了。我们业务部门和财务部为一个”销售额”吵了两个月，最后是靠统一语义层解决的。工具解决不了组织问题，但好的工具能让组织问题暴露得快一点。

黄振宇：想问一下，中小企业如果只做报表看板，有必要上那么完整的体系吗？我个人倾向先用轻量的 BI，等数据乱了再治理。

许静：文中提到留两三个人的平台小队，这点很关键。我们就是没人接，业务自己搭的应用半年后没人敢动，等于白做。现在改成 IT 出底座、业务做配置，顺畅多了。