一个不新鲜的情形：业务部门要做一张跨部门流转的申请表，按常规排期需要等，于是有人提议用低代码拖一个出来。两小时后表单上线，字段、审批节点、通知规则都在界面上点完了。省下来的时间是实的。问题出在后面——几个月过去，没人说得清某个字段为什么必填，某个节点为什么跳过部门负责人，只知道“当时是这么定的”。
这其实算不上工具的问题，更像是“被省掉的那部分”在别处重新出现了。
拖拽省掉的是语法，不是判断
低代码真正压缩掉的，是把想法翻译成代码语法的那段时间。而需求本身的模糊、字段口径的分歧、例外情况怎么处理，并不会因为界面上摆着下拉框就自动澄清。
变化在于，这些分歧以前会在跟开发对需求时被逼着讲清楚——你得说出这个状态有几种、谁有权改、改完要不要通知谁。现在可以绕开这场对话，先做出来再说。做出来很快，改起来也不慢，于是“先这样，回头再调”成了默认节奏。回头往往没有来，配置一点点长成了没人完整读过的样子。
所以我不太认同“低代码让业务人员自己搞定需求”这种说法。它让业务人员自己搞定了界面和流程，但需求里那些真正难的部分，只是换了个地方等人处理。
谁认领，决定它能活多久
低代码搭出来的应用，通常不进IT部门的标准资产清单，也不在常规的巡检和维护范围内。业务侧的人搭的，业务侧最懂；可一旦换岗、调部门，留下的就是一堆没人敢动的配置。删掉怕影响正在跑的流程，改又不知道牵动哪里，最后只能挂着。
可维护性跟平台能力关系有限，跟有没有人认领关系很大。见过做得比较稳的做法，是在搭之前就写明这条流程归谁、改配置需要谁点头、多久回看一次。听起来像多余的手续，但它决定这个东西半年后是资产还是包袱。
看变化频率，也看出错代价
判断一个场景该不该用低代码，我倾向于看两件事：一是变化频率，二是出错代价。
- 变化快、错了能马上纠正、影响范围有限的，比如内部登记、临时统计、活动报名这类，适合先把流程跑起来，边跑边改。
- 一旦定型、错一次代价明显的，比如涉及账务口径、对外承诺、需要长期留痕的环节，更值得花时间把规则前置想清楚，哪怕慢一些。
这两条不是技术难度问题。有些逻辑极简单的流程，因为错一次就要跟外部反复解释，反而应该老老实实写清楚、测清楚。
用得顺手的时候，人容易忘掉它的前提：拖拽出来的东西依然是一套系统，会有边界条件、会有并发、会在某个没人预料到的输入下给出奇怪的结果。这些不会因为界面上没有代码就消失，只是被推迟暴露。
所以讨论低代码，与其问“要不要用”，不如问“用在流程的哪一段”。拿它接住那些还没想清楚、需要反复试的部分，是合适的；指望它替代把规则想明白的过程，多半会在半年后收到账单。