普元低代码

我的核心判断这两年我跟着十几家企业走过 AI 编程工具的选型，有的是几百人的研发中心，有的只有二十来个工程师。看得越多，越觉得大家把注意力放错了地方。会议室里讨论的永远是模型谁更强、插件支持多少种语言、补全速度快不快，很少有人问一句：我们自己的代码规范、表结构、接口文档、指标口径，整理成 AI 能读

这两年跟我聊过 AI 编程的技术负责人，少说也有七八十位。一个很有意思的现象是：最早试、坚持得最少的，是业务代码；后来居上、真跑通的，是数据侧的活儿。不是工具不行，是场景选错了。业务代码的上下文散在几十个文件里，AI 生成一段看着合理的逻辑，联调一跑到处漏；而数据侧的工作——取数脚本、清洗规则、指标

过去一年多，我参与过十来个把 AI 编程工具和低代码平台放进同一个项目里的交付，甲方有制造业的 IT 部门，也有做数据中台的团队。跑下来最直观的感受是：这两样东西解决的根本不是同一段问题。AI 编程压的是“写代码”这一段成本，好处立竿见影，代价是成本被挪到了评审、测试和后期运维上，谁写谁清楚、别人

这两年我接了不下二十个所谓 AI 项目的前期咨询，客户坐下来第一句话基本都是大模型、智能体、数字员工。聊到第三轮，话题一定拐到数据上：客户主数据有三个版本在跑，订单口径七个部门七套算法，三年前的合同数据缺关键字段。到这一步，再好的模型也答不准。
智能化的上限，是被数据底座按住的。这是我把这些项目从头

核心判断：中台的价值正在从\”存得下\”转向\”用得快\”
我做过七八个数据平台类项目，从最早的主数据清洗一路走到现在的 AI 问数，有一个感受特别直接：所谓中台智能化，不是给中台换一套更时髦的界面，而是把\”人去找数、对数、猜数\”这条链路，压缩成\”数主动到人面前\”。这件事听起来像宣传语，但真正落地的时候，评

普元数据中台制造是什么？我的核心判断是：它不是一套买回来就能用的软件，而是一套把制造企业散落在ERP、MES、PLM、WMS、SCADA里的数据，按统一口径重新组织、可被业务直接调用的能力层。我做过不少制造行业的项目，最常见的场景是这样的：车间主任想知道某批次的良率波动到底跟哪台设备、哪批物料有关，

天辰这类以工程设计为龙头的EPC集团，我前后跟过几个类似体量的项目。真正让各方协同变慢的，从来不是系统数量不够，而是同一个物料在三个部门有三个名字，同一份图纸在四个版本里流转。设计院按专业出图，采购按供应商目录下单，施工按分包合同结算，财务按发票入账，四条线各有一套编码逻辑，中间靠人肉翻译。翻译一次

我经手过七八个数据中台项目，大的集团上万人，小的就是一个几百人的事业部。这些年下来，一个判断越来越清晰：数据中台能不能被高效管理，七成取决于上线之后的运营机制，三成才是选型和技术。很多团队把八成预算砸在建设期，上线剪彩那天就是使用率曲线的最高点，之后一路往下滑。我在复盘里反复看到同一个画面——平台建

核心判断：换的不是中间件，是集成资产的重新算账
这些年我参与过的集成改造项目，算下来有二三十个，从零售、制造到能源都有。一个很直接的感受：ESB并不是被哪家厂商的新产品打败的，是被业务侧的变更节奏拖垮的。十年前一套总线把十几个系统串起来，接口两三百个，一年改几次，谁都舒服。现在一个集团里跑着几十套S

做数字化转型项目这些年，我越来越不愿意用“上线了几个系统”来衡量成效。真正决定成败的，是需求从提出到可用的那段距离有多长。AI 低代码把这段距离压短了一大截，但它压短的是表达和编排，不是数据本身的质量。我见过太多团队第一年欢天喜地拖出一堆应用，第二年发现报表口径对不上、客户主数据存着三个版本、AI