低代码会干掉程序员吗？不，会编程的人将变得更加珍贵

一、低代码恐慌：一场由体验驱动的时代焦虑#

过去两年，我以技术顾问的身份服务过二十多家正在进行数字化转型的企业。几乎每一次与CTO或技术总监的初次交谈，都会绕不开同一个话题：“低代码会不会把我们团队的程序员给’优化’掉？”

这个问题的背后，是一种真实且普遍的情绪——焦虑。它不是来自某个具体的裁员新闻，而是来自体验。当你亲眼看到业务同事在低代码平台上拖拽几下就搭出一个审批应用，当你看到一名产品经理用半天时间做出一个可以演示的CRM原型，而你手下的开发排期已经排到了下个月，那种冲击感是实实在在的。

我记得2023年底，一位物流企业的技术VP老周跟我吃饭，讲了一件让他失眠的事。他们公司引进了一套低代码平台做内部工具试点，IT部门还没来得及出规范，运营团队自己就搭建了7个流程应用，包括快递异常上报、客户回访登记、运力调度看板。老周说：“我第一反应不是开心，是害怕。我怕老板觉得IT部门没用了。”

这种恐惧可以被理解，但它经得起推敲吗？答案是否定的。低代码不是来”干掉”程序员的，它更像一面镜子，照出了过去很多”伪编程工作”的冗余——那些重复的增删改查页面、那些永远在变的报表、那些换汤不换药的审批流。这些工作占用了程序员大量精力，却不产生真正的技术壁垒。当低代码把这些杂活接走之后，程序员的价值不是消失了，而是被重新聚焦到更复杂的系统设计、数据治理、性能优化和业务架构上。

换句话说，低代码让编程能力从”写代码”进化为”设计解决方案”。这正是行业洗牌的开始，也是真正稀缺人才的黄金时代。

二、拆解低代码：它到底是什么，不是什么#

很多企业对低代码的理解停留在”面向业务人员的可视化搭建工具”。这个认知不能说错，但严重局限了它的定位。

从技术本质上讲，低代码是一套模型驱动的开发范式。它把应用开发过程中大量可复用的部分——数据模型定义、页面渲染、接口调用、权限管理、流程编排——抽象成了可视化的配置界面。开发者不需要从零手写每一个类、每一行SQL、每一个按钮的点击事件，而是通过配置告诉平台”我要什么”，平台负责生成”怎么写”。

但低代码不是无代码。无代码（No-Code）面向零基础的业务人员，解决的是”表单+流程+看板”这类标准化需求；低代码（Low-Code）则面向专业开发者，它的边界远宽得多。专业低代码平台通常提供完整的编程扩展能力：自定义组件、事件脚本、外部API接入、数据源适配，甚至可以嵌入已有的微服务体系。

举一个我亲测过的场景。2024年夏天，我为一家零售连锁企业做低代码选型评估。当时测试团队在三家主流平台上分别搭建同一个库存盘点模块。其中一个平台纯靠拖拽就完成了80%的功能，但到了”批次过期自动预警+多仓调拨建议”这个环节，配置化方案卡住了——规则太复杂，状态机嵌套了四层。此时，平台的脚本扩展口派上了用场，我用大约200行JavaScript实现了这段逻辑，二十分钟搞定。

这件事给我最大的感触是：低代码不会取代程序员，但它会”重排”编程能力的变现方式。过去写200行代码解决的问题，现在可能只需要写20行，加上80%的配置。工作量看似减少了，但对设计能力的要求反而更高——因为你必须清楚哪些部分适合配置化，哪些部分必须硬编码，还要理解平台底层的运行机制，否则一旦复杂逻辑出现性能瓶颈，连排查都无从下手。

所以，关于低代码，更准确的定义是：一套让”编程能力”聚焦于复杂问题的开发范式。它不是程序员的终结者，而是平庸代码的终结者。

三、真实体验：低代码如何改造一条业务链路#

光讲概念容易飘，我来讲一个具体的业务链路改造故事，主角是华东一家中型SaaS公司的数据服务团队。团队负责人叫李然，手下有8名开发、2名测试。他们的典型痛点是：客户定制化报表需求太多。每个季度，客户成功部门攒下的报表开发需求超过60个，每个报表的平均开发周期是3天，而且逻辑并不复杂——无非是把已有数据源排列组合，加上几个筛选条件，再做视觉美化。

李然跟我抱怨：“我的开发人员一半以上的时间都在写SQL和调样式，真正的核心项目反而没人手做。”

2024年3月，他们引入了一款企业级低代码平台，专门用于处理报表和内部运营应用。我全程参与了前两周的落地过程，观察到的变化很清晰：

