前两天看到一篇文章，标题叫《无人再谈低代码》。
第一眼看到这标题，感觉作者设计的还挺巧妙，低代码热度虽然不高，但这篇文章热度很高，几万的阅读量。
我看到这个阅读量时，也被惊住了，低代码不是都已经凉了吗，为什么还有这么高的流量？
仔细思考一番，我决定认真阅读和理解这篇文章，顺便给大家解剖一下我的观点。
低代码（Low Code），这曾经不只是一个小众词。
它热过，吵过，也被很多厂商写进战略里。一个曾经被寄予厚望的IT技术方向，突然被人用“无人再谈”四个字盖住，多少有点刺眼。
刺眼的地方在于，它没有绕着“行业调整”，“技术演进”这些软词打转，而是把一个很多人隐约感受到、但没说出口的变化摆了出来：低代码好像没以前那么热了。
2020年前后，低代码是个很热的词。
各种技术峰会上讲，厂商讲，投资人讲，地方政策在讲，企业技术负责人也在讲。那时候低代码的故事，听起来很有想象力。
以后不用排IT排期了。
以后业务人员自己就能搭系统了。
以后写很少代码，甚至不写代码，就能把应用做出来。
当时很多企业听完，心里都会动一下。
因为太缺系统了。
销售想管客户，采购想管供应商，仓库想管库存，生产想管工单，财务想管付款节点。每个部门都有一堆Excel和微信群，每个需求都去找IT，IT排期永远不够。
低代码在那个时候出现，确实像一把钥匙。
可几年过去，很多人回头看，发现这把钥匙没能打开所有门。
表单能做，流程能配，图表报表也能出。可到了复杂权限、跨系统接口、历史数据迁移、审批例外、性能压力、版本管理、审计记录这些地方，事情又绕回了专业开发和系统治理。
然后AI来了。
这下就更尴尬了。
低代码以前说：少写代码。
AI说：代码我帮你写。
低代码以前说：业务人员也能做应用。
AI说：你把需求说出来，我先给你生成一版。
低代码以前说：快速交付。
AI说：页面、接口、脚本、小工具，我几分钟就能起个头。
你说怪不怪。
低代码吹了很多年的一些愿景，最后好像真被AI往前推了一大截。
所以，《无人再谈低代码》里面有些话，确实说中了。
但是，我不觉得结论可以停在“低代码凉了”。
更准确地说，凉掉的是低代码那套陈年老故事。
企业应用里的那些麻烦事，并没有因为AI会写代码就消失。
01、原文直接戳穿了低代码的“谎言”
那篇文章里有几个观点，我承认确实讲的对。
第一个观点：低代码和无代码不是一回事，但行业过去经常把它们混在一起卖。
这个判断很重要。
低代码，至少还承认复杂场景需要写一部分代码。
无代码听起来更激进，好像业务人员完全不需要开发能力，点点鼠标就能做系统。
这两个词放在一起讲，确实容易误导企业。
一个老板听到“无代码”，脑子里想的可能是：以后业务部门自己搞定，IT成本省了。
一个业务负责人听到“低代码”，脑子里想的可能是：我把流程画一下，加点表达式，系统自然就出来了。
但真正进项目现场，很快就会发现，系统不是这样长出来的。
一张采购申请单，看着只有供应商、物料、数量、金额、交期几个字段。
可它背后连着一串问题。
供应商是不是合格供应商？
物料编码是不是有效？
价格有没有超过协议价？
这笔采购属于哪个项目、哪个成本中心？
超过5万元走哪级审批？
到货以后怎么入库？
发票回来以后，怎么和采购单、入库单匹配？
退货以后，库存、应付、项目成本怎么一起调整？
你看，页面很简单，业务一点也不简单。
低代码过去最容易出问题的地方，就在这里。它把“快速做出一个应用”和“真正管住一套业务”说得太近了。
这笔账，迟早要还。
02、原文我认为对的观点：AI确实打到了低代码最脆弱的地方
原文里还有一个说法，大意是：低代码是在编程语言上面加一层图形化翻译层，拖组件，本质上还是在有限组件里排列组合。AI编程不一样，它把自然语言变成代码，表达空间更大。
这句话有道理。
以前做一个内部小工具，你要打开低代码平台，建数据表，拖组件，配按钮，写规则，再调页面。
现在你可以直接跟AI说：
帮我做一个客户跟进工具，有客户名称、联系人、跟进记录、下次拜访时间，还要能按销售人员筛选。
如果只是个人用，或者一个小团队先验证想法，AI很可能更快。
它不需要你先学平台组件。
不需要你理解画布上的各种配置项。
不需要你被固定组件限制住。
你说得越清楚，它生成得越接近。
这对传统低代码当然是冲击。
尤其是那些只靠表单、流程、CRUD吃饭的平台，会很难受。
因为用户心里会开始比较。
我为什么要在一个封闭画布里找组件？
我为什么要学你这套配置方式？
我为什么要被你的组件数量限制？
我直接让AI生成一版，不行吗？
这个问题很实际。
AI把“从0到1做出一个东西”的门槛往下压了。过去低代码厂商们卖的很大一部分价值，正是降低这个门槛。
门槛被AI重新压低，低代码的老卖点当然会缩水。
所以，低代码行业不能装作什么都没发生。
AI不是一个普通功能。
它会改变软件开发的入口。
过去入口是菜单、组件、画布、配置项。
以后入口很可能是一句话、一个文档、一张流程图、一段会议纪要。
用户不一定想拖控件。
用户更想说：这个审批节点加一个财务复核；这个字段改成必填；库存低于安全库存时提醒采购；这张报表按项目和部门分组。
如果平台还停留在“你来拖，我来配”，确实会显得旧。
03、但原文有个推论，我觉得走得太快了
原文还有一个很有杀伤力的观点：低代码有平台锁定，而VibeCoding生成的是标准代码。Python就是Python，React就是React，任何程序员都能接手。
这话听上去很爽。
也有一部分道理。
很多低代码平台确实存在平台锁定。业务逻辑放在私有DSL里，页面存在JSON配置里，运行时也依赖厂商。一旦用了几年，想迁出去，很麻烦。
有些企业最开始只是做一个报销流程，后来又加合同、采购、项目、库存。等业务越堆越多，才发现自己离不开平台。平台能力够还好，平台能力不够，就很难受。
这件事不能逃避。
低代码平台如果开放性差、扩展能力弱、代码能力弱、接口能力弱，未来一定会被AI和专业开发一起挤压。
但问题是，标准代码就一定自由吗？
未必。
AI生成的React、Python、Java代码，看起来都是标准代码。可如果没有架构约束、没有代码规范、没有测试、没有部署流程、没有权限模型、没有数据模型设计，半年以后也可能变成另一种锁定。
锁在谁手里？
锁在那个最初让AI生成代码的人脑子里。
锁在一堆没人写文档的业务判断里。
锁在一个个临时脚本和临时接口里。
锁在“现在能跑，但没人知道为什么能跑”的项目里。
这事在企业里并不陌生。
以前是Excel满天飞。
后来是小系统满天飞。
以后如果不管好，很可能变成AI生成的小应用满天飞。
表面上更自由，实际上更难治理。
所以，企业真正要防的，不只是某个平台的锁定。
还要防另一种更隐蔽的锁定：没有统一数据模型、没有统一权限、没有统一发布流程、没有统一负责人。
这种锁定，比平台锁定还难查。
因为它不一定写在合同里。
它藏在每个部门自己的工具里。
04、个人做工具和企业上系统，本质上差了十万八千里
很多关于AI替代低代码的讨论，容易把两个场景混在一起。
一个场景，是个人做工具。
另一个场景，是企业上系统。
这两个差得很远。
你给自己做一个小工具，代码能跑就行。报错了你自己改，数据错了你自己修，权限没管好也只是你自己承担后果。
企业里不是这样。
一个采购审批系统上线，采购要用，仓库要用，财务要用，老板也要看报表。
字段谁能改？
审批谁能撤回？
数据删了能不能恢复？
接口失败有没有提醒？
历史版本能不能查？
离职员工的权限谁回收？
集团能看全部数据，分公司只能看自己数据，这个范围怎么控制？
这些问题，AI可以帮你写一部分代码。
但AI不会天然替企业承担管理责任。
你让AI生成一个采购系统，它可以写页面、接口、数据库表。
可上线以后，谁来确认字段口径？
谁来处理权限变更？
谁来记录每一次审批动作？
谁来保证这个应用和ERP、财务系统、库存系统的数据一致？
谁来判断供应商名称变更以后，历史采购单、发票、付款记录要不要同步？
这些才是企业应用真正贵的地方。
第一版代码反而没那么贵。
贵的是后面每天都有人用，每次出问题都能查，每次业务变化都能改，每次组织调整都不会乱。
所以，AI能写代码，不代表企业可以不要平台。
代码生成只是把第一步变快。
企业系统真正难的，是把后面一百步也安排好。
05、低代码的陈年老故事结束后，新的定位在哪里？
低代码要继续存在，就不能再靠“拖拖拽拽，搭万能应用”这套话术。
它要换一个位置。
第一个位置，是企业应用的承载层。
什么意思？
企业每天有大量需求，ERP、MES、CRM、SRM这些主系统不一定都适合改。
比如临时项目台账、跨部门审批、供应商资料补充、售后问题跟踪、设备点检记录、费用预算调整。
这些需求不小，但又没大到必须重改ERP。
这时候，企业需要一个应用承载层，把表单、流程、权限、报表、接口、日志统一放起来。
像织信这类企业级低代码平台，如果只是讲“拖拽搭应用”，说服力会越来越弱。更有价值的说法，是它能把企业里的非标流程、权限边界、数据关联和系统接口放在同一个框架里管理。
第二个位置，是业务和IT之间的翻译层。
业务人员知道现场怎么做，但不一定能把需求讲成数据模型、流程规则和接口说明。
IT人员懂系统设计，但不一定知道每个业务的例外为什么存在。
过去双方开会，很容易吵成这样：
业务说：这个流程很简单，你们怎么做这么久？
IT说：你们需求天天变，昨天说按部门审批，今天又说按金额审批。
业务说：我们现场就是这样。
IT说：那你们到底按哪个规则？
低代码+AI以后，比较理想的状态，是让业务先把需求说出来，AI整理成字段、页面、流程、规则、异常分支，平台再把这些东西落到可配置、可审核、可修改的应用里。
这样，业务不用从零写代码，IT也不用从一堆口头描述里猜需求。
第三个位置，是AI生成结果的治理层。
AI会生成越来越多东西。
页面、流程、脚本、接口、报表、测试用例、说明文档。
问题是，这些东西不能生成完就扔给企业用。
谁审核？
谁发布？
谁回滚？
谁看日志？
谁确认没有越权访问？
谁确认这个字段不会把客户隐私暴露给不该看的人？
AI越强，这些问题越重要。
因为以前一个开发一周写一个功能，IT还有时间盯着。
以后AI一天生成十个功能，如果没有治理层，风险也会跟着放大。
06、为什么AI+低代码会成为当下的主流趋势？
因为它们刚好补上了彼此的短板。
第一，AI让需求入口变自然，低代码让需求落地有结构。
企业里很多需求，最开始都不是PRD。
它可能是一句抱怨：客户资料老是重复录。
它可能是一段会议纪要：采购超过5万元要加财务复核。
它可能是一张Excel：这张表以后要能多人填、自动汇总、按部门隔离。
AI擅长把这些自然语言、表格、文档，整理成初步的字段、页面、流程和规则。
但整理完以后，不能只停在文字里。
低代码平台可以把这些内容变成数据表、表单控件、审批节点、权限规则和报表视图。
一个负责理解。
一个负责承载。
第二，AI能提升开发速度，低代码能降低维护成本。
AI很适合生成初版。
但企业不只关心初版。
半年后字段要调整，流程要加节点，接口要改地址，权限要按组织调整，日志要给审计看。
如果每次都回到代码里改，业务和IT又会进入排期。
低代码平台把常见变更做成配置项，字段、流程、权限、页面、报表可以在平台里维护。AI再帮人解释变更影响、生成测试数据、检查规则冲突。
这样，快的不只是开发第一天。
后面的修改、维护和交接，也能变轻。
第三，AI需要企业上下文，低代码平台天然有业务模型。
AI如果不了解企业数据，只能给出“通常来说”的答案。
比如你问它：这个客户能不能赊账？
如果它不知道客户档案、合同记录、应收余额、信用额度、历史逾期情况，它只能讲原则。
但低代码平台里如果已经有客户表、合同表、回款表、审批流程和权限规则，AI就有机会围绕真实业务对象工作。
它可以知道哪个字段代表客户等级，哪张表记录回款，哪个流程决定信用额度调整，哪个角色有权限查看财务数据。
这就是企业AI和普通聊天AI的差别。
AI要进入企业工作流，就必须住进企业的数据和流程里。
第四，AI会带来更多小应用，低代码负责把它们管起来。
AI越好用，业务部门越容易产生新想法。
今天想做一个售后问题跟踪。
明天想做一个项目风险台账。
后天想做一个供应商准入评分。
这些东西都可以让AI快速生成。
但如果每个部门都自己生成、自己部署、自己维护，企业很快会出现新的混乱。
谁知道现在有多少个应用？
哪些应用在用客户数据？
哪些接口连着ERP？
哪些流程涉及付款？
哪些应用已经没人维护？
低代码平台的价值，是把这些应用纳入统一目录、统一权限、统一数据源、统一发布和统一运维。
AI负责让应用长得更快。
平台负责让应用不要野蛮生长。
第五，企业需要多种开发方式共存。
未来不会只有一种开发方式。
简单场景，业务人员可以用AI和低代码快速搭。
中等复杂场景，业务和IT一起配置表单、流程、权限、接口。
复杂场景，专业开发要写代码、做架构、处理性能和安全。
这就是零代码、低代码、高代码和AI协同。
织信这类平台如果能把AI对话式搭建、低代码配置和高代码扩展放在同一套工程体系里，就更符合中大型企业的真实需要。因为这类企业既要快，也要私有化、本地化、数据安全和复杂业务承载能力。
第六，AI应用更需要审计和责任。
以前系统是人点按钮。
以后可能是AI根据规则发起流程、调用接口、生成报表、提醒负责人。
这时候企业一定会问：
AI看了哪些数据？
它改了哪个字段？
它调用了哪个接口？
它有没有经过人工确认？
出错以后谁负责？
这些问题不能靠提示词解决。
必须靠权限、流程、日志、审批、版本和回滚机制解决。
低代码平台如果能把AI动作纳入同一套管理框架，企业才敢让AI进入核心业务。
这就是AI+低代码的趋势来源。
不是因为厂商想讲新故事。
而是企业真的需要一个地方，把AI生成能力和企业管理规则放在一起。
这也是我觉得织信这类平台仍然值得观察的原因。它如果只讲低代码，会显得不够新；如果只讲AI，又容易和普通AI编程工具混在一起。真正有价值的位置，是把AI对话式搭建、低代码模型、流程权限、接口集成和企业部署放在一起，让企业既能快一点做应用，也能清楚知道这些应用以后由谁改、谁审、谁负责。
07、最后的话
所以，再回到《无人再谈低代码》这篇文章的观点。我觉得它说中了一个时代的结束。
低代码不能再讲“人人都是开发者”的旧故事。
不能再把复杂企业系统说得像搭积木。
不能再回避平台锁定。
不能再拿几个漂亮Demo证明自己能承接长期业务。
这些批评，都应该听。
但它没有说完另一半。
企业对应用的需求没有消失。
企业对快速交付的需求没有消失。
企业对流程、权限、数据、接口、审计、私有化和长期维护的要求，也没有消失。
AI来了以后，这些要求反而更重了。
因为以前企业只是担心人乱建系统。
以后还要担心AI帮人更快地乱建系统。
低代码旧故事讲不下去了。
但新的故事，可能刚开始。
过去低代码的入口，是拖拽。
未来低代码的入口，可能是自然语言。
过去低代码的卖点，是少写代码。
未来低代码的价值，是把AI生成的页面、流程、接口、权限、数据和日志，放进企业可以长期使用的系统里。
过去低代码总想证明业务人员可以替代开发。
未来更健康的方向，是让业务、IT、开发、安全和AI一起工作。
这才是低代码真正该往前走的地方。
所以，不是无人再谈低代码。
是没人愿意再听低代码讲老故事了。
AI让软件更容易被生成。
企业级低代码平台要回答的，是另一个问题：
这些被生成出来的应用，能不能被企业放心地使用、持续地修改、清楚地追责、稳定地运行。
谁能回答这个问题，谁才有资格进入AI时代的企业软件牌桌。
参考资料：
1、Forrester低代码与无代码区别说明：https://www.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/
2、Gartner企业级低代码应用平台研究摘要：https://www.gartner.com/en/documents/6773234
3、Gartner关于AgenticAI影响企业应用软件支出：https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence
4、Oracle关于AI原生应用构建体验：https://www.oracle.com/news/announcement/oracle-introduces-ai-native-builder-experience-2026-07-14/
5、Mendix关于AgenticAI和低代码平台能力的说明：https://www.mendix.com/platform/ai/
6、OutSystems关于企业AI和治理平台的说明：https://www.outsystems.com/low-code-platform
7、TechCrunch关于YC创业公司AI生成代码比例：https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
