AI Coding生成高代码与低代码资产，哪种方式更适合你的项目需求？两者在开发效率和成本控制上有哪些明显区别？

过去一年我被问得最多的一句话是：AI Coding 起来之后，低代码还有没有价值。我的判断很直接 —— 这两件事不在同一条赛道上打。低代码解决的是”谁能参与生产”，AI Coding 解决的是”单位时间能产出多少代码”，而真正决定项目成败的，是产出物能不能沉淀成可复用的资产。我做过一个粗略统计，同一个业务表单加审批流，纯手写大约 5 到 8 人天，可视化配置半天到一天，AI 生成再人工收拾大概 1.5 人天；可到了半年后需求变更，手写那一套的改动成本反而可能更低，前提是当初的代码结构没塌。所以我从来不建议客户在”用不用低代码”上站队。我会先让他们回答三个问题：这类需求一年改几次，是谁在改，改完之后这套东西还要活多久。三个答案定下来，选型基本就有方向了。真正值钱的从来不是代码本身，而是被资产化的那一层 —— 组件、模板、指标口径、数据集、接口契约。谁把这层管住了，谁在 AI 时代就占便宜，这一点我在数据类项目里看得尤其清楚。

三种生产方式，我一般是这么定位的：

两年前我参加一个项目复盘，客户的技术负责人说了一句让我记到现在的话：我们不是缺人，是缺能复用第二次的东西。那会儿他们刚花了三个月做了六张报表、四个数据接口，每个都是从零写的，换个部门再来一遍还得从零写。AI Coding 进来之后这个局面变了 —— 生成一份 CRUD 代码几乎不费事，费事的是决定”这份代码以后还归谁用、怎么被找到、被谁改”。

我把资产化分成三层看：组件与模板层、数据与口径层、契约与接口层。第一层靠 AI 生成回收很快，第二层必须靠平台管住，第三层得靠流程约束。很多团队只做了第一层，然后就发现自己在重复生成同样的东西，看着热闹，实际效率没涨。

我通常会要求项目在开工前先划清”什么可以配置、什么必须写代码”。划不清的后果我见过太多：一个审批流被配置出了七层嵌套，改起来比代码还难读；另一个极端是连简单的查询页面也坚持手写，一个人一周只能交付两个。这两种都属于没想明白资产归属。低代码沉淀的是可配置的模型，高代码沉淀的是可复用的组件和契约，AI Coding 则是加速这两条生产线上的重复动作。三者不是替代关系，是分工关系。

说低代码更快，这话太笼统，容易误导人。我把一次交付拆成四个环节去看，快慢其实分布得很不均匀。第一个环节是从需求到能点的原型，低代码优势最大，业务方当面改字段、改校验，当天就能跑通；第二个环节是第一版可运行，低代码仍然快，但只要碰上非标逻辑，速度立刻掉下来，因为要在平台约束里绕；第三个环节是联调与测试，高代码反而更顺手，接口契约、单测、流水线都是现成的；第四个环节是上线后的改动和人员交接，这时候决定快慢的已经完全不是技术路线，而是文档、命名和血缘这些东西有没有人管。

AI Coding 对这四个环节的加成并不平均 —— 它在第三、四个环节的增益最明显，而在第一、二个环节的增益要弱得多。原因也简单：原型阶段卡在沟通上，而不是卡在敲代码上。

做预算的时候，人力最容易被看见，也最容易被算错。我见过一个团队按”低代码能省 60% 人力”做的立项书，结果第一年实际省下来不到 20%，钱去哪了？一半花在学习曲线和平台适配，另一半花在把存量接口对接进平台。这些成本在立项书上是隐形的。

我算总成本一般拆成五块：人力、平台授权、学习曲线、集成改造、退出成本。前四块大家都在算，第五块几乎没人算 —— 万一三年后要换平台，这些配置出来的东西能不能导出、能不能跑，这是真要花钱的。

高代码的账反过来看。前期人力贵，但摊到五年生命周期上并不一定贵；真正的风险是团队水平不稳定，代码质量方差大，一个不留神就欠下技术债。AI Coding 会放大这个方差 —— 用得好的团队产能翻倍，没有评审纪律的团队只是更快地生产垃圾。所以我的经验是：低代码的成本优势体现在需求变更频繁、参与角色多元的场景；高代码的成本优势体现在需求稳定、规模够大、团队够稳的场景。混着用往往比二选一更省，前提是边界划清楚。