改造前：

• 一个新报表需求从排期到上线，平均耗时 3天
• 开发人员每天约 60% 的工作时间消耗在SQL编写和图表样式调整上
• 客户提出修改指标口径，平均需要 6小时 才能完成全链路修改（改SQL→改页面→联调→发布）

改造后：

• 同一类报表需求，通过低代码配置+少量脚本扩展，平均耗时 4小时，效率提升约 85%
• 开发人员投入核心业务逻辑开发的时间占比，从40%提升至 78%
• 客户修改指标口径，通过配置中心直接调整，92.3% 的需求在 1小时内 完成交付

这个过程中最让我印象深刻的，不是效率数据，而是一个细节场景：

周五下午四点，客户成功经理张婷接到一家重要客户的电话——对方希望在下周一的项目汇报中，把报表里的”活跃用户数”统计口径从”按月去重”改为”按日去重再按月平均”。以前遇到这种需求，张婷的第一反应是”不可能，开发来不及”，毕竟这涉及底层SQL重写和前端图表联动。但这次，她直接打开低代码平台的配置面板，在数据模型里找到”活跃用户数”指标，把聚合方式从”月去重计数”切换为”日平均再求和”，保存发布。整个过程耗时 18分钟。

张婷后来在团队复盘会上说了一句让我印象颇深的话：“我从来没有想过，我能亲手改变一个统计口径。那种感觉不是’我抢了程序员的饭碗’，而是’我终于不用因为一个工具人的角色去求人等了’。”

而李然的开发团队呢？他们不仅没有被”架空”，反而因为从繁琐需求中解放出来，提前两个月完成了公司的数据中台改造项目。李然在季度总结里写道：“低代码不是替代开发者的工具，而是让开发者的每一小时都花在刀刃上的杠杆。“

四、数据真相：低代码没有减少岗位，反而放大了能力#

关于低代码对程序员就业的影响，我调研了国内多家引入低代码平台的企业的人力数据。一个反直觉的现象是：引入低代码后，这些企业的技术团队规模非但没有缩减，反而平均扩张了约15%。

为什么？因为低代码大幅降低了”应用创建”的边际成本，让原本被成本挡在门外的大量数字化需求变成了可执行项目。举个例子，某连锁餐饮企业过去只敢提”核心门店运营系统”这一个数字化项目，因为IT资源只够支撑一个大型开发项目。上线低代码平台后，一年内他们孵化了包括”食品安全巡检""员工排班优化""门店能耗监控”在内的23个独立应用。应用多了，需要的架构设计人员、数据管理人员反而更多了。

根据Gartner在2024年的一项预测，到2026年，全球超过65%的企业应用开发将采用低代码或混合开发模式。另有行业调研数据显示，2025年中国低代码市场规模将达到128亿元，同比增长约37%。

但这些数字背后更值得玩味的是岗位结构的变化：

表格中的数据来自我对6家企业的跟踪访谈，样本量虽然有限，但趋势极其一致。一个显而易见的结论是：低代码正在把程序员从”码农”角色推向”解决方案架构师”角色。编程能力的稀缺性不仅没有被稀释，反而因为低代码简化了入门环节，使得高级设计能力与业务理解能力之间的差距被进一步拉大。

换句话说，低代码不是让程序员失业，而是让不学习、不进化的程序员暴露在风险中——这部分人在低代码平台上可能真的会被业务人员通过配置工具替代。但一个拥有扎实程序设计思维、懂分布式架构、能驾驭复杂业务建模的程序员，在低代码时代的职业价值只会有增无减。

五、编程能力的价值正被重新估值#

过去十年，编程能力在行业中的”定价逻辑”其实有一点扭曲。一线开发者的薪资很大程度取决于”能写多少业务代码”，但对业务代码本身的理解深度反而不重要——因为很多代码只是套模板。你写一个订单列表和写十个订单列表，本质上是同一个能力，但简历上看起来经验翻了十倍。

低代码平台的出现，打破了这种虚假的复杂性。当一个订单管理页面只需要拖拽两个数据组件就能生成时，市场对”会写订单页面”这项技能的支付意愿会迅速归零。与此同时，市场对另一类能力的估值正在飙升：

第一类：业务抽象能力。 能看懂复杂业务流程，把非结构化的业务诉求拆解为数据模型、状态机、规则引擎中可配置的逻辑。这需要程序员不只看代码，还要理解业务本身。

