一个内部审批流程要加一个字段，业务方提了需求，排期却落在两个月后。会上有人半开玩笑地说：这种东西，我们自己搭一个不就行了。会议室安静两秒，然后大家开始认真讨论这件事的可行性——这大概是过去几年里，很多公司的技术部门都经历过的瞬间。
低代码真正改变的不是“能不能做”，而是“谁来动手”。它把界面、表单、流程编排这些原本需要写代码的部分收敛成配置，让熟悉业务的人可以直接把想法摆成一个能跑的东西。起步成本确实降了，问题是，降下来的只是起步成本。
省掉的排队，换了一种排队
最常见的路径是这样的：业务侧最着急的那个人先学会工具，花两周搭出第一版，用起来还算顺手，于是范围一点点扩大——多一个审批节点、多一张关联表、多一个导出。半年后，这套东西已经承载了部门的核心流程，但只有一个人知道它内部是怎么连的。
这里出现的不是技术难题，而是所有权问题。它由谁维护、改动前找谁确认、这个人调岗或离职之后怎么办，往往在搭建的那一刻没人问，等问的时候已经晚了。原本压在技术部门的排期，转移成了业务部门内部一条看不见的任务队列。
它更适合“薄”的东西
如果把应用按复杂度铺开，低代码明显在某一端更从容：
- 生命周期短：临时统计、专项活动报名、阶段性信息收集，用完可以下掉。
- 使用人数有限：几十人以内的内部工具，性能压力小，出问题影响面可控。
- 逻辑以表单和流转为主：状态少、分支清晰、不需要复杂的计算和事务保证。
- 与既有系统的交互简单：读一份名单、写一条记录，接口调用不深。
反过来，涉及复杂的业务状态机、跨系统数据一致性、高并发写入、需要长期演进的核心系统时，配置出来的东西很快会碰到表达能力的边界。这时候继续硬撑，通常表现为大量重复的变通做法堆在同一处，看起来能跑，改一次就要重新理解一遍。
边界并不总是清晰的。判断的粗略办法是问一句：这个流程三年后还在吗，还会由同一个团队维护吗。如果答案模糊，那它可能更适合先被简化，而不是先被做出来。
工程师的位置没有消失，只是往前挪了
很多时候，讨论低代码会滑向“还需不需要开发人员”。从实际观察看，需要，只是工作内容变了。当业务侧能自己拼出界面和流程之后，技术侧真正要做的是把地基铺好：统一的数据模型、清晰的身份与权限边界、可复用的集成接口，以及上线之后能被看见的运行状态。
还有一件经常被忽略的事：退场机制。一个组织里如果已经散落着几十个自制的小工具，谁来盘点它们、谁来判断哪些该合并、哪些该关掉。平台在演示时几乎从不提及这部分，但它决定了长期是变轻还是变重。
所以引入低代码之前，值得先回答几个朴素的问题：这个流程会活多久？出问题时谁来接？数据流向了哪里？如果答案都能落地，它确实能让一个想法在一周内被验证；如果答案含糊，那它只是把一段等待换成了一段没人记账的加班。
工具降低的是开始的门槛，不是持有的成本。真正的检验标准也很简单——三年之后，还有没有人愿意打开它。