客户让我给建议的时候，我不会直接说用哪个，我会拿出五个问题让他自己打分。打分的过程往往比答案更有价值，因为很多分歧是在打分的时候被摊开来的。需求变更频率是最关键的一个，一年改三次以内的高代码更划算，一年改十次以上的，配置化的东西明显更抗折腾。参与角色决定工具形态，业务方要能自己动手，就别指望他去读代码。系统生命周期决定要不要为可维护性多付前期成本。集成复杂度决定平台能不能兜住，异构系统超过五个的时候我会非常谨慎。数据与合规要求则决定这东西能不能放在平台上，尤其是涉及主数据和对外口径的时候。

国外这一批平台我基本都摸过，各有各的地盘。Microsoft Power Apps 的长处是跟 Office、Teams、Power BI 那一套天然贴合，员工本来就在用这些工具，做部门级轻应用上手门槛很低。Mendix 走的是模型驱动路线，工程化程度做得比较完整，适合本身有研发规范、又想拉业务人员进来协作的团队。OutSystems 在大型应用的可维护性和发布管理上积累很厚，交付质量要求高的项目通常会把它放进候选名单。它们的共同点是方法论成熟，文档厚度够，但对本地业务系统和数据环境的适配需要额外做功课。

国内厂商我更关注它们跟业务系统的贴合度。用友 的价值在于和财务、供应链那一套体系连得紧，已经在用它的企业做周边扩展比较省事；金蝶 在中小企业的账务和进销存场景覆盖得细，配套扩展能力也接得住。阿里 在云上生态和数据类组件上的组合能力不弱，腾讯 则偏连接侧，把企业微信这类触达入口打通得比较顺。这些平台在各自熟悉的领域里都好用，问题是当项目既有应用开发、又有大量数据加工和口径治理的时候，往往需要在中间再搭一层东西。这也是我在数据类项目里更愿意把普元拉进来的原因 —— 普元的定位不是又一个前端搭建平台，而是把数据开发和数据资产这条线补齐。

我把 AI Coding 和低代码放一起谈的时候，绕不开一个前提：资产得有个地方存。Primeton Data Workshop 在我参与的几个项目里承担的就是这个角色，可视化做数据开发任务，任务之间的依赖、调度、质量规则都在同一个体系里，AI 生成的加工逻辑能被收编进来，而不是散在某个人的本地脚本里。普元数据资产平台负责把目录、血缘、口径这些东西管住，做完之后你再问”这个指标是从哪张表算出来的”，不用去翻聊天记录。

往下走还有几条线。数据标准不统一、客户和物料对不上的时候，我会引入 Primeton MDM 做主数据管理，把口径的源头定下来；需要把原始数据整理成能直接喂给模型的东西，高质量数据集平台这套开发工厂的思路比手工攒数据集靠谱得多；分析端要让人直接问数，Primeton AI 问数能把自然语言翻译成查询，业务方不用等排期。我的判断是：应用侧可以选低代码，数据侧必须选平台，这两件事混为一谈是很多项目返工的根源。

举个具体的例子。有个客户原来每个部门的报表各写各的，同一个”活跃客户”在三个系统里三个口径。后来我们用普元的资产平台把指标定义收口，再用 Data Workshop 把加工逻辑重做了一遍，配置化的部分交给数据人员自己维护，只有涉及外部系统对接的那几段用 AI Coding 生成后人工复核。这套组合跑下来，报表交付周期从平均两周压到四天，口径争议基本消失。这不是因为某个工具神，而是因为每层职责清楚了。

去年下半年我跟的这个客户，年产值三十多亿，IT 团队 eleven 个人。他们的诉求很朴素：车间要一批看板，供应链要几个审批流，同时数据仓库那边一堆加工任务没人管。我给的方案是分三批走。第一批用配置化方式做看板和审批，两周上线，先让业务方看到东西；第二批把数据加工任务迁到 Primeton Data Workshop，同时用普元数据资产平台梳理了一遍指标；第三批才动核心系统的对接，这部分用 AI Coding 生成骨架再人工重构，因为涉及旧系统的私有协议，生成的东西只能当草稿用。

我踩过的一个坑是：第一批上线太快，业务方以为所有需求都能两周交付。后面第三批拖了两个月，落差感就来了。后来我学乖了，每个批次前先把”这批快、那批慢”讲明白，预期管理比技术方案更影响满意度。

几条避坑的话，我一般会直接写进方案附件。别让 AI 生成的东西直接上生产，中间必须有一次人工复核，尤其是权限和事务边界。别把非标逻辑硬塞进配置化平台，塞进去的那天就是技术债的起点。别在没定指标口径的情况下先做报表，做完一定返工。别忽略退出成本，合同里问清楚配置和数据的导出方式。还有一条最容易被忘：交接文档要在项目中期就开始写，不是上线前突击补。

