低代码常被放在“业务人员自己搭应用”的叙事里，听上去像把开发门槛削平。真到项目现场，问题往往不在拖拽顺不顺手，而在流程有没有稳定到值得被固化。一个审批、一张台账、一段客户回访记录，如果规则天天变、例外比常规多，拖拽出来的只是返工。
先看流程是否值得固化
判断是否适合用低代码，可以先看三件事：输入是否结构稳定，输出是否容易验收，例外路径是否可枚举。比如内容团队收集选题、登记素材授权、跟踪发布状态，字段和状态机相对清楚，适合先用可视化配置跑起来；反过来，涉及复杂定价、跨系统实时对账或高度依赖人工判断的环节，硬塞进表单里，维护成本会转移到后期。
这里的“快”并非来自少写代码，而是把重复的页面、权限和通知逻辑收进配置层。业务人员能改字段和流程，工程团队保留接口、数据模型和发布权限。两边各管一段，协作边界反而清楚。若把低代码当成绕开工程评审的捷径，上线后的权限漏洞和脏数据，通常还是要技术团队来收拾。
AI 接入后，表单之外还有一层
人工智能项目里，低代码常见的位置是“壳”：把模型调用、素材上传、人工复核、结果归档串成一个可操作界面。模型能力不稳定，界面就需要留出人工确认和回退路径；提示词或参数调整，也应记录版本，而不是散落在个人文档里。否则演示时顺畅，进入日常使用后，问题会集中在“这次结果为什么和上次不同”。
- 把人工复核做成显式步骤，别默认模型输出可直接进入下一步。
- 对上传内容设置字段级权限，避免配置方便带来数据暴露。
- 保留操作日志和版本记录，方便定位是流程改动还是模型变化。
把维护成本写进需求里
低代码并不消灭维护，只是把维护从代码仓库挪到配置、权限和流程说明里。选型或立项时，可以问几个朴素问题：谁负责字段变更，谁能发布上线，配置如何导出和备份，异常数据怎样回滚。这些问题不性感，却决定了半年后系统还能不能改得动。
稳妥的期待，是把它看作企业应用搭建的一种中间层：稳定流程先用配置跑通，复杂逻辑仍交给工程实现，AI 环节则加上复核和记录。它不负责让所有业务人员变成开发者，也不负责替代技术判断；它真正节省的，是那些反复沟通、重复搭建和低价值联调的时间。