1. 低代码的江湖它凭什么让程序员吵到今天1.1 低代码其实不是新鲜事只是换了张皮1999年我入行时第一份工作是给一家老国企写管理软件用的工具是Visual Basic 6.0加PowerBuilder。那时候没有低代码这个概念但我们干的事跟今天低代码平台做的事几乎一模一样从左边工具栏拖一个按钮到窗体上双击事件连数据库拉一张数据窗口把表格和表单拼一拼一个员工信息维护页面半天就能出来。Delphi更夸张拖一个DataSource绑一个DBGrid配置好SQL整个界面就活了。这跟今天大家在低代码平台上拖组件、配数据源、设表单流程有什么本质区别几乎没有只是服务对象变了。那时候这些工具是给专业程序员用的因为还是得写不少脚本、调不少API、处理各种异常。今天的低代码平台野心更大它想让业务人员也能上手建一套系统。这个转变本身是好事但也正是争议的起点——当门槛降低到拖一拖就能出系统程序员这个群体开始本能地慌张于是神器和骗术两派就吵起来了。我见过太多技术风口来回横跳。从面向对象、SOA、敏捷开发到中台、低代码、AI编程每一个新概念出来都会被吹成银弹过两年又被人往死里踩。低代码只是最新一轮而已。认清这个规律你才能冷静看待它。1.2 低代码平台的三条路线别一概而论讨论低代码最忌讳的就是把所有低代码平台混为一谈。我的经验是把它们分成三条路线每条路线的能力边界和适用场景完全不一样。第一种是表单流程类平台代表有简道云、氚云、宜搭这类。核心思路是表单审批流报表适合做报销、请假、报修、合同审批、数据填报等轻量业务。这类平台胜在人人可用业务部门自己搭一套流程只要半天但它的边界非常明显做不了复杂的多表建模做不了复杂逻辑性能也很有限。第二种是模型驱动类平台代表是国外的OutSystems、Mendix以及国内不少厂商推出的低代码引擎。这类平台能配置数据模型、业务规则、角色权限、API集成甚至可以写少量脚本扩展。当年咱们用PowerBuilder做的表单一体化应用其实就是这类玩法的原始形态。它们才是真正意义上面向专业开发者的低代码也是最有争议的一类。第三种是代码生成类工具比如各种DSL生成器、代码脚手架。用模板和配置生成可运行的源代码生成完你可以随便改没有平台锁定问题。这类严格说不算低代码但在实际工程项目里往往比前两类更实用因为生成的代码是自己的。所以在骂低代码之前先搞清楚骂的是哪一类。用表单流程平台去做核心交易系统当然处处碰壁用模型驱动平台给业务部门搭个内部小工具那是真香。讨论低代码必须落到具体场景和个人能力上来这种地图炮式的开火解决不了任何问题。1.3 程序员为什么一聊低代码就上头程序员对低代码的愤怒表面上是技术洁癖核心是身份焦虑和长期形成的职业惯性。过去十年很多程序员的日常就是翻译产品经理把需求讲清楚程序员把需求翻译成CRUD写接口、做列表页、做表单页上线后再改需求再改代码。这种模式支撑了整个软件行业的繁荣也养出了一大批只负责照着需求写代码的从业者。低代码来了最擅长的那部分工作恰恰被自动化掉了。一个懂业务的运营在低代码平台上拖一拖就能做出一个带审批流程的管理页面这时候某些程序员的价值就被压缩了。于是有人说低代码是骗术因为它做得好的项目你根本接不住做得差的项目你也不屑于接。这背后真正的问题是很多从业者的核心竞争力本来就不该是把代码敲出来。我说句实在话低代码平台最让我这种人感到舒服的一点是它把那些大量重复的表单列表逻辑吃掉了我反而能抽出时间去钻研真正有价值的部分数据模型怎么设计、权限体系怎么规划、出了问题怎么排查。这套逻辑放到今天依然成立。2. 用二十年代码生涯拆掉低代码的滤镜2.1 低代码真正替企业解决了什么如果你问低代码到底有没有价值我的回答是有而且价值很大但不在那些吵得最凶的商业宣传里。第一个价值是消化长尾需求。企业里大量内部系统是没人愿意做的IT部门排期要到三个月后外包报价又不便宜业务部门等不起。这时候一个低代码平台能让他们自己解决问题。我见过一家制造企业供应链部门用低代码三天搭出一个设备点检记录系统放在以前走采购流程走三个月开发三个月上线后需求又变了。这种场景下低代码是真的减少浪费。第二个价值是消灭数据孤岛。很多企业上了ERP、MES、OA但系统之间没有打通数据散落在各个Excel里。低代码平台往往自带集成能力能通过API把各系统数据拉到一个表格里做一个给管理层看的数据看板。这个活儿如果全用代码写要对接各种接口协议、处理各种鉴权方式、还要写数据清洗逻辑工作量不小但用低代码平台的现成连接器半天能搞定。第三个价值是沟通可视化。程序员和业务之间最大的矛盾是需求理解不一致。以前只能写文档、画原型再花两轮评审确认。低代码平台能直接做出可点击的界面业务人员在上面点一点、试一遍马上能发现自己提的需求哪里不对。这个价值被很多人忽视但它实打实地降低了沟通成本。2.2 五个我踩过的坑每一个都是代码路上不会教的我这些年给企业做过不少低代码项目的评审和救火也亲手踩过不少坑整理出几个反复出现的问题。第一个是平台锁定。这是最要命的。数据模型、业务逻辑、页面全部配置在平台上看着很美好等到你要把数据迁移出去或者项目规模变大要换技术栈时才发现导出的数据是一堆JSON业务逻辑散落在各种配置表里根本没法还原成代码系统。我的建议是用低代码平台之前先确认数据的导出能力以及有没有开放的API可以批量操作数据。第二个是定制天花板。低代码平台再牛总有你做不到的需求一个特殊的字段校验、一个跨系统的事务一致性要求、一个定制化的打印排版。真到那时候你会发现平台提供的能力就像一个笼子你只能笼子里转要么写插件、要么开后门、要么换平台哪个都是伤筋动骨。第三个是性能黑盒。低代码平台帮你管理了数据库访问但也藏起了SQL。很多平台生成的是动态查询用户一多、条件一复杂查询效率立刻恶化。我们遇到过给一个不到两百人的企业做报修系统上线两周后页面越开越慢最后查下来是平台默认的关联查询把所有历史工单都加载了一遍。第四个是调试困难。传统开发有断点调试、有日志跟踪低代码平台里逻辑是可视化的出了问题你往往只能看着报错信息瞎猜。尤其当你写了脚本、调用了外部API出错时的排查体验比纯代码项目难受十倍。第五个是安全和权限容易被忽视。拖拽界面太容易了反而让人忘记设计权限模型。有人建了一大堆角色但没想清楚角色之间的数据范围结果基层员工能看到全公司的薪酬数据。这种事在低代码项目里我见过不止一次。2.3 为什么低代码取代程序员是伪命题先说结论低代码确实会取代一批程序员但不是全部甚至不是多数。它取代的是只会做表单纯页面、只会照着需求写CRUD的人。这类人在市场上确实不少他们的价值本来就低被工具取代只是时间问题。但真正有技术含量的工作低代码根本不碰。业务建模、性能优化、分布式架构、数据一致性、容灾备份、安全合规这些事情低代码平台管不了也不打算管。低代码负责的是把已经想清楚的逻辑更快地变成界面和流程而想清楚逻辑这件事从来都是人来做。用个不恰当但贴切的比喻低代码是预制菜确实能让你快速做出一桌看着还行的菜但餐厅真正赚钱的招牌菜还是得靠厨师的功夫。预制菜普及不会消灭厨师只会消灭那些只会照菜谱炒大锅饭的帮厨。这话听着扎心但确实是行业正在发生的真实变化。3. 真实案例复盘我用低代码平台做了一个报修系统3.1 选型阶段的决策依据讲一个我前年深度参与的项目某中型制造企业想上一套售后报修管理系统负责对接的人既有车间报修流程又涉及设备台账、客户合同、维修记录、配件库存还要求跟老ERP系统做数据同步。企业内部只有一个三个人的IT小组没有专职开发外包报价又不低。最后决定评估低代码方案。我陪着做选型时一共对比了三个平台。我的评估维度不是看官网宣传而是拿一个实际的业务场景去压测约定了最典型的需求——工单创建时自动带出设备信息维修完成后回写ERP库存经理审批后短信通知客户给每家平台两周时间做demo。实测下来有的平台光是把设备台账和工单做关联就折腾了很久有的平台对API调用的支持弱到需要写大量脚本绕过最终只留下一家勉强达标。选型的心得是别被演示DEMO骗了。厂商演示时做的是精心设计的流程你把真实业务交给他跑一遍什么问题都暴露了。另外一定要看平台有没有免费的试用环境那种不让试用、只给看录屏的平台多少都有问题。3.2 数据模型设计配置平台更考验先想清楚做低代码项目最容易被轻视的环节就是数据模型设计因为拖字段太容易了反而没人愿意先静下来画关系图。这个项目里有几个实体设备、客户、合同、维修工单、维修记录、配件消耗它们之间有多对多关系。比如一个设备可以关联多个客户一个合同下面有多台设备一个工单可以消耗多个配件一个配件也可能用在多个工单上。我先在纸上画出ER图确认清楚主外键关联然后才在低代码平台上建模。在这里我特别想强调一点很多低代码平台在建表阶段改字段很容易但一旦录入了真实数据再改关系那叫一个痛苦。状态流转也一样工单从待派单到维修中再到待验收是个有分支的状态机我在平台上把所有流转条件先画出来才敢配置流程。这个项目里有个细节我印象很深配件库存存在ERP里低代码平台的数据表里需要存配件快照而不是实时去ERP查。因为报修工单创建后配件价格和规格可能会变如果只用关联查询历史工单显示的数据会和当时的实际情况对不上。这种设计思路就是做传统系统时积累的快照概念放在低代码平台上一样适用。3.3 与外部API对接低代码平台逃不掉的集成课题网上关于低代码的讨论很少深入讲API对接但这恰恰是实际项目中绕不开的坎。这个报修系统需要做到两件事一是从ERP同步客户和物料信息二是维修完工后把消耗的配件数据回传给ERP扣库存。低代码平台虽然有现成的HTTP请求组件但真实接口远远比文档例子复杂ERP接口是SOAP格式token的过期时间是两小时夜间有批量对账任务会锁表导致接口超时偶尔还会返回一些不规范的状态码。为了处理这些情况我在平台上搭了一张数据同步中间表先把ERP的数据拉到本地表再由平台内部的定时任务做增量同步。报错时只记录状态码和错误信息到日志表由定时任务自动重试。这个中间表重试模式其实就是传统开发里的消息队列和异步处理的最低配版本在低代码平台上一样能用。别指望低代码平台的一个接口组件能解决所有集成问题。真实世界里的系统对接总有各种超时、重试、幂等、脏数据、字段兼容的事情要处理平台组件只是帮你省了写HTTP封装的时间业务层面的设计一点也省不了。3.4 上线之后的性能与运维这个项目上线后最大的麻烦不是功能而是性能。最开始用户只有车间和客服部门的三十多个人数据量也不大一切正常。三个月后历史工单积累到两万多条列表页开始明显卡顿特别是按客户名称模糊搜索时经常要转圈十秒钟。排查下来发现低代码平台的默认查询是把工单对应的设备、客户、维修记录全部级联加载哪怕列表页只需要显示五个字段。解决方案是在平台里建了一张工单宽表把经常需要查询的字段冗余进去列表页直接查宽表详情页再去查关联表。上线后列表秒开。这件事给我的教训是低代码平台隐藏了SQL细节你省掉了写SQL的功夫就必须拿出额外的警觉去观察数据量增长和查询效率。平台上如果提供日志分析或慢查询能力记得一上线就打开。运维上还有一个容易被忽略的点备份恢复测试。低代码平台的数据存在云端很多企业以为平台方会妥善备份。实际上不少平台只保留短期备份或者恢复流程很麻烦。我推动这家企业每周导出一份完整数据到本地但这还不够还必须每季度做一次从导出数据恢复到新环境的演练否则真到出事那天备份数据可能根本恢复不了。4. 什么样的项目才配得上低代码我的规避清单4.1 适合低代码的项目长什么样基于这么多年折腾下来我对低代码的适用场景有一个相对清晰的判断符合下面几条的项目可以认真考虑低代码方案。第一企业内部管理系统用户数在几百人以内业务逻辑以增删改查审批流为主。这类系统的核心是效率和响应速度而不是高并发和高复杂度。第二生命周期短的工具型应用比如展会数据收集、活动报名、临时报表用完即弃不值得用代码重写。第三原型和PoC验证先用低代码快速把需求可视化让业务方确认后再决定是否投入资源做正式系统。我见过最成功的低代码项目是那种业务部门自己就能当管理员的系统。他们用低代码建模后自己维护数据字典里常见字段慢慢能改审批流、加报表IT部门几乎不需要介入。这种状态才是低代码最好的状态系统是活的业务是主导者代码工作量最小化系统生命周期也不长换代成本可控。4.2 哪些项目碰都别碰我的鬼故事清单比什么时候适合用低代码更重要的是什么时候绝对不能用。我列几个踩过或见过的鬼故事。第一核心交易链路。凡涉及资金、库存、订单核心流转的系统别用低代码。这类系统的正确性要求极高需要严格的事务控制、审计追踪和灾难恢复低代码平台很难满足。第二高并发场景。低代码平台的性能天花板摆在那里不管是数据库查询方式还是部署架构都不是为千万级请求设计的。第三复杂业务规则系统。比如金融头寸计算、动态定价、供应链优化这些牵涉大量算法和状态机可视化配置根本表达不了强上低代码就是自掘坟墓。第四类更隐蔽长期演进、生命周期超过五年的核心业务系统。就算今天低代码能满足需求你能保证平台五年后还在吗能保证平台的版本升级不破坏你现有的配置吗这种长期性风险在技术选型时容易被忽略但它比什么都致命。核心系统一旦被锁定等于把自己的命脉交到别人手里。我对所有来找我咨询的企业都说一句话低代码可以做边缘系统可以做辅助系统可以做快速验证但别拿它赌上自己的核心业务。这是底线。4.3 判断清单三类人五道题我整理了一套自用的低代码测评方法不给厂商打分只给自己打分。每一次考虑用低代码之前先回答五道题。一、数据复杂度你的数据模型有多少张表表之间有几层关联如果超过十张核心表并且有复杂的多对多关系低代码平台会让你非常痛苦。二、业务逻辑复杂度除了状态流转权限判断之外有没有涉及算法、外部规则引擎、复杂计算有的话慎用。三、并发与性能要求峰值在线用户会超过几百吗单表数据量会迅速过百万吗会涉及跨表的复杂统计报表吗只要有一条yes低代码就得靠边站。四、定制化深度你要做的是标准界面和标准流程还是要深度定制UI、特殊交互、复杂打印模板定制越深低代码价值越低。五、数据出口与可持续性平台支持批量导出原始数据吗有开放的API吗如果你今天做的系统明天决定不用这个平台了数据能搬走吗逻辑能带走吗答不上来就别用。配合这三类人看老板问成本和交付时间业务人员问使用门槛和响应速度程序员问定制边界和逃生通道。三个视角都通过了这个项目才真正适合上低代码。5. 低代码之后AI程序员来了真正的危机是什么5.1 AI编程和低代码的底层逻辑完全不同最近大家都在讨论AI程序员说AI要取代初级程序员。我观察到的现象是AI编程和低代码虽然都在改变软件行业但底层逻辑完全不一样。低代码的逻辑是可视化配置减少写代码它把代码藏起来让业务人员也能建系统。AI编程的逻辑是用自然语言生成代码它可以写接近人类水平的代码但依然需要人来确认需求、运行、测试、改bug。一个在降低编码门槛一个在降低生成代码的门槛两条路线交汇在一起共同把照着需求写代码这个动作变得极度廉价。但注意这两样东西都有一个共同的特征它们只是生产代码的机器不是决定要生产什么的决策者。系统为什么这么设计数据怎么建模哪些边缘情况需要处理上线后怎么运维这些价值依然完全握在懂业务的工程师手里。5.2 老码农的新技能树比会不会写代码更重要的是什么我自己是代码老手但我现在的日常工作早就不以写代码为主了。真正花时间的是和业务确认他们的真实诉求、梳理数据关系、设计权限体系、判断哪些需求可以在低代码平台上做、哪些必须用代码硬写、哪些可以借助AI生成一段代码再结合平台扩展。有意思的是这些能力在低代码项目里被放大了。因为平台把代码工作量压缩之后留给人的思考时间更多了。以前你写完一段CRUD代码顺手就完成了现在你画一个数据表、配置一个流程背后逻辑对不对全靠你的业务理解和系统设计功力。去学习SQL因为你要查数据验证逻辑去学习业务建模因为你要设计数据关系去学习接口集成和异步处理因为系统不会单独存在去学习运维和监控因为页面出了性能问题你得知道去哪看日志。这些技能树的每一个分支都不是低代码平台能替代的。5.3 给年轻程序员的真心话别慌但抓紧换姿势很多初级程序员焦虑说自己培训出身就靠那点代码手艺吃饭低代码和AI一来饭碗就没了。我不灌鸡汤直说如果你的价值确实只是照需求写CRUD那饭碗确实危险。这不是低代码的错也不是AI的错是本来这个价值就太低。但换个角度看低代码和AI反而给了初级程序员一条突围的路。以前你只能被安排做最基础的列表页和表单页因为项目里没人愿意让你碰核心模块。现在你可以借助低代码平台快速搭建一整套完整的业务系统从数据建模到权限设计到流程配置全程跟下来这种全流程经验在传统开发模式里你可能要熬好几年才攒得下来。我建议年轻的朋友们在做项目的过程中刻意去接触那些平台解决不了的部分数据异常处理、接口对接的坑、权限漏洞、备份与恢复、性能优化。这些越难啃的骨头越是未来值钱的本事。总是挑最简单的活干工具进步的第一个受害者就是你。别再把刷面试题、背八股文当成核心竞争力了。那些东西AI记得比你全低代码平台用得不比你差。真正的核心竞争力是面对一个模糊的需求你能比工具更早看清楚它该怎么落地方案。写在最后我的一点个人体会做了二十多年程序员我最大的感受是技术圈特别容易把一个工具神话化再把它妖魔化。低代码刚火的时候有人喊出程序员要失业过两年又有人说低代码就是智商税。其实这两句话都片面。低代码就是一个工具工具的价值取决于拿它的人、干的活、放的场景。我现在对低代码的态度很明确该用它的时候痛快地用用之前先想清楚退路。数据能导出的平台才放心用逻辑能离开平台才敢用和外部系统的边界一定要用代码封装好。这样做出来的低代码项目既快又稳将来就算换平台损失也可控。低代码最需要的不是热血是冷静。冷静下来看看自己手上的问题该用代码用代码该用低代码用低代码该让AI写就让AI写。工具是给人用的别反过来被工具牵着走。