第二类：平台驾驭与二次开发能力。 企业级低代码平台不是玩具，它有性能边界、有安全机制、有扩展接口。能判断哪些需求该用配置化实现、哪些必须走插件机制、哪些性能瓶颈需要用底层优化来解决的程序员，在任何团队里都是定海神针。

第三类：人机协作与流程设计能力。 低代码平台让业务人员参与开发变成现实，但业务人员不懂技术约束。如何设计协作流程，让业务人员负责”定义需求”，程序员负责”划定边界和兜底”，这本身就是一项管理艺术。

这三类能力，都属于更高维度的编程能力，因为它们都要求你真正理解计算逻辑的本质，只不过不再局限于一行一行敲代码。我的观察是：在低代码普及程度越高的团队，这类复合型人才的薪资溢价越明显——平均高出普通开发岗位 30%-50%。

在一次行业沙龙上，一位头部企业的CTO说过一句话我很认同：“以前我招程序员，看的是他写过多少行代码；现在我招程序员，看的是他用最少的代码解决了多复杂的问题。前者是工程量，后者是智力密度。”

这就是低代码给程序员带来的新定价模型：编程能力不再按劳动时长计价，而是按决策质量和架构判断力计价。对真正有实力的开发者来说，这是好事，甚至是暴利。

六、人机协作：低代码时代的全新工作范式#

很多技术管理者在考虑引入低代码时，最纠结的问题不是平台选型，而是”这会不会打乱我们现有的开发流程”。这个担心是合理的。低代码确实会改变团队的工作方式，但它改变的方向，不是简单的”程序员让位给业务人员”，而是形成一种更深度的人机协作模式。

这里的人机协作，包含两个层面。

第一层面：人与低代码平台的协作。 过去，程序员的产出是”代码文件”，现在，程序员的产出是”配置模型+少量精妙的脚本扩展”。人负责定义”做什么”和”为什么”，平台负责”怎么做”的重复部分。这种协作模式下，开发者的心智负担大幅降低，可以把注意力放在异常处理、边界条件、性能优化这些平台搞不定的地方。

第二层面：程序员与业务人员通过平台协作。 低代码创造了一个”共同语言层”。业务人员能看懂配置界面，也能上手搭建原型，程序员则负责把原型变成健壮的产品。这解决了困扰IT行业几十年的”需求传导失真”问题——业务人员不再需要用文档转述需求，程序员也不必猜测对方真正想要什么。

我见过一个非常良性的协作案例。某制造企业的设备维护部门，一位懂车间业务但不写代码的工程师，在低代码平台上搭了一个”设备点检实绩看板”的初版，界面粗糙、数据源也未打通。随后，IT部门的开发者介入，把数据源从Excel换成了工业数据库，加上了异常检测算法和自动告警机制，整个过程用了不到一星期。放在过去，这个需求从提报到上线至少要排两个月。

这位开发者事后分享时说：“以前业务人员提需求，十句话里我信三句；现在他们自己搭了原型摆在我面前，剩下的工作就是帮他们’加固’和’优化’。沟通成本断崖式下降。”

人机协作强调的不是”谁替代谁”，而是”各归其位”。低代码负责将重复劳动分解为可视化操作，程序员负责将创新思维转化为系统能力。这种协作范式一旦建立，团队的产出瓶颈将从”开发资源”变成”想法质量”——而想法，永远来自人。

七、给开发团队的技术选型与落地参考#

既然低代码是大势所趋，那么对于正在考虑引入的企业，如何避免踩坑？基于我的实践经验，建议按以下五步走。

第一步：明确引入边界。 低代码最适合的场景是：内部运营管理应用、报表与BI展示、业务流程审批、客户定制化需求交付。它不适合的场景是：高并发核心交易系统、复杂算法引擎、大规模实时数据处理。一开始就明确边界，可以避免团队因为平台能力不足而否定整个方向。

第二步：做平台能力评估。 选型时重点考察四件事：一是扩展能力（是否支持自定义代码、自定义组件）；二是开放能力（API是否丰富，能否接入现有SSO、消息队列、数据仓库）；三是治理能力（有没有完善的权限模型、环境隔离、审计日志）；四是生态成熟度（社区活跃度、组件市场丰富度）。建议安排一个为期两周的PoC（概念验证）测试，用团队真实业务场景去检验，而不是看厂商Demo。

第三步：设计双轨流程。 在过渡期，建议实行”传统开发+低代码开发”双轨制。明确哪些类型的需求默认走低代码通道，哪些必须走正式开发流程。设定需求分流标准，例如”涉及资金流水、用户隐私数据的核心逻辑，必须由专业开发者编写代码；非核心的报表、看板、内部流程，优先考虑低代码方案”。

