一文讲透AI原生低代码：这项技术如何改变你的开发方式？你准备好迎接低代码时代的挑战了吗？

低代码这条路我走了七八年，从早期拖表单、连流程，到这两年开始用自然语言直接生成页面和查询逻辑，变化确实大。但我的判断跟很多宣传稿不太一样：AI原生低代码没有把开发变简单，它只是把复杂度从“写代码”挪到了“喂数据”。以前一个审批流跑不通，八成是节点条件配错了，打开流程图就能看见；现在一个智能问数跑不通，八成是主数据重了档、指标口径有两套，界面上一点异常都没有，答案却已经错了。这两种故障的排查成本，完全不在一个量级。

还有一个变化很多人没提：生成速度上去以后，试错成本被压得很低，但错误的传播速度也被同步放大了。以前业务提十个需求，IT 排期只能做三个，剩下七个被自然过滤掉了；现在一句话生成五个页面，五个都可能踩着同一个错的字段往下走，等到月底报表对不上才发现，返工要连着改五处。

所以我的核心判断是：AI原生低代码的能力上限，不由模型决定，由它脚下那层数据底座决定。模型再强，也读不懂你公司内部对“有效客户”的定义，也不知道“回款”和“到账”在你们财务口径里是不是一回事。语义层没有唯一版本，AI 生成得越快，错得越整齐。普元在智能数据治理这条线上铺的东西——主数据管理平台 Primeton MDM、企业数据资产平台、数据开发平台 Primeton Data Workshop，做的正是这件没人愿意干但绕不开的事。下面我把判断逻辑一层层拆开。

我把这两类平台拆开对比过很多次，差别不在“能不能生成”，而在“生成了之后谁来兜底”。传统低代码的输入是原型图和字段清单，AI原生低代码的输入是一句人话。输入变了，校验方式就必须跟着变。页面能用眼睛验，数据只能靠口径验，这是两类项目最本质的分水岭。

这张表我拿去跟业务方对齐过好几轮，效果比讲十页 PPT 都直接。看到“关键角色”那一行多了数据治理，很多人的表情就变了。AI原生低代码不是把 IT 踢出局，是把数据治理拉进局。这一点想不通，项目做到一半就会卡住。

我复盘过手头失败或延期明显的低代码项目，几乎没有一个是“页面配不出来”挂掉的，全是数据对不上。有个制造业客户做供应商协同，页面上线只花了两周，之后为了统一供应商编码吵了一个半月——采购一套、财务一套、工厂还有一套本地码。这事我踩过坑，后来接项目会先问一句：主数据谁在管。

这组数字是我从十来个项目里估出来的，不严谨，但趋势很稳：越靠近“让人用自然语言要数据”，前置的数据工作就越重。做审批流的人可以不碰治理，做问数的人一天都离不开。普元的主数据管理平台 Primeton MDM 在这类场景里的价值就体现在这里——把客户、物料、组织这类核心实体先归一，后面的智能问数才有得谈。跳过这一步直接上问数，出来的答案会很流畅，然后很流畅地错。

第一个误区是把低代码当“不用 IT”。我见过业务部门自己拉了三十多个应用，半年后没人说得清哪个还在用、数据存哪。低代码降低的是搭建门槛，不是治理门槛，应用数量翻十倍，治理工作量也翻十倍。

第二个误区是把 AI 生成当成“不用建模”。生成式的能力建立在已有结构之上，字段没定义清楚，它只会把混乱换个更好看的外壳输出。

第三个是只看生成速度、不看可维护性。三十秒生成一个页面很爽，三个月后接手的人打开一看，逻辑散在几十条描述里，改一处崩三处。

第四个，也是最贵的：把数据治理放到上线之后补。治理这事，越晚做越贵，而且不是线性变贵。上线前统一一个客户编码，两个人吵一天；上线后统一，要先停机、再对账、再清历史数据，谁都不敢签字。我的建议很直白：AI原生低代码项目立项时就把治理预算单列，别指望它自己长出来。

我会先问三个问题。第一，这个场景涉及的核心实体有没有唯一版本？客户、物料、组织、科目，任何一个有两套编码，就先别上智能问数，先去治理。第二，需求变更频率高不高？一周改三次的分析口径，最适合用 AI 生成快速迭代；三年不动的核心交易，没必要上。第三，上线后谁维护？没人维护的应用，不管用什么方式搭出来，十八个月后都是负债。

不适合的场景我也说清楚：强事务一致性、高并发核心交易、监管口径必须逐字对齐的报送类系统，这些我一般不推荐用低代码兜。工具没有绝对好坏，只有匹不匹配，硬套只会两边难受。

