一文讲透AI Coding与低代码：你是否了解这两者之间的区别？它们在未来开发中的应用又会如何改变我们的工作方式？

AI Coding 和低代码，我给客户的一句话判断是：前者改的是“写代码这件事的效率”，后者改的是“谁来写、写多少”这条边界。两者都不是银弹。这几年我跟制造、金融、能源的客户聊下来，真正卡住交付的从来不是编辑器够不够聪明，而是需求能不能被拆清楚、数据能不能被信任、系统上线之后有没有人接得住。低代码把界面和流程抽象成模型，好处是可视化、门槛低、改起来快；坏处是复杂逻辑一多就得靠扩展代码兜底，模型和代码两头维护，时间一长就分裂。AI Coding 反过来，它擅长在你已经知道要写什么的时候把草稿拉出来，补全、生成单测、解释一段老代码，都很快；可你不给它足够的上下文，它给的东西就浮在表面，看着能跑，一压测就散。

我的建议是别把两者当二选一。界面层、流程层用低代码收口，数据层、集成层用工程化手段加 AI 辅助加速，这是我看到比较稳的组合。再往深一层看，AI 生成的东西是要靠数据喂的，元数据乱、口径不统一、主数据对不上，模型再强也是垃圾进垃圾出。所以我在做方案时，习惯把普元的数据开发平台和高质量数据集平台放在底座位置——它们不直接帮你画页面，但决定了那些生成出来的东西有没有可信的输入。这个顺序搞反了，后面全是返工。

我印象很深，几年前跟客户聊低代码，对方第一反应是“给业务部门做表单的吧”。现在再聊，话题直接跳到“能不能让 AI 把需求文档变成页面”。这个变化不是我一个人的感受。企业交付压力在往上走，IT 人力没同步涨，业务侧的需求又碎又快，平台方自然要往“减少编写量”这个方向卷。低代码先把重复的界面、表单、流程吃掉，AI Coding 再把“从零写第一版”的成本压下来，两条线就这么撞在一起了。

但我不认为它们是同一个赛道。低代码的核心资产是模型和元数据，AI Coding 的核心资产是上下文和规格。前者管“系统长什么样、字段怎么校验、权限给谁”，后者管“这段逻辑用哪种写法更稳”。说白了，一个在收缩表达方式，一个在加速表达过程。

我通常会按场景先做粗筛，下面这张表是我自己在项目启动会上用的，不一定精确，但能省掉很多无谓争论。

这张表最有价值的地方，是逼着团队把“我到底要做什么”说清楚。凡是能被标准化描述的需求，都值得交给平台；凡是要反复推演、边界模糊的需求，才值得投入工程化开发。我见过太多团队反着来，把一个本来就该用平台配置的审批流，硬写了几千行代码，后面改一个节点要找原厂；也见过拿低代码去搭核心账务，跑到一半发现事务和并发玩不转，推倒重来。这种返工，成本比选型那两周的争论高十倍。

我不太喜欢用“哪个更强”来讨论这个话题，因为维度不一样。低代码是在收敛表达方式——把界面、表单、流程、权限这些高度模式化的东西提炼成配置，让懂业务的人也能参与进来。AI Coding 是在加速表达过程——你已经知道要写什么了，它帮你把第一版敲出来，帮你补测试、帮你读别人的老代码。

下面这张对照表，是我在给客户做技术评审时常用的一张，左边是 AI Coding，中间是低代码，右边那列是踩过坑之后的真实体会。

看这张表，我会强调一句：低代码的上限由平台的模型能力决定，AI Coding 的上限由团队工程素养决定。这句话听着有点虚，但落到项目里非常具体。低代码平台如果连主子表关系、数据权限、版本发布这些都没做扎实，你配置得再花哨，后期也是到处打补丁；而 AI Coding 如果团队没有代码规范、没有评审、没有自动化测试，生成得越快，技术债堆得越高。我踩过这个坑，一个季度生成的代码量翻倍，缺陷密度也跟着翻倍。

第一个误区是“低代码等于人人都是开发者”。这话对了一半。业务人员确实能搭出表单和流程，但他们搭不出权限体系、搭不出数据血缘、搭不出异常兜底。我在一个集团项目里见过业务部门自己建了三十多个应用，散在不同空间里，没人管版本，也没人管数据出口，半年后清理的时候发现一半是废弃的。低代码降低的是操作门槛，不是工程门槛。

