半年前搭的一套审批应用，现在要加一个字段。点开配置界面，字段本身两分钟就加好了，麻烦的是它要出现在三张表单、两个列表页和一条通知里，而当初搭这套东西的同事已经调岗。
这个场景在不少团队里重复出现。拖拽确实把第一步变简单了，但系统的成本从来不在第一步。
省下的是写代码，挪走的是理解
低代码把开发动作换成配置：表单、流程、权限、通知，都在界面上点出来。这一步的收益是真实的，尤其是流程清晰、变化不多的内部工具，过去要排期等开发，现在业务侧自己就能跑起来。
问题在于，配置也是一层抽象。抽象会藏起细节，而细节恰恰是后来改不动的原因。写代码时，一个字段出现在哪几个页面，靠搜索能找出来；配置化之后，关联关系散在界面里，没有一处能完整说清楚。工具通常会提供依赖检查，但检查的是它自己认识的那部分。
数据模型会一直影响后续改动
很多人搭应用时从表单开始，想到什么加什么。前几张表没问题，到第十几张时，同一个客户在不同表单里有三种写法，报表就对不上。这时候再回头改结构，等于把已经跑起来的流程拆开重装。
我的判断是：低代码省下的时间，多半会在数据模型上还回去。工具不替人做建模决定，它只是让草率的决定更快落地。上配置之前，把实体、字段、关系在纸上写一遍，这个动作看起来老派，但能省掉后面很多次返工。
权限和分支，复杂度不会消失
流程画起来直观，箭头连着节点，像流程图。但真实业务里的例外总要有人处理：某人休假时谁代审、金额跨档时走哪条路、跨部门时数据给谁看。这些在界面上能配，只是配到一定数量后，流程图本身变得更像一份需要阅读的文档。
- 一次性活动、到期就废弃的收集表，收益很直接；
- 参与方少、规则稳定的内部流程，也合适；
- 跨多个系统取数、规则频繁变动的场景，配置量会追上写代码的工作量，还多了工具本身的约束。
最后一种情况的代价容易被低估：代码有版本管理、有代码评审、有测试，配置往往没有。改错了上线，只能靠回忆上一版是什么样。
真正能把应用搭到可维护的人是谁
不少企业引入这类工具时，期待的是“业务人员自己开发”。实际跑一段时间会发现，能独立把一套应用搭到可维护状态的，通常是懂业务又懂一点技术的人。他们人数不多，却决定这套东西能走多远。这不是工具的问题，是分工的问题——把开发动作简化，不等于把系统设计的判断也简化。
所以我现在看这类项目，会先问三个问题：这套应用预计用多久；半年内规则会不会变；出事时谁能看懂配置。答案清楚，再决定用拖拽还是写代码，都不迟。