运营同事想做一个门店巡检登记工具：手机填表、拍照上传、超时提醒、按区域汇总。需求不复杂，却常卡在同一个地方——IT排期。业务等不起，开发也未必愿意为一个小工具插队。低代码常被放在这个场景里讨论，它真正改变的，不是把代码这件事说没了，而是把“先找谁写”变成“先由谁把流程讲清楚”。
门槛降在哪里
表单、权限、流程节点、消息通知，这些能力在可视化界面里通常可以拼起来。对业务人员来说，最直接的变化是少走几道环境准备和发布流程；对技术团队来说，重复度高的内部工具可以先被搭出轮廓，再决定哪些部分需要写扩展逻辑。它省掉的往往是沟通和样板的成本，不是思考和设计的成本。
一个现实的问题是，拖拽不等于想清楚。字段怎么命名、谁能看哪条记录、状态变更要不要留痕，这些仍然要有人负责。平台把入口放低了，却没有替人做数据建模。若一开始把表格当草稿纸，字段越加越多，后面维护的人就要花时间猜每个字段的来历。
容易被忽略的维护账
小工具上线后，通常会经历一段安静期，然后需求回来：增加一个审批节点、同步到另一个系统、按季度导出。此时这个应用已经不只是“临时表单”，而是业务动作的一部分。它需要有明确的维护人、变更记录和权限复核。否则，业务能自己搭，也能自己改，问题会从“排队等开发”变成“没人说得清现在跑的是哪一版”。
- 先限定使用范围：一个工具只解决一类流程，避免无限扩张。
- 把数据口径写下来：字段含义、状态流转、导出规则都要有简短的说明。
- 给变更留个口：谁改了什么、为什么改，至少能被后来的人查到。
它适合放在哪类位置
如果需求是边界清晰的内部流程，参与人数有限，变化频率可预期，低代码能缩短从想法到可用的距离。反过来，涉及复杂算法、强实时交互、深度改造旧系统或大量外部接口的场景，单靠拖拽很难兜住，仍需要工程团队介入。把它当成所有系统的入口，容易在后期补更多的洞。
我的判断是，低代码的价值不在“谁都能开发”这句口号里，而在它让业务定义和系统实现之间的距离变短。距离变短之后，治理要跟上：谁能建、能建多大、上线前谁看一眼。把这些边界说清楚，工具才不会被用成新的技术债。