某个周一早上，行政同事在群里发了一张截图：报销入口点进去是空白页。技术同事排查了一上午，发现三个月前一位已经转岗的运营调整过流程字段，下游那张表单没跟着改。系统本身没坏，问题是没人说得清这个入口归谁管。
这类事在用了低代码的团队里并不罕见。它既不是灾难，也算不上什么新问题，只是把原本藏在代码仓库里的责任，摊到了每个人都能点开的页面上。
它真正替代的是「翻译」环节
过去业务提需求，要经过需求文档、评审、排期、开发、测试。中间每一步都在做翻译：把「我想要一个能按项目归集工时的表」翻译成字段，翻译成表结构，翻译成接口。低代码把这段翻译压短了——业务人员直接拖出表单、连线出审批路径、勾选谁能看哪几列。
压缩带来的直接感受是快。但快只是表象，实质是决策权发生了位移：字段怎么定义、状态有几种、谁能改，这些原本由工程侧把关的判断，交到了离业务最近的人手里。
省下的时间去了别处
经常听到的说法是「一周搭完」。这句话通常是真的，只是后面还有半句没说完。一周搭完的东西，在第三个月会遇到几件事：
- 同一份客户信息被建了三张表，字段名不同，口径也对不上；
- 某条审批流因为人员变动卡在中间节点，没人收到提醒；
- 最初搭它的人调岗或离职，留下的流程照常运行，却没人敢改。
这些不是低代码的缺陷，而是任何系统长到一定数量都会出现的问题。区别在于，写代码的年代，这些问题会在代码评审和版本管理里被记录、被拦下；而拖拽出来的东西，往往没有对应的记录习惯。
边界出现的信号
判断一个场景适不适合继续用低代码，我习惯看几个信号。一是流程里出现需要复杂计算、或与外部系统高频交互的部分；二是同一份数据被多个流程同时改写；三是需求开始要求在很短时间内完成校验。到了这些地方，抽象层会变薄，拖拽能表达的东西不够用了，硬撑下去，结果通常是一堆打补丁的节点。
反过来，那些规则稳定、参与人有限、改动频率不高的内部流程，往往是它待得住的地方。
维护成本不会因为拖拽而消失
低代码改变的是成本的位置，而不是成本的有无。开发环节省下的工时，会以另一种形式出现在治理环节：谁负责登记、谁负责归档、谁在人员变动时做交接。这部分工作没有进度条，也不产生演示效果，但缺了它，前面省下的时间会一点点还回去。
所以看一个团队用得怎么样，我不太看他们搭了多少个应用，而愿意多问一句：这些应用现在归谁管。答得清楚的团队，通常还能继续往下走；答不上来的，多半已经开始收拾残局。