一个做行政的朋友说，他们部门上个月自己搭了套会议室登记工具。没提需求、没排期、没开评审会，一个人在浏览器里拖了大半天，字段、审批流、提醒都有了。第二天开始用，第三天又加了两个字段。
听起来是件小事，但它把一个问题摆到了台面上：过去我们说的“开发一个系统”，时间到底花在哪了？
省下来的不是工时，是往返
常规流程里，业务方写一段需求，开发同学理解成另一段，做完对一遍，发现偏了，再改。一次往返可能就是几天。低代码压缩的正是这段距离——把“说清楚”换成“直接摆出来”，让讨论发生在能点开的界面上，而不是文档里。
所以它省下的常常不是程序员的工时，而是等待和返工。这两样在工时表上看不见，在实际使用中却最让人疲惫。
代价不会消失，只会换个地方
工具让“做出来”变容易，但系统一旦有人用，问题就会自然出现。最常见的几件事：
- 字段命名各自为政。同一个人，在三个表单里叫三种写法，后面想汇总时才发现对不上。
- 权限靠口头约定。谁能看、谁能改，搭的时候没想，用起来才发现边界模糊。
- 流程只在跑，不记状态。出了问题要回溯，得靠聊天记录拼。
- 没人认领。搭的人调岗了，工具还在跑，谁也不敢动。
这些问题与低代码本身无关，任何快速成型的方式都会遇到，只是低代码把“成型”这一步变短了，后面的部分就显得格外长。
它能压到哪里，压不动什么
我的判断是，它适合那些流程清楚、变化频繁、容错要求不高的内部工具：登记、审批、台账、信息收集这类东西，改十次也不心疼。
反过来，需要强一致性的核心业务、集成关系复杂的老系统、对性能和并发有明确要求的场景，就不该指望靠拖拽解决。这不是能力问题，是工具定位的问题。用一把好用的螺丝刀去拆承重墙，工具本身没错。
问题会从“能不能做”变成“谁来管”
当搭建门槛降低，团队里会出现一批“半个开发者”。他们懂业务，但未必懂版本、边界和数据口径。这时候真正需要设计的不是表单，而是几条朴素约定：字段命名先查再用，公共的表尽量别各建一份，上线前过一次权限，谁搭的谁负责留一句说明。
还有一件容易被忽略的事——退出机制。一个用低代码搭起来的原型，如果证明它确实重要，就应该有一个把数据迁到更稳定环境里的路径，而不是让它一直停在演示状态里承担正式职责。
我见过不少团队在这件事上吃过亏：最初只想省三天，最后花了三个月补窟窿。这不是说低代码不好用，恰恰是它太好用，才需要提前想清楚哪些东西不该交给它。
回到那位朋友。他们的会议室工具现在还在跑，用的人不多，也没出过事。这大概就是这类工具最舒服的状态：够用，随时可改，也没人指望它承担更重的东西。