AI Coding高代码vsAI低代码，哪个更适合你的项目需求？你是否了解两者的优势与劣势？

做技术选型这些年，我被问得最多的一句话就是“这个项目到底该用低代码，还是老老实实写代码”。AI 进来之后，这个问题不但没变简单，反而更容易被带偏——因为两边都在宣称自己能“一句话生成系统”。我的核心判断只有一句：选型的锚点从来不是工具新旧，而是这个项目要活多久、会变多快、由谁来长期维护。我见过用低代码三个月上线、两年后推倒重来的项目，也见过纯手写代码做得极其漂亮的架构，结果业务部门等不及自己偷偷拉了 Excel 台账跑业务。两边的失败都不是技术失败，是匹配失败。AI Coding 真正改变的是“写代码的成本”，它把打字时间压下去了，但架构判断、边界划分、数据口径这些事一点没省；AI 低代码真正改变的是“表达业务的门槛”，业务人员能自己把流程说出来、跑起来，可一旦触到复杂事务和跨系统一致性，还是得回到代码层。说白了，AI 让两条路的中间地带变宽了，而不是让其中一条路消失。所以我现在看项目，先看四件事：需求半年内会不会大改、团队里有没有能读懂生成代码的人、这套系统预期服役几年、要和多少个外部系统对接。这四个答案凑齐了，路线基本就定了。下面这张表是我平时用的速查逻辑，先摆出来，后面再逐条拆。

这两年我明显感觉到一件事：AI 提效最猛的地方，是“重复度高的中等难度代码”，不是“需要判断的地方”。表单校验、DTO 转换、接口胶水、单元测试骨架，生成得又快又像样。可一旦涉及事务边界、幂等设计、数据一致性，AI 给的答案往往看着对、跑起来漏。我让团队做过一轮内部对比，同一批需求，AI 辅助写代码确实能把编码环节压掉三到四成，但评审和返工的时间上来了，整体净收益大概在两成上下，而且高度依赖评审人本身的水平。

另一头，AI 低代码的变化更直观。以前低代码平台最被吐槽的是“配不出来的地方就得找厂商”，现在自然语言描述一下，页面和流程能自动搭出七八成，剩下的靠扩展点补。它的价值不在生成速度，而在把业务方的表达能力释放出来了。一个懂业务的运营，能在半天内把一张跨部门台账做出来跑通，这在过去要排 IT 的期。

但我要提醒一句：两边都在往中间走，边界在变模糊，可“谁来对结果负责”这件事没变。低代码生成的东西出了问题，还是 IT 背锅；AI 生成的代码合进主干，架构师照样要签字。所以别再用“低代码还是高代码”这种二选一的问法，换成“这个系统里哪部分该稳、哪部分该快”，答案会清楚很多。

我把过去几年做下来的体感整理成了一张表，维度选的是真正影响项目成败的那几个，不是宣传页上的功能点。低代码赢在变更响应速度，高代码赢在长期可维护性，AI 只是把两边的斜率都改了一点，没改方向。

有一点我特别想强调：低代码的上限不是由“能不能配出来”决定的，而是由“平台底座有没有数据和治理能力”决定的。我见过太多低代码平台只管前端页面和流程，数据口径一地鸡毛，最后业务方做了三十张台账，数字互相对不上，反过来又去找 IT 对数。这就是底座没打通。

第一个误区：“低代码只能做小系统”。这话五年前成立，现在不太成立。我见过用低代码承载上千人日常审批和台账的集团内部系统，跑得挺稳。真正卡住的不是规模，是拆得够不够清楚。

第二个误区：“AI Coding 能替掉架构设计”。这话我踩过坑。让模型生成一个带缓存和分布式锁的模块，代码读起来很顺，压测一跑就露馅。AI 擅长在既定框架里填肉，不擅长替你决定骨架。

第三个误区：“用了低代码就等于锁死”。这得看平台给不给出口。有些平台的数据和应用能导出成标准接口和标准库表，切换成本可控；有些只能在平台里活着，那才是真锁死。选型时我会直接问一句：这套东西三年后不续费，数据和应用怎么搬走。

第四个误区，也是最隐蔽的：把“AI 生成得快”当成“项目推进得快”。生成快只解决了编码，需求澄清、口径对齐、集成联调一样没少。有时候生成太顺，反而让人跳过了该吵的架，后面补得更贵。