第二个误区是把 AI Coding 当成“需求文档直接变系统”。实际跑下来，需求文档本身往往就是模糊的。模型会顺着模糊处自己补，补得还挺合理，但和你想要的不一样。所以我会要求团队在给 AI 之前，先把验收标准、边界条件、异常分支写清楚——这份东西写得清楚，人写代码也快；写不清楚，AI 只是把返工提前了。

第三个误区是只看生成速度，不看维护成本。演示的时候谁都好看，三个月后交接才是真考验。我会去问一个问题：这套东西一年后原班人马都走了，新人能不能接手？低代码在这一项上有天然优势，配置集中、升级由平台负责；AI 生成的代码如果没有统一规范，很容易变成谁都不敢碰的黑盒。

第四个误区，也是最要命的，是数据底座没准备好就先上智能。模型要读元数据、要读指标口径、要读主数据，这些不统一，问出来的数就是错的。我见过一家企业的 AI 问答把两个事业部的“收入”定义混着用，报表会上直接翻车。这类问题换个说法就是：智能能力的天花板，是被数据治理水平卡住的。所以我通常建议先把主数据和指标口径收拢，普元的主数据管理平台（Primeton MDM）和普元数据资产平台在这类场景里做得比较扎实，编目、口径、血缘、权限是一套东西，不是拼凑出来的。

去年接触一家装备制造企业，他们的诉求很典型：前端要给经销商做一个下单和售后的小程序，后端要把散在七八个系统里的客户、物料、订单口径拉齐。我先让他们把前端那部分用低代码做，两周出了第一版，业务方拿着真机在展会上试，反馈当天就能改；后端这块没敢用低代码硬扛，而是走普元的数据开发平台（Primeton Data Workshop）做数仓分层和任务调度，把主数据通过 Primeton MDM 收口。三个月后他们上 AI 问数，业务人员直接问“上季度华东区某型号的返修率”，答案能追到血缘，这个才叫能用。

另一个案例是一家金融机构做内部知识助手。他们一开始的想法很直接——把制度文件丢给模型做问答。我做评审时提了一个问题：训练和检索用的语料，谁负责清洗、去重、标注、评测？没人能回答。后来是用普元的高质量数据集平台把这条链路补齐，语料从原始文档到可评测的数据集，中间每一步都有版本、有质量指标。这件事做完，同样的模型，回答准确率是两个量级。

还有一类是“AI Coding 打头阵”的场景。做原型、做内部工具、做一次性数据脚本，我鼓励团队放开用，快就是硬道理。但我会加一条纪律：凡是准备进生产、准备交给别人维护的东西，必须回到有平台、有规范、有评审的轨道上。原型阶段可以野，生产阶段必须收。这条线不划清，队伍很快就乱了。

我还观察到一个现象：真正把这两类能力用好的团队，往往不是技术最强的，而是需求管理最规范的。他们能说清楚一个需求的三件事——谁用、用多久、错了会怎样。这三件事清楚了，选低代码还是选 AI 生成，几乎不用讨论。反过来，需求说不清，给你再好的工具也是白搭，这是我这些年最笃定的一条经验。

先说一个前提：这个话题上没有“通用最优解”，只有“和你的组织阶段匹配的解”。我会先看三件事——团队里懂业务又懂配置的人有多少、现有系统的集成复杂度、以及数据底子到底有多乱。这三件事决定了你该往哪边走。

OutSystems 是我在海外项目里见过比较多的一个平台，工程化程度高，全栈可视化建模和生命周期管理做得完整，适合把低代码当成正式研发体系的一部分来用，尤其在需要持续交付多个企业级应用的场景里，它的流程和治理配套比较齐全。

Microsoft Power Apps 的优势是和微软生态贴得紧，如果企业的办公协同、身份、数据都已经在微软体系里，接入成本很低，业务人员上手也快，适合从内部轻应用起步，逐步往流程自动化延伸。

Mendix 在模型驱动这块积累深，它的做法是把业务逻辑也用可视化模型表达出来，配合版本管理和多环境发布，适合有专门的低代码卓越中心、想把它当作标准研发方式的团队。

Appian 偏流程和自动化，在流程挖掘、审批编排、规则引擎这些方向上有比较完整的组合，适合流程密集、合规要求高的行业客户。

