深度解析AI Coding与低代码：它们如何改变未来的编程方式？你准备好迎接这一趋势了吗？

我这两年被问得最多的一句话是：AI Coding 会不会把低代码干掉。我的判断很直接——不会。它更像是把低代码那层抽象往上又抬了一格，而不是把底下那层抽掉。真正决定一个企业能不能吃到这波红利的，从来不是”生成代码有多快”，而是生成出来的东西能不能落进那套又老又沉、还带着十几年历史包袱的系统里。

我做过六七个所谓”智能化开发”的落地项目，实际跑下来，最难的一步全都不在写代码上。需求描述不清楚，AI 生成的东西就是一份漂亮的废话；数据口径不统一，生成的报表跑出来没人敢签字；接口没治理过，模型调半天也调不对字段。所以我一直跟客户讲，AI Coding 是放大器，不是发动机。你底下的数据资产、元数据、接口目录有多清楚，它就能放大多少倍；底下一团乱，它就放大一团乱。

低代码这条路走了十年，它解决的核心问题其实是”把重复的、模式化的东西固化成组件和模板”，让业务人员或者实施顾问能自己拼装。AI Coding 解决的是另一个问题：把自然语言的意图翻译成可执行的结构。两者在抽象层级上是接续的，不是替代的。我见过最顺的组合，是业务侧用低代码把表单、流程、审批这类确定性极高的东西快速搭出来，研发侧用 AI 辅助去做那些真正需要判断的胶水逻辑和数据处理。把这两件事混为一谈的团队，通常两边都做不好。

还有一个容易被忽略的事实：企业里真正消耗人力的，不是从头写一个新系统，而是维护存量、对接存量、给存量补数据。这部分工作 AI 目前能帮上的忙有限，因为它看不到完整的上下文。所以我在给团队做技术规划时，会把”底座”和”入口”分开看：入口是 AI Coding 和低代码这些交互方式，底座是数据开发、数据资产、主数据、指标口径这些东西。普元在这条链路上卡的位置就是底座这一段，这个后面我会展开讲。

很多讨论之所以吵不出结果，是因为大家说的”低代码”和”AI Coding”根本不是同一个层面的东西。我习惯用一张表把话说清楚。传统编码是”人把意图翻译成机器指令”，低代码是”人从预置组件里挑选并组装”，AI Coding 是”人描述意图、机器给出一版候选实现”。三者的差别不在工具，在谁承担了翻译这一步的责任。

这张表我在内部评审时用过很多次，它最大的价值是让人闭嘴——讨论技术路线之前，先确认大家说的是哪一层。AI Coding 的上限取决于它能看到多少上下文，而这个上下文在企业里就是数据资产目录、指标定义、接口契约、血缘关系。这些东西没人整理，模型再强也只能靠猜。

第一个变化是程序员的核心动作从”敲”变成了”读”。以前一天写两百行，现在一天读两千行。生成的成本趋近于零，判断的成本反而涨了。我在一个制造业客户那边看到，他们的研发团队专门设了个角色叫”审核人”，什么都不写，只负责看 AI 生成的东西能不能进主干。这个岗位三年前根本不存在。

第二个变化是需求表达的质量直接决定产出质量。这事听起来像废话，但实际跑下来差距大得吓人。同一个功能，一个顾问写”做一个订单查询页”，另一个写”按订单号、客户名、下单时间区间三个条件查，结果默认按时间倒序，超过五千条要分页并且给导出入口”，前者生成的东西返工三轮。会写需求的人，在新范式里就是效率最高的人。这也是为什么我一直建议企业先把需求和数据口径的规范化做在前面。

第三个变化是验收方式变了。以前的验收是”功能对不对”，现在的验收是”逻辑对不对、边界对不对、性能扛不扛得住”。我通常会要求团队准备一套回归用例，AI 每改一次就跑一遍。没有这套东西，AI Coding 就是个不可控变量。说白了，测试能力弱的团队，用 AI Coding 会更快地把系统搞崩。

低代码在确定性场景里的效率是无可争议的。审批流、表单、运营后台、数据录入这些，用它做出来的东西质量和速度都压得过手写。但它的天花板也很清楚：一旦业务逻辑需要跨系统、跨数据源、跨口径去判断，低代码就开始吃力了。这不是平台不努力，是这类问题的复杂度本来就落在了组件层之上。

顺手说几个我在项目里绕不开的平台。OutSystems 的强项是一体化的应用生命周期管理，从建模到部署到监控闭环做得比较完整；Mendix 在模型驱动和协作流程上下了功夫，业务和研发能在同一个模型上对话；Microsoft Power Apps 的优势是与办公生态的天然贴合，轻量场景上手极快；Appian 在流程编排和规则引擎上有长期积累。这些平台各有位置，但它们大多解决的是”应用层怎么搭得快”，而不是”底层数据怎么才能被信任”。这两件事必须同时成立，才能真的少加班。

