三年后没人敢动的那个表单
见过不少这样的内部系统：报销、设备报修、门店巡检，界面朴素，流程却意外顺手。它们大多不是 IT 部门排期做出来的，而是业务岗位上某个人，用一套可视化工具搭起来的。上线那阵子，改一个字段只要十分钟，谁都觉得省事。
问题往往出在第三年。搭它的人调岗或者离职，接手的同事打开编辑器，看到几十个分支、层层嵌套的条件、名字叫“测试2”的变量。系统还在跑，没人敢关；改动一行，怕牵连别处。于是它从“省事的工具”变成了“碰不得的资产”。
省下的是入场费，不是维护费
低代码真正降低的，是把想法变成可运行界面的那一小段距离。拖拽、连线、配置字段，确实比从零写一遍快得多。但这只是入场费。一套系统活得越久，花费越集中在理解它、改它、把它交给下一个人——这部分成本并不会因为界面是拖出来的就消失。
更微妙的是，配置界面把复杂度藏了起来。写代码时，一个判断分支有缩进、有函数边界；在画布上，它可能只是两段连线之间一个不起眼的开关。看得见的部分变简单了，看不见的部分——权限矩阵、状态流转、异常兜底——反而更容易被忽略。
它适合什么，不适合什么
把边界说清楚，比争论低代码能不能替代开发有用得多。
- 适合：表单填报、多级审批、数据汇总看板、部门内部的临时工具，以及那些需求还在变、先跑起来再说的场景。
- 不太适合：高并发写入、复杂计算与算法、强实时链路，以及需要精细性能调优的部分。
- 还有一个容易被忽略的判断标准：这套东西预期活多久。只用三个月就下线的，怎么快怎么来；预期跑五年的，一开始就得按长跑的标准搭。
把配置当代码来管
如果非要给一条最实在的建议，那就是：别因为它是“配出来的”，就免掉工程习惯。命名规则、变更记录、测试与生产环境分开、定期清理废弃的表单和字段——这些不是表演给程序员看的仪式，而是给下一个接手的人留的说明书。
有些团队会做一件小事：让搭建者在交付时写半页纸，说明这条流程为什么这么设计、哪些分支是特例、改动时要注意什么。半页纸的成本极低，却能挡掉很多“不敢动”。
另外值得留意的是，低代码工具的供应商也在往可读性上走：导出结构化描述、接入版本管理、支持代码与配置混写。这些能力比多几个炫目的组件更能决定一套系统能活多久。
门槛只是挪了个位置
把工具交到更多人手里，本身是好事——离业务最近的人，往往最清楚流程哪里别扭。但工具降低的是动手的门槛，不是理解系统的门槛。它把门槛从“会不会写代码”挪到了“能不能把一件事说清楚、管得住、交得出去”。
所以回到开头那个问题：第三年没人敢动，原因不在工具本身，而在于没人把它当成需要维护的东西。换一套工具，结局多半也一样。