把输入框拖进画布，连一条线，绑定一个数据表，表单就能跑起来。演示通常到这里结束。真正的工作从第二天开始：三个月后要加一个字段，要和另一个系统对齐口径，要有人能看懂当初为什么这么设计。
低代码压缩掉的，是“把想法翻译成代码”这一段。语法、框架、构建与发布这些环节被折叠成配置项，长期缺开发资源的团队确实能感觉到松动——需求不必再排几个月的队，业务方也不用先写一份自己都不确定能否被理解的文档。
被折叠的部分没有消失
它换了位置。表单能拖出来，数据模型、权限边界、状态流转仍然要人想清楚。配置界面不会替你判断“这个字段该不该可编辑”，它只提供开关；也不会告诉你两个模块的口径是否一致。这些判断依赖对业务本身的理解，工具替不了。
随之变化的是维护成本的分担。代码少了，配置多了；写代码的人少了，能读懂配置的人要求反而变高。半年后接手的人打开一个画布，看到几十个节点和条件分支，那种感觉并不轻松——代码至少还能被搜索，图形化的东西往往只能靠人一个个点开看。
改动变容易之后
业务方自己调整一个流程，两天上线，体验很好。改到第十次，已经没人记得第一版为什么那样写。低代码把“改动”的门槛降得很低，也顺手把“改动被记录、被评审”这件事变得容易被跳过。于是产生一类新问题：系统还跑得动，但没人能完整描述它现在是什么样。
还有连接。系统的价值常常在接口那一侧，而接口恰恰是最难配置的部分。字段映射、异常重试、时序与幂等，落到可视化界面里通常只剩一格输入框加一段说明。这里出问题，拖拽帮不上忙。
边界的判断标准
它适合表单、审批、数据录入、轻量内部工具、流程串接这类场景；面对复杂算法、高并发、需要精细性能调优的部分，通常不是合适的选择。判断的依据不应只看“能不能做出来”，还要看“做出来之后谁负责它三年”。
- 命名和分层有没有约定，还是各自随手起名；
- 谁有权发布到生产环境，有没有第二个人看过；
- 不再使用的应用由谁定期清理，还是只增不减；
- 关键配置能否导出、比对、回溯。
这几件事不好看，但决定了低代码用久了是资产还是负担。我更愿意把它理解为一次分工的重新划定，而不是开发工作的简化：实现被下放给离业务更近的人，设计与治理被抬到更高的位置。抬上去的那部分如果没人接，前面省下的时间会在后面慢慢还回去。
所以引入之前，值得先换个问法。与其问“能省多少开发人力”，不如问“这些被释放出来的改动，我们准备好承接了吗”。