第四步：培训与赋能。 低代码落地失败的最大原因不是技术问题，而是团队理念未对齐。要为开发者安排专门的培训课程，除了平台操作，更重要的是如何设计可维护的配置模型。同时，为业务骨干开设”业务侧低代码工作坊”，教会他们搭建原型和基础表单。注意，业务人员培训的目标是”表达需求”，不是”替代开发”。

第五步：建立度量体系。 低代码平台上线后，建议每季度复盘以下指标：需求交付周期变化、开发人员时间分配变化、应用故障率、平台性能瓶颈点。用数据说话，持续调整分工策略。

值得一提的是，目前市面上成熟的企业级低代码平台诸多，各有侧重。例如，有些平台在数据模型和复杂业务逻辑方面表现优异，有些则在UI还原度和移动端适配方面更强，还有些擅长与DevOps体系深度集成。建议决策团队在选型时，以”团队现有技术栈的融合度”和”目标场景的匹配度”为核心取舍标准，而非单纯比较宣传页面上的功能清单。

八、给个体开发者与决策者的成长建议#

低代码浪潮下，个体的应对策略比组织层面更重要。我从两个方面给出建议。

对程序员个人：

第一，停止”手写焦虑”，开始”抽象积累”。与其担忧低代码平台用配置代替了你的增删改查页面，不如主动学习平台背后的数据模型设计、状态机编排、权限模型设计逻辑。低代码平台把很多”体力活”标准化了，但设计这些标准的思维，仍然需要人来沉淀。

第二，深耕垂直行业的业务逻辑。纯技术红利期正在结束，“技术+业务”的复合能力成为新的护城河。比如，在制造行业做MES系统、在医疗行业做数据合规平台、在金融行业做风控引擎——这些领域有大量低代码无法标准化处理的复杂逻辑，掌握这些领域的程序员，议价能力会持续走高。

第三，建立”人机协作”心态。你不必把低代码平台视为对手，而是把它当作一个24小时待命的初级工程师。你负责架构设计和关键逻辑，它负责填充常规代码。你的时间被释放出来，意味着你有了更多精力去研究新技术、更多时间去理解业务、更多机会去构建个人影响力。

对技术决策者：

不要因为市场热度盲目引入低代码，也不要因为团队抵触就回避它。低代码是一把刀，用得好可以提升烹饪效率，用不好也会切到手。关键原则是：让平台服务于组织能力，而非反过来让组织被平台绑架。选型时关注平台的可替换性和数据可迁移性，避免被单一厂商锁定。

另外，请务必向你团队中的优秀开发者传达一个信号：低代码不是为了压低技术岗位的价值，而是为了让技术团队做更有挑战性的事。这种信号传递如果缺失，低代码项目很容易在内部遭遇软抵抗——毕竟，没有人愿意引入一个可能让自己贬值的东西。

九、程序员不会被淘汰，但会被重新分层#

回到文章开篇的那个问题：低代码会干掉程序员吗？

我的答案是：不会，但它会重新划分程序员的分层。

低层——那些只熟悉基础增删改查和简单业务页面开发、缺乏深入设计能力的开发者，确实面临被低代码平台和配置化工具替代的真实风险。这不是危言耸听，而是行业效率提升的必然代价。

中层——那些能理解业务模型、能驾驭平台扩展、能在人机协作流程中扮演关键角色的开发者，会变得更加抢手。低代码成为他们的效率放大器，编程能力转化为更高级的解决方案设计能力，职业价值随之上升。

高层——那些具备架构视野、能统筹复杂系统与低代码平台协同运作的架构师和技术领导者，则成为企业数字化转型中的稀缺资源。对他们来说，低代码不仅不是威胁，反而是帮助他们从”资源瓶颈”角色中解脱出来的催化剂。

如果一定要打个比方，低代码之于程序员，就像现代建筑机械之于建筑师。起重机和混凝土泵车不会让建筑师失业，但它们确实让”只会搬砖的力工”失业了，同时让真正的设计师的价值更加凸显。建筑行业因此变得更好了，程序员行业的未来，也会是这样。

这轮技术变革真正的终局，不是人机协作中的任何一方被另一方取代，而是人类把重复劳动交给机器，将创造性思维保留给自己。低代码推动的，正是程序员向更高价值工作的进化。

对于每一位处于变革中心的开发者，我想说：请珍惜你们手中的编程能力，它不会贬值，只会以另一种形式被重新估值。未来几年，低代码平台会越来越强大，但”把复杂问题拆解为计算模型”的能力，永远属于人类，永远属于真正会编程的人。

所以，别焦虑，去进化。