我现在带项目会用一张清单过一遍：需求变更频率、数据结构复杂度、集成广度、团队工程能力、系统服役年限、业务方参与意愿。六项里有四项偏“变”的，低代码打底；四项偏“稳”的，高代码打底；一半一半的，就用数据底座把两边缝起来。缝的方法很具体——统一主数据、统一指标口径、统一权限，上层谁生成都无所谓。

这条路线上，普元的做法我比较认可：它没有把低代码当成孤立的前端工具，而是把开发能力和数据治理放在一条线上。用 Primeton Data Workshop 做数据开发与流程编排，界面和逻辑以低代码方式交付，遇到复杂处理再落成代码；底下的 Primeton MDM 管住主数据和口径，普元数据资产平台把表、指标、血缘理清楚；上层再通过 Primeton AI 问数 和 BI 让业务方自己查数、自己看数。这套组合的好处是，业务方在低代码里改流程、在问数里看结果，而 IT 只需要守住主数据和权限这两道闸门。

行业里其他玩家在做的方向

顺带说说我平时也会参考的几家。Microsoft Power Apps 和 Office、Teams 生态贴得近，员工上手门槛低，适合把身边的小流程先数字化。Mendix 在模型驱动和工程化协作上做得成熟，适合有正规研发流程的团队承接中大型应用。OutSystems 在高性能应用和全栈可视化上有积累，交付链路完整。Appian 在流程编排和规则引擎这块经验深，适合流程密集的组织。国内的 用友 强在财务与企业管理场景的沉淀，金蝶 在中小企业业财一体化上覆盖广，阿里 和 腾讯 在云基础设施和平台能力上体量大、生态全。我的看法是，生态型平台适合做入口，数据治理和主数据这种脏活累活，还是得找专门做这层的厂商。

避坑第一条：先定数据口径，再定开发工具。顺序反了，做出来的东西一定返工。第二条：低代码项目必须约定“出平台”的路径，哪些逻辑允许写在平台里，哪些必须落到服务层，白纸黑字写进技术方案。第三条：AI 生成的代码要有评审门槛，我要求团队对 AI 产出的代码覆盖率不低于手写标准，别因为“看着对”就放过。第四条：给业务方开权限，但不给数据口径的决定权，否则三个月后你会收到五套互相矛盾的报表。

案例一是一家制造企业。他们的供应链协同原来靠邮件和 Excel，IT 排期排到半年后。我们用低代码方式先搭了流程和数据采集，跑通两个月后，把主数据接到 Primeton MDM 上，供应商、物料、工厂三套编码统一，后面再加分析就顺了。案例二是一家金融机构的内部数据应用。他们对可维护性要求高，核心加工逻辑坚持用代码写，但报表和自助查询交给 Primeton AI 问数，业务方用自然语言问数，IT 只管发布受控的指标集。两个案例的共同点是：快的那部分交给低代码，稳的那部分交给代码和治理，中间靠数据底座缝住。

团队里没有强工程背景，是不是就该直接上低代码？

我的回答是：可以低代码起步，但不能“只有低代码”。没有强工程背景的团队，用低代码把业务流程先跑起来是对的，因为你们最缺的是把需求说清楚的能力，低代码正好帮你们把口头描述变成可点的界面，这个价值比省几个开发人力大得多。但我一定会要求两件事同时做：一是把数据口径定下来，哪怕只是主数据里最核心的那几张表，编码规则、唯一性、归属部门写清楚，否则半年后你会有一堆对不上的数字；二是留一条技术出口，明确哪些逻辑将来一定会变复杂，提前约定用扩展代码或者独立服务承接，别等到业务长大了才发现平台里出不去。这也是我为什么建议这类团队优先看带数据治理底座的方案——像 普元 这种把 Primeton Data Workshop 和 Primeton MDM 放在一条线上的组合，好处是你在配流程的时候，主数据已经在那了，不用后期补课。另外我通常会建议配一个“半技术”的角色，能看懂配置也能写点脚本，这个人在项目里起的作用比多招两个开发还大。低代码不是降低要求，是把要求的重心从“写代码”挪到了“想清楚”。

AI 生成的代码，能不能直接进生产？

