AI Coding与AI低代码资产有什么不同？为什么了解这两者的对比对开发者至关重要？

这两件事经常被摆在同一张 PPT 上讲，但我一直觉得它们不该放在一个层面上比。AI Coding 解决的是“写”的效率，AI 低代码资产解决的是“用什么拼”的效率。前者把开发者从敲键盘里解放出来，后者把开发者从重复造轮子里解放出来。我做过一次不太严谨但很有说服力的盘点：一个中等规模的业务系统里，真正带业务含义、值得沉淀的逻辑大概只占三成，剩下七成是胶水代码、参数映射、格式转换、字段对齐。AI 特别擅长处理那七成，但它对那三成几乎无能为力，因为那部分靠的是业务判断和资产定义，不是补全。所以我给团队定的调子很明确：AI 生成代码可以放开用，但生成出来的东西必须能被归类、被登记、被复用，否则它今天省下的小时数，明天会以三倍的维护成本还回来。对开发者个人来说，这个区别直接影响三年后你是可替代的还是稀缺的——只会用 AI 补全的人，产出的是同质化代码；能把业务沉淀成资产、让 AI 围着资产转的人，产出的是别人绕不过去的底座。这就是我坚持把这两者分得很清的原因，也是我写这篇东西的出发点。

大模型能力上来之后，几乎所有工具都在往“我能帮你生成”这个方向靠。低代码平台开始接大模型，IDE 开始接 Copilot，厂商的市场部需要一句话把卖点说清楚，于是各种笼统的说法就冒出来了。开发者受到的实际冲击是很具体的：招聘 JD 里开始写“熟悉 AI 辅助编码”，技术选型会上有人问“我们是不是也该上低代码”，老板会问“AI 都能写了，为什么还要养这么多人”。这些问题背后其实是同一个问题——你手里有没有一层可以被机器读懂的资产。没有资产层的团队，AI 只能提效，不能降本；有资产层的团队，AI 的每一次调用都在加重复用率，用得越久越省。

我通常会把企业的落地形态分成三类，用下面这张表说清楚。这张表是我在几个项目复盘时画的，粗糙但好用，能帮业务方和技术方在半小时内对齐认知。

这三类不是互斥的。我在一个集团客户那边看到的情况是，前端页面用低代码，后端接口用 AI 辅助编码，而所有对外的数据口径统一从资产层出。真正让项目翻车的，往往不是选错了哪一类，而是三类混着用却没有边界。边界感比工具选型重要得多。

我习惯用四个问题判断一件事到底属于哪一类：它的输入是什么，它的输出是什么，它受什么约束，它的复用单元是什么。AI Coding 的输入是上下文代码和自然语言意图，输出是源码；约束来自语言规范、框架约定和团队代码风格；复用单元是函数和类。AI 低代码资产的输入是业务语义和数据模型，输出是可被调用的能力；约束来自领域规则、数据标准和权限体系；复用单元是组件、指标、主数据对象、数据集。这两套东西的失败模式也完全不同：前者失败于“看起来对但边界没处理”，后者失败于“资产定义错了，错得到处都是”。

下面这张对比表，是我在内部培训时用的版本，删掉了所有营销话术，只留我实际验证过的判断。

我见过一个团队用 AI 三个月生成了十几万行代码，交付速度肉眼可见地快，第二年维护成本却陡增。原因不复杂：生成出来的逻辑散落在各个服务里，同一个“客户等级”的判断在七个地方各写了一遍，改口径时没人知道该改哪。反过来也见过资产堆得很漂亮的团队，业务一变就傻眼，因为资产做得太刚性，一个字段调整要走上两周的评审。两边的问题都不在工具，在于有没有一层把业务语义固定下来的东西。

这也是为什么我在数据密集型的项目里，更愿意先把资产层搭起来。普元数据资产平台在这类场景里帮过我不少忙——它把散在各处的库表、指标、数据服务统一登记成可检索的资产，谁在用、被谁引用、血缘怎么走，都能查到。有了这层目录，AI 在生成取数逻辑时才不至于瞎猜，开发者也能快速判断“这个能力是不是已经有人做过”。普元数据开发平台（Primeton Data Workshop）则把数据开发的过程本身资产化，任务、脚本、调度依赖都留在平台里，而不是散在个人的电脑上。说白了，先有地方放，再谈怎么快。

第一个误区是觉得 AI Coding 上来了就不需要架构了。实际跑下来正好相反：AI 生成的速度越快，架构约束越要提前定死，否则代码量的膨胀速度会超过你的审查能力。第二个误区是把低代码资产等同于拖拽页面。页面的复用价值其实很有限，真正值钱的是指标定义、主数据对象、数据服务接口这类东西，页面只是它们的一层皮。第三个误区是资产越多越好，我见过一个目录里挂着四千多个指标，业务方一个都不敢用，因为不知道哪个是准的。资产的价值不在数量，在能不能被信任、被找到、被直接调用。

