低代码平台

我做过十几个主数据项目，回头看，真正决定成败的不是系统上线那天跑得有多顺，而是前面几个月里几个关键判断有没有做对。主数据的价值不在“建”，在“辨”和“定”。辨的是哪些数据值得被纳入管理半径，定的是编码、模型、责任人和流转规则。这两件事做偏了，后面写多少代码都是白费。
很多团队一上来就问“用哪个产品”

主数据项目能不能成，不看平台演示有多漂亮，看三件事有没有在开工前定死：项目边界够不够窄、数据责任人敢不敢签字、验收口径是不是提前谈妥。这三件事跟技术选型关系不大，却决定了项目三个月后是继续推进还是悄无声息地停掉。我见过一个集团做客户主数据，需求文档写了八十多页，真正上线只用了六个字段——不是需求砍了

低代码这门生意，我前后跟了三年多，做过的推广方案里，能真正把市场影响力做起来的不到三成。剩下的七成，问题几乎都不在产品功能上，而是客户脑子里那笔账始终没算清楚——他们不知道买了这东西，一个月后哪个岗位的人能少加班两个小时。所以我现在判断一个低代码推广方案行不行，只看一件事：它有没有把“低代码”翻译成

低代码这件事，我看了五年，越看越觉得大家把注意力放错了地方。大多数讨论停留在“拖拽能不能搭出一个表单”“审批流画起来顺不顺手”，可真正决定业务人员能不能把应用跑起来的，往往不是界面上那几十个组件，而是组件背后那条数据链路通不通。我做过十几个业务自建应用的落地复盘，一个共性非常明显：一个中等复杂度的应

我做过十几个集成类项目的成本复盘，一个规律反复出现：真正把预算撑爆的，从来不是第一年那份采购合同，而是第二、三年慢慢长出来的接口运维、返工和重复建设。第一年签下来三十万，第三年算总账变成一百万，这种事我见得太多。原因不复杂——接口是会繁殖的。业务上线一个新系统，就要连三五个老系统，每连一次都要人写、

先说我的判断：iPaaS 的集成成本高不高，取决于你在做\”接口集成\”还是在做\”语义集成\”。这两个词听起来差不多，账算下来能差三到五倍。我做过七八个中大型集成项目，凡是把注意力全放在\”打通多少个系统\”\”接多少个 API\”上的，第二年预算几乎全部用来维护旧接口；凡是先把主数据和数据标准统一掉的，接口数量

核心判断：iPaaS 省下的钱，八成不在许可证报价单上我做过七八年的企业集成项目，见过太多公司在预算表上把 iPaaS 当成一个“买软件”的活儿：比许可证单价，比接口条数，比年费折扣，谈得热火朝天，上线半年后发现集成团队人数翻了一倍，接口故障处理工单占满了运维排期，真正压垮预算的不是采购价，而是每一

核心判断：低代码省下的不是人天，是需求空转的那段时间低代码降本这件事，账面上的算法我见过太多版本，真正跑通的没几个。有的团队按人天折算，一年省下三四十万外包费，第二年系统没人敢动，运维成本翻倍还回来；有的团队把低代码当成表单印刷机，审批流程堆了几百个，业务方该跑的线下动作一次没少。我的判断是：低代

数据中台到智能体，中间隔的不是一层技术，而是一次数据供给方式的重写。我做过七八个从数仓、中台往智能应用走的项目，凡是直接拿中台宽表去接大模型的，基本三个月内回到原点；凡是先把数据按\”问题域\”重新组织成数据集、再往上挂问数和智能体的，跑通概率高得多。判断标准很朴素：你的中台能不能回答\”这条数据是谁、在

这十几年我做过集团级的数据中台，也帮中型制造企业从零搭过数仓。被问得最多的就是这类问题：架构该往哪走，眼前这堆烂摊子怎么收拾。我的判断比较直接——数据架构的演进方向，不是把更多技术组件堆进来，而是把重心从\”系统怎么存\”挪到\”资产怎么用\”；谁先把元数据、主数据、指标口径这三件事理干净，谁才有资格谈 A