会议室里常见的画面：运营同事把笔记本转过来，浏览器里是一个刚搭好的表单，三个字段、一条审批路径、一张列表页，前后不到半小时。旁边有人问了一句：“这个能上线吗？”问题听着简单，答案不简单。
低代码降下的是语法门槛，不是逻辑门槛
这类工具做的事情，本质是把表单、列表、权限、流程节点、数据关联这些反复出现的结构，提前抽象成可拖拽的部件。写代码时你要先搭环境、定框架、处理校验和权限，现在这些被收进配置面板。省掉的是语法和工程脚手架，不是思考。
于是第一个误区就出现了：能拖出来，等于能用。字段要不要必填、谁能看哪一行、审批卡住时由谁兜底、状态一共有几种——这些是业务本身的复杂度，工具不会替你决定。拖界面往往一两天就够，讨论“离职员工的历史单据归谁审”却能耗上更久。后面那段才是真正的工作。
分水岭出现在上线三个月之后
刚上线时一切顺利。三个月后，最初搭建的人调了岗，表单上多了七个别人加的字段，其中两个名字很像，没人说得清区别；有人复制了一份改造成新流程，两份数据开始对不上。这时候你会发现，这套东西虽然没有代码仓库，却同样需要有人负责。
- 谁有权改配置，改动要不要留痕；
- 一份数据只允许有一个来源，还是允许各搭各的；
- 流程卡住、字段算错时，找谁，多久能修好。
这些问题和工具无关，和有没有把它当资产看待有关。把它当“临时办法”的地方，半年后容易积起一堆没人认领的小应用；郑重对待的地方，反而会先立几条规矩再放手。
低代码的天花板不在功能清单上
很多讨论喜欢比较“能支持多复杂的流程”，但真正的分界往往在别处：当需求开始跨系统取数、要求事务一致性、要求在高并发下别掉链子，配置界面上的连线就会变成另一种代码——只是它没有版本管理，没有测试，出了错只能靠人回忆当时点了什么。这不是工具的失败，是抽象层的边界。任何抽象在某个复杂度之上都会漏风。
所以更实际的做法是，一开始就问清楚：这个东西的寿命有多长，坏了谁修，数据要活多久。答案不同，做法就该不同。
把它当成探针，而不是终点
需求还没定型时，用它两三天做出可点的东西，让业务方看到真实的样子，比几十页文档有效得多。等逻辑稳定、使用面扩大、开始牵扯核心数据，再判断是继续长大，还是交给工程团队重写。迁移有成本，但比起用错工具硬撑三年，成本更可控。
配套动作也不复杂：给它定一个收口的人，把关键规则写在配置之外的地方，哪怕只是一份文档；限制生产环境的改动权限；定期清掉没人用的东西。
我自己的判断是，这类工具改变的不是“谁在写程序”——业务人员依然在做业务决策，只是把决策直接落成了可运行的东西。它真正挪动的是需求与可用之间那段距离，以及这段距离由谁承担。想清楚这一点，比争论它能不能取代开发有意义得多。