今天看到一个有意思的话题——低代码是效率革命，还是程序员鄙视链的底端？
看到这个问题的第一眼，我就代入了。作为一位从业过3年的前程序员，现在身份是8年的项目经理（目前在带团队做IT信息化系统交付）。我回想起之前做程序员的那段时光，特别有意思。
在程序员圈子里呢，有个永恒的鄙视链。它就是：
- 写汇编的永远看不起写C的
- 写C的永远看不起写Java的
- 写Java又永远看不起写Python的
那写低代码的呢？
不好意思，那是鄙视链的最底端。
用他们的话说：拖拖拽拽就能开发系统？那还要程序员干什么？
可另一边，企业的CIO们却在疯狂采购低代码平台。据IDC数据，2024年中国低代码市场规模已达40.3亿元，同比增长21.6%。Gartner预测，到2026年，70%的新应用将通过低代码/无代码技术构建。
这就有意思了。
一边是程序员的集体嘲讽，一边是市场的火热追捧。低代码究竟是效率革命，还是程序员说的那样不堪？
今天我们来好好聊聊。
一、低代码为什么突然火了？
说低代码是新技术，那是你不了解历史。
早在2014年，Forrester就提出了低代码概念。但那时候的低代码，基本就是Access数据库的翻版，画几个表单、搭几个流程，土得掉渣。
真正让低代码站上风口，是三股力量的合流。
第一股力量是数字化转型的压力。
企业想要数字化，但程序员的供给跟不上。据工信部数据，中国每年新增软件开发人才缺口超过百万。培养一个合格的Java工程师，至少需要三年。企业等不起。
低代码平台通过可视化组件和模块复用，把开发门槛大幅降低。IDC的数据显示，使用低代码平台后，开发周期平均缩短67%，人力成本平均降低52%。
这是什么概念？
原来三个月能上线的项目，现在一个月就能跑起来。原来需要五个开发，现在两个人就够了。
第二股力量是SaaS生态的成熟。
企业的业务系统越来越多，但系统之间的数据却像一座座孤岛。低代码平台天然具备集成能力，可以快速打通ERP、CRM、OA等各种系统。
第三股力量是AI的加持。
2023年开始，大模型技术爆发式发展。低代码平台开始深度融合AI能力，实现了“自然语言生成应用”“智能流程优化”等功能。
Gartner数据显示，61%的企业已将AI开发能力列为低代码选型的首要指标。
现在的低代码，早已不是当年那个土气的表单工具了。
二、低代码到底省不省钱？
这是每个企业在采购前都会问的问题。
我们来算一笔账。
传统软件开发有两条路：外包和自建。
外包的好处是不用养团队，省人力成本。但问题也明显：核心技术在外包手里，企业容易被卡脖子；沟通成本高，需求传递容易失真；出了问题响应慢，业务部门干着急。
自建团队呢？好处是技术自主可控，响应快。但问题是人力成本高，一个初级Java工程师年薪也要十几万，更别说架构师了。养一个五人团队，一年光人力成本就上百万。
低代码的出现，似乎在两者之间找到了平衡点。
IDC数据显示，低代码项目的人力投入仅为传统开发的30%-50%。一个原本需要六个月的项目，用低代码可能两个月就完成了。
但问题来了：这是有前提的。
前提就是你的业务场景不能太复杂。
一定场景下，低代码确实能省钱。像常规的一些表单、审批、报表、流程，或者是ERP、MES、PLM、WMS这类系统模块，这些用拖拽+少量代码就能搞定。而且现在很多低代码都接入了AI大模型，几句话需求描述就能让一个不懂代码的业务人员快速上手配置。
但是，凡事都有一个“但是”。
一旦涉及比较复杂的逻辑呢？
比如你要对接ERP系统，要实现自定义的财务核算规则，要处理高并发的订单业务……这时候，低代码的组件化搭建优势就没有了，你只能是再配合上传统编码开发的模式。才能完成这项任务。
不过这一块相比之下，前面省去的数据表、流程、图表的搭建时间，在时间和人效上，还是可以节省不少。
但有一点需要提醒的是，像一些公司领导曾，他是不太懂技术的，就很容易被一些软件厂商的宣传话术忽悠，说我们也是低代码，我们也可以做ERP，也可以做MES，对于这个我的建议是：先验证，再决定要不要买。很多时候低代码不是万能的，在一些场景下不一定就能省多少钱。所以凡是先验证可行性是最好的方式。
所以，总结下来，低代码到底省不省钱呢？
我的答案是：看场景。
一定情况的定制场景（业务场景的功能），低代码是能大幅提效的。但一旦涉及到高交互，高并发的场景，它的优势就没了。这一点你是要先知道的。
三、再来聊另外一个值得分析的点：无代码
说到低代码，就不得不提“无代码”。这个词在营销文案里特别常见——
- “无需任何代码基础，几个小时开发一套系统”，
- “业务人员自己就能搞定IT需求”。
听起来很美好。
但现实很骨感。
我一个朋友在制造业企业做信息化负责人。前两年被某无代码厂商的销售一顿忽悠，采购了一套“无代码平台”，号称不用招开发，自己人就能搞定。
结果呢？
他派了两个文员去学，学了半个月，连基本的表单逻辑关系都没搞定，搭出来的表单狗屁不通。更别说后续还要对接生产设备的数据采集、实现质量追溯系统的需求了。
最后老板忍痛又找了一名IT，不得不说，IT在做系统这块仍然是具备天然优势的，两周时间，一套系统功能，30多张表（各表之间的逻辑关联），8个工作流审批，10来张图表都搞定了。但是最后卡在了做设备对接这一步上。原因是无代码因为本身平台的限制，太多的定制能力，平台无法支持。
最后因为这个问题，项目实在推进不下去，我那朋友去找这家无代码厂商售后解决问题，人家迟迟没有回应。几万块的采购费，外加人力投入的几万块都打了水漂。
为什么会这样？
首先低一点，任何系统的设计都是有技术壁垒的。低代码平台的可视化组件虽说降低了使用门槛，但组件背后的逻辑，如数据关联、流程触发、权限控制，依然需要技术理解。
业务部门先天缺乏技术基因。他们习惯了“等靠要”：等信息部门建设，靠信息部门维护，要信息部门服务。你让他们自己搞系统？大概率是一学就会、一做就废。
更重要的是，企业核心业务系统的需求往往是复杂的、多变的。一个简单的审批流，用无代码没问题。但如果是涉及复杂计算逻辑的财务系统呢？如果是需要对接多个老旧系统的集成项目呢？无代码由于本身的限制（超出平台能力部分，需要另外定制这一块的能力比较弱），导致系统只能是个表单工具，无法拥有太多复杂的功能。
因此，无代码在我看来，很多时候只是营销口号，它并不是万能的，它有明确的能力边界。
记住这句话：无代码是给业务人员用的，用来快速实现简单需求。低代码是给技术人员用的，用来高效实现复杂需求。因此如果企业想要实现更加复杂的业务逻辑需求，有多套系统集成的需求，建议还是找企业级低代码开发平台。目前在国内，这一类平台的典型代表有：织信Informat，ClickPaaS。织信目前主要是基于模型驱动开发理念，采用Java+Vue技术架构，支持私有化部署与多端兼容（电脑/手机/钉钉/企业微信等），其独创的“数据+流程+组件”三驱开发模式，支持企业无代码/低代码/全代码灵活组合，复杂需求用它不在话下。
很多时候，脱离技术人员的低代码，根本走不远。
四、对于“低代码”，程序员的焦虑真没有必要存在
说完企业视角，我们来看看程序员的视角。
在程序员社区，低代码几乎是“过街老鼠”般的存在。
- “低代码是程序员的棺材板”，
- “用低代码的都是不懂技术的领导”，
- “低代码开发出来的东西，根本不叫软件”。
为什么程序员这么讨厌低代码？
第一层是技术控制权的焦虑。
传统开发中，代码是程序员的手术刀。每一个变量命名、每一段逻辑分支，都在掌控之中。出了问题，看日志、追调用栈，精准定位。但低代码把底层逻辑封装成了可视化组件。用户看到的是拖拽，看不到的是背后的SQL、接口调用、数据流向。这种“黑箱感”让程序员极度不适。
第二层是定制化能力的焦虑。
低代码平台依赖标准化模块。80%的通用场景没问题，但剩下的20%核心需求（在少部分场景下），往往需要多出一份精力去“打补丁”。
但程序员真的会被取代吗？
我的观点是：不会取代，但会筛选。
低代码消灭的是重复性编码工作，比如表单生成、简单CRUD、基础页面开发。这些工作繁琐、重复，没有技术含量，却占用了程序员60%以上的时间。
而真正需要程序员的地方，架构设计、性能优化、安全防护、复杂算法。低代码根本替代不了。更何况现在AI都能自动写代码了。这种筛选就会更加明显了。
换句话说，AI和低代码这类工具，淘汰的不是程序员，而是“只会搬砖”的程序员。
那些担心失业的开发者，本质上是自己核心竞争力不够。与其抱怨低代码抢了饭碗，不如思考如何提升自己的不可替代性。
五、企业选低代码的五看原则
说了这么多，企业到底该怎么选低代码？
结合行业经验和数据支撑，我总结了五看原则。
一看阶段。
看企业处于数字化转型的哪个阶段。
数字化初期，系统集成需求多且杂，业务需求多IT响应慢，IT效率低导致业务创新也低，那么用低代码快速验证业务场景是对的。
二看场景。
低代码不是万能的，它有自己的能力边界。
简单场景——表单录入、审批流转、数据统计——用无代码效率高。
复杂场景——涉及复杂逻辑、大数据了处理、系统集成——用企业级低代码可能会更好。
选型之前，先问自己：这个需求，最复杂的那部分是什么？无代码/低代码平台能支持吗？不确定的一律先去验证，得到结果你才能做出决定。
三看能力。
企业自身的技术能力，决定了低代码能不能用好。
有技术团队的企业，低代码可以成为效率工具。没有技术团队的企业，低代码可能变成负担——买了没人会用，或者用了维护不了。
能力强用得好是神器，能力弱用不好是灾难。
四看协同。
低代码成功的关键，是技术与业务的协同。
技术部门负责平台配置和复杂开发，业务部门负责需求确认和基础操作。两者配合，而不是相互排斥。
同时也要注意原生开发团队与低代码工具的协同。低代码不是要替代传统开发，而是与传统开发互补。
五看边界。
只有看清楚低代码的技术边界，才能建立正确的预期。
边界内的需求，低代码可以高效满足。边界外的需求，要承认低代码的局限，寻求其他方案。
既不神化低代码，也不妖魔化低代码。把它当成一个工具，用其长、避其短。
六、低代码的两个核心趋势与变化
说了现状，再来看看未来。
低代码行业正在经历两个重要变化。
第一个变化是AI原生。
Gartner预测，到2026年，80%的技术产品将由非专业开发者构建。这个预测的背后，是AI对低代码的深度赋能。
当前主流低代码平台都在集成AI大模型能力，实现了“自然语言生成应用”，“智能流程优化”，“代码片段自动生成”等功能。
开发效率提升300%-500%，是可以的。
非技术人员能完成的开发工作，从20%提升到80%。这意味着，更多的人可以参与到数字化建设中来。
第二个变化是信创适配。
在国产化替代政策推动下，国企、金融、政务等关键行业对低代码平台提出了新的要求：全栈适配国产芯片、操作系统、数据库。
IDC数据显示，2025年政企客户复杂核心系统开发需求占比超过65%。能否适配国产化生态，直接决定了低代码平台在关键行业的竞争力。
全栈信创适配的AI低代码平台，市场占有率正在快速提升。
七、个人总结：低代码不是终点，是起点
回到开头的问题：低代码究竟是效率革命，还是程序员鄙视链的底端？
我的答案是：都不是。
低代码既没有那么神，也不是那么烂。
它是一个工具，一个在特定场景下能大幅提升效率的工具。
它的价值不在于替代程序员，而在于让程序员从重复劳动中解放出来，去做更有价值的事情。
它的局限不在于技术落后，而在于任何工具都有其能力边界，认清边界才能用好它。
对于企业而言，低代码不是数字化转型的终点，而是起点。
用好低代码，企业可以快速验证业务场景、积累数字化能力、培养数字化思维。
但当业务复杂度提升，企业终究需要更强的技术力量、更完善的系统架构。
低代码帮企业迈出第一步，但第二步、第三步，还要靠人。
所以，与其争论低代码好不好，不如思考怎么用好它。
毕竟，工具是死的，人是活的。
世界上没有完美的技术，只有最适合的方案。
低代码不是万能百宝箱，但用它来解决它能解决的问题，那就是效率革命。
用它来解决它解决不了的问题，那就是自找麻烦。
区别在哪里？在于用的人。
