低代码平台：技术人应该认真对待的事

一、那时行业的声音

2021 年是低代码话题的密集期。

钉钉发布宜搭，阿里云推出低代码引擎，各类平台的营销材料里都有一句类似的话：”让不懂编程的人也能搭建业务应用”。公众号上类似《低代码会替代程序员吗》的文章每隔一段时间就会出一篇，评论区里总有一批人在激烈争论。

有一次在公司的技术讨论群里，有人丢了一篇文章进来，说某大厂内部用低代码把一个部门的 CRUD 系统开发工期缩短了 80%。接下来大家的反应分成两类：一类人觉得这是在扯，一类人觉得这件事值得认真对待。

我当时属于第三类：不太确定，但觉得应该真的试一试再说。

二、我的第一反应

说实话，最开始听到”低代码”这个词，我的第一反应是带着一点防御性的——这是给不懂技术的人用的，和我有什么关系？

这种想法来得挺自然，也来得挺快。大概是某种职业性的本能：我学了好几年写代码，现在你说拖拖拽拽就能搞定，那我这些年算什么？

但这个想法撑不住仔细想。我见过太多”绕过工程师”的工具最后还是得靠工程师才能用起来。我更好奇的是：低代码的边界在哪里？它真正擅长解决什么问题？

于是我专门花了一周时间，把宜搭和某开源低代码平台（AMIS）认真摸了一遍。

三、我了解之后的判断

低代码是真实有效的，在特定场景里。

它最擅长的是：内部管理系统、流程审批、表单配置、简单的数据展示页面。这类需求有几个特点——业务逻辑不复杂、用户量有限、迭代频繁、交互不需要太精细。在这类场景下，低代码平台确实能把开发速度拉上去，而且维护成本也低。

但它做不了的事情同样明确：复杂的业务规则（多个状态机联动、动态权限）、高性能要求（几万 QPS 以上）、深度定制化的交互体验。更重要的是，它的扩展性是有边界的——一旦你的需求超出了平台的能力范围，你会发现自己被平台锁住了，改都改不动。

所以我对低代码的判断是：它把某类重复劳动产品化了，这是真实的效率提升，但它无法取代”解决复杂问题”这个部分。

四、对自己职业路径的影响

这次认真了解低代码，给我带来的最大收获不是”我会用低代码了”，而是让我更清楚地看到：程序员的价值不在于写代码这个动作本身。

有一个很具体的例子。我们当时有一个内部的报表需求，产品经理说要一个能自定义列、支持导出、能按部门权限过滤的报表页面。用低代码平台，这个需求大概三天能搭出来。但同期还有一个需求：用户下单后要根据商品类型、库存位置、配送距离，自动选择最优的仓库。这个需求低代码根本碰不了。

第一个需求，我不在，平台也能做。第二个需求，离开了理解业务规则和系统结构的工程师，什么工具都没用。

低代码出现以后，我反而更清楚了：程序员的价值在于判断，而不是生产。判断哪些东西需要工程化，哪些不需要；判断复杂性在哪里，简单性在哪里；判断技术方案和业务目标之间的匹配度——这些事情，低代码平台没法替你做。