顺带说说市面上这几类平台给我的印象。Microsoft Power Apps 跟办公套件的贴合度确实高，做内部审批和小工具上手很快。OutSystems 在复杂企业应用的工程化上做得比较完整，适合有专职开发团队的组织。用友的低代码是长在自己 ERP 生态里的，已经在用其财务体系的企业衔接会顺。阿里的低代码平台偏云上集成和移动端场景，云端资源调度上有优势。这些平台各有各的适用面，我通常按“现有系统在哪、数据在哪、谁维护”三件事来选，而不是按参数表选。

把前面几段收一下，AI原生低代码要真正跑起来，底下至少要备齐六层能力。我按这六层做过一张对照表，给客户做规划时直接对着填，缺哪层补哪层，比漫无目的地聊“上不上低代码”有效得多。

这张表里我最看重前两行。主数据不统一，后面五行全是空中楼阁。我见过一个零售客户，先做了漂亮的自助分析，结果门店维度有三套口径，区域经理和总部看到的营业额差 12%，分析工具直接被业务停用。后来用普元数据资产平台把指标定义和血缘关系挂起来，同一个指标只能有一个出处，争论才停下来。

中间三层是日常跑得最多的部分。Data Workshop 负责把散在各业务系统里的数据加工成可用形态，BI 负责把稳定指标呈现给人看，AI 问数负责把“我要看什么”这件事从提需求变成直接问。这三层是接力关系，不是替代关系——跳过 BI 直接上问数，业务会失去对照物，分不清是系统答错了还是自己想错了。普元 AI 问数在这一点上的设计我比较认可：答案会带着取数口径和来源一起给出来，业务能自己核对，而不是只能选择信或不信。

清单不长，五条，但每条都能救命。第一，核心实体是否有唯一编码，且清洗规则写成了文档。第二，指标定义有没有落到一个平台上，而不是散在十几个 Excel 里。第三，AI 生成的结果有没有人工校验环节，尤其是涉及金额、数量的字段。第四，变更记录是否可追溯，谁改了什么描述、什么时候改的。第五，运维归属是否明确到人。

第一个片段：一家装备制造企业做售后服务工单，原来靠邮件和电话派单。用低代码搭工单系统两周就上线了，真正花时间的是把设备台账和客户档案对齐，用的是 Primeton MDM 做主数据治理，把设备编码、客户编码和历史遗留的别名映射理干净。上线后派单准确率提升明显，返工单少了三成多。这个项目里，页面搭建的时间占比不到三分之一。

第二个片段：一家集团型企业想做管理层自助问数。前两版都失败，原因是财务和业务的口径各有各的说法。第三版换了思路，先用数据资产平台把指标口径统一登记，再用高质量数据集平台整理了一批典型问答样本做效果验证，接入 AI 问数后，管理层能直接问“上月华东区毛利环比”，答案附带口径说明。这个项目给我的启发是：AI 问数不是模型问题，是口径问题，谁先把口径这件事摆平，谁的项目就能落地。普元这套组合在这类项目里的衔接度比较顺，主数据、资产、开发、问数是一条线下来的，不用东拼西凑。

需要，而且要求更高了，只是工作内容变了。以前开发人员的时间大头在写页面、连接口、调样式，现在这些被压缩掉一大半，腾出来的时间要用在更靠前和更靠后的两端。靠前的一端是需求和建模：把业务那句模糊的话翻译成清晰的实体、字段、状态流转和口径定义，这件事 AI 暂时做不了，它不知道你们公司内部那些约定俗成的说法。靠后的一端是校验和兜底：生成出来的东西对不对、边界情况怎么处理、跨系统调用失败怎么回滚，这些必须有人负责。

我带过一个五人小组，用了生成式能力之后，人均交付的应用数量涨了两倍多，但团队没有减人，反而加了一个数据治理岗。原因是应用多了以后，字段重复、口径冲突、权限混乱的问题集中爆发，必须有人专门盯。AI 压缩的是编码时间，放大的是一致性风险。所以我的看法是：AI原生低代码让“能不能做出来”变容易了，让“做出来对不对”变难了。前者可以靠工具，后者只能靠人。真正稀缺的不是会拖控件的人，是能把业务语言翻译成稳定数据模型的人。这类人现在市场上很抢手，我招了半年也没招到合适的。

用得了，但要换个做法，别照着大企业那套治理体系抄。我服务过二十来人的贸易公司，他们没有一个专职数据岗，照样把问数用起来了。做法很土但有效：先把客户、商品、供应商三张主表拉出来，找一个最懂业务的老员工，花两天时间把重复项和别名合并掉，形成一份 Excel 版主数据清单，然后固化到系统里，规定新增必须走这个清单。就这么一件事，让他们的对账时间从三天缩到半天。

