常见的画面是这样：某个业务部门用两周时间，把一个内部审批应用搭了出来，表单、节点、通知都在可视化界面里配好，上线那天大家觉得挺省事。三个月后，流程要加一个跨部门会签，负责的同事打开配置页，发现上一位改动人留了七个条件分支，其中三个判断条件互相覆盖，谁也说不清某张单据到底会走到哪条路上。于是新需求被搁置，应用继续按老样子跑。
这不是工具不好用，也不是使用者不认真。低代码真正降低的是“把想法变成可运行页面”的门槛，它没有同步降低“把业务规则想清楚”的门槛。前者靠拖拽几分钟就能看到结果，后者需要在动手之前把例外、边界、责任归属一条条列出来。可视化界面让前者变得极其顺手，顺手的代价是让人误以为后者也一并完成了。
复杂度没有消失，它换了存放的位置
传统开发里，业务规则写在代码里，改动要走提交、评审、测试、发布。这套流程慢，但慢有慢的好处：每次改动都留下痕迹，谁改的、为什么改、影响哪些地方，在版本记录里能查到。配置驱动的低代码平台把这套过程压缩成在界面上点几下，速度快了，痕迹却常常只剩一条“某某于某日保存”。
更麻烦的是隐式耦合。表单上的一个字段，可能同时被权限规则、流程分支、报表统计、消息模板引用。在代码里，这类引用以显式调用的形式出现，删掉一个字段，编译或测试会提醒你哪里断了。而在配置模型里，这些关系散落在元数据表之间，改动时界面上一切正常，直到某张单据跑进一个没人预料的分支。
所以问题往往不在“能不能做”，而在“做完之后谁来维护”。这是两件事，中间隔着一段常被跳过的功夫。
它适合什么样的活儿
判断一个场景该不该用配置化方式搭，我倾向于先看三点：
- 规则是否稳定：例外多不多，会不会每个月都要改一次判断条件；
- 边界是否清楚：输入输出能不能说清，和别的系统怎么交互；
- 使用范围是否可控：谁会用到，出问题时找谁。
内部审批、信息采集、简单的台账管理，规则大体稳定，例外有限，参与的人也就那么几个，这类场景用拖拽确实省事。反过来，交互复杂、状态多、并发要求高的东西，配置界面里能表达的部分会迅速逼近极限，剩下的只能靠写代码补，补完之后变成一半配置一半代码，维护的人两边都得懂。
还有一个容易被忽略的点：影子系统。业务部门自己搭出来的应用，一开始是便利，用的人多了就成了依赖，等到当初搭它的人调岗或离职，接手的人既不敢改也不敢停。IT 部门往往不愿意接这类应用，因为没有文档、没有测试，规则只存在于原作者的记忆里。
缓解的办法其实不新：把配置当成代码来对待。谁改的、改了什么、为什么改，留下记录；上线前在测试环境跑一遍关键路径；对核心的流程分支画一张人能看懂的图，放在应用旁边。这些事做起来不酷，却决定了三个月后的那次改动是一小时还是拖一个月。
工具本身在进步，版本管理、环境隔离、配置比对这类能力，越来越多的平台开始提供。但工具能给的只是手段，愿不愿意在使用前花半天把规则写清楚，仍取决于人。
回到开头那个画面。那位同事最后没有加会签节点，而是把需求转给了 IT。这不算失败，只是提醒：低代码缩短的是实现的距离，没有缩短理解的距离。