去年有个场景我一直记得：一位做运营的同事用拖拽的方式，把一份线下台账搬到了线上。两周做完，录入、校验、审批都齐了，团队挺高兴。半年后再问起来，人已经调岗，表单还在跑，但某个字段为什么这样校验、那条流程分支为什么多绕一圈，没人说得清。
这不是工具的错，也不是她的错。只是我们聊低代码的时候，习惯问“上线有多快”，很少问“半年后它归谁”。
它真正缩短的，其实是一小段距离
把常见需求拆开看，会发现大量内容在重复：一张表单、几个字段、一条审批链、一份能按条件筛出来的列表。这类东西被实现过无数次，做成可视化配置是合理的，也确实省事。低代码缩短的，是从“口头描述的需求”到“能被点开看一眼的界面”之间的距离。
但从界面到长期运行，还有另一段路。这段路没有被缩短，只是被推到了后面，而且常常落到不负责运维的人手上。
抽象层漏掉的那部分
用预制件搭房子是个常见的比喻：墙体和楼梯是现成的，地基和管线还得自己盯着。落到具体工作上，漏出来的通常是这些地方：
- 几张表之间的状态互相牵制，改一个字段会牵动别处的判断；
- 权限的关键在于“谁能看哪几行、在什么阶段看”，而不只是“谁能看”；
- 和外部系统对接时，对方改了接口，配置里那一层不一定有人留意；
- 数据量涨上去之后，原来顺手的查询开始变慢；
- 规则散落在表单、流程、脚本三处，改需求时得靠记忆拼回去。
这些不是低代码独有的问题，写代码同样会遇到。区别在于，写代码时它们会以文件、模块、依赖的形式摆在明面上，而配置化的东西容易藏在界面后面，看起来简单，读起来并不简单。
先问谁维护，比先问能不能搭更值得
实际推进时，我越来越觉得该先问一句：这个东西半年后坏了，谁去修？
如果答案是“当初搭的人”，那要确认他还在、还有时间、还愿意。如果答案是“IT 部门”，那要在动手之前就把交接方式说清楚：配置存在哪、命名有没有约定、改一个字段会影响哪些地方。这些听起来像琐事，但它们决定这个东西最后是资产还是负担。
还有一个容易忽略的点：一旦某个配置出来的东西开始承载日常业务，它在事实上就是生产系统了。生产系统该有的备份、变更记录、出错时的兜底路径，一样都不能少，不会因为它是拖出来的就打折。
我愿意把它放在什么位置
我的判断偏保守：低代码适合那些生命周期不长、参与人数有限、业务规则还在变、就算停掉也不影响大局的场景。做内部登记、活动报名、临时统计、跨部门收集意见，很合适。用来承载未来很多年都要依赖的东西，需要多想一步。
更值得说的一个用法，是把它当草稿纸。业务方对需求的理解，往往在看见东西之前是模糊的。先拖出一个能点的版本，大家对着它吵一架，把边界吵清楚，再决定是继续在上面改，还是交给工程团队重做。这时候省下的不是开发工时，而是沟通来回。
当草稿纸还是当承重墙，结果差得很远。前者失败的成本是一次演示，后者失败的成本是一次停机。把这两件事分开看，比争论它能不能取代程序员有意义得多。