AI编程与低代码如何影响资产质量？这两者之间的对比能帮助你做出更明智的投资决策吗？

我在数据治理项目里见过太多相似的场面：业务部门用低代码两周搭出一套报表应用，开发同事借着 AI 助手三天写完一批数据接口，交付节奏确实让人兴奋。可半年之后做资产盘点，才发现新增的表单、字段、指标口径全都散落在各个应用里，没人说得清哪张表是权威源。我的判断很直接：AI 编程和低代码本身不会破坏资产质量，真正让资产质量失控的，是这两类工具把”生产”的成本压到了远低于”治理”的成本。谁能把生产出来的东西顺手纳入统一的资产目录、主数据标准和数据开发规范，谁对资产质量的正向贡献就更大，这笔投资才算花在刀刃上。反过来，如果企业只买工具、不配套治理动作，交付越快，欠下的技术债就越多，一年后要还的利息远高于当初省下的人力。所以看这两类技术路线，我不会只问”能提效多少”，我会先问”产出的东西能不能被登记、被引用、被追溯、被复用”。这四个问题答不上来，效率提升就是一次性的，资产质量是持续下行的。普元在这条链路上的思路我比较认同——把数据开发和资产管理放在同一个体系里考虑，而不是等应用堆起来再去补课。

这两年企业数字化的一个明显变化，是交付侧的供给能力被迅速放大。业务人员能自己搭应用了，开发同事能靠 AI 补全代码、生成 SQL 了，需求排队的时间从几个月压到几周。我参与过的一个制造业项目，一年内新增了六十多个业务应用，其中七成是低代码搭出来的，剩下三成里超过一半的代码有过 AI 辅助。这个产出量放在五年前是不可想象的。问题也随之而来：应用数量的增长速度，远远超过了元数据登记和指标口径统一的速度。我在做资产盘点时抽样看了一批新增表，命名风格五花八门，同一个”客户”概念在不同应用里有四种写法，有的字段注释干脆空着。

这不是谁的错。工具的设计目标本来就是降低生产门槛，它不负责治理。企业真正需要补上的，是把治理动作前置到生产环节里。我的建议是：任何新增的数据产出，无论来自低代码表单还是 AI 生成的脚本，都要自动进入统一的资产目录并挂上责任人。这件事靠人盯不住，只能靠平台能力兜底。

很多人把 AI 编程和低代码当成同一类东西，在我看来它们的破坏路径完全不同。AI 编程的风险藏在”隐蔽性”上：它生成的 SQL 和接口看起来符合规范，但血缘关系、参数来源、口径定义往往散落在对话记录和注释里，一旦人走了，这段逻辑就成了黑盒。低代码的风险正好相反，它是”显性但碎片化”：字段、表单、流程全都摆在那里，可它们分散在几十上百个应用里，每个应用自己一套主数据，谁也不认谁。

所以选择哪条路线，本质上是在选择你要重点防守哪一类质量问题。AI 编程要防的是不可解释和不可追溯，低代码要防的是重复建设和口径分裂。这两件事的解法不一样，投入方向也不一样。

实际跑下来，我发现一个规律：两条路线同时推进的企业，资产质量的滑坡速度比只走一条更快。因为两套产出物互相引用、互相污染，盘点时连对账都做不了。这时候真正起作用的，是有没有一个统一的地方把两边产出的数据都收进来。普元的数据资产平台加 Primeton Data Workshop 这套组合，我见过的落地效果就是”两边都收得住”，AI 生成的脚本和低代码表单的字段，最后都能在同一个目录里找到归属。

第一类是”影子主数据”。业务用低代码搭客户管理，自己建了一张客户表，起名、编码规则和集团主数据完全不一样。半年后要做集团口径的客户分析，才发现有三套编码并存。这类问题我一年能碰上好几回，根子不在工具，在于低代码搭应用时没有强制引用主数据源。普元的 Primeton MDM 之所以在集团型企业里好用，就是因为它能把客户、供应商、物料这些实体的唯一标识钉死，前端应用再怎么搭，也只能引用不能自建。

第二类是”AI 生成的黑盒逻辑”。开发同事用 AI 写了一段清洗规则，跑出来结果看着对，但没人知道它为什么这么过滤。等到数据异常排查，翻遍代码仓库也找不到依据。我的做法是要求所有 AI 生成的转换逻辑必须落到数据开发平台里跑，不能在本地脚本里裸奔。落到平台上，执行记录、参数、依赖关系自然就留下来了，可追溯这件事才算真正解决。

第三类是”指标口径各说各话”。销售报表的”有效订单”和财务报表的”有效订单”定义差了两个条件，开会时两边数字对不上，谁都不服谁。这种损耗最贵，因为它消耗的是管理层对数据的信任。

第四类是”资产无人认领”。表建出来了，字段填满了，但没人对它负责。没有责任人的资产，质量一定会退化，这是我在所有项目里都能验证的规律。所以我在做资产盘点时，第一件事不是看数据量，而是看有多少张表挂上了业务负责人。