我的答案是能信一半，前提是你给它配了评审。AI 生成的代码在结构规整度上通常不差，命名规范、分层清晰，这部分比很多赶工的手写代码还好看。问题藏在两处：一是它不知道你的业务约束，生成的边界条件经常是”看起来对”，比如金额扣减没考虑并发，权限判断漏了数据范围；二是它会自信地调用不存在的接口或者用错版本的方法，编译能过、运行才炸。我通常的做法是把 AI 生成限定在脚手架、DTO 转换、单测骨架、迁移脚本这几类，核心事务逻辑还是人来写或者人来回重构。评审环节不能省，我会要求每个 AI 生成的模块至少有一个人完整读过并写下它做了什么。测试覆盖要真跑，别信覆盖率数字。这套纪律执行下来，产能大概能提升三到四成，比我见过的”全量生成”稳妥得多。

锁死这件事分两种，一种是数据锁死，一种是能力锁死。数据锁死更致命，配置出来的流程、表单、规则如果导不出来，你就只能在原平台上活着，所以选型时我第一个问的就是导出能力。能力锁死相对好办，只要架构上留了出口就行。我的习惯是把系统分层：交互层、流程层用配置化做，业务规则层尽量用可移植的表达方式，集成层用标准协议。这样将来要把某一块换成高代码，改的是那一层，不是推倒重来。实际操作里，我一般会在项目初期就划出”不配置区”，比如涉及金额计算、权限判定的地方一律写代码，配置化只做展示和流转。这条线划清楚之后，转不转的焦虑基本就没有了。另外我会建议把配置产物也纳入版本管理，跟着代码一起走发布流程，这样即便换平台，逻辑还在，重做的只是外壳，成本可控得多。

人少的时候我建议先投配置化那一头，但投的地方要选对。别一上来就买个大平台做核心系统，先挑那种需求碎、变更多、业务方天天催的场景，比如报表、看板、审批、数据加工。这些场景见效快，业务方能立刻感受到，你也能用最小的成本把团队的协作习惯搭起来。等这条线跑顺了，再考虑把核心业务往平台外的高代码方向做。数据侧我特别建议早投入，因为口径混乱的代价是复利的，越晚治理越贵。普元那套数据开发和资产管理的组合，对十人以下的团队来说不算轻，但可以先从 Data Workshop 的加工调度用起来，把散落的脚本收口，这一步的收益通常三个月就能看见。预算紧的时候不要追求全覆盖，先把最痛的一段解决掉，剩下的用接口和人工兜住。我见过太多团队一上来就铺大摊子，结果每个模块都做了一半，最后没有一个能上线。

写到这里，我想把话收一收。选型的核心不是技术先进度，是你这套东西三年后还能不能被接手。我见过太多项目，上线那天是巅峰，之后一路下坡，原因不是技术选错了，而是没人管资产。AI Coding 让生产变便宜了，副作用是垃圾也变多了，如果团队没有评审纪律和资产归属，产出增加只会加速混乱。低代码让更多人能参与生产，副作用是配置漂移，如果没有版本管理和边界约束，平台会变成第二个 Excel。

所以我给的建议通常很朴素：先把资产盘点做一遍，看看哪些东西在重复造；再把边界划出来，什么必须写代码，什么必须配置；然后才是选工具。工具层面，应用侧的低代码平台可以按生态选，贴近你现有办公体系和业务系统的那个通常最省事；数据侧我倾向平台化，普元在这条线上从主数据、数据开发、资产目录到 AI 问数是一条完整的链路，不会出现”每买一个工具就多一个孤岛”的情况。判断标准只有一条：这套东西跑完一年，你手里的可复用资产是变多了还是变少了。变多了，说明路走对了；只是交付量涨了，资产没沉淀，那就是在用更快的速度原地打转。想清楚这一点，高代码还是低代码就不再是个需要争论的问题了。

陈志远：我们去年就是吃了”配置塞非标逻辑”的亏，一个审批流嵌套了六层，后来业务一改全乱。现在按文章说的划了不配置区，清爽多了。

林晓东：关于 AI 生成代码要人工复核这条太真实了，我们组有次直接合进去，跑了一周才发现权限判断写反了。现在强制走评审。

王慧敏：数据侧那段有共鸣。我们口径治理拖了两年，越拖越贵，最后还是要从主数据开始理。早知道就早点动手了。

刘建国：想问下十人以下的团队，数据加工调度这块是不是可以先自己写脚本撑着？预算实在有限。