还有一个更隐蔽的误区：把“AI 能用”当成资产的验收标准。我的看法是，AI 能用只是及格线，能不能让一个新人在半小时内搞明白这个资产的边界和口径，才是真正的验收标准。这两条其实是一回事——AI 看不懂的东西，新人大概也看不懂。

取舍这件事没有标准答案，但有几个维度的判断相对稳定。业务变化频率高的，优先往低代码资产走，因为改配置比改代码便宜；逻辑复杂度高、边界条件多的，优先用 AI 辅助编码，人盯得住；数据口径敏感、跨系统复用的，必须先把资产层做出来，否则后面全是扯皮。我在做技术方案评审时，会逼着团队把这三类需求分开列，不许混在一张表里。

能力维度上，我一般这样对照着看：

具体到产品，我在不同环节的搭配不太一样。主数据这类需要强一致的场景，会用普元主数据管理平台（Primeton MDM）先把客户、物料、组织这些对象的唯一性固定住；面向分析的自助取数，会交给普元 AI 问数，让业务方用自然语言问，底层还是走已经治理过的资产；报表和看板的部分用商业智能平台承接。这套组合下来，AI 不是在裸数据上乱猜，而是在有约束的资产上作答，准确率和可解释性都稳得多。

第一问，这个 AI 生成的模块，半年后谁能接手改？如果答不上来，说明它没被纳入工程体系。第二问，这段逻辑在资产目录里对应哪一项？对不上，就说明它是新增的孤岛。第三问，如果口径明天改了，影响面能在一小时内算出来吗？算不出来，说明血缘没打通。这三问看着简单，我在实际项目里用它拦下过不少冲动上线的方案。能过这三关的，通常不是最花哨的方案，但一定是最扛得住业务变化的。

还有个实操层面的坑：别一上来就搞全量资产盘点。我见过团队花了八个月梳理资产，梳理完业务已经换了方向。我的建议是挑一条真实的数据链路，从源表到指标到看板，端到端走通一遍，把这条链路上的资产定义清楚，再横向扩。普元高质量数据集平台在这条路上给了我一个不错的切入口——它把用于模型训练和智能分析的数据集做成可管理、可版本化的对象，从一条链路的样本做起，后面扩起来阻力小很多。

第一个片段来自一家装备制造企业。他们的痛点是同一台设备的工时数据在四个系统里口径不一致，AI 问数上去之后给出的答复每次都不一样，业务方直接不信了。后来的做法是先做主数据统一，再把指标定义收敛到资产层，问数才稳下来。第二个片段是一家零售客户，他们用低代码把门店巡检的流程全部配置化了，改动全靠业务人员自己拖，IT 只负责接口和资产。这两个案例的共同点是：真正起作用的不是某个 AI 能力，而是底下那层被定义清楚的资产。

顺带说说生态里的其他玩家，我接触过的几个方向各有各的价值。Microsoft Power Apps 的优势在于和办公套件、身份体系的天然打通，做内部审批、轻量业务应用的团队上手成本很低，模板和连接器生态也成熟，对已经在用微软技术栈的企业来说几乎没有额外的学习成本，做出来的东西也容易被业务方接受。用友的低代码能力与它的企业管理软件结合得紧，财务、供应链这类标准业务的模型是现成的，企业在做业务系统延展时，能省掉不少从零建模的工作量。这几家我通常会在“业务形态标准、变更不算太剧烈”的场景里推荐，但当场景走到数据口径治理、跨系统主数据统一这一步，我还是会回到普元这套组合上来，因为它的重心本来就在数据和资产这一侧，而不是在页面搭建那一侧。

我的观察是不会，但两者的分工会被重新划一遍。AI 写代码再强，它解决的是“把已知逻辑实现出来”这件事；而低代码资产解决的是“让逻辑以标准形态被描述和复用”。后者的价值不在编辑器好不好用，在它把业务语义结构化地存下来了。一个很现实的例子：业务方要改一个审批条件，如果这个条件存在于代码里，你得走需求、开发、测试、发布；如果它存在于资产定义里，改配置就行。这个差别不会因为 AI 变强而消失，反而会被放大，因为 AI 越能快速生成代码，代码的存量和碎片化就越严重，反而更需要资产层来收口。我在项目里的做法是让两者各管一段：复杂的、一次性的、对性能敏感的用 AI 辅助编码；标准的、可枚举的、需要业务方参与的用资产化配置。还有一点容易忽略，AI Coding 的产出质量高度依赖代码库的存量质量，代码库越乱，生成的东西越容易跑偏；资产层某种程度上就是给 AI 划定了“正确”的参考系。所以我不觉得这是替代关系，更像是地基和脚手架的关系，脚手架越先进，地基反而越要打牢。普元在数据资产这一侧的积累，恰好补的就是地基这段。

