从一张改了三次的申请表说起
业务同事要在一个审批表里加一栏“预计交付时间”，顺带把原来的两级审核改成按金额分流。走常规流程，提需求、评估、排期，中间还要和开发对两次口径。等待的时间里，表格先在聊天工具里传着用。
后来有人试着用低代码把这张表拖出来：字段、流程、谁能看谁能改，都在界面上点几下。半天时间，链接发到群里，能用。这件事给人的印象很深——原来卡住我们的不是技术难度，是排队。
但故事通常不会停在这里。
它封装的其实是几类高频结构
把低代码说得玄乎没有意义。它做的事情说穿了很朴素：把表单、流程分支、权限、数据表这几样在业务系统里反复出现的东西，做成可视化配置，让不写代码的人也能拼出来。
所以它的价值并不在“人人都是开发者”这句口号上。真正的变化是需求流转路径：一批边界清楚、参与人少、结构稳定的小需求，不必再挤进研发排期，而是由最懂业务的人自己先跑起来。跑得通，再决定要不要沉淀。
理解这一点，就能理解后面为什么会出问题——它解决的是“做出来”的成本，并不解决“养下去”的成本。
上线之后，麻烦才刚开始
一个应用刚上线时通常很干净：十来个字段，两三条分支，做的人对整个结构了然于胸。半年后再打开，情况往往是这样：
- 字段加了一批，有些名字相近但含义不同，没人说得清哪个才是准的；
- 流程分支从两条长到五六条，每条背后都对应某次临时讨论；
- 同一份客户信息在两个应用里各存一份，改了一边忘了另一边；
- 当初搭建的人调岗了，接手的人打开画布，看到一片连线和节点。
这些问题和工具本身关系不大。传统开发也会积累技术债，区别在于它有仓库、有评审、有测试环境，改动留下痕迹，也留下可以被追问的理由。而在可视化界面上点两下就生效，太顺了，顺到很少有人在改之前问一句：这个改动会影响谁。
换句话说，低代码把搭建的门槛降下来了，却没有同步降下维护的门槛。它把一件需要协作的事，变得看起来像一个人的事。
哪些该交给它，哪些不该
谈边界比谈能力更有用。按经验，比较适合放手去做的，是结构相对稳定、参与人数有限、生命周期可预期的东西：内部登记、信息收集、轻量审批、临时性的项目跟踪。这类需求即使推倒重来，代价也不大。
需要谨慎的，是那些会被别的系统依赖、涉及复杂计算、或者承载核心数据的东西。它们一旦被大量引用，任何一次字段调整都可能牵动别处，而配置界面很难把这种牵连直观地呈现出来。这时候省下的搭建时间，往往会在后面以别的方式还回去。
还有一类容易被忽略：需求本身还没想清楚的时候。可视化搭建太快了，快到可以绕过“我们到底要解决什么”的讨论，直接产出一个能点开的页面。页面很唬人，问题还在原地。
几件不起眼但决定成败的小事
如果团队已经在用，与其追求搭建速度，不如先定几条土办法：
- 字段命名有个统一约定，公共的信息只维护一处，别让同一个人在两套表里有两副面孔；
- 每个应用有个明确的责任人，哪怕只是兼职，也要有人能回答“这个能不能改”；
- 上线前留一页说明，写清用途、数据从哪来、谁在用，几十个字就够，将来救的是别人；
- 隔一段时间清一次，把没人打开的应用归档。留着不是资产，是负担。
这些事听起来琐碎，却决定了一个团队用低代码是在积累，还是在制造新的混乱。
它改变的是路径，不是人数
回到开头那张申请表。它确实被更快地做出来了，这本身就值得。但如果半年后没人说得清表里那栏数字是谁填的、准不准，那么省下的时间只是被推迟支付。
我的判断是：低代码不会让开发岗位消失，也不会让业务部门变成技术团队。它做的事情更微妙——把原来集中在研发队列里的等待，分散成许多个需要自治的小决定。排队问题换成了治理问题，后者更难，但也更接近事情本来的样子。
工具能给的，是把想法快速变成可用东西的能力。至于这东西能不能活过一年，取决于用它的人愿不愿意在没人催促的时候，做那几件不显眼的事。