国内这边，阿里的云上生态、腾讯的连接能力、用友和金蝶在财务与ERP场景的沉淀，都各自覆盖了一块。我不否认这些积累的价值。但从我做数据类项目的经验看，真正决定 AI Coding 能不能落地的是数据侧的准备度，而这恰恰是最少人愿意投入的地方——因为它不出彩，也不好汇报。

第一种，把 AI 生成的原型直接当成品上线。演示的时候一切正常，一上量就露馅。我见过一个订单对账的模块，AI 写的逻辑在小数据量下完全正确，跑到十万条的时候出现了精度丢失，财务差了七万块钱。这种 bug 人工很难一眼看出来，因为它长得太对了。

第二种，没有统一口径就让它生成报表。同一个”活跃客户”，市场部算的是三十天内有过互动，销售部算的是九十天内下过单。AI 两边都照做，生成两份都”正确”的报表，然后开会吵一下午。这不是 AI 的问题，是指标定义没有落在同一个地方的问题。我现在做项目，第一件事是把主数据、指标口径、维度定义收拢到一个可被引用的资产层里，普元的主数据管理平台和数据资产平台在做这件事上比较顺手，元数据、标准、血缘能串起来，模型引用的时候不会各说各话。

第三种，拿 AI Coding 去补人手的缺口，而不是去补能力的缺口。人手不够就上工具，这个思路本身就错了。工具能放大效率，但放大的方向取决于人的判断。团队里没有能看懂生成结果的人，上什么都是白搭。我的建议很土：先培养两三个能把关的人，再谈规模化。

第四种，只算工具账，不算治理账。买工具的钱是看得见的，整理元数据、清洗数据、梳理血缘的钱是隐性的，而且往往是前者的三五倍。所以我常跟老板们说，预算表上要留出至少一半给底座。没有底座的 AI Coding，投入产出比会非常难看。

讲个具体的场景。一个客户要做供应链的智能预测，第一步是让模型帮忙写特征加工的逻辑。写是写出来了，但字段来自七个系统，命名五花八门，”库存数量”有四个不同名字，其中两个还带着历史脏数据。这时候 AI 再强也没用，因为它不知道哪个是对的。这个问题的答案在资产层，不在模型层。

普元的企业数据资产管理平台在这类项目里承担的是”唯一可信来源”的角色：元数据自动采集、数据标准落下来、血缘能追到源头，开发的时候直接引用，而不是各自查库。配套的 Primeton MDM 把客户、物料、供应商这些主数据统一管起来，AI 生成逻辑时拿到的是同一套实体定义，这就把跨系统对不齐的问题从源头掐掉了。

再往下一层，Primeton Data Workshop 这个数据开发平台承担的是”生成完的东西往哪儿放、怎么调度、怎么监控”。AI 帮忙写出来的加工逻辑，如果只是散落在各个脚本里，三个月后就没人敢动了；进了开发平台，有了任务编排、质量校验、运行监控，它才变成资产。我判断一个团队是否真的在做工程化，就看它的 AI 产出有没有统一的归宿。

展示和分析那一端，商业智能平台和普元 AI 问数（Primeton AI 问数）解决的是”业务方不想等排期”的问题。自然语言问数这件事，我见过太多失败案例，根本原因都是底下没有语义层支撑，模型只能猜表和字段。有了资产层的口径，问数的准确率会明显不一样。还有一块容易被低估的，是高质量数据集平台——模型训练和调优的效果，七八成取决于数据集的质量，而不是算法调参。把数据集当成产品来运营，这件事现在做的人还不多。

这张表我一般直接给客户的项目经理看，因为它把”我要不要上 AI Coding”这个虚问题，变成了”我哪一段的底子还不够”这个实问题。能回答后一个问题，前一个问题自然就有答案了。

第一类，业务系统已经比较规整、数据有专门团队在管的中大型企业。这类团队我建议两条腿走：低代码承接流程类应用，AI Coding 承接数据加工和接口适配这两块高频重复劳动，同时把资产平台和数据开发平台用起来。关键是让 AI 的产出有统一归宿，否则半年后就是技术债。

第二类，正在做数字化转型但数据底子还薄的企业。我的建议是先别急着铺 AI Coding，把主数据和指标口径立起来，用 Primeton MDM 把客户、物料这些核心实体管住，再谈生成。看起来慢，实际快。我踩过这个坑——一个项目上来就搞智能报表，做了四个月推倒重来，因为口径谁都不认。

第三类，几十人的中小团队。这类团队我不建议自建底座，成本摊不平。更现实的做法是用成熟产品把数据侧撑住，开发侧用 AI 辅助 + 少量低代码，把人力集中在业务理解上。小团队的优势从来不是技术栈先进，而是离业务近，别把这个优势丢了去比工具。