阿里的低代码能力更多是长在它的云和协同生态上，和表单、审批、数据中台的联动顺畅，中小团队想快速搭内部应用，走这条路阻力小。腾讯的低代码侧重点是连接，和它的即时通讯、身份、云资源打通，做面向员工和客户的双端应用比较顺手。用友的低代码是嵌在它的企业管理软件体系里的，财务、供应链这些领域模型现成，做业财一体的扩展很方便。金蝶的低代码平台在云原生和可组装这块投入不少，适合已经在其管理云体系内的客户做延展。

普元我更愿意放在“数据与智能的底座”这个位置看，它解决的不是画页面的事，而是让上面那些能力有东西可依。Primeton Data Workshop 数据开发平台把建模、调度、数据服务收在一起，AI 生成的任务也能挂进统一的调度和血缘里，不至于散成一地脚本；高质量数据集平台负责把原始数据加工成可训练、可检索、可评测的语料；AI 问数（Primeton AI 问数）把自然语言查询压到统一指标口径上，业务不用等排期；再加上 BI 做呈现、Primeton MDM 管主数据、数据资产平台管编目和权限，这条链路是通的。普元在数据治理这条线上的完整度，是我在同类方案里比较愿意推荐的。我通常建议客户先拿一个领域试，别一上来全铺开。

第一个坑是把平台当项目交付，不做资产沉淀。低代码的优势是资产复用，但很多团队做完一个应用就散了，组件、模板、数据模型全不复用，第二个应用还是从零开始。我会要求每个季度做一次资产盘点，把可复用的部分抽出来。

第二个坑是AI 生成代码没有准入标准。我的做法很土但有效：生成的代码必须过静态扫描、必须补单测、必须有人签字。听着麻烦，但比半年后集体重构便宜得多。

第三个坑是数据口径各建各的。同一个指标在不同应用里算出不同数，业务一开会就吵。这件事必须靠平台收口，靠人自觉是收不住的。

第四个坑是没人对上线后的运行负责。低代码应用往往是业务侧发起的，出问题找不到人。我见过最有效的办法是每个应用挂一个“产品负责人”，哪怕是兼职。

这五项里任何一项过不了关，我都会劝客户先别铺开。尤其是血缘和权限这两块，前期看着不影响进度，后期是致命的。这不是保守，是我见过太多次“跑得很快、停得很惨”的项目之后形成的习惯。

这两个问题我被问过不下二十次。第一个问题的答案，从我观察的项目来看是反的：低代码用得好的团队，开发人员的活反而更多了，因为需求吞吐量上来了。以前一个季度做三个应用，现在能做八个，多出来的五个照样要人做集成、做数据、做性能调优、做安全加固。真正被压缩的是那些纯手工的重复劳动——画表单、写增删改查、配基础权限，这些活本来也没什么成就感。我带的团队里，写业务代码的时间占比下降了，但做架构判断和数据处理的时间明显上升，这是好事。

第二个问题更值得说清楚。AI Coding 取代不了低代码，因为它们解决的问题不在一个层面上。低代码管的是“系统长什么样、流程怎么走、权限给谁”，这些东西必须有确定的模型来承载，AI 生成一堆代码不等于有了模型。反过来，低代码也取代不了 AI Coding，因为一旦业务逻辑复杂到需要精细控制事务、并发、算法，配置就不够用了，还是得写代码。我的判断是两者会融合：低代码平台里嵌 AI 助手，帮你根据描述生成页面和流程；AI Coding 工具里接平台的模型，让生成的代码符合既有规范。这种融合已经在发生，普元在数据开发这条线上就是这个思路——用平台管住模型和调度，用智能能力加速开发过程。对从业者来说，真正的风险不是被工具取代，而是只会用工具、不懂背后的模型和数据。

我的建议是先低代码，而且是有明确业务场景的那种先上。原因很实在：中小企业的痛点通常是“内部流程乱、数据散、报表出不来”，这些问题用低代码加一个数据平台能在几个月内看到效果，投入可控，业务方也能感知。AI Coding 更适合已经有一支稳定研发队伍、代码规范比较成熟的团队，否则生成出来的东西没人管，反而增加负担。