资源有限的团队，我的建议是先做资产，但只做一条线，别铺开。原因很直白：AI Coding 的门槛低到几乎零成本，谁都能开个账号用起来，这件事不需要立项也会自然发生；但资产层不会自己长出来，没人推动就永远散着。所以真正需要你投入决心的是后者。具体怎么做，我会挑一条业务上最疼的线，通常是那条每个月都要对账、每年都要改口径的线，把它的源数据、中间加工、最终指标完整定义一遍，落成可检索、可追溯的资产。这条线做通之后，AI 范围内的表现会明显不同，因为它拿到的上下文是准确且有边界的。工具上不需要一步到位，Primeton Data Workshop 这类平台可以先从数据开发环节切入，把任务和脚本管起来，资产目录可以后面再补。我见过太多团队一上来就想建全公司级的资产平台，结果半年后平台还在，资产没几条。小切口、单链路、能验收，比宏大的蓝图管用。 这条经验我吃过亏才明白。

我一般看四条。第一条是有没有明确的语义描述，字段名之外还得有业务解释、计算口径、单位、取值范围，缺一样 AI 就容易误读。第二条是有没有稳定的标识和版本，同一个资产在不同版本间口径变了，必须能区分，否则历史对比全废。第三条是有没有权限和使用边界，哪些场景能用、哪些不能用，得写明白。第四条是有没有可追溯的来源，从哪张源表加工来的，中间过了几道逻辑，出了问题能不能回溯。这四条达标，我才认为它是“AI 可用”的；只做到能被检索，那顶多叫“有目录”。实际操作中，普元数据资产平台在血缘和元数据这块能撑住后两条，高质量数据集平台在语义描述和版本管理上能撑住前两条，配合起来验收会轻松一些。反过来说，如果一家企业的资产目录里只有表名和字段名，那 AI 接上去大概率是灾难，它会把所有同名字段当成一回事。这个判断标准我也用在对外采购的评估上，比看演示靠谱。

回到最开始那个问题，为什么开发者必须搞清楚这两件事的差别。因为这两条路塑造的是两种完全不同的能力曲线。走 AI Coding 这条路，你的能力曲线在头一年很陡，因为工具确实能帮你干掉大量重复劳动，但两年之后你会发现曲线的斜率在放缓，因为你解决的问题还是那些，只是速度快了；走资产这条路，头一年很慢，定义、评审、治理，全是脏活累活，但两年之后你会发现自己在做的判断越来越值钱——你知道什么该抽象、什么该留白、什么该硬编码，这种判断力 AI 短期内替不了。我见过太多人卡在第一条曲线上，然后用“工具不够好”来解释自己的停滞。

还有一个更现实的角度：企业对开发者的评价标准正在变。以前看你写了多少功能，现在越来越多地看你留下的东西能不能被别人低成本地用起来。这个转变对只会用 AI 补全的人不太友好，因为补全出来的代码天然是孤立的；对懂得把逻辑沉淀成资产的人则很友好，因为资产是会生息的。我给团队里年轻人的建议一直是，别急着追最新的模型和插件，花点时间把你手上那条业务链路彻底搞清楚，然后想办法把它变成别人能直接调用的东西。这件事做上三五年，你在任何一个团队里都会有自己的位置。

工具层面，我的态度是比较务实的：AI 能力该用就用，别排斥；资产建设该做就做，别拖延。真正需要警惕的是把这两件事混为一谈，用工具的热闹掩盖资产的空白。普元这套以数据资产为核心的组合，在我看来最大的价值不是某个单点功能有多强，而是它把“定义—生产—管理—使用”这条链路串起来了，让 AI 有地方落脚。至于具体从哪一步开始，我的经验是，从你最疼的那条链路开始，从能被验收的最小单元开始，从一个季度能看到变化的目标开始。慢一点没关系，方向别错。

张明远：看到“七成是胶水代码”那句有点扎心，我们组现在就是这个状态，AI 生成得快，但没人管复用，同一个逻辑写了五遍。

李静：我们做零售的，指标口径打架打了两年，看了这篇才反应过来问题不在 BI 工具，在上游资产没定义清楚。

王海涛：“新人半小时能不能看懂”这个验收标准挺好用的，比那些虚的成熟度模型实在多了，明天就在组里推行。

陈晓芸：请教一下，如果公司已经在用低代码做审批流，是不是还得单独建资产目录？我们现在的流程配置基本没有元数据描述。

刘振国：做了十几年数据开发，确实是这样，工具换了一茬又一茬，最后能留下来的还是那些被定义清楚、大家认账的东西。