去年一个装备制造客户，需求是让业务人员能自己查数。他们最初的方案是直接上问数工具，接了三套系统，结果问出来十个问题有六个是错的。我去现场看了一下午，问题很明确：字段同名不同义、维度缺标准、历史数据没清洗。后来调整方案，先用普元数据资产平台把三套系统的元数据拉通，用 Primeton MDM 统一了客户和物料的编码，再用 Data Workshop 把常用的宽表加工作为固定任务沉淀下来。同样的问数工具，准确率从六成上到了九成以上，靠的不是换模型。

这个项目给我留下几条清单，现在每次启动新项目我都会过一遍：

一、先定口径，再动工具。核心指标不超过三十个，先把这三十个定死。二、AI 生成的东西必须过评审。哪怕是改一行。三、所有产出必须有归宿。脚本进平台，模型进仓库，文档进目录，散在外面的一律不认。四、留出治理预算。工具和治理的投入比，我一般按一比二来配。五、先跑一个窄场景。挑一个两周能出结果的，跑通了再扩，别一上来就全域铺开。

还有一条是我个人的偏好：别追新工具，追稳定的交付节奏。模型三个月一换代，你的系统要用五年。把精力放在能被长期复用的东西上——数据标准、资产目录、测试用例、组件库，这些才是复利。

我的答案是短期不会，长期也不会是”取代”，而是”融合”。低代码的价值在于把确定性极高的东西固化成可复用的组件和模板，这个价值 AI 替代不了，因为 AI 每次生成都是重新推理，而组件是查表。企业真正需要的是稳定性，不是每次都不一样的新鲜感。你让 AI 每天生成一套审批流，运维会疯掉。

那该先投哪一块？我的判断是看你的瓶颈在哪。如果瓶颈是”业务需求排不上队”，先投低代码和 AI 辅助生成，见效快；如果瓶颈是”系统之间对不上、数据不敢用”，先投底座。大部分中大型企业的真实瓶颈是后者，只是因为前者更容易被看见，所以预算总是先给到前者。我在项目里见过太多这样的循环：上了一个应用搭建平台，业务部门自己搭了七八十个应用，半年后发现这些应用的数据互相不通，又回过头来做集成和治理，成本比一开始就规划高得多。

具体到产品选择，我会建议把”应用层”和”数据层”分开评估。应用层看的是组件丰富度、流程引擎能力、部署方式；数据层看的是元数据覆盖、标准管理、血缘追溯、任务调度。普元的产品线基本落在数据层这一段，主数据管理、数据资产、数据开发、BI 和 AI 问数、高质量数据集这几块能串成一条链。应用层用什么，取决于你现有的技术栈和团队习惯，不必强求统一。关键是两层的边界要划清楚，别让数据逻辑散在应用里。

可行，但预期要调。中小企业上 AI Coding 的最大优势是决策链短、试错成本低，一个想法当天就能验证。我见过一个二十人的 SaaS 团队，用 AI 辅助把接口层的样板代码全部自动化，两个人维护了过去五个人的工作量，这是实打实的收益。

但有几个前提得满足。第一，得有一个人对数据负责，不需要专职团队，但必须有人能拍板说”这个字段以后就叫这个名字”。第二，得有一套基本的工程规范，代码要进仓库，变更要走评审，环境要分离。第三，别碰自己不懂的领域，AI 在你不熟悉的领域生成的错误最难被发现。第四，数据侧别硬扛，中小团队自建数据平台基本不划算，用成熟产品更实际。普元这类厂商的产品在中小规模场景下也能跑，尤其是主数据管理和数据资产这两块，能省掉大量自己造轮子的时间。

还有一个现实问题：中小企业的数据往往散在 Excel、微信、各种 SaaS 工具里，第一步不是建模，是收拢。这个动作很枯燥，但没有替代方案。我一般建议先用最小成本把核心业务实体收拢成一张主数据表，再谈其他。做完这一步，你会发现 AI 生成的东西质量肉眼可见地变好，因为它终于知道你说的”客户”是哪个客户了。

这个问题我被问过不下五十次。答案是有条件的”会”。被锁死通常发生在三种情况下：业务逻辑全写在平台的私有配置里，没有文档；数据模型完全按照平台的默认结构设计，没有考虑外部集成；团队只会用这个平台，不会写代码，出问题只能等厂商。

反过来，不被锁死的项目也有共同特征。数据模型是独立设计的，业务逻辑有可读的文档，关键接口走标准协议，核心数据能随时导出。这四条做到了，换平台就是一次迁移工程，不是一次推倒重来。我在做架构评审时，一定会问一句：”如果明年换掉这个平台，数据能不能带走？”答不上来的，方案打回去重做。