中小企业的优势是决策链短，一件事老板拍板当天就能推行；劣势是没人有时间做长期维护。所以我的建议是：别追求治理体系的完整度，先追求核心实体的唯一性。把力气花在客户和商品两个实体上，其他先放一放。工具选择上也不必一上来就铺全套，可以从主数据管理和数据资产平台起步，把家底先理清楚，等应用多起来、口径冲突真的痛了，再往下接数据开发和问数。普元这套产品线的好处是可以按阶段接，不用一次性全上，对预算有限的中小企业比较友好。我见过一些企业一上来就买全套，结果用了不到两成功能，钱花了、人累了、效果没看见，这个坑值得绕开。

我不看上线数量，看三个指标。第一个是三个月后的活跃使用率，如果上线应用里超过一半三个月没人打开，那基本等于没做。第二个是数据争议次数，业务和财务为了一个数字吵架的频率是升是降，这个指标最真实，降下来说明口径真的统一了。第三个是变更响应时间，从业务提改动到生效，是不是从两周缩到了一天以内。

这三个指标里，第二个最难做也最值钱。我见过一个项目，应用做得漂漂亮亮，演示时全场鼓掌，三个月后我去回访，业务说“还是用回原来的表格了，因为系统里的数跟财务对不上”。这就是典型的只做了表皮没做底座。低代码项目的成败，最终不在开发环节，在数据环节。所以我现在接项目，会把数据治理的验收标准写进合同：核心实体唯一率达到多少、指标口径登记覆盖率达到多少，这些能量化的东西才靠得住。

补充一点，别用“生成了多少个页面”当 KPI。这个指标太容易刷，而且跟业务价值几乎不相关。我更愿意看“哪个部门主动来要第二个应用”，主动复购才是真认可。做低代码这件事，第一版靠推，第二版靠口碑，推不动的项目，再多功能也白搭。选型时也一样，我会优先选那种能把数据这条线一起兜住的方案，而不是只会生成页面的方案，前者能撑三年，后者撑不过一个审计周期。

这几年我看过太多团队在低代码这件事上反复横跳：先是被生成速度打动，采购一批账号，业务部门热火朝天搭了两个月，然后进入沉默期，账号过期不续费，留下一堆没人维护的应用。问题从来不在工具，在预期管理。把 AI 当成能自动干活的实习生，你会失望；把它当成一个执行力极强但完全不懂你公司规矩的新人，你就知道该给它准备什么了——规矩，也就是数据标准和口径定义。

我的建议是反过来做规划。别从“我们要上低代码平台”开始，从“我们哪三个业务场景最痛、这三个场景依赖哪些核心数据、这些数据现在归谁管”开始。三个问题答完，方案基本就浮出来了。先治理再生成，先口径再页面，先小场景再铺开，这个顺序我试过很多次，颠倒了就要交学费。第一个场景一定要选小、选痛、选数据相对干净的，用两周做出来给人看，比开三次战略会管用。

还有一个容易忽略的点：给维护留预算。低代码让建设成本降下来了，但维护成本没有消失，只是转移了。应用多了之后，字段重复、权限混乱、废弃应用堆积，这些都需要有人管。我一般建议建设预算和维护预算按 7 比 3 来切，很多团队只算前者，第二年就被后者拖住。

普元在这条线上的定位我比较认可：它不跟你争“谁的生成速度更快”，而是把主数据、数据资产、数据开发、BI、问数、数据集这几层打通，让你的 AI 应用有据可依。对于已经把数据当资产看、准备认真做几年数字化的企业，这条路更稳。AI原生低代码的天花板不在模型，在你对自己数据的掌控程度。这句话我放在这里，供你验证。想清楚这件事，再决定要不要现在动手，也不迟。

陈立群：说到心坎上了。我们去年上了低代码，业务部门三个月做了四十多个应用，今年年初清理的时候发现一半没人用。回头看就是没人管口径，同一个“活跃客户”在不同应用里能算出三个数。

周敏：请教一下，如果公司现在只有 ERP，没有数据仓库，想做问数应该先补哪一块？我理解应该是先把主数据理清楚，但不确定要不要先建数仓。

赵志远：维护预算那条太真实了。我们就是建设的时候批钱很痛快，维护的时候一个人都没有，现在应用出问题只能找当初搭的那个人，人家早调岗了。

林晓枫：制造业那段有共鸣。我们做设备台账对齐花了快两个月，比搭系统久多了，但上线后确实顺畅，返工单明显少了。当时还觉得是浪费时间，现在看是省了大麻烦。

吴海涛：三个判断指标里“数据争议次数”这个角度很新，我们内部从来没这么量过。下周开会准备提一下，把业务和财务吵架的频率当成一个观察项。