前两天，一个做IT负责人的朋友，给我发来一条消息。
“纪总，有个问题困扰我好几天了。”
我说，什么问题？
“您说，AI现在都能自己写代码了，而且写得比大部分初级程序员都好。那我们公司花了几十万上的低代码平台，是不是刚买回来就过时了？低代码这玩意儿，还有存在的必要吗？”
这个问题，很有意思。
或者说，这背后藏着更大的焦虑：当AI都能编程了，我们还需要低代码吗？当工具变得越来越智能，我们这些“用工具的人”，还有价值吗？
正好，最近我也在思考这个问题。今天，就和你聊聊我的看法。
一、一个正在发生的“阶跃”
在聊低代码之前，我们先来看看AI编程这件事。
就在前几天，AI公司Anthropic宣布了一个消息：他们的模型，现在可以高效地处理和优化一种名叫COBOL的古老编程语言。
COBOL是什么？是全球金融、银行系统的基石。维护和升级COBOL系统，是一个每年高达300亿美元的庞大市场。
Anthropic一宣布这个消息，这个领域的巨头IBM，股价应声暴跌，创下了20多年来的最大单日跌幅。
为什么？因为资本嗅到了一个信号：那些曾经需要成千上万程序员才能维护的“古董级”系统，可能很快就不需要那么多人了。
这不是孤例。
2025年底开始，AI在编程能力上，出现了一次“阶跃式的提升”。一个熟练的开发人员，借助AI，只需要几周时间，就能复制出一家中等规模SaaS公司的核心产品。
这意味着什么？
意味着，过去软件是“盖房子”，一砖一瓦，费时费力。未来，软件可能是“抽纸巾”，随用随取，用完即扔。
当软件的开发成本低到这种程度，整个软件行业的商业模式，都会开始动摇。
所以，回到开头那个问题：当AI都能写代码了，低代码还有存在的必要吗？
我的答案是：不仅有必要，而且比以往任何时候都更重要。
为什么？我给你讲个故事。
二、为什么“会写代码”不等于“会建系统”
去年，我去一家电子制造企业调研。
他们的IT负责人，是个很潮的年轻人，姓王。王总跟我说：“纪总，我们今年上了AI编程助手，效果确实好。原来要三天的活，现在一天就能干完。但我遇到了一个新问题。”
什么问题？
“我们团队现在能用AI生成一堆一堆的代码，速度飞快。但是，这些代码怎么和我们的ERP对接？怎么保证和MES系统的数据同步？权限怎么统一管理？一个代码片段跑得很快，但100个代码片段拼在一起，整个系统就卡死了。”
他说这话的时候，表情很复杂。就像一个人突然有了造砖头的超能力，能一天造一万块砖，但发现自己根本不知道该怎么盖房子。
这就是问题的关键。
AI编程解决的是“怎么写代码”的问题。而低代码解决的是“怎么建系统”的问题。
这是两个完全不同的维度。
“写代码”是造砖头。一块砖，精致、高效、符合标准，这很好。
但“建系统”是把砖头变成建筑。这需要蓝图，需要结构力学，需要水电管线的统一规划，需要知道哪里是承重墙，哪里是通风口。
回到企业里，建系统面临的挑战是什么？
第一，是“遗产”。
没有一家企业是从零开始的。你总有一堆老系统：ERP、OA、MES、WMS……有的是十年前用Java写的，有的是五年前外包做的，还有几个是Excel宏演变来的。AI生成的代码，怎么和这些“老古董”对话？
第二，是“治理”。
集团总部想统一管控数据标准，子公司想保留业务灵活性。既要保证中央集权，又要允许地方自治。这不是代码层面的问题，这是组织架构层面的问题。
第三，是“安全”。
特别是制造业、金融业，数据就是生命。能不能私有化部署？能不能通过等保2.0或3.0？能不能字段级的权限管控？AI生成的代码，放在公有云上跑，你敢吗？
这些问题，AI解决不了。AI不懂你的组织架构，不懂你的历史包袱，不懂你的合规要求。
那谁懂？或者说，什么东西能承载这些复杂的“企业级逻辑”？
低代码平台。准确地说，是企业级的低代码平台。
三、低代码的2026：不是被替代，而是被重新定义
很多人对低代码的理解，还停留在“快速做个审批流”或者“拖拽生成一个表单”。
那是2019年的低代码。
2026年的低代码，已经完全不一样了。它正在沿着三条路径进化：
进化路径一：
过去的低代码，核心是“可视化”。把按钮、输入框、表格这些积木块，用鼠标拖到一起。
现在，AI负责写代码，低代码负责干什么？负责指挥。
一个好的低代码平台，应该能把AI生成的代码片段，有机地组织起来。它就像一个乐队指挥家，知道什么时候让小提琴进，什么时候让铜管乐器起，什么时候整个乐队一起轰鸣。
更重要的是，它能把企业的业务流程、数据模型、权限体系，沉淀成一套“元数据”。AI可以在这套元数据的基础上，生成更符合企业实际情况的应用。
换句话说，低代码正在成为AI和企业之间的翻译官。
进化路径二：
这是2026年最显著的变化。
以前，低代码火在业务部门。市场部偷偷搭个小工具，效率翻倍。现在，大型集团开始入场了。
这就带来了一个巨大的挑战：多组织架构的适配。
比方说：
- 总部财务想看到所有子公司数据，但子公司总经理不想让总部看到自己的成本细节。
- 采购中心想统一供应商管理，但各地的工厂有各自的采购周期。
这已经不是技术问题了，这是政治学。
低代码平台必须进化出强大的“多租户”和“多组织”能力。就像一个国家的治理体系，既要保证中央的权威，又要发挥地方的积极性。
进化路径三：
“低门槛”不等于“无脑开发”。
当低代码开始承载核心交易系统、生产管理系统时，企业最怕什么？怕的是“做的时候很爽，维护的时候想撞墙”。
没有版本管理，没有多人协作，没有压力测试，没有断点调试——这不叫低代码，这叫“草台班子”。
2026年的低代码平台，必须经得起“工程级”的审视。它必须能让普通的业务人员，交付出来的系统，像高级架构师设计的一样稳定、可维护。
说到这里，我想起我们团队从前年开始就接触的一个低代码平台，叫织信Informat。它在“工程级交付”和“多组织治理”这两个维度上，做得很有意思。它不是那种“五分钟搭个表单”的轻量级工具，而是从一开始就奔着“替换企业核心系统”去的。你用它做的东西，是可以拿去跟CTO汇报、可以进机房的。
当然，这只是众多选择中的一个。但它代表了一个方向：低代码正在从玩具变成武器。
四、三把“降落伞”
回到最初那个焦虑：AI会替代我们吗？低代码会被淘汰吗？
我记得前段时间，研究机构Citrini Research发布了一份报告，叫《2028年全球智能危机》。它做了一个思想实验，站在2028年回望现在，推导出一个结论：2026年之后，会出现大规模的失业，AI会取代程序员、设计师、分析师……
报告出来之后，很多人恐慌了。
但我看完之后，跟团队说：逻辑起点是对的，但结论未必准确。
为什么？因为现实世界，有三把“降落伞”。
第一把，叫“市场调节”。
缝纫机淘汰了织布工，但创造了成衣厂和时装设计师。汽车淘汰了马车夫，但创造了司机和高速公路服务区。
AI会替代一些岗位，也会创造出新的岗位。比如，低代码平台出现之后，催生了一个新的职业叫“低代码架构师”——不是写代码的，而是设计业务逻辑的。
有岗位消失，是痛苦的。有岗位诞生，是确定的。你很难说，消失的速度，就一定碾压诞生的速度。
第二把，叫“社会惯性”。
真实的企业，是有粘滞性的。
一家公司，就算技术上可以裁掉一半的人，也不能明天就这么做。有法律的约束，有工会的博弈，有企业文化的惯性，有社会责任的考量。
变革，在真正的组织里，从来都不是瞬间的事。它更像沙漏，而不是决堤。
第三把，叫“政府干预”。
任何一个正常的政府，都不会眼睁睁看着大规模失业。
5%的失业率，就会有干预了。AI税、全民基本收入、缩短法定工作时间……工具箱里，有很多东西。
所以，基于“能力飞跃”和“应用普及”的起点，很多报告做了理论上成立的推演。但是，现实世界，有“速度”这个变量。
三把降落伞，会把“瞬间坠落”，变成“颠簸降落”。
这大概就是低代码的处境，也是我们每个人的处境。
五、写在最后
回到开头那个朋友的问题。
我给他的回答是这样的：“低代码不会因为AI的出现而消失，就像汽车的出现没有让道路消失。相反，汽车让道路变得更重要了。”
AI解决的是“生产力”的问题——怎么更快地生成代码。
低代码解决的是“生产关系”的问题——怎么让这些代码协同工作，怎么匹配组织架构，怎么符合合规要求。
生产力越强，生产关系就越重要。
你需要的，可能不是担心低代码会不会过时，而是思考：什么样的低代码平台，能帮你在AI时代，把“生产力”转化为真正的“竞争力”？
这个平台，要懂你的业务，要扛得住复杂场景，要能私有化部署，要有工程化的交付能力。不是让你更快地“搭积木”，而是让你能真正地“建大厦”。
最近，我自己也在试着用AI低代码做点什么。我看到有人给自己公司写了库存管理软件，有人给学生做了英语学习应用。
网友们的很多做法，给了我更多启发：
未来从来不是写好的剧本。风浪是肯定的，造船是必要的。
你不必成为AI专家，也不必成为程序员。但是，参与进去。理解它，使用它，思考它能为你做点什么。
用好奇，淘汰恐惧。
用尝试，开启探索。
用具体，对抗焦虑。
这，或许就是当下，最该做的事。
你说呢？