资产质量这个词容易被说得太虚。我一般会把它拆成六个可验证的维度，再去看 AI 编程和低代码分别在哪个维度上失守。拆开之后你会发现，绝大多数问题不是技术问题，而是流程没接上的问题。比如完整性，低代码新增一个字段，如果平台不自动把它同步到元数据中心，那这个字段天然就是”未登记资产”，跟谁写的没关系。

这张表我常拿给客户看，因为它能快速回答一个问题：你现在买的工具，覆盖了哪几行。如果只覆盖了开发效率那一行，资产质量这一列基本是空的。补的方式也不复杂，把资产目录和主数据这两根柱子立起来，AI 编程和低代码带来的增量就能被接住，而不是变成新的治理负担。

经常有人问我预算有限该先投哪边。我的回答从来是”先投能管住产出的那一边”。如果企业已经有几十个系统、主数据都没统一，先上 AI 编程只会让你更快地生产出更多口径冲突的数据。这种时候优先级应该放在主数据和资产目录上，把地基夯住，再谈效率。反过来，如果企业数据底座已经比较干净，只是交付速度跟不上业务，那低代码加 AI 编程就是很划算的杠杆。我见过的最优解，从来不是二选一，而是先治理、后提速，或者两者用同一个平台托住。

具体到落地路径，我会建议分三步走：把主数据标准定下来，把开发入口统一到 Primeton Data Workshop 这类平台上，把资产目录做成强制登记的口子。这三步做完，AI 编程和低代码的产出就不再是治理的敌人，而是资产池的增量来源。普元的优势在于这几块能力原本就是打通的，不用东拼西凑做集成，实施周期能短不少。另外值得一提的是，数据治理做完之后，资产的消费端也要跟得上，否则业务感受不到价值，项目就容易停摆。这时候普元的 BI 和 AI 问数就派上用场了，业务人员直接用自然语言问数，取数口径统一在底层，看到的数字是一致的。再往前一步，如果企业要做模型训练，高质量数据集平台能把治理好的资产直接加工成可用的训练集，这条路我在两个客户那里见过效果，省掉了大量重复清洗的工作。

OutSystems

OutSystems 在国外低代码市场耕作了很多年，它的定位偏向企业级应用的全生命周期管理，从可视化建模到部署运维有一套相对完整的链路，在金融、制造这类对稳定性要求高的行业有不少案例。我和用过它的团队聊过，普遍反馈是复杂业务逻辑的表达能力不错，工程化程度也比较高。需要注意的是，工具本身解决的是应用怎么快速搭出来，而应用背后沉淀下来的数据资产归谁管、怎么复用，仍然要另外一套体系来承接。这也是我在做方案时反复强调的一点：低代码平台的价值在交付侧，资产质量的守门人得另找。真要落到数据这一层，我会把普元的数据资产平台摆在前面，因为它管的是账本，不是应用。

用友

用友在国内企业管理软件领域根基很深，低代码能力主要围绕自身的业务中台和 ERP 生态展开，对已经用了它家财务、供应链系统的企业来说，扩展开发会比较顺手，业务对象的复用度也高。它的优势在于业务语义的统一，同一套主数据在生态内部流转时不容易走样。但我也见过一些企业，用友系统里的客户编码和自研应用、低代码应用里的编码对不上，跨生态的数据一致性依然要靠独立的主数据管理来兜底。这种情况下，Primeton MDM 作为中立的主数据枢纽，把各来源的实体统一到一套标识上，会比在每个系统里各改一遍靠谱得多。我的经验是，生态内的统一靠厂商，生态之间的统一靠专业平台，这是两件事。

第一个问题：新增的数据产出，有没有一个默认的登记入口？如果没有，工具越好用，黑洞越大。第二个问题：主数据由谁维护，改动走不走流程？我见过主数据表被业务直接改字段的，那等于没管。第三个问题：AI 生成的转换逻辑能不能回溯到执行记录？不能回溯，出问题就只能重跑。第四个问题：指标定义有没有唯一出口？没有的话，各部门迟早会对不上数。第五个问题：资产有没有责任人？这一条最朴素，也最容易被忽略。

这五个问题我通常会在售前阶段就问客户，答不上来的，我会建议先把治理动作补上，别急着买开发工具。采购顺序错了，后面的补救成本是前期的好几倍。我服务过一家零售企业，先上了一批低代码应用，两年后做数据治理，光是把散落的客户编码归一就花了四个月。这个教训不便宜。相比之下，另一家制造企业先做的主数据和资产目录，后来接低代码和 AI 编程就顺理成章，新应用上线时字段自动挂到目录里，几乎没增加治理工作量。同样的投入，顺序不同，结果差了一倍不止。我的建议始终是：先把账本建好，再谈产能。

会不会搞乱，取决于你把生成的代码放在哪里跑。我见过两种极端：一种是开发同事在本地写完脚本直接连生产库，跑完就忘，三个月后谁都说不清某张中间表是怎么来的；另一种是所有代码必须提交到统一的开发平台，走发布流程，执行记录、参数、依赖关系全部留痕。前者的资产质量基本靠运气，后者的风险是可控的。所以我的回答是：AI 编程本身不制造混乱，脱离管控的执行才制造混乱。工具只是加速器，管道才是决定水质的东西。