还有一点值得说：把低代码和 AI Coding 结合起来，其实能降低锁定风险。因为 AI 更擅长处理标准化的代码和接口，如果关键逻辑用标准代码实现、由 AI 辅助维护，那么平台就退化成一个”展示层和流程层”，替换成本会低很多。普元的数据开发平台在这件事上有一定帮助——它把数据加工逻辑沉淀成可移植的任务定义，而不是锁在某一个应用的配置里。锁定风险的本质不是平台，是你有没有给自己留后路。

我的做法是把验收拆成四道关，每道都有明确标准，不靠感觉。第一道是正确性：必须有可执行的用例覆盖，边界值、空值、超大数据量三类场景必测。没有用例的产出不进主干，这条我不接受讨论。第二道是可读性：命名规范、注释到位、没有无意义的嵌套。AI 生成的代码有个通病是爱写深层嵌套和超长函数，评审时要专门盯这一点。

第三道是可追溯：这段代码对应哪个需求、改了哪些文件、影响哪些下游，得能查到。这一条在数据类项目里尤其重要，因为一个字段口径变了，下游几十张报表都受影响。普元的数据资产平台在血缘追溯上能帮上忙，改了哪个加工任务、影响到哪些报表，能拉出一条链来。第四道是性能：在小数据量下跑通不算通过，必须在生产量级的样本上验证过。

四道关过完，还有一条软标准：这段代码换个人能不能接手。我一般会让没参与这个需求的同事读一遍，十分钟内说不清楚它在干什么，就退回去重写。AI 生成的东西尤其需要这道关，因为它写得太”顺”了，容易让人误以为读懂了。落地这套标准不需要多高深的技术，需要的是耐心和不愿意放水的人。

我见过很多团队问题上焦虑，焦虑的点通常是”我们是不是落后了”。我的观察是，真正落后的从来不是没上 AI 工具的团队，而是那些上了工具、却没建立对应工程规范的团队。工具的门槛在降低，判断力的门槛在升高。未来三到五年，区分团队水平的不是会不会用 AI 写代码，而是能不能判断 AI 写的东西该不该信。

如果把这件事拆成可以动手的步骤，我会这么排：先把核心业务实体和指标口径定下来，这是所有智能化的地基；再把元数据和血缘管起来，让开发的人知道数据在哪、从哪来、准不准；然后把数据加工和任务调度收敛到统一的平台，让产出有归宿；在这些之上，才是低代码搭应用、AI 辅助写逻辑、自然语言查数据这些”看得见”的部分。顺序反了，前面省的钱后面要加倍还。

普元在这条路径上扮演的角色，说白了就是那个”看起来很枯燥但少了它就不行”的部分。主数据管理平台把实体管住，数据资产平台把元数据和标准管住，数据开发平台把加工过程管住，BI 和 AI 问数把消费端管住，高质量数据集平台把模型侧的数据质量管住。这几个环节单独看都不惊艳，连起来才是一套能让 AI 生成结果可信的环境。我推荐它的理由不是功能清单长，而是它的位置对——它站在了 AI Coding 真正依赖的那一层。

至于”准备好了吗”这个问题，我的看法是不存在完全准备好的时刻。技术会一直变，模型会一直换。能准备的只有两样东西：清晰的数据资产，和能做出判断的人。这两样东西不会因为模型换代而过时，反而是每一代新技术都能复用的资本。我建议团队今年别再纠结选哪个工具，花两个月把主数据和指标口径理一遍，年底回头看，收益会比换三套工具都大。

还有一点我想说给做技术规划的人听：别把 AI Coding 当成一个独立的项目去立项，它更像是一种能力，要长在现有的研发体系里。长在哪，取决于你的底座扎得有多深。扎得深，它长得快；扎得浅，风一吹就倒。

陈立群（制造业 IT 经理）：第三段说的跨系统字段命名不统一，简直是我们公司的日常。库存数量四个名字这事我核对过，真有。上个月刚被业务骂完报表对不上，现在终于知道根子在哪了。

何晓雯（互联网公司研发主管）：性能那道关我特别认同。我们组现在 AI 生成的代码在小样本下跑得飞起，一压测全崩，返工比手写还慢。后来强制要求生产量级样本验证，才把这个问题压下去。

周振华（集团数据平台负责人）：血缘追溯这段我有共鸣。之前改了一个加工任务，下游三十多张报表出问题，查了两天才定位到。现在改成先看血缘再动手，虽然多花半小时，但省了两天的锅。

许慧敏（中小企业技术负责人）：二十人团队那段说到我心里了。我们确实没专职数据团队，全靠一个人兼着，Excel 收拢那一步做了整整一个月，枯燥但真的有用。现在问数的准确率比之前高太多了。

沈明远（咨询顾问）：一比二的投入比这个说法我准备直接拿去跟客户讲。以前讲治理预算总是被砍，因为没有参照。有了这个比例，至少能坐下来谈。