低代码起步很快：今天业务提需求，明天管理员搭表单，后天就能用。问题是，两年后表单从 5 张变成 80 张，字段、权限、自动化规则和报表开始互相缠绕。
从 5 张到 80 张，表单开始互相牵连
失控信号很具体：没人知道某个字段能不能删，改一个流程影响三个报表，管理员离职后没人接得住，业务抱怨系统越来越慢，老板要一个新指标却要翻很多表。
根因是把流程表单当成长期业务对象。客户、订单、库存、合同、项目应该稳定存在；如果同一个客户在销售表、合同表、售后表、回访表里各存一份，报表只能依赖管理员手工拼接。
一个简单判断是：新报表需要同时查三张以上表单才能拼出口径，低代码就已经从提效工具变成治理问题。
先冻结新增，再拆三类资产
补救没有立刻废掉低代码。第一步盘点现有表单，第二步冻结新增核心对象表单，第三步把全部资产分为核心对象、流程记录和临时收集。
客户、订单、合同、项目、库存、员工、供应商属于核心对象；审批、变更、验收、付款和巡检是围绕对象发生的流程记录；活动报名、一次性统计和临时调研属于到期应归档的临时收集。
分类完成后，再统一高频字段名称，把成熟稳定的核心对象迁到可维护平台，低代码继续承担轻量流程和临时审批。这样保留灵活性，也避免一刀切迁移带来新的业务中断。
三条治理红线
第一，核心对象不能随便复制，否则客户、订单和库存会出现多套口径。第二，权限规则必须有人负责，不能让每个表单管理员临时添加。第三，新增表单要有退出机制，临时流程到期后归档或合并，不能无限堆积。
低代码适合验证流程、承接轻量审批和快速补洞，但不应替代长期业务架构。核心数据逐步沉淀到稳定平台，成熟流程继续复用，才是可持续边界。
从表单堆叠回到对象模型
治理时先画对象模型，而不是照着旧表单重做页面。核心数据先确定唯一来源，流程围绕对象关联，临时收集则约定失效时间。这样改字段时，才能知道会影响哪些流程和报表。
先冻结新增核心对象，再统一高频字段，最后按业务成熟度迁移。等管理员离职后仍有人看得懂对象关系，系统才算从个人经验回到组织资产。
每张新表单都要写退出方式
新表单上线时，要写清服务哪个业务对象、预计使用多久、到期后归档还是合并。如果一张表单半年后已成为高频核心流程，就重新评估是否产品化；如果只是临时统计，则按约定关闭。
没有退出机制的低代码，最后会把企业带回“系统很多、数据更乱”的状态。治理的目标不是否定低代码，而是让临时灵活性不再侵蚀核心数据。
盘点要把依赖关系一起画出来
表单清单不能只记录名称。要逐张标出它属于哪类对象、是否仍在使用、权限由谁维护、自动化会改哪些数据、哪些报表引用了字段。已停止使用的进入历史归档；仍在运行的，再检查是否复制了客户、订单、合同等核心对象。
遇到同一对象分散在多张表单、字段名又不同，不要先删字段。先统一高频字段和对象归属，再调整流程与报表，最后决定迁移或保留。这个顺序是为了避免改一个流程又牵动三个报表，让后续交接继续依赖原管理员。
