在 ZStack-UI 正式发布版本中，总共有 1800 多个受控的页面元素，叠加5种 license 和11个系统角色，总共最多会有接近 10 万个配置项，如果算上 OEM 定制版，数量只会更多。如果没有低代码开发平台，前端的工作量将是非常恐怖的，系统也处于不可测试的境地。为了方便产品和测试人员进行配置，我们创造性的在 UI 中引入了 Debug 模式，当开启时，UI 中所有的受控元素都会进行标注，鼠标悬浮上去就可以跳转到配置系统进行配置，如下图所示：

所见即所得的配置方式可以让测试人员一边测试，一边修正配置集合，在传统的开发模式，测试需要等待开发修正完，重新打包才能看到修正后的效果，通过配置系统解耦后，大大提升了整体的开发效率。

综上所述，低代码开发对于 ZStack-UI 绝不是锦上添花，而是伴随着项目进展产生的必然需求。另一个典型需求是列表的自定义，我们 UI 中八成以上的界面都是列表，以及针对列表的相关操作，如下图所示：

我们虽然封装了完善的列表组件，可以让开发人员以对象形式定义列表显示的字段，但在实际开发中，由于每个人理解不同，类似列宽、字段顺序、过滤、排序定义的千差万别，不仅造成界面展示的不美观，还会造成功能上的缺失，列表的数据拉取需要编程获得，但列表的具体展示形式则由产品、设计共同维护。

如果以传统的方式解决这个问题，需要借助脑图梳理信息，梳理后需要多方确认，最终再由开发人员进行编码。如果中途变更，还需要同步修改并告知开发人员改动，最后再由测试人员重新测试，这个沟通链路非常长，中间任何一个环节都可能出现信息不同步，对开发人员来说，可能只需要改 1 行代码，却需要反复沟通半天时间。

既然操作的对象是表格，很自然的想到了利用钉钉自带的表格功能，钉钉表格支持多人协同编辑，也可以非常方便的锁定并回溯历史。为了维护构建表格所需的原始数据，我们创建了一个模板，称为字段配置表，如下图所示：

该模板的每一列都有相关的维护角色，由不同的人来维护，同时每列还有一个 key，代码生成引擎会读取行列内容，根据 key 生成相关代码。以云主机为例，填充后的内容如下：

生成后的代码如下（云主机列表生成的代码约800行，只截取片段）