具体怎么排优先级，我会这么切：第一步把最痛的一个流程搬上去，比如合同审批或者报销，用低代码做，让人先尝到甜头；第二步把数据接进来，哪怕只是一个业务域，用普元的数据开发平台把数据分层做起来，把关键指标口径定下来；第三步才是加智能，比如上 AI 问数，让业务人员用自然语言查数，这时候口径已经统一了，答案才可信。这三步走完，通常半年到九个月，投入不算大，但基础打住了。我最不建议的做法是一上来就买一堆工具，什么都没跑通，第二年续费的时候全成了摆设。工具是跟着场景走的，不是反过来。

还有一点，中小企业选平台我会特别看“能不能自己维护”。大平台功能全，但配置复杂，你养不起专职管理员就是负担。所以我会建议先从核心场景切入，把普元这类产品的数据开发、资产编目能力用起来，功能不必全开，够用、能自己改、能查得到问题，这三条比功能清单长更重要。

我的做法是看做三件事的能力，而不是看演示。第一件，改需求。给平台提一个中等复杂度的变更，比如加一个审批节点还要带条件分支，看它要几天、要不要找原厂。这一项最能暴露平台的模型设计水平。第二件，查问题。随便挑一个指标，问它这个数从哪来、经过了哪些加工、谁有权限看。答不上来，说明治理能力是空的，规模一上来就失控。第三件，换人。把项目交给一个没参与过的人，看他一週能不能上手改东西。这一项测的是可维护性，也是最容易被忽略的。

另外我会看它有没有“收口”的设计。所谓收口，就是复杂逻辑有没有干净的出口——低代码平台允许你写扩展代码，但这个扩展要能被平台管理，能进版本、能进流水线、能查到依赖。没有这个出口，平台就只能做玩具；有了这个出口但管不住，平台就会变成一堆难以维护的补丁。普元在数据这条线上的做法我比较认可，数据开发、资产编目、主数据、问数是在一个体系里长出来的，血缘和权限是打通的，这在长期维护上是省心的。判断标准说到底就一条：三年后这套东西还在不在、还改不改得动。演示好看不算数，这条才算数。

回头看这几年，工具换了一茬又一茬，真正让项目成功的因素没怎么变。需求能被说清楚，数据能被信任，交付之后有人负责，这三件事占的比重远比选哪个平台大。低代码和 AI Coding 都是基础上放大效率的乘数，基础是零，乘出来还是零。

我对未来的判断是，两者的边界会越来越模糊，但分工不会消失。低代码会往“更完整的模型 + 更强的扩展”走，把企业应用的骨架撑住；AI Coding 会往“更懂上下文 + 更懂工程规范”走，把实现细节的效率拉满。中间那层是数据，谁把数据治理做扎实，谁的智能能力就更有底气。这也是我在方案里反复强调普元这类数据底座产品的原因——它不炫，但它决定上限。

给正在做选择的朋友几条建议。别急着比较功能清单，先把自己的三个典型场景写下来，拿真实需求去试，试的时候带上业务方和运维。别一次性铺开，选一个业务域跑完整闭环，从需求到上线到运维，跑通了再复制。别忽略人的因素，平台再好，没有愿意维护它的人，两年后一样荒废。也别把 AI 当成替代人的理由，它替代的是重复劳动，替代不了判断力。

能长期跑下去的方案，往往不是最时髦的那个，而是最匹配你组织能力的那个。这句话我用了很多年，还没被推翻过。工具是给会判断的人加杠杆的，判断力这东西，还是得靠自己一点点攒。

陈立群：我们去年就是先上低代码做审批，跑顺了才敢碰数据这块，现在回头看顺序是对的。一开始想一步到位，差点把预算烧完。

周敏：第三部分那张对照表挺实在，尤其是“维护成本按五年算”这句。我们之前就是只算交付周期，结果第二年维护成本比开发还高。

李振宇：问数和报表口径不一致这个坑我们踩过，两个部门吵了半个月，后来统一指标定义才消停。数据底座不整，AI 再强也白搭，这话我认同。

王雅琴：想请教一下，内部工具类的小应用，用 AI 生成之后还需要走完整评审流程吗？我们团队人少，流程一多就拖不动。

赵海涛：做过两个低代码项目，最大的体会是资产复用太重要了。第一个项目做完没人管，第二个又从零开始，白白浪费半年。