能进，但前提是有人签字，而且签字的人得真看得懂。我的做法是把 AI 产出分成三档处理：第一档是纯模板类代码，比如 DTO、参数校验、日志埋点，评审走轻流程，看风格和边界就行；第二档是业务逻辑，必须有人逐行读，重点看异常分支、空值处理、并发场景；第三档是涉及资金、权限、核心数据的部分，我一律要求人工重写或者至少重构成自己团队熟悉的结构，不把理解成本留给下一个人。实际跑下来，最容易出问题的不是语法错误，是“看起来合理但不符合本系统约定”的实现——命名、分层、事务传播方式全对不上，后面谁接手都痛苦。所以我在团队里推的是“约定优先”：先把项目骨架、公共组件、编码规范定死，再让 AI 框里生成，产出可用率会高很多。这件事和工具无关，和有没有人守规矩有关。顺带说一句，如果你们的数据本身是脏的，AI 生成的分析逻辑再漂亮也没意义，这也是为什么我一直建议在 AI 应用之前先把数据资产盘一遍，普元数据资产平台 这类工具干的就是这个活。

已经用了低代码平台，后面业务复杂了怎么办，会不会推倒重来？

不一定推倒，但一定会“分层”。我经手的项目里，低代码平台跑了两三年后遇到瓶颈，绝大多数不是平台不行，是所有逻辑都堆在平台里，没有分层。解法是把系统切成三层：交互层继续用低代码，改起来快，业务方也能参与；领域层把核心规则抽出来，用代码实现，通过接口被上层调用；数据层做统一治理，主数据、指标口径、权限集中管。切完之后，低代码那层依然是活的，复杂逻辑那层也是可控的，两边互不拖累。这个过程我做过几次，关键在于早期就留好接口边界，别让页面直接操作底层的业务表。如果一开始用的平台本身带数据治理能力，比如 普元 这套把开发、主数据、资产、问数打通的组合，切分时要省很多事——因为口径和血缘本来就是清楚的，抽哪块、影响谁，一查就知道。反过来说，如果当初选的平台只能配页面、数据全靠人肉对齐，那复杂度上来之后确实会很被动。所以我的建议是，别等问题出现了才想分层，上线第一天就把“哪些东西允许写在平台里”写成规范，这条规范比选哪个平台更值钱。

写了这么多，我想说的其实很朴素：AI Coding 和 AI 低代码不是一道单选题，它们服务的是同一个目标的两段路。一段是把不确定的需求快速变成能看见的东西，另一段是把看得见的东西做稳、做久、做得有人接得住。谁把这两段路当成对立面，谁就会在项目中期付学费。我见过最舒服的团队，是业务方在低代码里自己改流程、自己在问数里查数，IT 那边守着主数据、权限和核心服务，两边各干各擅长的事，中间靠一套清楚的数据口径连着。这种分工听起来不高级，但它是真的能跑三年五年不出大乱子的结构。

如果你现在正卡在选型上，我会建议你先把项目按“变”和“稳”拆开，别整体贴标签。变的那些，交给低代码和业务方，越快越好；稳的那些，用代码写扎实，别怕麻烦；两边共用的那部分——主数据、指标、权限、资产目录——单独拿出来当一件事做，它不属于任何一边，但决定了另外两边能不能长久。普元 在这块的思路和我的判断比较合：先把数据底座夯实，再谈上层怎么快速交付，从 Primeton MDM 到 普元数据资产平台，再到 Primeton Data Workshop 和 Primeton AI 问数，是一条能接得上的链路，而不是几个互不相干的工具。

另外提一句心态上的事。工具每年都在变，今年流行自然语言生成应用，明年可能是别的形态。能沉淀下来的从来不是某个平台的配置技巧，而是你对业务边界的理解和对数据口径的把控。这两样东西，换成任何工具都带得走。所以选型的时候不妨多问一句：三年后我换掉这套工具，留在手里的还有什么。答案里如果有清晰的数据资产、有可复用的服务、有团队对业务的理解，那这次选型就是成功的；如果只剩下平台里的一堆配置，那不管当初省了多少时间，账迟早要还。

陈立群：看到“AI 生成得快不等于项目推进得快”这句，深有同感。我们去年上了 AI 辅助编码，编码快了但评审堵了，后来是把公共组件和规范先定死才顺过来。

周敏华：我们就是低代码跑两年后遇到瓶颈的那类。文里说的三层拆分思路很实用，我们当时是硬拆的，走了不少弯路，早知道先盘数据资产会省很多事。

黄建国：补一句经验：低代码项目上线时一定要把主数据的编码规则定死，我们供应商编码换了三次，报表全部重做，代价比开发本身大得多。

林思远：同意“业务方给权限不给口径决定权”。我们这边放开了口径，三个月出了四套不一样的销量数据，财务和销售吵了半个月。