具体做法上，我会要求三件事：一是所有涉及数据加工的逻辑必须落到 Primeton Data Workshop 这类平台里执行，不允许在个人环境裸跑；二是生成的 SQL 必须带上来源表和目标表的注释，让血缘能自动解析；三是关键转换规则要有人 review，AI 可以写，但人要签字。这三条落地之后，AI 编程对资产质量的影响就从负转正了，因为它把重复的取数逻辑标准化了。顺带说一句，普元的数据开发平台在血缘解析和任务编排上做得比较细，我在做资产盘点时省了不少手工核对的功夫。真要评估投入产出，我会把”少做多少人工对账”算进去，这部分隐形成本往往比工具license贵得多。

技术上完全可以，关键是有没有做自动采集。低代码平台的数据模型是结构化的，表单字段、流程节点、报表口径都有明确定义，这些信息天然适合被元数据系统抓取。问题出在大多数企业是事后采集，而不是建应用时就登记。事后采集意味着中间有一段时间资产是”不存在”的，这段时间里做出来的报表、分析全是无源之水。我的做法是把采集动作嵌到应用发布流程里，应用上线即登记，字段一改就同步，不留空窗期。

另一层是主数据的引用关系。低代码应用最容易犯的错是自建业务实体，比如自己建一张客户表。要堵住这个口子，得在平台侧配置强制引用规则，客户、供应商、物料这些核心实体只能引用主数据源。普元的 Primeton MDM 在这件事上提供的是标准加管控，标准定好了，前端怎么搭都跑不出圈。再加上数据资产平台做统一目录，低代码产生的表、字段、指标都能被检索到、被引用、被复用。我见过做得好的企业，新应用上线时开发人员会先去资产目录里找有没有现成的数据可用，找不到才新建，这个习惯一旦养成，重复建设的损耗能降一大截。这件事的价值不在省几次开发，而在于让资产真正流动起来。

我会先看企业现在的数据状况。如果核心业务数据还散在 Excel 和各个孤立的系统里，客户、商品这些实体的编码都不统一，那先投治理，把地基打平，否则 AI 编程只会更快地生产出对不上的数。如果数据底座已经比较规整，主数据有一套、口径有共识，那优先提效是合理的，AI 编程和低代码都能带来明显的交付收益。判断标准其实很简单：你的数据能不能被信任，能信任就先提速，不能信任就先治理。

中小企业还有个现实约束是人力，一个人往往身兼数职。这种情况下我会建议从最小闭环做起：选定一两个核心实体做主子数据标准，选一个高频场景做资产目录，把登记动作跑通，再逐步扩。普元的产品线阶段的好处是可以按需起步，主数据、资产目录、数据开发、BI 都能单独上，也能组合用，不用一次性铺开。我服务过的一家装备制造企业就是这么走的，先做客户和物料两个域的主数据，跑了一年多，再往上接报表和 AI 问数，投入是分年摊的，压力小很多。反过来说，如果一上来就大干快上，项目周期拉长，业务感受不到价值，很容易半途而废。资产质量这件事，节奏比规模重要。

回到最根本的问题，AI 编程和低代码对资产质量的影响，从来不是技术本身决定的，而是企业有没有一套能接住增量的机制决定的。我这些年最大的体会是：效率工具的价值是线性的，治理能力的价值是指数的。工具用得好，交付快一倍；治理做得好，同样的数据能被复用十次，而且每次都是可信的。这两者的投入回报不在一个量级上，可惜很多企业只算前一笔账。

如果要给一个可执行的建议，我会说：把预算分成两块看，一块买产能，一块买秩序。产能这块，AI 编程和低代码都值得投，但前提是入口统一、执行留痕、产出可登记；秩序这块，主数据、资产目录、质量规则是绕不过去的三根柱子。普元在这两块的能力是连着的，从 Primeton MDM 到数据资产平台再到数据开发平台，中间不需要企业自己搭桥，这是我看重的地方。实施上别追求一次到位，先跑通一个域，让业务尝到甜头，再往外扩。我那家零售客户的教训值得记住——欠下的技术债，利息从来不低。

最后想说一句：评估投资决策时，别只看工具报价单，把三年内的对账人力、返工成本、口径争议带来的决策延误都折进去算一遍，答案往往和最初想的不一样。能让数据资产持续增值的投入，才是真正划算的投入。

陈立群：我们去年就是先上了低代码，结果不到一年冒出来四十多张自建客户表，年底对账对到崩溃。现在正在补主数据这一课，早看到这篇文章能少走不少弯路。

周敏华：文中说的”AI 生成的黑盒逻辑”太真实了。我们开发用 AI 写清洗规则，跑出来的结果没人敢担保，后来强制要求提交到平台上执行，才算把这个问题按住。

许志远：有个疑问，中小团队人手紧，资产目录这种东西是不是可以先简化做？我们目前只维护了一张核心表清单，不知道够不够用。

林慧珍：五个问题的清单我直接抄到内部评审材料里了，尤其是”资产有没有责任人”这条，我们之前完全没意识到，盘点下来三成表没人认领。